파드 정보 확인 명령어 정리
kubectl get pods 현재 생성된 파드 정보들 *전부 출력
kubectl get pod hello-dockerhello-docker라는 이름을 가진 파드에 대한 정보 출력
저번시간에 기본적으로 이러한 명령어를 쓰는 게시글을 작성했어는데, 상세 정보 중 특정한 항목을 따로 지정해서 출력할 수 있다.
kubectl get pod hello-docker --output=custom-columns="NAME:.metadata.name,NODE_IP:.status.hostIP,POD_IP:.status.podIP"이와 같이 출력하면 다음과 같이 나온다.
특정 항목 출력 방법
--output=custom-columns
: 원하는 열(column)을 직접 지정해 출력하는 옵션
"NAME:.metadata.name,NODE_IP:.status.hostIP,POD_IP:.status.podIP"
: 각 항목을 컬럼명:필드경로 형식으로 작성
(데이터베이스에서 AS로 별칭 주는 것과 유사하다.)
- .metadata.name : 파드 이름
- .status.hostIP : 노드 IP
- .status.podIP : 파드 IP
| 컬럼명 | 필드 경로 | 설명 |
| -------- | ------------------ | -------------------- |
| NAME | `.metadata.name` | 파드 이름 |
| NODE_IP | `.status.hostIP` | 파드가 실행 중인 노드의 IP |
| POD_IP | `.status.podIP` | 파드 자체의 IP |
자주 쓰이는 파드 필드 경로 정리
항목 필드 경로 설명 파드 이름 .metadata.name파드의 이름 네임스페이스 .metadata.namespace파드가 속한 네임스페이스 노드 이름 .spec.nodeName파드가 스케줄링된 노드 이름 노드 IP .status.hostIP파드가 동작 중인 노드의 IP 파드 IP .status.podIP파드 자체의 IP 주소 상태 .status.phase파드의 현재 상태 (Pending, Running, Succeeded 등) 재시작 횟수 .status.containerStatuses[*].restartCount파드 내 각 컨테이너의 재시작 횟수 컨테이너 이름 .spec.containers[*].name파드 내 컨테이너 이름 목록 컨테이너 이미지 .spec.containers[*].image파드에서 사용하는 이미지 이름 시작 시간 .status.startTime파드가 시작된 시각 QoS 클래스 .status.qosClass파드의 QoS 클래스 (BestEffort, Burstable, Guaranteed) 오너 리소스 .metadata.ownerReferences[*].kind파드를 생성한 리소스 종류 (예: ReplicaSet, Deployment 등) 레이블 .metadata.labels파드에 설정된 레이블(key=value) 어노테이션 .metadata.annotations파드에 설정된 어노테이션 이 필드 경로들은 실제로
kubectl get pod <파드이름> -o yaml명령어로 확인되는 YAML 구조의 key를 그대로 따온 것이다.
따라서 다른 리소스들에도 동일한 방식으로 적용할 수 있다.
JSONPath로 복잡한 출력하기
--output=jsonpath 옵션을 사용하면, 쿠버네티스 리소스의 특정 필드 값만 정확히 추출할 수 있다.
단순히 커스텀 컬럼을 지정하는 것보다 훨씬 정교한 정보 조회가 가능하다.
예를 들어, 파드의 첫 번째 컨테이너의 컨테이너 ID 를 출력하고 싶다면 아래와 같이 입력한다.
kubectl get pod hello-docker -o jsonpath='{.status.containerStatuses[0].containerID}'
이 명령어를 실행하면 다음과 같이 첫번째 컨테이너의 컨테이너ID가 반환이 된다.
JSONPath 특징
- 배열(List) 형태 데이터 접근 가능 → [0], [1], [*] 등 인덱스로 지정 가능
- 필드 접근 → .status, .metadata.name 등 점(.) 표기법 사용
- 여러 값 동시 조회 → 쉼표(,)로 구분하여 여러 필드를 동시에 출력 가능
- 출력 포맷 조정 → '{'와 '}'로 문자열 내 JSON 구조를 유지 가능
파드와 컨테이너의 실제 관계 확인하기
앞서 게시물에 썼듯, 쿠버네티스는 컨테이너를 직접 실행하지 않으며, 컨테이너를 직접 띄우는 것은
컨테이너 런타임인 도커이다.
즉, 파드 안의 컨테이너는 도커 엔진 위에서 동작하며 쿠버네티스는 그 컨테이너를 참조하여 관리한다.
이 관계를 확인하기 위해 다음 명령어를 통해 직접 조회해볼 수 있다.
# 파드에 포함된 컨테이너 찾기
#해당 컨테이너 삭제하기
docker container rm -f (docker container ls -q --filter label=io.kubernetes.container.name=hello-docker)
# 파드 상태 확인
kubectl get pod hello-docker
위 과정을 실행해보면 도커에서 컨테이너를 삭제해도, 쿠버네티스가 파드를 감시하고 자동으로 복구하는 것을 볼 수 있다. 따라서 이 명령어를 통해 쿠버네티스가 컨테이너의 실제 실행은 도커에게 맡기지만, 상태 관리는 직접 한다는 것을 볼 수 있다.
이렇게 hello-docker 라는 컨테이너가 삭제 전과 후의 아이디가 바뀐 것을 확인 할 수 있으며
이전 컨테이너를 확인하기 위해
docker ps -a | grep b545c4324b1b명령어를 통해 이전 컨테이너의 상태를 확인해보기로 했다.
이렇게 과거 삭제시켰던 컨테이너의 ID를 사용해서 찾아도 찾을 수 없음을 확인할 수 있다.
docker inspect b545c4324b1b참고로 이 명령어의 inspect라는 명령어는, 컨테이너가 완전히 삭제되지 않았을 경우
실행 시점, 이미지, 환경변수, 라벨 등 세부 정보를 확인할 수 있는 명령어이다.
현재 삭제되지 않은 컨테이너의 아이디를 통해서 보면 다음과 같이 보인다.
다음과 같이 컨테이너의 많은 정보들을 확인할 수 있다.
정리
결론
쿠버네티스가 컨테이너를 직접 복원할 수 있었던 이유는
컨테이너를 파드(Pod) 라는 상위 개념으로 추상화했기 때문이다.
도커 컨테이너가 삭제되더라도, 쿠버네티스는 파드 자체를 기준으로 상태를 관리한다.
따라서 문제가 생긴 컨테이너는 단지 “일시적”일 뿐이며,
쿠버네티스는 파드 정의를 바탕으로 새로운 컨테이너를 만들어낸다.
이처럼 파드 수준에서 컨테이너를 추상화하고 관리하는 구조 덕분에
쿠버네티스는 애플리케이션의 자가 복구(Self-Healing) 기능을 구현할 수 있다.
즉, 파드 위의 추상화 계층을 통해 시스템은 더 높은 복원력을 가질 수 있다.
이 과정을 정리하면서 도커& 쿠버네티스 & 파드 & 컨테이너의 관계가 너무 헷갈렸다
파드 안에 컨테이너가 있고, 쿠버네티스가 컨테이너를 관리하는 주체인데,
도커는 컨테이너를 실행한다니 하고 머리가 복잡했는데 정확하게 개념을 잡았다.
계층 역할 관리 대상 주요 책임 쿠버네티스(API Server, Controller 등) 전체 클러스터의 상태 관리 및 오케스트레이션 파드 파드 생성·삭제·스케줄링, 상태 감시, 복구(Self-healing) 파드(Pod) 컨테이너의 논리적 묶음 (실행 단위) 컨테이너 네트워크(IP)·스토리지 볼륨 공유, 컨테이너 간 통신 및 실행 환경 정의 kubelet (쿠버네티스 노드 에이전트) 노드 단위 파드 관리 컨테이너 런타임(Docker 등) 파드 명세에 따라 런타임에 컨테이너 실행 요청 도커(containerd 등) 컨테이너 실행을 실제로 담당하는 런타임 컨테이너 이미지 다운로드, 컨테이너 생성·실행·삭제, 네트워크 연결 컨테이너(Container) 애플리케이션의 실제 실행 단위 없음 Nginx, Redis 등 실제 애플리케이션 프로세스 실행
이 개념을 잡는데 오랜 기간이 걸렸던 것 같고 매우 헷갈려서 자주 혼동됐던 것 같다.
요약하자면,
쿠버네티스는 파드를 관리하고,
파드는 컨테이너들을 묶어서 관리하며,
kubelet은 그 명세대로 도커에게 컨테이너 실행을 요청하고,
도커는 실제로 컨테이너를 실행한다.
