Amazon EKS 포드가 "failed to create pod sandbox" 오류와 함께 ContainerCreating 상태에서 멈춘 이유는 무엇입니까?

해결 방법

사전 요구 사항

어떤 포드에 문제가 있는지 확인합니다. 다음 단계를 완료하십시오.

1. 다음 명령을 실행하여 클러스터의 포드를 나열하고 ContainerCreating 상태의 포드를 식별합니다.

   kubectl get pods --all-namespaces -o wide

2. 다음 명령을 실행하여 ContainerCreating 상태의 각 포드에 대한 세부 정보를 검색합니다.

   kubectl describe pod pod-name -n pod-namespace

   참고: pod-name을 포드의 이름으로 바꾸고, pod-namespace를 포드가 위치한 네임스페이스로 바꾸십시오.

3. 이벤트의 출력을 검토하여 포드를 식별한 후 다음 섹션을 사용하여 문제를 해결하십시오.

"Resource temporarily unavailable" 오류

PID 또는 파일에 대해 정의된 커널 설정이 운영 체제(OS)의 최대 한도를 초과하면 다음과 유사한 오류 메시지가 표시됩니다.

"kubelet, ip-192-168-0-1.us-east-1.compute.internal Failed to create Pod sandbox: rpc error: code = Unknown desc = failed to start sandbox container for Pod "example_pod": Error response from daemon: failed to start shim: fork/exec /usr/bin/containerd-shim: resource temporarily unavailable: unknown"

문제를 일시적으로 해결하려면 노드를 다시 시작합니다.

이 문제를 해결하려면 다음 단계를 완료하십시오.

1. Containerd 및 Kubelet에 대한 노드 로그를 수집합니다.
   Windows의 경우 인스턴스에 연결합니다. PowerShell 명령 프롬프트를 연 다음 Windows EKS 로그 수집기 스크립트를 사용하여 워커 노드 로그를 수집합니다. 자세한 내용은 GitHub 웹 사이트에서 EKS Logs Collector (Windows)를 참조하십시오. 다음 명령을 실행합니다.

   Invoke-WebRequest -OutFile eks-log-collector.ps1 https://raw.githubusercontent.com/awslabs/amazon-eks-ami/main/log-collector-script/windows/eks-log-collector.ps1
   .\eks-log-collector.ps1

   Linux의 경우 인스턴스에 연결합니다. 그런 다음 Linux EKS 로그 수집기 스크립트를 사용하여 워커 노드 로그를 수집합니다. 자세한 내용은 GitHub 웹 사이트에서 EKS Logs Collector (Linux)를 참조하십시오. 다음 명령을 실행하여 로그 수집기 스크립트를 다운로드합니다.

   curl -O https://raw.githubusercontent.com/awslabs/amazon-eks-ami/master/log-collector-script/linux/eks-log-collector.sh

2. 그런 다음 다운로드한 스크립트를 실행합니다.

   sudo bash eks-log-collector.sh

3. Kubelet 로그에서 다음 오류 응답을 검토합니다.
   "kubelet[5267]: runtime: failed to create new OS thread (have 2 already; errno=11)""kubelet[5267]: runtime: may need to increase max user processes (ulimit -u)"

4. 좀비 프로세스를 식별한 다음 필요하지 않은 프로세스를 중지합니다.
   Windows의 경우 작업 관리자를 연 다음 Details 탭을 선택합니다. Not responding 상태로 표시되는 프로세스를 확인하여 좀비 프로세스를 식별합니다.
   Linux의 경우 다음 ps 명령을 실행하여 Z 상태로 나열된 좀비 프로세스를 확인합니다.

   ps aux | egrep "Z|defunct"

   자세한 내용은 Linux Journal 웹 사이트에서 How to kill Zombie processes on Linux를 참조하십시오.

"Network plugin cni failed to set up pod network" 오류

컨테이너 네트워크 인터페이스(CNI)가 새로 생성된 포드에 IP 주소를 할당할 수 없는 경우 다음과 같은 오류 메시지가 표시될 수 있습니다.

"Network plugin cni failed to set up pod network: add cmd: failed to assign an IP address to container"

이 오류는 여러 가지 이유로 발생할 수 있으며, 크게 세 가지 범주로 나눌 수 있습니다.

리소스 제한:

• 서브넷 IP 소진
• 최대 ENI 연결 한도 도달

구성 문제:

• 워커 노드에서 IAM CNI 정책 누락
• VPC CNI(aws-node) 포드가 실행 중 상태가 아님
• VPC CNI, kube-proxy 또는 CoreDNS 버전이 오래됨
• 보안 그룹 또는 액세스 제어 목록이 잘못 구성됨

아키텍처 관련 문제:

• 사용 사례에 맞지 않는 VPC CNI 구성
• OpenID Connect(OIDC) 구성 누락
• EKS 관리형 추가 기능이 아닌 자체 관리형 추가 기능

자세한 문제 해결 단계는 Amazon EKS에 대한 kubelet 또는 CNI 플러그인 문제를 해결하려면 어떻게 해야 합니까?를 참조하십시오.

다음과 같이 하는 것이 가장 좋습니다.

• VPC CNI에 사용자 지정 네트워킹을 사용하여 대체 서브넷에 포드를 배포할 수 있도록 합니다.
• 접두사 위임 모드를 활성화합니다. 자세한 내용은 Windows용 접두사 모드를 참조하십시오.
• 포드용 보안 그룹을 사용하여 워커 노드의 브랜치 ENI를 통해 사용자 지정 보안 그룹을 여러 포드에 할당합니다.

참고: CNI 구성을 변경한 경우 영향을 받는 노드를 다시 시작해야 변경 사항이 적용됩니다.

"Error while dialing" 오류

aws-node 포드가 노드에서 실행되지 않아 aws-node 포드가 IPAM과 통신하지 못한 경우 다음과 비슷한 오류가 표시됩니다.

"Error while dialing dial tcp 127.0.0.1:50051: connect: connection refused"

이 오류는 다음과 같은 시나리오에서 발생합니다.

VPC CNI가 보류 중 상태임

보안 규칙 구성 또는 애플리케이션 오류로 인해 생동성 및 준비 상태 프로브 오류가 발생할 수 있습니다. 리소스 고갈로 인해 지연이 발생할 수도 있습니다. 일반적으로 엄격한 모드에서 POD_SECURITY_GROUP_ENFORCING_MODE를 사용하여 DISABLE_TCP_EARLY_DEMUX를 false로 설정하면 오류가 발생할 수 있습니다.

포드별 보안 그룹과 생동성 또는 준비 상태 프로브를 사용하는 경우 엄격한 모드에서 DISABLE_TCP_EARLY_DEMUX를 true로 설정하십시오. 이렇게 하면 kubelet이 TCP를 사용하여 브랜치 네트워크 인터페이스의 포드에 연결할 수 있습니다.

CNI 관리형 플러그인 문제

aws-node는 AWS Management Console에 관리형 플러그인으로 추가되면 프로브에 실패합니다. 관리형 플러그인이 서비스 계정을 덮어쓰기 때문입니다.

이 문제를 해결하려면 다음 중 하나를 수행하십시오.

• AWS Management Console에서 관리형 추가 기능을 제거합니다. 그런 다음 필요한 AmazonEKS_CNI_Policy IAM 정책을 제공하는 올바른 IAM 역할을 사용하여 이 기능을 다시 만듭니다.
• 기존 aws-node 서비스 계정을 편집하여 필요한 CNI 권한이 있는 올바른 IAM 역할과 연결합니다.
• 클러스터에서 Pod Identity를 사용하는 경우 aws-node 서비스 계정을 VPC CNI에서 사용할 IAM 역할과 바인딩하는 필수 Pod Identity 연결을 만듭니다.

추가 권장 사항:

• 최신 버전의 VPC CNI(aws-node), kube-proxy 및 coredns를 사용하십시오.

"Failed to setup network for sandbox" 오류

VPC-CNI(aws-node) 포드에서 접두사 위임 활성화를 사용하는 경우 다음과 같은 오류 메시지가 표시될 수 있습니다.

"Failed to create pod sandbox: rpc error: code = Unknown desc = failed to setup network for sandbox"

이 문제에 대한 자세한 내용을 보려면 워커 노드의 /var/log/aws-routed-eni/ipamd.log에서 IP 주소 관리 대몬(IPAMD) 로그를 확인하십시오.

서브넷에 사용 가능한 IP 주소가 있더라도 서브넷에 사용 가능한 연속된 /28 IP 블록이 없으면 오류가 발생합니다. 이 오류는 기존 보조 IP 주소의 조각화가 서브넷 전체에 분산될 때 발생합니다. 오류는 Kubernetes용 Amazon VPC CNI 플러그인 로그 또는 영향을 받는 워커 노드의 CloudTrail 이벤트에 나타납니다. 다음과 같은 오류 메시지가 표시될 수 있습니다.

"InsufficientCidrBlocks: The specified subnet does not have enough free cidr blocks to satisfy the request"

이 오류를 해결하려면 다음 옵션 중 하나 이상을 완료하십시오.

새 서브넷을 만든 다음 거기서 포드를 시작합니다.

-또는-

Amazon EC2 서브넷 CIDR 예약을 사용하여 서브넷 내에서 접두사 할당에 사용할 공간을 예약합니다.

IP 주소 할당에서 IP 접두사 할당으로 전환하는 경우 새 노드 그룹을 만드십시오. 그러면 기존 노드를 순차적으로 교체하는 대신 사용 가능한 IP 주소의 수를 늘릴 수 있습니다.

IP 주소와 접두사가 모두 할당된 노드에서 포드를 실행하면 광고된 IP 주소 용량에 불일치가 발생할 수 있습니다. 이 시나리오는 노드의 향후 워크로드에 영향을 미칠 수 있습니다. 이 문제를 해결하려면 접두사를 사용하여 Amazon EKS 노드에 추가 IP 주소 할당의 단계를 따르십시오.

Windows 노드의 "Pod does not have label" 오류

Windows 노드에 예약된 nodeSelector가 포드에 없는 경우 다음과 비슷한 오류 메시지가 표시될 수 있습니다.

"Failed to parse Kubernetes args: pod does not have label vpc.amazonaws.com/PrivateIPv4Address" or "Pod does not have label vpc.amazonaws.com/PrivateIPv4Address"

이 문제를 해결하려면 PodSpec의 nodeSelector 파라미터에 다음 레이블을 포함해야 합니다.

nodeSelector:
    kubernetes.io/os: windows
    kubernetes.io/arch: amd64

amazon-vpc-cni configmap에서 enable-windows-ipam 파라미터를 true로 설정했는지 확인하십시오.

amazon-vpc-cni configmap이 없는 경우 다음 템플릿을 사용하여 클러스터에 업로드하십시오.

apiVersion: v1
kind: ConfigMap
metadata:
  name: amazon-vpc-cni
  namespace: kube-system
data:
  enable-windows-ipam: "true"

aws-node 및 node-windows 포드를 다시 시작합니다.

Amazon EKS 클러스터에 Windows 노드를 배포하는 방법에 대한 자세한 내용은 EKS 클러스터에 Windows 노드 배포를 참조하십시오.

보안 그룹 오류

보안 그룹 문제가 있는 경우 다음과 비슷한 오류가 발생합니다.

"Plugin type="aws-cni" name="aws-cni" failed (add): add cmd: failed to assign an IP address to container
Vpc-resource-controller failed to allocate branch ENI to pod: creating network interface, NoCredentialProviders: no valid providers in chain. Deprecated."

이 오류 응답은 health.kubernetes 컨트롤 플레인에 문제가 있음을 나타낼 수 있습니다. 이 문제를 해결하려면 AWS Support에 문의하십시오.

관련 정보

Amazon EKS의 kubelet 또는 CNI 플러그인 문제를 해결하려면 어떻게 해야 합니까?

Amazon EKS에서 OIDC 공급자 및 IRSA 문제를 해결하려면 어떻게 해야 합니까?

Amazon EKS에서 IRSA 오류를 해결하려면 어떻게 해야 합니까?

IRSA를 사용하도록 Amazon VPC CNI 플러그인 구성 - Amazon EKS

서비스 계정의 IAM 역할