마스터 KUBERNETES POD 문제 해결: 고급 전략 및 시나리오

Kubernetes(K8s) 배포는 포드, 서비스, 수신, 응답하지 않는 클러스터, 제어 플레인 및 고가용성 설정을 비롯한 다양한 관점에서 문제를 제시하는 경우가 많습니다. Kubernetes Pod는 Kubernetes 생태계에서 배포 가능한 가장 작은 단위로, 리소스와 네트워크를 공유하는 하나 이상의 컨테이너를 캡슐화합니다. 포드는 애플리케이션이나 프로세스의 단일 인스턴스를 실행하도록 설계되었으며 필요에 따라 생성 및 삭제됩니다. Pod는 K8s 환경에서 애플리케이션을 확장, 업데이트 및 유지 관리하는 데 필수적입니다.

Master Kubernetes Pods: Advanced Troubleshooting Strategies 에서 번역됨 , 작성자 없음.

이 문서에서는 Kubernetes Pod가 직면한 문제와 수행해야 할 문제 해결 단계를 살펴봅니다. Kubernetes Pod를 실행할 때 발생하는 일부 오류 메시지는 다음과 같습니다.

이미지풀백오프
오류이미지풀
잘못된 이미지 이름
충돌루프뒤로끄기

때로는 나열된 오류가 발생하지 않지만 여전히 Pod가 실패하는 경우가 있습니다. 먼저, Kubernetes 리소스를 디버깅할 때 API 참조를 이해해야 한다는 점에 유의하는 것이 중요합니다 . 다양한 Kubernetes API가 정의되는 방법과 포드/배포의 여러 객체가 작동하는 방식을 설명합니다. 문서는 Kubernetes 웹사이트 의 API 참조에 명확하게 정의되어 있습니다 . 이 경우 포드를 디버깅할 때 API 참조에서 포드 개체를 선택하여 포드 작동 방식에 대해 자세히 알아보세요. 이는 포드에 들어가는 필드, 즉 버전, 유형, 메타데이터, 사양 및 상태를 정의합니다. Kubernetes는 필수 명령에 대한 안내가 포함된 치트 시트 도 제공합니다 .

전제 조건

이 문서에서는 독자가 다음과 같은 조건을 가지고 있다고 가정합니다.

시나리오 시연용으로 설치된 종류
Kubernetes 아키텍처에 대한 중급 이해
Kubectl 명령줄 도구

Kubernetes 포드 오류 - ImagePullBackoff

이 오류는 다음 세 가지 이유로 나타납니다.

잘못된 이미지
잘못된 태그
잘못된 권한

이러한 상황은 이미지에 대한 올바른 정보가 없을 때 발생합니다. 또한 저장소(개인 저장소)에서 이미지를 가져올 수 있는 권한이 없을 수도 있습니다. 아래 예에서 이를 보여주기 위해 nginx 배포를 만듭니다.

➜ ~ kubectl create deploy nginx --image=nginxdeployment.apps/nginx created

Pod가 실행된 후 Pod 이름을 가져옵니다.

➜ ~ kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-8f458dc5b-hcrsh 1/1 Running 0 100s

실행 중인 Pod의 이름을 복사하고 이에 대한 자세한 정보를 가져옵니다.

➜ ~ kubectl describe pod nginx-8f458dc5b-hcrsh
Name:             nginx-8f458dc5b-hcrsh
hable:NoExecute op=Exists for 300s
Events:
 Type    Reason     Age    From               Message
 ----    ------     ----   ----               -------
 Normal  Scheduled  2m43s  default-scheduler  Successfully assigned default/nginx-8f458dc5b-hcrsh to k8s-troubleshooting-control-plane
 Normal  Pulling    2m43s  kubelet            Pulling image "nginx"
 Normal  Pulled     100s   kubelet            Successfully pulled image "nginx" in 1m2.220189835s
 Normal  Created    100s   kubelet            Created container nginx
 Normal  Started    100s   kubelet            Started container nginx

이미지를 성공적으로 가져왔습니다. Kubernetes 포드가 오류 없이 실행 중입니다.

ImagePullBackoff를 시연하려면 배포 YAML 파일을 편집하고 존재하지 않는 이미지를 지정합니다.

➜ kubectl edit deploy nginx
 containers:
 -image: nginxdoestexist
  imagePullPolicy: Always
  name: nginx

새 포드가 성공적으로 배포되지 않았습니다.

➜ ~ kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-5b847fdb95-mx4pq 0/1 ErrImagePull 0 3m40s
nginx-8f458dc5b-hcrsh 1/1 Running 0 38m

ImagePullBackoff 오류가 표시됨

➜  ~ kubectl describe pod nginx-6f46cbfbcb-c92bl
Events:
 Type     Reason     Age                From               Message
 ----     ------     ----               ----               -------
 Normal   Scheduled  88s                default-scheduler  Successfully assigned default/nginx-6f46cbfbcb-c92bl to k8s-troubleshooting-control-plane
 Normal   Pulling    40s (x3 over 88s)  kubelet            Pulling image "nginxdoesntexist"
 Warning  Failed     37s (x3 over 85s)  kubelet            Failed to pull image "nginxdoesntexist": rpc error: code = Unknown desc = failed to pull and unpack image "docker.io/library/nginxdoesntexist:latest": failed to resolve reference "docker.io/library/nginxdoesntexist:latest": pull access denied, repository does not exist or may require authorization: server message: insufficient_scope: authorization failed
 Warning  Failed     37s (x3 over 85s)  kubelet            Error: ErrImagePull
 Normal   BackOff    11s (x4 over 85s)  kubelet            Back-off pulling image "nginxdoesntexist"
 Warning  Failed     11s (x4 over 85s)  kubelet            Error: ImagePullBackOff

Kubernetes Pod 오류 - 이미지를 가져왔지만 Pod가 보류 상태입니다.

프로덕션 환경에서 K8s를 실행할 때마다 K8s 관리자는 클러스터 내에서 실행되는 네임스페이스의 요구 사항에 따라 각 네임스페이스에 리소스 할당량을 할당합니다. 네임스페이스는 클러스터 내에서 논리적 분리를 위해 사용됩니다.

리소스 할당량의 사양이 포드에 있는 애플리케이션의 최소 요구 사항을 충족하지 않으면 "이미지를 가져왔지만 포드가 여전히 보류 중입니다." 오류가 발생합니다. 다음 예에서는 Payments라는 네임스페이스를 만듭니다.

➜ ~ kubectl create ns payments

namespace/payments created

관련 사양을 사용하여 리소스 할당량 생성

➜  ~ cat resourcequota.yaml
apiVersion: v1
kind: ResourceQuota
metadata:
 name: compute-resources
spec:
 hard:
   requests.cpu: "1"
   requests.memory: 1Gi
   limits.cpu: "2"
   limits.memory: 4Gi

네임스페이스 결제에 리소스 할당량 할당

➜ ~ kubectl apply -f resourcequota.yaml -n paymentsresourcequota/compute-resources created

생성된 리소스 할당량/컴퓨팅 리소스

리소스 할당량 제한이 있는 네임스페이스 내에 새 배포를 만듭니다.

kubectl create deploy nginx --image=nginx -n paymentsdeployment.apps/nginx created

배포가 성공적으로 생성되었지만 Pod가 존재하지 않습니다.

➜ ~ kubectl get pods -n payments

No resources found in payments namespace

배포가 생성되었지만 준비 상태의 포드가 없고 업데이트할 포드가 없으며 사용 가능한 포드가 없습니다.

➜  ~ kubectl get deploy -n payments
NAME    READY   UP-TO-DATE   AVAILABLE   AGE
nginx   0/1     0            0           7m4s

추가로 디버깅하려면 nginx 배포를 설명하세요. 포드 생성 실패:

➜  ~ kubectl describe deploy nginx -n payments
Name:                   nginx
Namespace:              payments
CreationTimestamp:      Wed, 24 May 2023 21:37:55 +0300
Labels:                 app=nginx
Annotations:            deployment.kubernetes.io/revision: 1
Selector:               app=nginx
Replicas:               1 desired | 0 updated | 0 total | 0 available | 1 unavailable
StrategyType:           RollingUpdate
MinReadySeconds:        0
RollingUpdateStrategy:  25% max unavailable, 25% max surge
Pod Template:
 Labels:  app=nginx
 Containers:
  nginx:
   Image:        nginx
   Port:         <none>
   Host Port:    <none>
   Environment:  <none>
   Mounts:       <none>
 Volumes:        <none>
Conditions:
 Type             Status  Reason
 ----             ------  ------
 Available        False   MinimumReplicasUnavailable
 ReplicaFailure   True    FailedCreate
 Progressing      False   ProgressDeadlineExceeded
OldReplicaSets:    <none>
NewReplicaSet:     nginx-8f458dc5b (0/1 replicas created)
Events:
 Type    Reason             Age   From                   Message
 ----    ------             ----  ----                   -------
 Normal  ScalingReplicaSet  10m   deployment-controller  Scaled up replica set nginx-8f458dc5b to 1

Kubernetes 이벤트를 추가로 분석한 결과 Pod 생성에 필요한 메모리가 부족한 것으로 나타났습니다.

➜ ~ kubectl get events --sort-by=/metadata.creationTimestamp

이 오류는 이미지를 성공적으로 가져오고 컨테이너가 생성되었지만 런타임 구성이 실패할 때 발생합니다. 예를 들어, 존재하지 않거나 폴더에 쓸 수 있는 권한이 없는 폴더에 쓰려고 하는 작동 중인 Python 애플리케이션이 있는 경우입니다. 처음에 애플리케이션이 실행된 후 오류가 발생합니다. 애플리케이션 로직에 패닉이 발생하면 컨테이너가 중지됩니다. 컨테이너는 CrashLoopBackOff로 이동합니다. 결국 배포에 Pod가 없다는 것을 알게 됩니다. 즉, Pod가 있지만 실행되지 않고 CrashLoopbackoff 오류가 발생합니다.

활성 상태 및 준비 상태 프로브 실패

활성 감지는 포드가 손상된 상태에 진입하여 더 이상 트래픽을 제공할 수 없는지 여부를 감지합니다. Kubernetes가 포드를 다시 시작합니다. 준비 상태 프로브는 애플리케이션이 트래픽을 처리할 준비가 되었는지 확인합니다. 준비 프로브는 애플리케이션이 구성 맵에서 필요한 모든 구성을 가져오고 해당 스레드를 시작하는지 확인합니다. 이 프로세스를 완료한 후에만 애플리케이션이 트래픽을 수신할 수 있게 됩니다. 이 프로세스 중에 애플리케이션에 오류가 발생하면 CrashLoopBackoff도 시작됩니다.

문제 해결을 시작하세요!

이 문서에서는 Kubernetes Pod 문제 해결 기술에 대한 개요를 제공합니다. Pod를 배포할 때 발생하는 일반적인 오류를 해결하고 이러한 오류를 해결하기 위한 실용적인 솔루션을 제공합니다. 또한 Kubernetes의 작동 방식을 이해하고 문제를 효과적으로 식별 및 해결하는 데 중요한 참조 페이지와 치트 시트에 대한 통찰력을 제공합니다. 이 문서에 제공된 지침을 따르면 독자는 문제 해결 기술을 향상하고 Kubernetes Pod의 배포 및 관리를 단순화할 수 있습니다.

이 기사는 Yunyunzhongsheng ( https://yylives.cc/ ) 에 처음 게재되었습니다 . 누구나 방문하실 수 있습니다.