트러블슈팅

1.  ImagePullBackOff

1.1  철자 오류 또는 이미지 태그 오류

이미지 이름 또는 이미지 태그를 잘못 기입해서 컨테이너 이미지를 찾을 수 없는 경우, 이미지 철자를 고쳐서 *.yaml 파일을 재작성하면 파드를 정상적으로 동작시킬 수 있습니다. 파드의 경우 파드를 삭제한 후 다시 파드를 재생성 해주어야 합니다.

 

1.2  권한 오류

 

사설 저장소에서 이미지를 가져와야 할 때 해당 저장소에 접근 권한이 없는 경우 오류가 발생할 수 있습니다. 이를 해결할 수 있는 여러가지 방법이 있는데 가장 간단한 해결 방법에 대해 알아보겠습니다. 그것은 ImagePullSecret을 생성하여 파드에 할당하는 것입니다. ImagePullSecret을 사용하면 파드가 이미지를 가져올 때 필요한 인증 정보를 제공할 수 있습니다.

 

아래와 같이 docker-registry 유형의 시크릿을 생성해줍니다.

kubectl create secret docker-registry <secret-name> \
  --docker-server=<registry-url> \
  --docker-username=<username> \
  --docker-password=<password> \
  --docker-email=<email>

 

이후 imagePullSecrets 필드에 이름을 할당 후 기존 파드를 삭제 후 새로운 파드를 생성해 줍니다.

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  containers:
  - name: example-container
    image: <registry-url>/<image-name>:<tag>
  imagePullSecrets:
  - name: <secret-name>

 

정상적으로 파드가 시작된 것을 볼 수 있습니다.

 

1.3  호스트 오류

클러스터가 호스트에 대한 도메인을 찾을 수 없는 경우에 해당합니다. nslookup 명령어를 통해 도메인을 찾을 수 없을 때 발생할 수 있는 오류에 해당합니다. 따라서 유효한 호스트 도메인을 입력하는 것으로써 문제를 해결할 수 있습니다.

 

2.  CrashLoopBackOff

해당 오류는 파드 내 컨테이너가 시작했지만 어떤 이유로 인해 컨테이너가 재시작하는 루프에 빠진 상황을 일컫습니다. 그로 인해 Restart한 횟수가 계속해서 올라가는 특징을 갖고 있습니다. 파드에 대한 restartPolicy를 설정하지 않을 경우 Always로 설정이됩니다. 이것이 의미하는 것은 컨테이너가 종료되면 다시 컨테이너를 시작하는 것이 특징입니다. Never이라는 값도 줄 수 있는데 해당 값을 줄 경우 컨테이너가 종료되면 다시 컨테이너를 시작하지 않는 것을 의미합니다.

 

2.1  애플리케이션 에러로 인한 에러

아래는 CrashLoopBackOff가 발생한 파드에 대한 상태를 보여줍니다. 여기서 Exit Code가 1일 때 애플리케이션 쪽에 문제가 발생했다는 것을 의미합니다. 그래서 애플리케이션의 로그를 통해 해당 오류를 확인하는 것이 좋습니다.

 

2.2  컨테이너 내 파일 실행 권한이 없어 발생하는 오류

 

위와 같은 오류는 컨테이너 내에서 script.sh를 실행시켰을 때 해당 스크립트를 실행시킬 수 있는 권한이 없을 때 발생합니다. 따라서 해당 컨테이너로 접속해 실행 파일에 대한 권한을 부여하는 것으로 문제를 해결할 수 있습니다.

 

2.3  컨테이너가 동작하기 위해 필요한 메모리보다 적은 메모리가 할당된 경우

 

OOMKilled(Out Of Memory Killed) 오류가 발생하는 이유는 컨테이너가 동작하기 위해 필요한 메모리보다 최대 메모리 리밋이 작은 경우 발생합니다. 따라서 *.yaml 파일 설정에서 메모리 한계치를 높이면 위 오류를 해결할 수 있습니다. 아래는 리소스 관련 부문이고 limits을 기존 값보다 올려서 설정해서 해당 문제를 해결합니다.

    spec:
      containers:
      - name: memory-limited-container
        image: nginx:latest
        resources:
          requests:
            memory: "256Mi"      # 기본적으로 보장받는 메모리 양
          limits:
            memory: "512Mi"      # 최대 사용할 수 있는 메모리 양

 

2.4  Kill 신호로 인해 컨테이너가 중단된 경우

 

 종료 코드가 137인 경우 Kill 신호에 의해서 컨테이너가 중단된 경우에 해당합니다. livenessProbe에서 어떤 이유로 인해 계속해서 컨테이너가 재시작하는 경우가 이에 해당할 수 있습니다. 세부 적인 예로 liveness endpoint가 유효하지 않아서 발생할 수도 있고 livenessProbe를 통한 컨테이너와의 연결이 유효하지 않아 발생할 수도 있습니다.

 

 두번째 예시인 컨테이너와의 연결이 유효하지 경우 특정 컨테이너가 웹서버여서 정상적으로 서버를 시작하기 위해 필요한 패키지들을 설치하는 시간이 필요해서 위와 같은 오류가 발생할 수 있습니다. 따라서 livenessProbe 속성 중 delay 값을 조절해서 livenessProbe를 시작하는 시점을 뒤로 늦추는 방식으로 위와 같은 오류를 해결할 수 있습니다.

 

3.  Pending Pods

3.1  스케줄링 하려는 노드에 CPU 리소스가 부족할 때

 

파드가 스케줄링 됐는데 해당 노드에 리소스가 부족해 컨테이너를 생성할 수 없을 때 Pending Pods 상태가 된다.

 

3.2  노드 셀렉터에 명시한 노드가 존재하지 않을 때

파드를 특정 노드에 배치하고자 했는데 해당 노드의 레이블이 존재하지 않을 때 Pending Pods 상태가 된다.

 

정리

두 예시 모두 파드를 특정 노드에 스케줄링할 수 없을 때 Pending Pods 상태가 된다.

 

4.  Missing Pods

노드에 충분한 자원이 있지만 파드가 스케줄링되지 않는 경우도 있는데 해당 상황은 네임스페이스에 quota를 설정했을 때 발생할 수 있다.

 

현재 디플로이먼트에서 레플리카수를 2개에서 5개로 증가시켰는데 3개의 파드가 현재 동작하지 않는 상황을 볼 수 있다. 이런 상황에서 해당 네임스페이스에서 발생한 상황을 통해 에러를 확인 할 수 있다.

 

kubectl get events -n staging

 

위 명령어를 입력하면 staging 네임스페이스에서 발생한 이벤트에 대한 내역을 확인할 수 있는데 quota와 관련한 이유로 컨테이너 생성이 실패한 것을 볼 수 있다.

 

아래와 같이 네임스페이스를 확인해 보면 5개를 초과해서 파드를 생성할 수 없게 제한을 건 것을 확인할 수 있다. 해당 네임스페이스에서는 파드를 5개를 넘겨 생성할 수 없는 것이다. 이러한 상황에서 deployment 리소스를 활용하여 replicas 수를 늘리더라도 deployment는 정상적으로 동작하지만 파드는 사용자가 원하는 수를 충족할 수 없게 된다. 따라서 쿼터의 수를 늘리면 해당 이슈를 해결할 수 있다.