쿠버네티스 네트워킹 문제 해결 완벽 가이드: CNI부터 Service Mesh까지 단계별 트러블슈팅
쿠버네티스(Kubernetes)는 현대 클라우드 네이티브 아키텍처의 핵심 축입니다. 컨테이너 오케스트레이션의 강력함 덕분에 수많은 개발자와 인프라 담당자들이 이 플랫폼을 사용하고 있죠. 하지만 이 강력함의 이면에는, 마치 미로와 같은 복잡한 네트워킹 레이어가 존재합니다. "왜 Pod A에서 Pod B로의 통신이 안 될까?", "Service IP는 정상인데 실제 트래픽이 안 가는 건 왜일까?"와 같은 질문은 모든 인프라 담당자가 한 번쯤 부딪히는 벽입니다.
쿠버네티스 네트워킹은 단순한 라우팅 이상의 문제입니다. IP 주소 할당, 서비스 디스커버리, 정책 기반 접근 제어(Policy Enforcement) 등 여러 계층이 얽혀있기 때문에, 문제가 발생했을 때 어느 지점부터 점검해야 할지 막막함을 느끼기 쉽습니다. 이 가이드는 여러분이 네트워킹 문제에 직면했을 때, 좌절하지 않고 체계적으로 원인을 좁혀나갈 수 있는 실전 트러블슈팅 로드맵을 제공합니다.
1. 쿠버네티스 네트워킹, 왜 이렇게 복잡한가? 기본 원리 재정립
쿠버네티스 환경에서 통신이 이루어지는 기본 흐름을 이해하는 것이 모든 문제 해결의 시작점입니다. 우리는 기본적으로 **L3(IP 주소 기반 라우팅)**와 **L4(포트 기반 통신)**의 개념을 이해하고, 이 위에 서비스 추상화 계층이 덧씌워진다고 생각해야 합니다.
Pod IP와 Service IP의 차이점 이해하기
가장 혼동하기 쉬운 부분은 Pod IP와 Service IP의 차이입니다.
- Pod IP: 각 Pod는 클러스터 내에서 유일한 실제 IP 주소를 가집니다. 이는 물리적인 네트워크 인터페이스에 할당된 주소와 유사합니다.
- Service IP: Service는 일종의 가상 안정적 엔드포인트입니다. 이 IP는 실제 Pod의 IP가 아니라, 해당 서비스에 접근할 수 있는 고정된 논리적 주소입니다. 쿠버네티스는 내부적으로
kube-proxy를 통해 이 Service IP로 들어오는 트래픽을 현재 활성화된 Pod IP들로 로드 밸런싱(Load Balancing) 해줍니다.
💡 실무자 경험 공유: 제가 가장 많이 겪는 실수는, Service IP가 정상이라고 안심하고 Pod IP를 직접 호출하는 경우입니다. Service를 거치지 않고 Pod IP를 직접 호출하면, 해당 Pod가 스케일 아웃(Scale Out) 되어 IP가 바뀌거나, 해당 Pod가 다운되면 통신이 즉시 끊깁니다. 항상 Service 추상화를 거치는 것이 원칙입니다.
CNI의 역할: 오버레이 네트워크의 이해
CNI(Container Network Interface)는 쿠버네티스 노드 간의 Pod 통신을 가능하게 하는 '실질적인 통신 다리' 역할을 합니다. CNI가 없다면, 각 노드의 Pod들은 서로의 IP 주소를 알 방법이 없습니다.
| CNI 종류 | 주요 작동 방식 | 트러블슈팅 포인트 |
|---|---|---|
| Flannel | VXLAN 기반 오버레이 네트워크 (가장 단순) | 오버레이 터널링 설정 문제, 네트워크 경로 제한 |
| Calico | BGP 기반 라우팅 (네이티브 라우팅 지향) | BGP 피어링 문제, 라우팅 테이블 누락 |
| Cilium | eBPF 기반 (커널 레벨 패킷 처리) | eBPF 맵(Map) 로딩 실패, 커널 버전 호환성 |
만약 통신이 안 된다면, 먼저 "이 CNI가 정상적으로 노드 간 라우팅 테이블을 구축했는지"를 의심해야 합니다.
2. 단계별 트러블슈팅 체크리스트: 통신 실패 시 점검 순서
네트워킹 문제가 발생했을 때, 이 순서대로 점검하는 것이 가장 효율적입니다.
🟢 1단계: Pod 레벨 확인 (가장 낮은 계층)
가장 먼저, 통신하려는 두 Pod가 실제로 통신할 수 있는 상태인지 확인합니다.
- IP 주소 확인: 두 Pod의 IP 주소를 확인하고, 해당 IP가 실제로 할당되었는지 확인합니다.
Bash
kubectl get pods --all-namespaces -o wide - 네트워크 연결성 테스트:
ping이나nc(netcat)을 사용하여 직접 통신을 시도합니다.Bash# 예시: Pod A에서 Pod B의 IP로 핑 테스트 kubectl exec -it <Pod_A_Name> -- ping <Pod_B_IP> - 노드 레벨 확인: 만약 Pod 간 통신이 안 된다면, 노드 레벨에서 라우팅이 제대로 되었는지 확인합니다. (SSH로 노드 접속 후)
Bash
ip route show # Pod IP 대역으로의 경로가 정상적으로 설정되어 있는지 확인
🟡 2단계: Service 레벨 확인 (추상화 계층)
Pod 간 통신이 되는데도 서비스 호출이 실패한다면, Service 정의나 kube-proxy 문제를 의심해야 합니다.
- Service 정의 검토:
selector가 실제 Pod의 레이블과 정확히 일치하는지 확인합니다.YAML# YAML 확인: selector: app=backend 이 실제 Pod의 label app=backend 와 일치해야 함 - Endpoint 확인: Service가 바라보는 실제 엔드포인트 목록을 확인합니다.
만약Bash
kubectl get endpoints <service-name> -n <namespace><service-name>: <IP:Port>목록이 비어있다면, Service가 어떤 Pod도 찾지 못하고 있다는 의미입니다.
🔴 3단계: 정책 및 경계 레벨 확인 (가장 높은 계층)
위 두 단계가 모두 정상이라면, 외부 정책이나 방화벽이 트래픽을 차단하고 있을 가능성이 큽니다.
- NetworkPolicy 검토: 가장 흔한 원인입니다. 특정 네임스페이스나 Pod에 대해 명시적인
NetworkPolicy가 적용되어 있다면, 해당 정책이 허용하는 포트와 소스/목적지를 벗어난 트래픽은 모두 차단됩니다.- 점검:
kubectl get netpol -n <namespace>명령어로 정책 목록을 확인하고,Ingress와Egress규칙을 점검해야 합니다.
- 점검:
- 네트워크 정책 (CNI): 사용 중인 CNI(Calico, Cilium 등)가 강제하는 네트워크 정책이 있는지 확인해야 합니다.
🚀 심화 분석: 트러블슈팅 시나리오별 접근법
| 문제 현상 | 의심 원인 | 해결 방법 |
|---|---|---|
| "Connection Refused" | 1. 서비스가 다운됨. 2. 포트가 열리지 않음. | kubectl get pods 확인. netstat 또는 ss로 포트 리스닝 확인. |
| "Timeout" | 1. 방화벽(Security Group/NetworkPolicy)에서 차단. 2. 라우팅 문제. | 네트워크 흐름 분석 도구 사용. CNI 정책 검토. |
| "No Route to Host" | 1. Service IP가 잘못 라우팅됨. 2. Service Mesh 설정 오류. | Service IP와 실제 Pod IP 간의 라우팅 테이블 확인. |
이 가이드를 통해, 단순한 애플리케이션 오류가 아닌, 인프라 레벨의 네트워킹 문제를 체계적으로 진단하고 해결할 수 있을 것입니다.
이 글은 AI 에이전트가 1차 초안을 작성한 뒤, 사람 편집자가 사실관계·출처·톤과 맥락을 검토하여 발행했습니다. 오류나 부정확한 내용이 확인되면 24시간 이내에 정정합니다.
댓글
불러오는 중...