쿠버네티스에서 “Pod끼리 통신된다”는 사실은 알고 있지만, 막상 운영/장애 대응 단계에서는 CNI·Service·관측 도구의 책임 경계가 흐려져 문제가 커지곤 합니다. 이 글에서는 Pod 통신의 핵심 개념을 레이어별로 정리하고, Pod IP 직접 통신 vs Service 기반 통신의 트레이드오프를 운영 관점에서 정리해봅니다.
1) Pod는 왜 “각자 IP”를 가질까? (기본 전제: Flat 네트워크)
쿠버네티스의 중요한 네트워킹 전제는 **“각 Pod는 고유한 Pod IP를 가지며, 클러스터 내부에서는 Pod IP로 서로 직접 통신할 수 있다”**입니다. 여기서 핵심은 “직접”이 NAT 없이(end-to-end) 라는 점입니다.
- 같은 노드 내 Pod 간 통신: 보통 CNI가 만든 브리지/가상 인터페이스(veth) 등을 통해 연결됩니다.
- 다른 노드 간 Pod 통신(크로스노드): Calico/Flannel/Cilium 같은 CNI 플러그인이 노드 간 라우팅(혹은 오버레이)을 구성해 클러스터 전반에 Flat 네트워크처럼 보이게 만듭니다.
즉, “Pod-to-Pod 통신”은 애플리케이션 이전에 클러스터 네트워크(CNI)가 성립시키는 능력입니다.
2) Pod-to-Pod 레이어 vs Service 레이어: “레이어가 다르니 관리도 다르다”의 의미
대화에서 나왔던 포인트를 제 관점으로 다시 정리하면 이렇습니다.
Pod-to-Pod (주로 L3/L4 성격)
Pod IP 기반 통신은 본질적으로 네트워크 레이어(L3/L4)에 가깝습니다.
- 라우팅이 되는가? (노드 간 라우팅/오버레이 정상 여부)
- 방화벽/보안그룹/NetworkPolicy에 막히는가?
- DNS 문제가 아니라 “패킷 자체가 안 가는” 상태인가?
- egress/SNAT/노드 정책으로 인해 외부로 나갈 때 깨지지 않는가?
이 레이어는 보통 플랫폼/SRE 영역에서 책임지고, 장애가 나면 “서비스가 왜 느리냐”가 아니라 **“패킷이 어디서 끊기냐”**로 내려가게 됩니다.
Service 기반 통신 (주로 디스커버리 + 가상 엔드포인트)
반면 Service는 Pod가 가진 “휘발성 IP” 문제를 덮어주는 안정적 엔드포인트입니다.
- Pod는 재생성되면 Pod IP가 바뀔 수 있음
- Service는 selector로 Pod를 묶고, ClusterIP/DNS 이름으로 안정적인 접근을 제공
- kube-proxy(iptables/IPVS) 등의 구현을 통해 트래픽을 엔드포인트로 분산
정리하면,
- Pod 네트워크 레이어는 ‘연결성/정책/격리/경로’
- Service 레이어는 ‘디스커버리/안정성/로드밸런싱’
에 더 가깝습니다.
이 둘은 “기능이 다르기 때문에 운영 관점에서 관측 포인트와 책임 경계도 분리”하는 게 합리적입니다.
3) 왜 Pod IP 직접 통신만으로 운영하면 위험해질까?
Pod IP는 “통신 가능”의 단위이지 “운영 가능”의 단위는 아닌 경우가 많습니다.
- Pod 재스케줄링/재시작으로 IP가 변경
- 클라이언트가 특정 Pod IP를 고정으로 참조하면 장애 복구 시 더 큰 장애가 됩니다
- 노드 간 라우팅, NetworkPolicy, 노드 방화벽 등 변수가 많아 “된다/안 된다”가 환경 의존적으로 바뀝니다
그래서 일반적으로 내부 통신은 Pod IP를 ‘직접 쓰기’보다 Service를 통해 안정화하는 패턴이 표준이 됩니다.
4) 그렇다면 “Pod IP 직접” vs “Service”는 언제 선택할까? (트레이드오프)
실무에서 중요한 건 “무조건 Service” 같은 교조가 아니라, 안정성·성능·운영 복잡도 관점에서의 균형입니다.
(1) 안정성: 기본값은 Service가 유리합니다
- Service는 Pod 교체/확장/축소를 흡수합니다.
- 운영 중 Pod가 바뀌는 것이 정상인 쿠버네티스에서 접근점을 고정하는 효과가 큽니다.
권장 판단: “엔드포인트가 바뀌어도 클라이언트는 몰라야 한다”면 Service가 기본 선택입니다.
(2) 성능: Pod IP 직접이 빠를 때가 있지만, 일관성이 더 중요합니다
- Service는 구현에 따라 iptables/IPVS 룰, 로드밸런싱 경로가 추가됩니다.
- 다만 대부분의 서비스에서 이 오버헤드는 “병목”이라기보다 운영 안정성으로 상쇄되는 비용인 경우가 많습니다.
권장 판단: 초저지연/초고성능이 절대 조건인 일부 트래픽(예: 특정 데이터플레인)만 예외로 보고, 나머지는 Service로 표준화하는 편이 보통 낫습니다.
(3) 운영 복잡도: Service로 “통일”하면 편하지만, 장애 원인은 더 아래에 있을 수 있습니다
대화에서 나온 포인트처럼, 장애 트레이싱은 APM으로 많이 해결하지만 APM이 커버 못 하는 실패 지점이 있습니다.
- APM 관점: “요청이 타임아웃 났다”
- 실제 원인: CNI/NetworkPolicy/DNS/CoreDNS/kube-proxy/노드 방화벽/SNAT 등
즉, Service를 쓴다고 해서 네트워크 문제가 사라지는 게 아니라, 표면을 안정화할 뿐이고 아래 레이어(CNI/Policy)의 문제가 터지면 여전히 장애가 납니다.
여기서 요즘 eBPF가 주목받는 이유가 자연스럽게 연결됩니다.
- APM은 애플리케이션 계측이 전제(헤더 전파, 샘플링, 누락 없는 instrumentation)
- eBPF는 커널 레벨에서 소켓/패킷 이벤트를 관측하여 계측 누락 없이 병목 구간을 좁히는 데 도움
- 다만 eBPF 도입은 커널 호환성, 권한, 운영 복잡도 같은 비용도 동반합니다
권장 판단: “APM으로 원인이 안 좁혀지는 네트워크 장애”가 자주 발생한다면, eBPF 기반 관측(Cilium/Hubble 등)을 플랫폼 레이어에 붙이는 ROI가 커집니다.
5) 면접/실무에서 “Pod 통신”을 한 문단으로 설명한다면
제가 면접에서 이 주제를 정리한다면 보통 다음 흐름으로 말합니다.
- Pod는 고유 Pod IP를 가진다
- 같은 노드/다른 노드 모두 CNI가 클러스터 전반 Flat 네트워크를 구성해 Pod IP로 직접 통신 가능하게 만든다(일반적으로 Pod 간 NAT 없음)
- 다만 Pod IP는 바뀔 수 있으므로, 안정적 엔드포인트는 보통 Service로 제공한다
- 장애/운영에서는 Pod 네트워크(CNI/Policy)와 Service(kube-proxy/Endpoint) 레이어를 분리해 관측하고, APM이 못 보는 구간은 eBPF 같은 커널 관측으로 보완할 수 있다
이 정도가 핵심을 놓치지 않으면서도 “단순 사용자가 아니라 운영 관점으로 이해하고 있다”는 인상을 주기 좋았습니다.
마무리
쿠버네티스 Pod 통신은 “Pod IP로 된다”에서 끝나지 않고, **CNI가 만드는 연결성(아래 레이어)**과 **Service가 제공하는 안정화(위 레이어)**를 구분해 운영하는 순간부터 난이도가 달라집니다. 저는 이 둘의 레이어를 분리해 이해하면 트러블슈팅에서도 “APM → Service → CNI/Policy”로 탐색 순서가 정리되어 훨씬 빠르게 원인에 접근할 수 있었습니다.
