PLEG 문제로 인해 NotReady 상태로 전환되는 Amazon EKS 워커 노드의 문제를 해결하려면 어떻게 해야 합니까?

4분 분량
0

포드 수명주기 이벤트 생성기(PLEG)가 비정상적이기 때문에 Amazon Elastic Kubernetes Service(Amazon EKS) 워커 노드가 NotReady 또는 Unknown 상태로 전환됩니다.

해결 방법

Amazon EKS 클러스터의 워커 노드가 NotReady 또는 Unknown 상태가 되면 해당 노드에 스케줄링된 워크로드가 중단됩니다. 이 오류를 해결하려면 다음을 수행합니다.

다음 명령을 실행하여 워커 노드에 대한 정보를 가져옵니다.

$ kubectl describe node node-name

출력에서 조건 섹션을 확인하여 문제의 원인을 찾습니다.

예:

KubeletNotReady  PLEG is not healthy: pleg was last seen active xx

PLEG가 비정상인 가장 일반적인 이유는 다음과 같습니다.

  • 대몬(daemon)이 사용 중이거나 작동하지 않기 때문에 Kubelet은 Docker 대몬(daemon)과 통신할 수 없습니다. 예를 들어 EKS 워커 노드의 Docker 대몬(daemon)이 손상을 입었을 수 있습니다.
  • 인스턴스 수준에서 메모리 부족(OOM) 또는 CPU 사용률 문제로 인해 PLEG가 비정상 상태가 되었습니다.
  • 워커 노드에 많은 수의 파드가 있는 경우 kubelet 및 Docker 대몬(daemon)의 워크로드가 증가하여 PLEG 관련 오류가 발생할 수 있습니다. 활성 상태 또는 준비 상태를 자주 조사하면 워크로드가 증가할 수도 있습니다.

kubelet 로그 확인

인스턴스의 kubelet 로그를 식별해 PLEG가 비정상인 이유를 확인할 수 있습니다.

1.    SSH를 사용하여 인스턴스에 연결해서 다음 명령을 실행합니다.

$ journalctl -u kubelet > kubelet.log

Amazon EKS에 최적화된 AMI를 사용 중이고 SSH가 활성화되지 않은 경우 SSM을 사용하여 연결할 수 있습니다. 자세한 내용은 세션 매니저를 사용하여 Linux 인스턴스 연결을 참조하십시오.

2.    kubelet이 다음 로그에 게시한 PLEG 관련 이벤트를 확인합니다.

예:

28317 kubelet.go:1873] "Skipping pod synchronization" err="PLEG is not healthy: pleg was last seen active 4h5m43.659028227s ago; threshold is 3m0s"
28317 kubelet.go:1873] "Skipping pod synchronization" err="PLEG is not healthy: pleg was last seen active 4h5m48.659213288s ago; threshold is 3m0s"

3.    kubelet 로그를 확인하여 준비 상태 및 활성 상태 프로브에 실패한 포드가 있는지 확인합니다. 이러한 로그 메시지는 다음과 유사합니다.

"Probe failed" probeType="Liveness" pod="nginx/bus" podUID=2527afb7-b32c-4c84-97e2-246eb48c97a9 containerName="nginx" probeResult=failure output="Get \"http://192.168.154.18:15020/app-health/livez\": context deadline exceeded (Client.Timeout exceeded while awaiting headers)"

이 로그를 사용하여 장애가 발생한 포드를 식별할 수 있습니다. 식별한 포드의 경우 상태 프로브가 올바르게 구성되었는지 확인하십시오.

워커 노드 리소스 사용량 모니터링

OOM 문제 또는 높은 CPU 사용률로 인한 리소스 크런치 등의 인스턴스 수준 문제가 발생하는지 확인합니다.

기본 Amazon Elastic Compute Cloud(Amazon EC2) 워커 노드의 CPU 사용률 지표를 모니터링합니다. 이 지표를 확인하여 갑작스러운 스파이크 발생 여부 또는 CPU 사용률의 100% 도달 여부를 확인합니다.

Kubelet은 구성된 유예 기간과 관계없이 노드가 하드 또는 소프트 제거 임계값을 충족하면 노드에 압력이 가해진다고 보고합니다. 다음 명령을 실행하여 노드 상태를 확인할 수 있습니다.

$ kubectl describe node <node_name>

출력에서 노드 조건이 MemoryPressure로 표시되는지 확인합니다. 이러한 경우 리소스를 사용할 수 없게 되어 인스턴스가 중단될 수 있습니다. 이로 인해 프로세스가 응답하지 않을 수 있습니다.

리소스 크런치로 인한 문제를 완화하려면 포드에 CPU 및 메모리 사용량 제한을 설정하는 것이 가장 좋습니다.

컨테이너에 리소스 제한을 지정하면 kubelet은 이러한 제한을 강화합니다. 실행 중인 컨테이너의 사용량은 이러한 제한을 초과할 수 없습니다. 이렇게 하면 포드가 필요 이상으로 많은 메모리를 차지하지 않도록 예방하여 OOM 문제를 방지할 수 있습니다. 자세한 내용은 Kubernetes 웹 사이트의 포드 및 컨테이너에 대한 리소스 관리를 참조하십시오.

또한 Container Insights를 사용하여 컨테이너화된 애플리케이션 및 마이크로서비스에서 지표와 로그를 수집, 집계 및 요약하는 것도 고려해 보십시오. 자세한 내용은 Amazon EKS 및 Kubernetes 컨테이너 인사이트 지표를 참조하십시오. node_cpu_utilizationnode_memory_utilization를 사용하여 노드 수준에서 리소스 사용률을 모니터링할 수 있습니다. 특정 임계값에 도달하면 알림을 받도록 경보를 설정할 수도 있습니다.

루트 Amazon EBS 볼륨 성능을 모니터링

Amazon Elastic Block Store(Amazon EBS) 볼륨의 디스크 문제로 인해 PLEG가 비정상일 수 있습니다. 이 경우 kubelet 로그는 다음과 유사합니다.

fs: disk usage and inodes count on following dirs took 1.262610491s: [/var/lib/docker/overlay2/709e904d843733d746e5134e55e3c6553db4c0f5297d5e3c3a86c206bcb6b172/diff /var/lib/docker/containers/158725d2d97578713034c5f5c16291a068349b7e989b417324c142bb584f79ad]; will not log again for this container unless duration exceeds 2s

이는 인스턴스의 포드를 사용하는 애플리케이션이 디스크에 대해 집중적인 I/O 작업을 수행할 때 발생합니다.

Amazon EBS용 Amazon CloudWatch 지표를 사용하여 Amazon EBS 볼륨의 IOPS 사용률 및 스루풋을 모니터링할 수 있습니다.

다음 CloudWatch 지표를 사용하여 Amazon EBS 볼륨의 스루풋 및 IOPS를 모니터링합니다.

  • VolumeReadOps
  • VolumeWriteOps
  • VolumeReadBytes

예를 들어 다음 공식을 사용하여 평균 IOPS를 ops/초 단위로 계산할 수 있습니다.

((VolumeReadOps) + (VolumeWriteOps)) / (Period)

다음 공식을 사용하여 평균 스루풋을 바이트/초 단위로 계산할 수 있습니다.

((VolumeReadBytes) + (VolumeWriteBytes)) / (Period)

자세한 내용은 CloudWatch 지표를 사용하여 EBS 볼륨이 제공하는 평균 스루풋과 평균 IOPS 수를 계산하려면 어떻게 해야 하나요?를 참고하십시오.

이 문제를 해결하려면 디스크 크기를 늘리거나 EBS 볼륨 유형을 변경하여 I/O 스루풋을 높이는 것이 좋습니다.


AWS 공식
AWS 공식업데이트됨 일 년 전