Skip to Content
Infra & DevOpskubectl로 상태·로그·배포 확인하기
☁️ Infra & DevOps2019년 3월 6일

kubectl로 상태·로그·배포 확인하기

#kubernetes#k8s#kubectl#cheatsheet#devops

Kubernetes를 사용하며 적어 둔 kubectl 명령입니다. 원래 메모에는 Cassandra 상태 조회와 CoreDNS ConfigMap 편집, 리소스 생성·수정·삭제 명령이 있었습니다.

조회하는 명령과 실제 상태를 바꾸는 명령을 나눠 정리했습니다. 아래의 example, example-pod, example-web 등은 설명용 이름입니다.

컨텍스트와 조회 범위

bash
kubectl config current-context kubectl get namespaces kubectl get nodes -o wide kubectl get pods -n example -o wide

같은 이름의 리소스가 다른 클러스터나 네임스페이스에 있을 수 있어 대상을 먼저 확인합니다. 전체 네임스페이스의 Pod는 kubectl get pods -A로 조회할 수 있습니다.

Pod 상세 정보와 로그

bash
kubectl describe pod example-pod -n example kubectl logs example-pod -n example --tail=100 kubectl logs example-pod -n example -c app --previous

describe의 이벤트는 스케줄링과 이미지 다운로드, 컨테이너 시작 문제를 확인할 때 도움이 됩니다. --previous는 같은 Pod에서 종료된 이전 컨테이너 인스턴스의 로그를 요청합니다. 이미 삭제된 임의의 Pod 로그를 찾아주는 옵션은 아닙니다.

실시간으로 따라보려면 logs -f를 사용할 수 있습니다. 여러 컨테이너가 있다면 확인할 컨테이너도 지정해야 합니다.

컨테이너 내부 명령 실행

원래 기록에 있던 Cassandra 조회 명령은 다음과 같습니다.

bash
kubectl exec -it cassandra-0 -- nodetool status

이 명령은 해당 Pod에 Cassandra와 nodetool이 있을 때 사용할 수 있습니다. 일반적인 셸 접속 예시는 다음과 같습니다.

bash
kubectl exec -it example-pod -n example -c app -- /bin/sh

컨테이너 이미지에 셸이 없으면 접속할 수 없습니다. exec 권한과 대상 컨테이너의 실행 상태도 확인해야 합니다.

리소스 생성과 변경

bash
kubectl apply -f deployment.yaml -n example kubectl edit deployment example-web -n example kubectl delete -f deployment.yaml -n example

apply는 선언한 구성을 반영하고, edit는 서버의 리소스를 편집합니다. 저장소의 매니페스트와 서버 설정이 따로 바뀌지 않도록 변경 내용을 관리해야 합니다.

원래 메모에는 다음 명령도 있었습니다.

bash
kubectl edit configmap coredns -n kube-system

CoreDNS 변경은 클러스터의 DNS 동작에 영향을 줄 수 있습니다. 일반 애플리케이션 설정을 수정하는 예시처럼 그대로 실행하기보다, 변경할 항목과 적용 방법을 확인해야 합니다.

Deployment 롤아웃 확인

bash
kubectl rollout status deployment/example-web -n example kubectl rollout history deployment/example-web -n example

이전 리비전으로 되돌리는 명령은 다음과 같습니다.

bash
kubectl rollout undo deployment/example-web -n example

이 작업은 Deployment의 Pod 템플릿을 되돌리는 것이며 DB 스키마나 외부 시스템 변경까지 복구하지는 않습니다. 롤아웃이 끝났는지와 실제 요청이 정상인지도 구분해서 확인해야 합니다.

명령을 읽을 때의 주의점

kubectl get all은 이름과 달리 모든 종류의 리소스를 보여주지 않습니다. ConfigMap이나 Secret 등은 필요한 종류를 지정해 조회합니다.

원래 메모에 있던 ServiceAccount Secret 토큰 추출 방식도 현재의 공통 절차로 사용하기 어렵습니다. 자동 토큰 Secret 생성 여부는 버전에 따라 다르며, 권한 확인과 토큰 발급은 Dashboard와 RBAC 글에서 별도로 다룹니다.

참고 자료

Last updated on