"유령" 인터페이스. Calico v3.24의 BIRD CPU 100% 이슈

어느 날부턴가 calico-node가 간헐적으로 NotReady 상태로 전환되는 이상한 현상이 발생했다. 처음에는 단순히 한 노드에서만 나타났고, 서비스에 큰 문제가 없어 "뭐지?" 하고 넘겼다. 그런데 시간이 지나니 다른 노드들까지 하나둘씩 NotReady 상태로 변해버렸다. 마치 퍼지는 전염병처럼 말이다!

 

🚨 이슈

알고 보니 calico-node에서 동작하는 BIRD 프로세스의 CPU 사용률이 점점 높아지면서, readinessProbe에 설정된 calico-node -bird-ready 명령어의 응답이 느려지고 있었다. 그 결과로 노드의 상태는 하나둘씩 NotReady로 전환되는 일이 벌어진 것이다. 

 

🔍 원인

https://github.com/projectcalico/bird/pull/104

nest/iface.c: Determine if the iface passed by the if_update() functi… by splitice · Pull Request #104 · projectcalico/bird

사용 중이던 calico v3.24 버전의 BIRD는 SHUTDOWN된 인터페이스 정보를 삭제하지 않고, iface_list에 계속 쌓아두는 습관(?)을 가지고 있었다는 것! 🧟‍♂️

 

이때 쿠버네티스 환경에서는 매 분마다 생성되고 삭제되는 크론잡(CronJob) 파드가 있었는데, 이 파드가 매번 사라진 인터페이스의 수를 계속 늘려버렸다. 그 결과 간헐적으로 CPU 사용률이 100%까지 치솟게 되었고, 그때마다 -bird-ready 응답이 지연되는 일이 반복되었다. 말 그대로 인터페이스의 '유령 군단'이 CPU를 괴롭히고 있었던 셈이다! 👻

 

🧪 확인방법

2024.09.25 - [K8S/network] - Calico 트러블슈팅 가이드: BIRD 프로세스에 SIGUSR1 신호 보내기

Calico 트러블슈팅 가이드: BIRD 프로세스에 SIGUSR1 신호 보내기

 

 

가이드를 참고하여 BIRD 프로세스를 디버깅하면 iface_list의 상태를 볼 수 있다.

그리고 다음 명령어를 실행해보자

$ grep "IFO" calico-dump.txt | wc -l
약 10만개

 

놀랍게도 약 10만 개의 인터페이스 정보가 보관되어 있는 걸 확인할 수 있었다. 10만 개라니

 

🔧 해결방법

이 문제를 해결하려면 최소 calico v3.27 버전 이상을 사용해야 한다.

 

참고로, BIRD는 BGP 통신을 담당하고 있기 때문에 VxLAN 구성으로 사용할 때는 이 이슈가 발생하지 않는다.