CNI 이슈로 인한 간헐적 http 요청 실패

[이슈] 내부/외부 http 통신이 간헐적으로 실패한다. 구조상 치명적이였음 (거대한 json 주고받기 때문에) ->> TCP 덤프, LB로그, 방화벽로그

• 웹 앱 입장에서는 찍히지도 않고 안들어오는데, 보내는 측에서는 연결실패로 뜨니까 둘다 황당

[원인] Cilium + CoreDNS 조합이슈

• 간헐적 timeout → 사실은 DNS resolve 실패
• policy mismatch → silently drop 임
• 원인은 eBPF 기반 라우팅(kube-proxy replacement) 버그때문

[해결법]

• Calico = 안정적이고 전통적인 네트워크 (iptables 기반)으로 변경
• iptables 많아지면 성능 떨어짐 / 실리움은 L7정책도 가능한데, 칼리코여서 L3&4정책만 가능

Q2. "CNI 이슈, 자세히 설명해주세요" ⭐ 최우선

이건 6단계 구조로 외우세요. 아래는 뼈대이고, [ ] 부분은 본인 기억으로 채우셔야 합니다.

① 증상 "대규모 데이터 마이그레이션 배치를 돌리는데 간헐적으로 소켓이 끊겼습니다. 전체가 아니라 [N%] 정도였고, 재실행하면 통과하는 경우가 있어서 처음엔 애플리케이션 타임아웃으로 의심했습니다."

② 애플리케이션이 아니라고 판단한 근거 "[커넥션 풀 설정, 타임아웃 값, 재시도 로직]을 먼저 확인했는데 설정상 나올 수 없는 시점에 끊겼습니다. 그리고 애플리케이션 로그에는 정상 요청 후 응답 없이 끊긴 것으로 남았습니다. 요청은 나갔는데 응답이 안 온 거라 그 사이 구간, 즉 네트워크를 봐야 한다고 판단했습니다."

③ 관측 방법 "[tcpdump로 양쪽 패킷을 떠서 비교 / conntrack 테이블 확인 / Hubble로 드롭 관측] 했습니다. [어느 쪽에서 RST가 나갔는지 / 커넥션이 어디서 사라졌는지]를 확인하니 애플리케이션이 보낸 적 없는 종료였습니다."

④ 근본 원인 "Cilium [버전]의 [eBPF 맵 / conntrack 처리 / NAT 테이블] 관련 이슈였습니다. [장시간 유지되는 커넥션 / 특정 부하 조건]에서 커넥션 추적 정보가 유실되면서 정상 세션이 끊기는 문제였습니다."

⑤ 조치 "패치 버전 대기와 CNI 전환을 두고 검토했는데, [일정·지원 상황] 때문에 성숙도가 높은 Calico로 전환하기로 했습니다. 전환은 [노드 순차 교체 / 신규 노드풀 생성 후 워크로드 이관] 방식으로 진행했고, [롤백 계획 / 검증 절차]를 준비했습니다."

⑥ 재발 방지 "[커넥션 관련 지표 알람 추가 / 배치 실행 이력 로깅 / 장애 회고 문서화]로 같은 증상이 재발하면 바로 네트워크 계층을 의심할 수 있게 했습니다."

꼬리 질문 대비:

질문 답변 방향 eBPF와 iptables 차이가 뭔가요? iptables는 룰이 선형 증가해 O(n) 탐색, 서비스 많아지면 지연. eBPF는 커널에 프로그램을 붙여 해시맵 조회로 처리, kube-proxy 대체 가능. Cilium은 XDP로 NIC 단계에서 경로 단축까지 함 왜 Cilium 패치를 안 기다렸나요? 트레이드오프로 답하세요. "성능 이점보다 안정성이 우선인 배치 워크로드였고, 일정 리스크를 감수하기 어려웠습니다. 신규 클러스터였다면 Cilium을 유지하고 패치를 기다렸을 겁니다" 전환 중 무중단은 어떻게? 노드 단위 순차 교체 + PDB로 최소 가용 파드 보장 + 검증 후 다음 노드 지금 다시 한다면? "Hubble로 드롭을 먼저 봤을 겁니다. 그때는 tcpdump부터 갔는데 관측 도구를 먼저 세웠으면 며칠 줄였을 것 같습니다" ← 이 답변이 성숙도를 보여줍니다