Kubernetes Calico CNI와 스케줄링 실패 관계

Kubernetes Calico CNI: 극심한 파드 지연 혹은 스케줄링 실패

운영 중 약 1년간 유휴 노드 상태로 대기중인 노드의 cordon 상태를 uncordon 상태로 변경한 뒤

POD 스케줄링 실패 및 calico-node pod crashloopbackoff 현상 발생등 비정상 동작을 야기했다.

 

calico-node pod 로그와 CERN 포럼에 올라온 디버깅 무선를 참고해 왜 이런현상이 발생했는지에 대한 분석을 작성한다.

 

(명확하지 않은 부분은 경험을 토대로 작성하였습니다. 이는 정확한 정보가 아닐 수 있음을 알려드립니다.)

참고자료

CERN calico 디버깅 PDF

728x90

---

 

 

파드 생성이 느려지거나, 무한 대기하는 경우

유휴 기간이 긴 노드를 스케줄링 상태로 변경하거나,
짧은 순간에 폭발적인 배포 상태를 상정한다.

IPAMBlock 충돌과 피드백 루프

노드의 calico CNI 로그를 점검한 결과, IPAMBlock 오류가 1초 간격으로 발생

 

"Error updating resource Key=IPAMBlock...the object has been modified; please apply your changes to the latest version and try again"

 

IPAMBlock은 Calico의 IP 주소 관리를 위한 CRD 리소스이다. Calico IPAM 플러그인이 파드에 IP를 할당할 때, 해당 IPAMBlock을 조회(GET)하고 IP를 선택한 뒤, IP 사용 중을 표시하기 위해 IPAMBlock을 업데이트(UPDATE)하려고 시도한다.

 

다수의 파드가 동시에 IP를 요청하고 동일한 IPAMBlock을 병렬적으로 업데이트하려고 할 때, 낙관적 잠금 실패가 발생하여 충돌이 다수 발생한다.

 

이 경우 노드에 POD 스케줄링이 불가능해지며, calico-node pod의 상태 또한 지속적인 crashloopbackoff 상태로 빠질 수 있다.

낙관적 잠금은 동시성 충돌이 드물다고 가정하고 읽기 시점에는 락을 잡지 않는다. 커밋 또는 갱신 시점에 버전이 바뀌었는지 확인해 바뀌었다면 충돌로 간주하고 갱신을 거부한다. 이때 발생하는 거부가 낙관적 잠금 실패다. 

 

출처: https://indico.cern.ch/event/968726/contributions/4125774/attachments/2153824/3632320/pod-throughput-calico.pdf

 

다만 이번 경우 낙관적 잠금 실패가 발생한 경우라고 단정짓기는 힘들며, 위와 비슷한 양상을 보이는 장애 정도로 생각된다.

 

짧은 시간 내 다수의 POD 스케줄링 상태와 update 되지 못한 잔존 IPAMblock에 의한 실패로 보이며 장기간 유휴 노드는 점진적인 스케줄링 혹은 uncordon 전 노드 재기동을 통한 리프레시를 진행하는것이 안전한 방법이라 생각된다.

---

중요

잘못된 정보나, 문의등은 댓글로 메일과 함께 적어주시면 감사하겠습니다.