[CKA] crictl, journctl 및 명령어 기본 정리

 

 

평소 인프라 환경을 운영하면서 docker나 kubectl은 손에 익을 정도로 자주 사용한다. 하지만 클러스터에 원인 모를 장애가 발생하거나 노드 레벨의 문제가 생겼을 때, 종종 crictl이나 journalctl을 꺼내 들어야 하는 순간들이 온다.

 

자주 쓰지 않다 보니 명령어와 정확한 용도가 헷갈릴 때가 있어,

이번 기회에 두 도구의 명확한 역할과 접근 관점을 회고록 형태로 정리해 둔다.

 

 

---

 

 

1. crictl — 컨테이너 런타임 직접 디버깅

왜 crictl을 사용해야 하는가?

Kubernetes의 명령 처리 구조를 추상화해서 보면 대략 다음과 같은 흐름을 가진다.

 

kubectl → API Server → kubelet → Container Runtime (containerd 등)

 

우리가 평소에 밥 먹듯이 사용하는 kubectl은 이 구조에서 가장 상위 레벨의 도구다. 클러스터가 정상적일 때는 문제가 없지만, 다음과 같은 상황에서는 kubectl만으로 원인을 파악하기 어렵다.

• Pod이 아예 뜨지 않거나(Pending 등) Image Pull에 지속적으로 실패할 때
• 컨테이너가 원인 없이 Crash 루프를 돌 때
• API Server 장애 등으로 kubectl 자체가 정상 동작하지 않을 때

 

 

이럴 때는 kubectl이 아니라, kubelet의 지시를 받아 실제 컨테이너를 구동하는 컨테이너 런타임 레벨로 직접 내려가서 상태를 확인해야 한다.

 

 

crictl ps vs kubectl get pods

얼핏 보면 두 명령어는 비슷해 보인다. 하지만 바라보는 관점과 레이어가 완전히 다르다.

• kubectl get pods: Kubernetes의 추상화된 자원(Pod) 관점
• crictl ps: 실제 노드에서 돌아가고 있는 컨테이너 런타임 관점 (진짜 실행 상태)

 

Kubernetes의 Pod 안에는 여러 개의 컨테이너가 들어갈 수 있다. kubectl은 이 묶음(Pod)을 기준으로 상태를 보여주지만, crictl은 노드 내부에 있는 각각의 실제 컨테이너 단위로 상태를 추적한다. 즉, kubectl로 보이지 않는 노드 내부의 실제 상태를 뜯어볼 때 사용한다.

 

 

기본 사용법

K3s 환경 등에서 containerd 소켓을 직접 지정하여 상태를 확인할 수 있다.

# 노드 내 실행 중인 컨테이너 목록 확인
sudo crictl --runtime-endpoint unix:///run/k3s/containerd/containerd.sock ps

# 특정 컨테이너의 상세 상태 및 로그 확인
sudo crictl inspect <container_id>

---

 

 

2. journalctl — 노드 및 서비스 레벨 로그 확인

왜 journalctl을 사용해야 하는가?

 

 

crictl이 컨테이너 런타임 레벨의 문제를 잡는다면, journalctl은 "kubectl도, crictl도 알려주지 않는 노드 자체의 에러"를 보기 위해 사용한다.

 

Kubernetes를 구성하는 핵심 컴포넌트들(kubelet, containerd 등)은 결국 Host OS 위에서 돌아가는 systemd 백그라운드 서비스들이다. 따라서 이 서비스들 자체에 문제가 생기면 클러스터 내부 도구로는 원인을 찾을 수 없다.

다음과 같은 상황에서 주로 사용한다.

• kubectl get nodes 결과가 이유 없이 NotReady 상태일 때
• 노드의 리소스 문제로 Pod이 영문도 모르게 죽거나 Evicted 될 때
• kubelet 프로세스 자체가 정상적으로 동작하지 않는 것 같을 때

기본 사용법

OS 레벨에서 kubelet 서비스가 뱉어내는 로그를 확인하여 근본적인 시스템 에러를 추적한다.

# kubelet 서비스의 전체 로그 확인
sudo journalctl -u kubelet

# kubelet 서비스 로그 실시간(tail) 확인
sudo journalctl -u kubelet -f

 

3. 전체 요약 및 회고

장애 상황에 따라 어느 레이어부터 확인해야 할지 명확히 하기 위해 표로 정리해 둔다.

상황 / 확인 목적	사용하는 도구	바라보는 관점
클러스터 및 리소스의 전반적인 상태 확인	kubectl	Kubernetes (Pod 단위)
컨테이너의 실제 구동 상태 및 런타임 에러	crictl	Container Runtime (컨테이너 단위)
노드 자체, OS, 백그라운드 서비스 에러	journalctl	Host OS (systemd 서비스 단위)

 

 

처음에는 crictl의 명령어들이 kubectl과 너무 비슷해 보여서 굳이 이걸 왜 따로 써야 하나 의문이 들었다.

 

하지만 시스템이 어떻게 맞물려 돌아가는지 레이어(Layer)의 차이를 이해하고 나니 각 도구의 용도가 명확해졌다.

 

 

문제가 발생했을 때 상위 레이어에서 답을 찾을 수 없다면,

망설이지 말고 추상화를 걷어내고 한 단계 아래의 레이어를 파헤쳐야 한다.