AWS EKS PLEG이슈

반응형

AWS EKS를 쓰다 도저히 잡히지 않는 에러가 발생하여 한창 고민한 하루입니다.

 

상황에 대한 시나리오입니다.

(1) 쿠버네티스 클러스터 노드 중 일부 노드 그룹 (레이블로 그룹핑) 의 노드가 비정상 동작을 감지

(2) 비정상 동작 시, 해당 노드의 파드들이 정상동작되지 않는 사태

    -> OOM (unable to create new native Thread) , Connection Exception, 뭐 등등등등.. 일반적으로 스레드 풀 획득 실패

(3) 파드가 다운되고, HPA 스케일러가 이를 복구하며, 무한반복 및 파드 스케줄에 펜딩 걸리는 난장판이 펼쳐지기 시작 (와우!)

WOW!

아직도 쿠버네티스 운전 잘 못하는 앙몬드의 트러블슈팅 시작..

 

(1) 2번 상황에서, 모든 이슈가 하나의 공통점으로 수렴하는데, 네트워크 자원에 대한 문제가 있었댜..? 

=> 문제는 해당 노드의 모든 파드가 그런 증상을 보이진 않았으며, 만약 그렇다면 ENI 매니지드 서비스에 대한 클라우드 AZ단위 장애일 가능성이 높고, 그에 대한 알람을 받은 적이 없으므로 패스

(2) 파드 내부 컨테이너 런타임인 어플리케이션의 문제댜..?

=> 그럼 다른 노드의 같은 어플리케이션들은 왜 잘 돌아가는지에 대한 확신이 없으므로, 이 또한 아니댜..

(3) 노드가 터졌댜..?

=> 반드시 그런건 아니고, 노드에 할당된 (Allocation) 은 노드 내부 프로세스 리소스 사용률을 고려하여, 70%까지만 유지하였고, 또한 이 당시에 파드가 제한값까지 치는 상황은 일어나지 않았댜.. 그런데.. NodeNotReady는 왜 뜨지.. 안의 파드들은 정상 기동중이댜..

(4) 뭐냐 그럼...?

 

사실 AWS EKS를 살펴보다 보면, 생각보다 간과하고서 넘어간 부분이 있습니다.

kubectl describe node {노드명}

커맨드로 쿠버 API를 호출하면, 맨날 지나쳤던 로그의 일부분. (맨날 정상이었으니 그냥 넘어갔지....)

노드의 상태값인데, 자세히 보면, Ready Type이 False. 즉 노드가 NotReady 상태로 나타났고, 이 노드를 매니징해야하는 Kubelet, 쿠버 워커노드의 중간관리자가 일할 준비가 안되어있죠.

그리고, 그 옆에 왜 쿠블릿이 정상동작하지 못한 사유가 나옵니다

"PLEG is not healthy: pleg was last seen active .... ~~"

당신 뭡니까..? PLEG요..? 아직 쿠버 초보운전이라지만, 이건 또 뭡니까..? 

developers.redhat.com/blog/2019/11/13/pod-lifecycle-event-generator-understanding-the-pleg-is-not-healthy-issue-in-kubernetes/

 

Pod Lifecycle Event Generator: Understanding the "PLEG is not healthy" issue in Kubernetes - Red Hat Developer

We look at the Pod Lifecycle Event Generator (PLEG) module in Kubernetes and show how to troubleshoot various issues.

developers.redhat.com

레드햇 공홈의 영어 원문입니다. 워커노드의 중간관리자인 쿠블릿 안에 위치한 모듈이고, 컨테이너 런타임의 상태를 조절하는 녀석이라고 설명하고 있습니다. 자세한 사항은 상기 레퍼런스를 참조해주시면 좋을 것 같아요! (머리속에 집어넣을 것도 많은데 CKA도 따야 하는건가..)

자 그럼 여기서 문제를 던져보면, PLEG모듈이 왜 컨테이너들의 상태를 비정상이라고 판단하였는지, 그리고 쿠블릿이 정상적으로 동작하던 파드들을 마구마구 죽이면서 저 에러가 난 것일까라는 의문에 도달하고 마는데!

* 그렇다면 PLEG에 대한 로그는 어떻게 볼까?

보통은, 노드의 이벤트 필드에 그 값이 나타나지만, 많은 로그를 보여주진 않습니댜.

따라서, 이에 대한 로그를 시간대별로 볼 방법이 필요한데....

journalctl -xfu kubelet (OS별로 커맨드는 다를 수 있어요! 제가 사용하고 있는 것은 AML2, 레드햇계열 리눅스입니다)

워커노드의 쿠블릿에 대한 로그를 보여줍니다.

 

그러나, 이 로그와, 실제 어플리케이션의 활동로그를 보면 상이한 차이가 발생했는데..

    - kubelet : pleg가 그러던데, 너님 이상하니까 아웃

    - pod : ?????? 아니 왜 선량한 저를...

지금 이 상황입니다 정말..

 

결국, 왜 쿠블릿의 pleg 모듈이 저 파드들을 전부 이상한 사람 취급해서, 못살게 구나는 야간 철야로도 밝혀지지 않게 되었고, 다음 날 EKS 실제 테크니션의 답변을 듣게 됩니다.

 

아.. 지금 야간 작업 해야하니 간단하게만 결론 내고 가죠..

 

EKS 1.16 미만 의 버전에서, 노드의 CPU가 100% 가까이 사용될 때, pleg가 오작동을 하는 버그가 존재합니다.

글로벌적으로도 많이 문의가 들어온 내역입니다.

EKS의 버그이며, 현재 사용하고 있는 1.14 버전을 업그레이드 해주시면 됩니다.

 

.....?

그리고 이건 쿠블릿 아키텍처입니다.

programmer.help/images/blog/30f7ca203efd66487c602c86184b5b87.jpg

 

반응형

설정

트랙백

댓글