[Kubernetes] 파드(Pod) 디버깅하는 방법

 

쿠버네티스로 애플리케이션을 운영, 관리하다보면 대부분의 문제는 파드에서 발생한다.

 

유지/보수 관점에서는 대부분의 시간을 결국 파드에서 발생하는 문제를 해결하는데 써야하는데, 이를 디버깅하는 방법을 알아둘 필요가 있다.

---

파드(Pod)가 정상적으로 실행되지 않았을 때

 

보통 파드 관련 문제는

파드 실행 이전, 파드 실행 이후 파드 내부 컨테이너가 죽거나 에러가 발생하는 경우 두 가지로 나뉠 수 있다.

 

파드 실행 이전 단계에서 문제가 터지면, 파드 자체에 접속하는 것도 불가능하다.

 

redis-pod.yaml

apiVersion: v1
kind: Pod

metadata:
  name: redis-pod

spec:
  containers:
    - name: redis-container
      image: redis:v1234
      ports:
        - containerPort: 6379

 

예시로, 위와 같이 매니페스트 파일을 작성하고 파드를 생성해보도록 하겠다.

image의 redis:v1234 는 실제 존재하지 않는 도커 이미지이고, 실제 docker hub 레지스트리에도 존재하지 않는다.

 

kubectl apply -f redis-pod.yaml

 

이 명령을 실행하면 redis-pod 파드 생성을 시도한다.

kubectl get pods

 

1차적으로 파드가 제대로 실행됐는 지 확인하려면

kubectl get pod(또는 pods) 명령을 통해 파드 목록을 조회해보면 된다.

파드 생성에 실패했다면 STATUS 를 통해 간단한 상태 정보를 확인할 수 있다.

 

여기서 STATUS 를 보면 ErrImagePull 이라고, 이미지 풀링에 실패했다는 메시지가 나타난다. 뭔가 이미지 풀링에 실패했다는 것을 위 메시지만 보고 추측은 할 수 있다.

 

하지만 이런 정보만 가지고 뭐가 문제인지 알기 힘들 수 있다.

 

# kubectl describe pods [파드명]
$ kubectl describe pods redis-pod # redis-pod 파드의 세부 정보 조회

 

더 상세한 정보를 확인하고 싶은 경우  kubectl describe pods 명령을 사용하면 파드의 상세 정보를 조회할 수 있는데, 여기서 Events 쪽에서 좀 더 상세한 로그를 확인할 수 있다.

 

실행 과정에서 이미지 풀링을 시도했고, 이미지를 찾지 못 했다는 메시지를 출력한다.

redis:v1234 이미지를 찾지 못 했다는 메시지를 볼 수 있다.

 

이런 메시지를 읽어서, 문제를 해결을 위해 참고할 수 있을 것이다.

---

파드(Pod)의 로그를 확인하고 싶을 때

파드는 정상적으로 실행됐는데 내부에서 컨테이너를 실행하는 과정에서 문제가 터졌을 수도 있고, 컨테이너가 잘 작동하다가 도중에 예상치 못한 이유로 죽는 경우도 존재한다.

 

혹은 파드가 지금 잘 작동하는데 파드 내부의 프로세스가 잘 동작하는 지 확인해보고 싶을 수 있다.

일단 파드 내부에서 애플리케이션이 잘 작동하는 지 로그를 확인해보는 법을 알아보자.

apiVersion: v1
kind: Pod

metadata:
  name: redis-pod

spec:
  containers:
    - name: redis-container
      image: redis:7.4.2 # 실제 존재하는 태그의 redis 이미지
      ports:
        - containerPort: 6379

 

이전에 작성했던 redis-pod.yaml 파일에서, redis 의 태그명을 7.4.2 로 바꿔보았다.

 

별도로 ImagePullPolicy 를 작성하지 않았고 이미지 태그를 구체적으로 지정했기 때문에 IfNotPresent 이미지 풀 정책이 적용된다.

 

로컬에서 이미지가 존재하는 지 먼저 확인하고, 존재 하지 않는다면 레지스트리를 통해 이미지를 조회해온다. DockerHub 의 redis 이미지가 가져와지고, 7.4.2 버전이 가져와져서 파드가 실행될 것이다.

 

kubectl delete pod redis-pod
kubectl apply -f redis-pod.yaml

 

기존에 잘못 만들었던 redis-pod 를 제거하고, 다시 redis-pod.yaml 파일을 통해 파드를 생성해보자.

 

kubectl get pod

 

 

kubectl get pod 명령을 사용하면, 파드가 잘 실행됐는 지 1차적으로 목록을 통해 확인할 수 있다.

 

 

# kubectl logs [파드명]
$ kubectl logs redis-pod

 

여기서 redis-pod 내부의 로그를 확인하려면 위 명령을 입력하면 된다.

 

 

실제 파드 내부에서 출력되는 로그를 확인할 수 있는데, redis 컨테이너의 메시지가 출력되는 것을 볼 수 있다.

---

파드(Pod)에 접속하고 싶을 때

# kubectl exec -it [파드명] -- bash
$ kubectl exec -it nginx-pod -- bash

# kubectl exec -it [파드명] -- sh
$ kubectl exec -it nginx-pod -- sh

 

이것은 지난번 글들에서도 몇 번 다뤘던 방식이다.

쿠버네티스 파드에 직접 쉘을 통해 접속하는 방법이다.

 

컨테이너 사양에 따라 bash/ shell 로 사용할 수 있는 쉘이 다를 수 있다. 어느 한쪽이 안 되면 반대쪽 명령을 입력해서 접속하면 된다.

 

---

놓쳤던 맹점 : 사실 위의 명령을 통해 접근한 것들은 파드가 아니라 파드 내부의 컨테이너

 

 

그런데 나는 redis-pod 에 bash 명령을 통해 접속했는데, 들어온 창에서 바로 바로 redis-cli 를 통해 레디스 명령줄로 넘어간 것을 알 수 있다.

 

내가 들어왔다고 생각한 것은 redis-pod 인줄 알았는데, 사실 redis-pod 안에 위치한 redis-container 였던 것이다.

# kubectl exec -it [파드명] -c 컨테이너명 -- bash
# kubectl exec -it [파드명] -c 컨테이너명 -- sh
kubectl exec -it my-pod -c main-container -- bash

 

이것이 왜 그런지 궁금해서, 쿠버네티스 공식문서의 Get a Shell to a Running Container 문서를 확인했는데, 이 문서에서 말한 바에 따르면 사실 exec -it 명령은 파드의 컨테이너에 접속하는 명령이였던 것이다.

 

-c 옵션을 제외할 경우 먼저 선언된 컨테이너에 접속하게 된다.

파드 내에 컨테이너가 두 개 이상 존재하는데 원해는 컨테이너에 접속하고 싶은 경우 -c 옵션을 통해 구체적인 컨테이너도 지정해서 접속해야한다.

 

kubectl logs 명령 역시, 컨테이너 옵션을 생략할 경우 첫번째 컨테이너에 대한 로그를 조회하는 명령이였다.

파드 내에 컨테이너가 두개 이상 있을 경우 'kubectl logs -c 컨테이너명' 을 통해 컨테이너를 지정해야한다.

그런데 파드 내에 컨테이너 두 개를 지정하는 경우는 일반적이지 않은 경우이므로 이 명령을 쓸 일은 그렇게 많지 않을 듯 하다.

---

 

[참고자료]

[Inflearn 강의] 비전공자도 이해할 수 있는 쿠버네티스 입문/실전

 

---