Kubernetes 에서 사용되는 대표적인 CNI 중 하나인 Cilium 프로젝트에서 아주 작은 코드 변경이 네트워크 안정성에 미친 큰 효과를 설명하는 기술 사례입니다. 핵심 내용을 요약하면 다음과 같습니다.
NAT(Network Address Translation): 하나의 공인 IP로 여러 사설 IP 기기가 인터넷 통신할 수 있게 해주는 기술. 공유기, 쿠버네티스 노드 등에서 사용.
쿠버네티스는 복잡한 NAT 조합(SNAT, DNAT)을 사용하여 통신을 중개. 쿠버네티스 내 NAT 활용
기존 리눅스 iptables/conntrack 대신 eBPF 기반 NAT 구현.
NAT 테이블을 LRU Hash Map으로 관리.
하나의 커넥션에 대해 정방향(ORG)과 역방향(REV) 엔트리 두 개를 저장.
이유: 요청과 응답 패킷이 src/dst가 바뀌므로 빠른 조회를 위해 두 방향 모두 저장.
LRU 특성상 메모리 부족 시 엔트리 일부가 삭제(evict) 됨.
정방향과 역방향 엔트리 중 하나라도 사라지면 NAT 매핑 실패 → 커넥션 끊김.
특히 장기 연결이나 부하 상황에서 불안정성 초래.
관련 PR: #35304 #37747
아이디어: "패킷이 어느 방향이든 한번 관측되면, 그 역방향 엔트리도 함께 복원(갱신) 하자."
즉, 한쪽 엔트리가 LRU로 사라졌더라도, 반대방향 패킷이 오면 양쪽 엔트리를 모두 다시 넣어줌. 결과적으로 엔트리 유실 확률이 크게 줄어들고, NAT 매핑이 유지되어 커넥션 안정성 향상.
코드 변경량은 if문 하나 추가 수준이지만, 네트워크 안정성에 미치는 영향은 매우 큼. 단순한 아이디어로 복잡한 시스템의 신뢰성을 크게 개선한 사례. 벤치마크 결과, 커넥션 유실이 현저히 줄어듦.
작은 개선이 시스템 안정성에 미치는 큰 효과를 보여주는 사례. eBPF, 쿠버네티스, NAT 등 복잡한 기술 스택 내에서 기본 원리에 충실한 단순한 해결책이 효과적일 수 있음을 시사.
근본 원인은 NAT 테이블 크기 부족 → 크기 늘리면 회피 가능. 하지만 근본적이고 우아한 해결책은 아니므로, 이번 개선이 더 바람직.
글쓴이는 이 사례를 통해 기초 지식의 중요성과 작은 아이디어의 힘을 강조.