[Kubernetes] kubectl 기본 명령어

클러스터와 대화하는 방법에 대해 알아봅시다.
쿠버네티스 API 서버는 REST API로 통신을 합니다.
사용자가 직접 HTTP프로토콜로 API 서버와 통신할 수도 있지만 쿠버네티스는 쉽게 마스터와 통신 할 수 있게 해주는 클라이언트 툴인 kubectl을 제공합니다.

 

기본 명령

쿠버네티스는 기본적으로 도커 컨테이너와 마찬가지로 컨테이너의 실행과 삭제, 조회 등을 할 수 있습니다.

 

컨테이너 실행

kubectl run <NAME> --image <IMAGE>

 

mynginx라는 이름의 컨테이너를 nginx라는 이미지로 생성하는 명령어입니다.

 

컨테이너 조회

kubectl get pod

 

 

위와같이 뜬다면 정상 실행이 된 것입니다.

 

근데 왜 kubectl get container가 아닌 get pod일까?

pod는 도대체 뭔데?

간단히 설명하자면 쿠버네티스에서 프로세스를 실행할 때 단순히 컨테이너를 사용하지 않고 Pod라는 리소스를 사용합니다.

(쿠버네티스의 실행 최소 단위는 Pod)

일단 지금은 컨테이너와 Pod가 같다고 이해해도 무방하다합니다.

다만, 컨테이너라고 표현한 부분이 전부 Pod를 의미하는 거라고 기업하면 됩니다.

 

위 명령어에서 STATUS 속성은 Pod의 상태 정보를 나타내는데 상태의 종류는 아래와 같습니다.

• Pending - 마스터에 명령 전달은 됐지만 아직 실행 전
• ContinerCreating - 특정 노드에 스케줄링되어 컨테이너 생성 중인 단계 (이미지 다운로드 등)
• Running - Pod가 정상적으로 실행되고 있는 상태
• Completed - 배치작업 Pod에서 작업이 완료된 상태
• Error - 문제가 생겨 에러가 발생한 상태
• CrashLoopBackOff - 지속적인 에러로 crash가 반복되는 상태 -> 죽으니까 쿠버가 계속 띄워보려다가 실패해서 재시작 무한루프에 빠진 상태

참고) 배치작업 예시

쿠버네티스에서 Job 리소스는 “한 번 돌고 끝나는 작업”을 실행할 때 사용합니다
즉, 서비스처럼 계속 실행되는 Pod (Deployment) 와는 다르게, Job은 끝나면 상태가 Completed 가 되지요.

• DB 마이그레이션 스크립트 실행 (python migrate.py)
• 매일 새벽 3시에 로그 정리 (CronJob으로 스케줄링)
• 카프카 메시지를 받아서 특정 배치 처리를 수행 (예: 대량 데이터 insert, 통계 집계)
• 이미지/영상 한 번 변환 후 종료 (예: 썸네일 생성)
• 데이터 백업 (S3 업로드 후 끝냄)

 “카프카 트리거로 DB insert” 같은 것도 적절
다만 보통 카프카 Consumer는 끊임없이 메시지를 소비하니까 Deployment 로 두는 경우가 많고,
“특정 기간 모아둔 메시지를 한 번에 처리” 하는 식이라면 Job으로 볼 수 있지요.

 

Pod의 정보를 더 자세히(PodIP, nodeName등) 보고싶다면 -o yaml 옵션을 사용하면 된다.

 

또 간단히 Pod의 IP를 바로 확인하려면 -o wide 옵션을 사용 할 수 있다.

 

컨테이너 상세 정보 확인

kubectl describe pod <NAME>

위 명령어도 get 명령어와 유사하게 Pod의 상태 정보를 나타냅니다.

차이점은 Events 기록까지 확인 할 수 있습니다.

문제 발생시 get과 함께 디버깅 용도로 자주 사용되지요.

 

컨테이너 로깅

kubectl logs <NAME>​

컨테이너의 로그 정보를 볼 수 있고 -f, --follow 옵션으로 지속 출력이 간능하게 합니다.

 

컨테이너 명령 전달

kubectl exec <NAME> -- <CMD>

 

docker exec 명령과 유사한데 명령을 전달 할 때 구분자로 전달 명령을 구분합니다.

 

도커와 마찬가지로 -it 옵션으로 내부 진입이 가능합니다.

 

컨테이너 / 호스트간 파일 복사

kubectl cp <TARGET> <SOURCE>

 

컨테이너에서 호스트로 혹은 반대로 파일을 복사할 때 사용합니다.

 

컨테이너 정보 수정

kubectl edit pod <NAME>

 

실행된 컨테이너의 정보를 수정합니다.

kubectl get pod <NAME> -o yaml에서 살펴본 내용과 동일한 구조가 vi로 켜집니다.

이를 수정하면 실제 컨테이너에 반영됩니다.

 

위 명령어로 hello: world라는 라벨 추가 후 상세 조회를 하니 추가된 것을 볼 수 있습니다.

 

컨테이너 삭제

kubectl delete pod <NAME>

 

생성한 컨테이너를 삭제할 수 있습니다.

 

YAML(선언형 명령 정의서) 기반의 컨테이너 생성

kubectl apply -f <FILE_NAME>

쿠버네티스는 선언형 명령을 지향합니다.

선언형 명령 정의서 YAML을 기반으로 명령을 실행하는 방법을 살펴봅시다.

 

아래와 같이 YAML 파일을 생성합니다.

apiVersion: v1
kind: Pod
metadata:
  name: mynginx
spec:
  containers: 
  - name: mynginx
    image: nginx​

 

전에 본 상세정보 조회 내용과 다르게 많이 간소화 됐지만 위처럼 기본이 되는 정보만 채우면 쿠버네티스가 알아서 나머지 값을 채웁니다.

 

kubctl apply -f mynginx.yaml로 파드를 실행시키면

 

아래와같이 동일하게 mynginx라는 컨테이너가 생성되는 것을 확인할 수 있습니다.

 

apply를 사용하면 로컬 파일 뿐만 아니라 인터넷에 잇는 YAML 정의서도 쉽게 가져다 쓸 수 있지요

생성한 mynginx.yaml 파일을 수정하고 apply를 다시 진행하면 새로 컨테이너가 생성되는 것이 아닌 기존 컨테이너의 설정값이 수정됩니다.

apply라는 선언형 명령은 멱등성을 보장해 여러번 실행해도 항상 YAML정의서에 선언된 내용과 동일한 결과를 얻을 수 있습니다.