AWS announces preview of AWS Interconnect - multicloud
AWS announces AWS Interconnect – multicloud (preview), providing simple, resilient, high-speed private connections to other cloud service providers. AWS Interconnect - multicloud is easy to configure and provides high-speed, resilient connectivity with dedicated bandwidth, enabling customers to interconnect AWS networking services such as AWS Transit Gateway, AWS Cloud WAN, and Amazon VPC to other cloud service providers with ease.
Amazon EKS에서 Kubernetes 포드 문제를 해결하려면 어떻게 해야 합니까?
Amazon Elastic Kubernetes Service(Amazon EKS) 클러스터의 Kubernetes 포드가 실패합니다. 포드 오류의 근본 원인을 파악하고 싶습니다.
해결 방법
포드 문제를 유발하는 오류 파악
-
포드에 대한 정보를 얻으려면 다음 kubectl describe 명령을 실행합니다.
kubectl describe pod YOUR_POD_NAME -n YOUR_NAMESPACE참고: YOUR_POD_NAME을 포드 이름으로 바꾸고 YOUR_NAMESPACE를 네임스페이스로 바꾸십시오.
-
명령 출력의 이벤트 섹션에서 오류 메시지를 파악합니다.
출력 예시:
Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning FailedScheduling 24s default-scheduler no nodes available to schedule pods Warning FailedScheduling 19s (x2 over 22s) default-scheduler no nodes available to schedule pods
표시되는 오류 메시지에 따라 다음 문제 해결 방법을 사용하여 포드 문제를 해결하십시오.
EBS 볼륨 탑재 문제
다음 출력 예시는 kubectl describe pod ebs-pod 명령에서 가져온 것입니다. 출력에는 Amazon Elastic Block Store(Amazon EBS) 볼륨 탑재에 대한 볼륨 노드 선호도 오류가 표시됩니다.
Name: ebs-pod ... Status: Pending ... Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning FailedScheduling 88s (x20 over 96m) default-scheduler 0/2 nodes are available 2 node(s) had volume node affinity conflict
위 오류는 여러 가용 영역에서 포드의 영구 볼륨 청구(PVC)를 예약하면 발생합니다. 포드를 다른 가용 영역의 볼륨에 연결할 수 없기 때문에 포드를 스케줄링할 수 없습니다. 이 문제를 해결하려면 하나의 가용 영역에서 PVC를 스케줄링해야 합니다.
위의 오류를 해결하려면 다음 단계를 완료하십시오.
-
네임스페이스에 있는 모든 PVC에 대한 정보를 가져오려면 다음 kubectl get pvc 명령을 실행합니다.
kubectl get pvc -n YOUR_NAMESPACE참고: YOUR_NAMESPACE를 네임스페이스로 바꾸십시오.
-
영구 볼륨(PV)에 대한 정보를 가져오려면 다음 kubectl get pv 명령을 실행합니다.
kubectl get pv -
사용 중인 PVC에 해당하는 PV를 찾으려면 다음 kubectl describe pv 명령을 실행합니다.
kubectl describe pv your_PV참고: your_PV를 PV 이름으로 바꾸십시오.
-
이전 명령에서 받은 볼륨 ID가 올바른 가용 영역과 연결되어 있는지 확인합니다.
-
가용 영역이 있는 노드를 확인합니다.
볼륨 노드 선호도 충돌이 발생하는 경우 다음 조치 중 하나를 취하십시오.
- 테인트와 톨러레이션을 사용하여 Amazon EBS 탑재를 사용하는 포드가 올바른 노드에 스케줄링되도록 합니다. 노드는 EBS 볼륨이 있는 가용 영역에 있어야 합니다. 자세한 내용은 Kubernetes 웹 사이트의 Taints and toleration을 참조하십시오.
- Deployment 대신 StatefulSets를 사용하여 StatefulSet의 각 포드에 대한 고유한 EBS 볼륨을 동일한 가용 영역에 만듭니다. 자세한 내용은 Kubernetes 웹 사이트에서 StatefulSets를 참조하십시오.
포드 또는 StatefulSet은 보류 중 상태에서 멈출 수 있습니다. 포드 또는 StatefulSet이 EBS 볼륨과 동일한 가용 영역에 있는 경우에도 마찬가지입니다. 이 문제를 해결하려면 다음 kubectl logs 명령을 실행하여 Amazon EBS CSI 드라이버 포드의 로그를 확인하십시오.
kubectl logs your-ebs-csi-controller -n your-kube-system -c your-csi-provisioner
참고: your-ebs-csi-controller를 Amazon EBS CSI 컨트롤러로 바꾸십시오. 또한 your-kube-system을 미리 정의된 네임스페이스로 바꾸고, your-csi-provisioner를 로그를 가져오는 데 사용되는 컨테이너 이름으로 바꾸십시오.
ContainerCreating 상태 오류
포드가 ContainerCreating 상태에서 멈췄을 때 네트워크 플러그인에서 멈췄을 때 networkPlugin: cni가 포드에 IP 주소를 할당하지 않으면 다음과 같은 오류 메시지가 표시됩니다.
"Failed to create pod sandbox: rpc error: code = Unknown desc = failed to set up sandbox container "0fdf25254b1888afeda8bf89bc1dcb093d0661ae2c8c65a4736e473c73714c65" network for pod "test": networkPlugin cni failed to set up pod "test" network: add cmd: failed to assign an IP address to container."
ContainerCreating 상태 오류를 해결하려면 다음 조치를 취하십시오.
- 서브넷에 사용 가능한 IP 주소가 있는지 확인하여 문제를 해결합니다. Amazon Virtual Private Cloud(Amazon VPC) 콘솔을 엽니다. 탐색 창의 Virtual Private Cloud에서 서브넷을 선택합니다.
- aws-node용 포드가 실행 중 상태인지 확인합니다. 또한 지원되는 최신 버전의 Amazon VPC CNI를 사용해야 합니다.
- 인스턴스의 포드 수가 최대 포드 수에 도달했는지 확인합니다.
- 포드를 스케줄링한 노드의 var/log/aws-routed-eni 경로에서 ipamd 로그와 플러그인의 오류 메시지를 찾아봅니다.
CrashLoopBackOff 상태 오류
"Back-Off restarting failed container" 오류 메시지가 표시됩니다.
위 오류 메시지는 컨테이너 시작이 반복적으로 실패한 후 CrashLoopBackOff 상태로 전환되고 포드 내에서 지속적으로 다시 시작되기 때문에 발생합니다.
다음과 같은 문제로 인해 컨테이너 시작이 반복적으로 실패할 수 있습니다.
- 메모리 부족
- 리소스 과부하
- 배포 오류
- DNS 오류와 같은 외부 종속성 문제
- 서드 파티 종속성
- 포트 충돌로 인한 컨테이너 수준 장애
현재 포드의 로그에서 오류를 가져오려면 다음 kubectl logs 명령을 실행합니다.
kubectl logs YOUR_POD_NAME -n YOUR_NAMESPACE
참고: YOUR_POD_NAME을 포드 이름으로 바꾸고 YOUR_NAMESPACE를 네임스페이스로 바꾸십시오.
충돌한 이전 포드의 로그에서 오류를 가져오려면 kubectl logs --previous 명령을 실행합니다.
kubectl logs --previous YOUR_POD_NAME -n YOUR_NAMESPACE
참고: YOUR_POD_NAME을 포드 이름으로 바꾸고 YOUR_NAMESPACE를 네임스페이스로 바꾸십시오.
프로브 실패 오류
포드가 충돌하면 연결 거부나 클라이언트 시간 초과로 인해 프로브 실패 오류가 발생합니다.
거부된 연결 문제 해결
연결이 거부되어 프로브가 실패한 경우 다음 오류 메시지 중 하나가 표시될 수 있습니다.
- "Liveness probe failed: Get https://$POD_IP:8080/<healthcheck_path>: dial tcp POD_IP:8080: connect: connection refused."
- "Readiness probe failed: Get https://$POD_IP:8080/<healthcheck_path>: dial tcp POD_IP:8080: connect: connection refused."
연결 거부 문제를 해결하려면 다음 단계를 완료하십시오.
-
포드 매니페스트에 정의된 상태 확인 경로를 워커 노드에서 수동으로 가져오려면 다음 명령을 실행합니다.
[ec2-user@ip-10-5-1-12 ~]$ curl -ikv podIP:8080//your_healthcheck_path참고: podIP를 포드의 IP 주소로 바꾸고 your_healthcheck_path를 경로 이름으로 바꾸십시오.
-
생동성 프로브 또는 준비 상태 프로브에 장애가 발생한 포드의 포드 매니페스트에 정의된 상태 확인 경로를 확인합니다. 상태 확인 경로를 확인하려면 다음 명령을 실행합니다.
local@bastion-host ~ % kubectl exec YOUR_POD_NAME -- curl -ikv "http://localhost:8080/your_healthcheck_path"참고: YOUR_POD_NAME을 포드 이름으로 바꾸십시오.
-
배스천 호스트에서 동일한 컨테이너 이미지를 실행합니다.
-
매니페스트의 프로브에 정의된 상태 확인 경로를 가져올 수 있는지 확인합니다. 그런 다음 컨테이너 로그에서 실패, 시간 초과 또는 오류를 확인합니다.
-
포드가 실행되는 워커 노드의 kubelet 로그에서 오류를 확인하려면 다음 journalctl 명령을 실행합니다.
[ec2-user@ip-10-5-1-12 ~]$ journalctl -u kubelet //optionally 'grep' with pod name
클라이언트 시간 초과 문제 해결
클라이언트 시간 초과로 인해 프로브가 실패한 경우 다음 오류 메시지 중 하나가 표시될 수 있습니다.
- "Liveness probe failed: Get "http://podIP:8080/<healthcheck_path> ": context deadline exceeded (Client.Timeout exceeded while awaiting headers)."
- "Readiness probe failed: Get "http://podIP:8080/<healthcheck_path> ": context deadline exceeded (Client.Timeout exceeded while awaiting headers)."
클라이언트 시간 초과 문제를 해결하려면 애플리케이션 포드의 생동성 프로브 및 준비 상태 프로브에 대한 구성이 올바른지 확인하십시오.
포드에 보안 그룹을 사용하고 ENABLE_POD_ENI=true인 경우 TCP 초기 디먹스를 비활성화해야 합니다. 이러한 조치를 취하면 kubelet이 TCP를 사용하는 브랜치 네트워크 인터페이스의 포드에 연결할 수 있습니다.
TCP 초기 디먹스를 비활성화하려면 다음 kubectl patch 명령을 실행합니다.
kubectl patch daemonset aws-node -n kube-system \-p '{"spec": {"template": {"spec": {"initContainers": [{"env":[{"name":"DISABLE_TCP_EARLY_DEMUX","value":"true"}],"name":"aws-vpc-cni-init"}]}}}}'
ImagePullBackOff 오류
ImagePullBackOff 오류는 포드에서 실행 중인 컨테이너가 컨테이너 레지스트리에서 필요한 이미지를 가져오지 못할 때 발생합니다.
이 오류는 다음과 같은 문제로 인해 발생할 수 있습니다.
- 네트워크 연결 문제
- 잘못된 이미지 이름 또는 태그
- 자격 증명 누락
- 권한 부족
문제의 원인을 확인하려면 다음 단계를 완료하십시오.
-
포드의 상태를 확인하려면 다음 명령을 실행합니다.
kubectl get pods -n YOUR_NAMESPACE참고: YOUR_NAMESPACE를 네임스페이스로 바꾸십시오.
-
포드에 대한 실패 세부 정보를 가져오려면 다음 명령을 실행합니다.
kubectl describe pod YOUR_POD_NAME -n YOUR_NAMESPACE참고: YOUR_POD_NAME을 포드 이름으로 바꾸고 YOUR_NAMESPACE를 네임스페이스로 바꾸십시오.
출력 예시:
Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 18m default-scheduler Successfully assigned kube-system/kube-proxy-h4np6 to XXX.XXX.eu-west-1.compute.internal Normal Pulling 16m (x4 over 18m) kubelet Pulling image "<account-id>.dkr.ecr.eu-west-1.amazonaws.com/eks/kube-proxy:v1.21.5-eksbuild.2" Warning Failed 16m (x4 over 18m) kubelet Failed to pull image "<account-d>.dkr.ecr.eu-west-1.amazonaws.com/eks/kube-proxy:v1.21.5-eksbuild.2": rpc error: code = Unknown desc = Error response from daemon: manifest for <account-id>.dkr.ecr.eu-west-1.amazonaws.com/eks/kube-proxy:v1.21.5-eksbuild.2 not found: manifest unknown: Requested image not found
ImagePullBackOff 오류를 해결하려면 Amazon EKS에서 ErrImagePull 및 ImagePullBackoff 오류를 해결하려면 어떻게 해야 합니까?를 참조하십시오.
- 언어
- 한국어
