쿠버네티스 네트워킹 완벽 가이드: CNI 원리부터 Istio/Linkerd 도입 전략까지

쿠버네티스(Kubernetes)는 현대 클라우드 네이티브 아키텍처의 핵심입니다. 수많은 마이크로서비스를 컨테이너 단위로 배포하고 관리하는 이 시스템은 그 강력함만큼이나 '네트워킹'이라는 블랙박스를 가지고 있습니다. "서비스 A가 서비스 B를 호출할 때, 내부적으로 정확히 어떤 경로로, 어떤 규칙을 거쳐 통신하는 걸까?" 이 질문에 답하는 것이 바로 쿠버네티스 네트워킹의 핵심입니다.

이 가이드는 단순히 kubectl get svc 명령어로 보이는 서비스 이름 뒤에 숨겨진, 컨테이너 간의 통신 원리부터 트래픽 제어의 최전선인 Service Mesh 도입 전략까지, 인프라 아키텍트와 DevOps 엔지니어가 반드시 알아야 할 깊이 있는 내용을 다룹니다.

쿠버네티스 네트워킹의 기초: Pod IP와 Service IP의 차이점

쿠버네티스 환경에서 서비스 통신을 이해하려면 세 가지 주소 개념을 명확히 구분해야 합니다.

1. Pod IP (실제 통신 주소): 각 Pod는 클러스터 내에서 고유한 IP 주소를 할당받습니다. 이 IP는 가장 낮은 레벨에서 실제 트래픽이 도달하는 지점입니다.
2. Service IP (추상화된 주소): 사용자가 애플리케이션 코드에서 호출하는 주소입니다. Service는 여러 Pod에 걸쳐 로드 밸런싱을 제공하는 '가상' IP 역할을 합니다.
3. ClusterIP: Service가 클러스터 내부에서 접근 가능한 고정된 내부 IP입니다. 외부에서는 접근할 수 없습니다.

이러한 추상화 덕분에, 개발자는 Pod의 IP가 언제 바뀌든 신경 쓸 필요 없이 my-service:8080과 같이 일관된 이름으로 통신할 수 있게 됩니다.

CNI: 네트워크의 설계자이자 실행자

그렇다면 이 IP 할당과 라우팅은 누가 담당할까요? 바로 **CNI (Container Network Interface)**입니다.

CNI는 쿠버네티스 자체가 아니라, 컨테이너 런타임(예: Containerd)과 쿠버네티스 컨트롤 플레인 사이에 위치하여 '네트워크 플러그인' 역할을 수행합니다. CNI는 노드(Node)에 접속하여 다음과 같은 작업을 수행합니다.

1. IP 할당: Pod가 생성될 때, CNI 플러그인이 작동하여 해당 Pod에 유효한 IP 주소를 할당합니다.
2. 네트워크 정책 적용: 네트워크 폴리시(Network Policy)에 따라 통신 가능/불가능한 규칙을 설정합니다.
3. 라우팅 규칙 구성: 해당 Pod가 클러스터 내 다른 Pod들과 통신할 수 있도록 노드 레벨의 라우팅 테이블을 설정합니다.

💡 CNI 동작 원리 시각화 (개념적 흐름):

[외부 요청] $\rightarrow$ [Node A의 Kube-proxy/CNI] $\rightarrow$ [Service IP (Virtual)] $\rightarrow$ [CNI가 설정한 라우팅 규칙] $\rightarrow$ [실제 Pod IP (Node B)] $\rightarrow$ [Pod 애플리케이션]

이 과정은 마치 고도로 정교하게 설계된 '도로망'과 같습니다. CNI가 도로의 설계도와 신호 체계를 구축하는 것이죠.

서비스 통신을 한 단계 업그레이드하는 Service Mesh의 필요성

기본적인 쿠버네티스 네트워킹은 **'연결성(Connectivity)'**을 보장합니다. 즉, A가 B에게 도달할 수 있게 해줍니다. 하지만 현대의 복잡한 마이크로서비스 환경에서는 단순한 연결성만으로는 부족합니다.

우리는 다음과 같은 요구사항에 직면합니다.

• 관측성(Observability): "어떤 요청이 실패했는지, 왜 실패했는지, 어느 단계에서 병목 현상이 생겼는지"를 애플리케이션 코드 수정 없이 알아야 합니다.
• 트래픽 제어: "신규 버전(v2)을 전체 트래픽의 10%만 받아보게 하고, 문제가 생기면 즉시 롤백"하고 싶습니다 (Canary Deployment).
• 보안: 모든 서비스 간 통신은 암호화되어야 합니다 (mTLS).

이러한 복잡한 트래픽 제어 로직을 애플리케이션 코드(Java, Python 등)에 직접 구현하는 것은 재앙입니다. 코드가 비즈니스 로직에 오염되고, 모든 언어별로 구현해야 하는 오버헤드가 발생합니다.

Service Mesh는 이 문제를 해결하기 위해 등장했습니다. Service Mesh는 서비스 간의 통신 계층(Sidecar Proxy)을 가로채서, 네트워킹, 보안, 관측성 관련 로직을 플랫폼 레벨에서 처리하도록 분리해주는 인프라 계층입니다.

Sidecar 패턴과 L4 vs L7 제어 이해하기

Service Mesh의 핵심 구현 방식은 Sidecar 패턴입니다. 각 애플리케이션 Pod 옆에 별도의 프록시 컨테이너(Sidecar)를 붙여서, 모든 인바운드/아웃바운드 트래픽을 이 프록시를 통과시키게 만듭니다.

이 구조 덕분에 우리는 트래픽을 **L4(전송 계층)**와 L7(응용 계층) 두 가지 관점에서 제어할 수 있습니다.

Service Mesh는 Sidecar 프록시를 통해 L7 레벨의 HTTP 헤더 정보를 읽어내기 때문에, "특정 헤더를 가진 요청만 백엔드 A로 보내고, 나머지는 백엔드 B로 보내라"와 같은 정교한 제어가 가능해집니다.

실전 비교: Istio vs. Linkerd

현재 시장을 주도하는 대표적인 서비스 메시 솔루션은 Istio와 Linkerd입니다.

• Istio: 가장 기능이 풍부하며, 강력한 정책 제어(Authorization Policy)와 복잡한 트래픽 관리(VirtualService)가 가능합니다. 학습 곡선이 가파르지만, 가장 많은 시나리오를 커버합니다.
• Linkerd: 가볍고 사용하기 쉬운 것이 강점입니다. 트래픽 관리의 복잡성보다는 안정적인 서비스 디스커버리, 자동 메트릭 수집에 초점을 맞춥니다.

결론: 언제 무엇을 사용해야 하는가?

1. 단순한 통신 및 안정성 확보: Linkerd가 더 적합할 수 있습니다.
2. 복잡한 트래픽 분할 및 정책 제어: Istio가 더 강력한 옵션입니다.

💡 요약 정리: