
아래 환경, 상황에서 겪은 문제를 손쉽게 해결한 후에 작성된 게시글입니다.
환경 : kubespray로 신규 구축한 HA Kubernetes 클러스터
상황 : 서로 다른 노드에 있는 파드 간 통신 안됨
해결 방법 : BPG Route 모드의 calico-cni를 위한 calico-backend bird 활성화[1]
calico_network_bird: bird
트러블 슈팅
신규 구축한 클러스터에서 lookup timeout 이슈 발생
아래 환경을 배포한 이후에 테스트하니 nslookup timeout 발생
[목적지] nginx svc + deploy 오브젝트를 test ns에 배포
[출발지] nicolaka/netshoot 이미지를 pod로 test ns에 배포
nslookup nginx.test.svc.cluster.local
/etc/resolv.conf를 확인하였으나 이상없음
search test.svc.cluster.local svc.cluster.local cluster.local
nameserver 10.96.0.10
options ndots:5
이후 nodelocaldns, coredns 로그 확인했으나 lookup timeout만 출력됨
아래를 구분하기 위해 coredns 파드를 워커 노드 당 1개씩 스케줄링
노드 내 통신이 안되나?
노드 간 통신이 안되나?
포워딩 설정이 있는지 확인
(kube-proxy 모드가 ipvs가 아니라면 모드 확인 후 다른 스크립트 쓸 것)
sudo ipvsadm -n -L | grep 10.96.0.10
TCP 10.96.0.10:53
-> A pod clusterip Masq 1 0 4
-> B pod clusterip Masq 1 0 5
...
-> N pod clusterip Masq 1 0 5
TCP 10.96.0.10:9153
-> A pod clusterip Masq 1 0 0
-> B pod clusterip Masq 1 0 0
...
-> N pod clusterip Masq 1 0 0
UDP 10.96.0.10:53
-> A pod clusterip Masq 1 0 0
-> B pod clusterip Masq 1 0 0
...
-> N pod clusterip Masq 1 0 0
N개의 노드에 최소 1개씩 분산되어 있는 CoreDNS 배포
0이 아닌 값이 나오면 성공한 것이고 그렇지 않으면 timeout으로 가주
통신 길이가 길다면 --max-time 을 늘릴 수 있지만 0.5~1로도 충분
for i in {1..N}; do curl -s 10.96.0.10:9153/metrics --max-time 0.5 | wc -l; done
N-1번은 실패하고 1번은 응답에 성공하는 현상으로 보아 노드 간 통신이 안되는 것으로 추정. 혹시 모르니 pod clusterip로도 직접 요청
curl -s A-pod-clusterip:9153/metrics
curl -s B-pod-clusterip:9153/metrics
...
curl -s N-pod-clusterip:9153/metrics
결국 calico 쪽에 문제가 있는 것으로 보이지만
정작 calcio-node에는 별도의 에러 로그가 보이지 않음(기억상..)
따라서 C번 워커 노드에 접속해서 calicoctl로 calico-node 상태 확인
sudo calicoctl node status
+--------------+-----------+-------+-------+------+
| PEER ADDRESS | PEER TYPE | STATE | SINCE | INFO |
+ -------------+-----------+-------+-------+------+
구글링 이후 아래 옵션을 활성화
calico_network_bird: bird
활성화 이후 다시 C번 노드에서 확인
sudo calicoctl node status
+--------------+-------------------+-------+------------+-------------+
| PEER ADDRESS | PEER TYPE | STATE | SINCE | INFO |
+ -------------+-------------------+-------+------------+-------------+
| A | node-to-node mesh | up | 2025-06-18 | Established |
| B | node-to-node mesh | up | 2025-06-18 | Established |
| D | node-to-node mesh | up | 2025-06-18 | Established |
| E | node-to-node mesh | up | 2025-06-18 | Established |
| ... | ... | up | 2025-06-18 | Established |
| N | node-to-node mesh | up | 2025-06-18 | Established |
+--------------+-------------------+-------+------------+-------------+
원인 분석
BGP Route 방식으로 네트워크 라우팅을 하는 Calico는 백앤드로 Bird가 필요합니다.
BGP Route를 사용하면
Routing Table을 통해서 통신하며 이는 Tunneling을 하지 않아서
Encapsulation/Decapsulation이 줄어들어서 훨씬 가볍고 빠르게 작동합니다.
대신 이를 위해서 백앤드가 필요하고
백앤드가 없으면 통신이 되지 않으며
그 백앤드가 bird라는 친구입니다.
다른 블로그들 몇개 첨부만 합니다.
한 걸음 더 : BGP Route
BRP Route는 라우팅 정보를 교환하는 표준 프로토콜입니다.
BGP Peer(calico-node) 들 간의 라우팅 정보를 교환하는 역할을 합니다. [1]
한 걸음 더 : Bird
BGP Route를 사용하기 위해서 필요한 백앤드 프로그램입니다. [1]
마지막 의문 : 해결 안됨
이미 이슈가 해결되어서 버려서 미결 의문으로 남아있습니다.
BGP Route가 없으면 Tunneling으로 동작할 것 같은데,,,
왜 노드간 통신이 안되었을까요?
나중에 비슷한 문제를 만나면 설정을 다시 뜯어봐야겠습니다.