쿠버네티스 운영
이 문서는 쿠버네티스와 클러스터에 배포된 워크로드들의 상태를 확인하고 문제가 있을 시 트러블슈팅하는 데 도움이 될만한 정보를 기술하고 있다.
kubectl
kubectl은 쿠버네티스 클러스터에 각종 커맨드를 실행하기 위한 커맨드라인 인터페이스로, 쿠버네티스 클러스터에 배포된 워크로드들의 상태를 조회하고 운영하기 위해 가장 기본적으로 필요한 툴이다. 기본적인 사용법은 공식문서를 참고하면 되고, 사내 EKS 클러스터 접속을 위한 kubectl 설정 가이드를 참고해 EKS 클러스터에 대한 세팅을 할 수 있다. kubectl은 go 클라이언트에 기반하고 있는데, 해당 라이브러리를 이용하면 손쉽게 커스텀한 클라이언트 프로그램을 작성할 수 있다.
oh-my-zsh plugin
kubectl 사용이 익숙해졌다면 oh-my-zsh의 kubectl 플러그인을 이용해 커맨드 에일리어스 및 자동완성을 이용할 수 있다. 특히 레플리카셋, 파드 이름 등은 해당 자원을 관리하는 디플로이먼트, 잡 등의 이름에 기반하여 랜덤하게 부여되므로 자동완성 기능이 있으면 매우 편리하게 운영과 관련된 작업을 할 수 있다.
krew(kubectl 플러그인 매니저)
krew는 kubectl 플러그인을 위한 패키지 매니저다. 파드(Pod) 재시작 플러그인처럼 kubectl에서 기본적으로 지원하지 않는 확장 기능이 다수 제공되므로 확인해볼 것을 권장한다.
kubectx
kubectx + kubens 는 간편하게 클러스터나 네임스페이스 컨텍스트를 전환할 수 있도록 도와주는 유틸리티이다. 여러 클러스터를 관리하거나 네임스페이스를 오가며 작업할 때 유용하다.
현재 버즈빌에서는 서비스별로 네임스페이스를 할당하고, 개별 사용자의 접근제어도 네임스페이스 단위로 이뤄지기 때문에 kubens postbacksvc 와 같은 커맨드로 본인이 작업할 네임스페이스로 컨텍스트를 전환하는 것이 권장된다.
여러 컨텍스트를 옮겨다니며 작업하는 경우 리소스를 잘못 변경하는 경우가 생길 수 있다. kube-ps1을 이용하면 커맨드 프롬프트에 현재 context(cluster, namespace) 정보를 출력되기 때문에 실수의 여지가 줄어든다.
파드 상태 조회하기
파드(Pod)는 쿠버네티스에서 하나 또는 그 이상의 연관된 컨테이너가 배포되는 기본적인 단위이다. 연관된 컨테이너라 함은 메인이 되는 컨테이너(주로 애플리케이션 컨테이너)를 보조해 메트릭을 외부 저장장치로 전송하거나, nginx와 같은 리버스 프록시가 함께 묶여 스케쥴링이 되는 사이드카 패턴을 의미한다. 횡적인 확장을 위해 컨테이너가 추가적으로 필요한 경우 파드에 컨테이너를 추가적으로 정의하는 것이 아니라 파드의 개수를 늘리는 방향으로 확장한다.
애플리케이션 상태를 확인하기 위해 가장 먼저 하게 되는 일은 주로 파드의 상태를 확인하는 것이다. 파드가 재시작되고 있지 않는지, 노드에 잘 스케쥴링 되었는지, 리소스(CPU 및 메모리 자원)는 어느정도 할당되었고 현재 사용하고 있는지 등을 확인할 수 있다. 리소스 할당은 특히나 중요한데, 리소스의 요청량(requests) 및 한도(limits)에 의해 파드가 어떻게 스케쥴링 될지, 과도한 리소스가 요구될 시 해당 컨테이너에 CPU를 더 스케쥴링할지, OOM Kill을 할 지 등이 결정되기 때문이다.
kubectl 이용
파드의 상태를 조회하는 가장 기본적인 방법은 kubectl을 이용하는 방법이다.
# 파드 상태 확인
# READY: 파드에 정의된 컨테이너 중 몇 개의 컨테이너가 준비되었는지 확인할 수 있다.
# STATUS: 모든 컨테이너가 잘 동작하고 있으면 Running. 다른 상태에 대한 설명은 https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase 참고
# RESTARTS: 파드가 총 몇 회 재시작되었는지를 나타낸다. livenessProbe 실패 시, 혹은 메인 커멘드가 종료될 시 쿠버네티스는 파드를 재시작한다.
$ kubectl get pods
> NAME READY STATUS RESTARTS AGE
buzzscreen-api-dev-7cc4c6b6b9-4rnq8 3/3 Running 2 7d8h
buzzscreen-api-dev-7cc4c6b6b9-wh8bk 3/3 Running 1 7d20h
buzzscreen-api-prod-68f4494fdd-6tz8j 3/3 Running 1 46m
buzzscreen-api-prod-68f4494fdd-czpvt 0/3 Init:0/1 0 2s
# 파드 리소스 사용량 확인
# CPU: 1 == 1000m == 1코어
$ kubectl top pods
> NAME CPU(cores) MEMORY(bytes)
buzzscreen-api-dev-7cc4c6b6b9-4rnq8 4m 119Mi
buzzscreen-api-dev-7cc4c6b6b9-wh8bk 4m 123Mi
buzzscreen-api-prod-68f4494fdd-6tz8j 3m 123Mi
buzzscreen-api-prod-68f4494fdd-8vrxg 68m 110Mi
스피네커 이용하기
커맨드라인 인터페이스 없이도 스피네커 UI의 Infrastructure - Clusters 메뉴에서 배포된 디플로이먼트에 속한 파드의 상태 확인 및 간단한 로그 조회 등을 할 수 있다.
Newrelic Infrastructure
Newrelic Infrastructure의 쿠버네티스 연동을 통해 클러스터의 노드나 파드 등에 대한 상태를 GUI로 손쉽게 확인할 수 있다. 노드의 스토리지, 개별 파드의 리소스 사용량 및 잦은 재시작 등에 대한 현황을 확인하고 얼럿을 설정할 수 있다.
Log 조회
컨테이너 워크로드는 로그스트림을 STDOUT, STDERR로 출력하는 것을 기본으로 한다. 개별 컨테이너에서 로그 저장이나 관리를 담당하지 않고 클러스터 레벨에서 한번에 하기 위함이다. 이렇게 출력한 로그를 조회하는 방법은 다음과 같다.
kubectl logs
가장 기본적인 방법으로, kubectl logs 커맨드를 사용할 수 있다. 이 커맨드는 개별 파드에 대한 조회가 가능하며 -f, --follow 옵션을 이용해 테일을 할 수 있다.
# POD_NAME에 해당하는 파드를 출력. 선택적으로 CONTAINER_NAME에 해당하는 컨테이너의 로그만 출력 가능.
$ kubectl logs -f POD_NAME -c CONTAINER_NAME
# 특정 label에 매칭되는 여러 파드의 로그를 출력. 하나의 파드에 여러 컨테이너가 존재할 경우 컨테이너 옵션이 필수이다.
$ kubectl logs -l LABEL=value -c CONTAINER_NAME
stern
kubectl은 조회할 파드를 식별해야 하기에 빠르게 여러 파드의 로그를 조회하기에 불편하다. stern을 이용하면 파드 이름을 쿼리하여 매칭되는 여러 파드의 로그를 실시간으로 테일을 할 수 있으며, --since TIME 옵션을 이용해 특정 시점부터의 로그를 손쉽게 조회하는 것이 가능하다.
# buzzscreen-prod이 들어간 모든 파드의 1분 이내의 로그 조회
$ stern buzzscreen --since 1m
파드의 이름을 쿼리 기반으로 검색할 수 있기 때문에, stern과 grep을 잘 활용하면 kubectl logs보다 훨씬 편리하게 로그를 확인할 수 있다. bash나 zsh 자동완성도 제공하니 활용하는 것을 권장한다.
kibana
kubectl이나 stern은 파드가 삭제되면 이전의 로그를 조회할 수 없기에 클러스터 레벨에서 STDOUT으로 출력된 로그를 별도의 ElasticSearch로 저장하고 있다. 로그 조회는 kibana를 이용해 할 수 있고, 각종 쿼리를 이용해 조회하는 범위를 좁혀나갈 수 있어 유용하다.
Rollback
TBD
Grafana
TBD