Kubernetes 네트워킹
마지막 업데이트: 2026년 2월 22일
개요
Kubernetes 네트워킹은 컨테이너화된 애플리케이션 간의 통신을 가능하게 하는 핵심 인프라 계층입니다. 이 섹션에서는 Kubernetes 네트워킹의 기본 개념부터 고급 CNI(Container Network Interface) 솔루션, 그리고 AWS EKS 환경에서의 네트워킹 패턴까지 다룹니다.
Kubernetes 네트워킹 모델
Kubernetes는 다음과 같은 네트워킹 요구사항을 기반으로 설계되었습니다:
- 모든 Pod는 NAT 없이 다른 모든 Pod와 통신할 수 있어야 함
- 모든 노드는 NAT 없이 모든 Pod와 통신할 수 있어야 함
- Pod가 자신을 보는 IP와 다른 Pod가 그 Pod를 보는 IP가 동일해야 함
Pod 네트워킹
Pod 네트워킹은 Kubernetes 네트워킹의 가장 기본적인 계층입니다. 각 Pod는 고유한 IP 주소를 가지며, 클러스터 내의 다른 모든 Pod와 직접 통신할 수 있습니다.
Pod 네트워킹 구현 방식
| 방식 | 설명 | 예시 CNI |
|---|---|---|
| Overlay 네트워크 | 기존 네트워크 위에 가상 네트워크 구성 | Flannel (VXLAN), Calico (IPIP), Weave Net |
| 언더레이 네트워크 | 물리 네트워크에 직접 라우팅 | AWS VPC CNI, Calico (BGP), Cilium (Native Routing) |
| 하이브리드 | 환경에 따라 오버레이/언더레이 선택 | Cilium, Calico |
Service 네트워킹
Service는 Pod 집합에 대한 안정적인 네트워크 엔드포인트를 제공합니다.
Service 유형별 특징
# ClusterIP Service 예시
apiVersion: v1
kind: Service
metadata:
name: my-service
namespace: default
spec:
type: ClusterIP
selector:
app: my-app
ports:
- protocol: TCP
port: 80
targetPort: 8080
---
# NodePort Service 예시
apiVersion: v1
kind: Service
metadata:
name: my-nodeport-service
spec:
type: NodePort
selector:
app: my-app
ports:
- protocol: TCP
port: 80
targetPort: 8080
nodePort: 30080 # 30000-32767 범위
---
# LoadBalancer Service 예시
apiVersion: v1
kind: Service
metadata:
name: my-loadbalancer-service
annotations:
service.beta.kubernetes.io/aws-load-balancer-type: "nlb"
spec:
type: LoadBalancer
selector:
app: my-app
ports:
- protocol: TCP
port: 443
targetPort: 8443Ingress 네트워킹
Ingress는 HTTP/HTTPS 트래픽을 클러스터 내부 Service로 라우팅하는 규칙을 정의합니다.
# Ingress 예시
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: my-ingress
annotations:
kubernetes.io/ingress.class: "alb"
alb.ingress.kubernetes.io/scheme: "internet-facing"
spec:
rules:
- host: api.example.com
http:
paths:
- path: /v1
pathType: Prefix
backend:
service:
name: api-v1
port:
number: 80
- path: /v2
pathType: Prefix
backend:
service:
name: api-v2
port:
number: 80
- host: web.example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: web-frontend
port:
number: 80CNI (Container Network Interface)
CNI는 컨테이너 네트워크 연결을 위한 표준 인터페이스입니다. Kubernetes는 CNI 플러그인을 통해 Pod 네트워킹을 구현합니다.
CNI 동작 방식
CNI 플러그인 구성 요소
CNI 비교 매트릭스
주요 CNI 솔루션 비교
| 기능 | Cilium | Calico | Flannel | AWS VPC CNI | Weave Net |
|---|---|---|---|---|---|
| 기반 기술 | eBPF | iptables/eBPF | VXLAN/host-gw | AWS ENI | VXLAN |
| Network Policy | ✅ 고급 (L3-L7) | ✅ 고급 (L3-L4) | ❌ | ✅ 기본 (L3-L4) | ✅ 기본 |
| 암호화 | ✅ WireGuard/IPsec | ✅ WireGuard/IPsec | ❌ | ❌ | ✅ 내장 |
| Service Mesh | ✅ 내장 | ❌ | ❌ | ❌ | ❌ |
| Observability | ✅ Hubble | ⚠️ 제한적 | ❌ | ❌ | ❌ |
| BGP 지원 | ✅ | ✅ | ❌ | ❌ | ❌ |
| 멀티클러스터 | ✅ ClusterMesh | ✅ Federation | ❌ | ❌ | ✅ |
| Windows 지원 | ⚠️ 베타 | ✅ | ✅ | ✅ | ✅ |
| 성능 | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ |
| 복잡도 | 중간-높음 | 중간 | 낮음 | 낮음 | 낮음 |
| 커뮤니티 | 활발 | 매우 활발 | 활발 | AWS 지원 | 보통 |
상세 기능 비교
네트워킹 모드
| CNI | Overlay | Native Routing | BGP | Direct Routing |
|---|---|---|---|---|
| Cilium | VXLAN, Geneve | ✅ | ✅ | ✅ |
| Calico | VXLAN, IPIP | ✅ | ✅ | ✅ |
| Flannel | VXLAN | host-gw | ❌ | ❌ |
| AWS VPC CNI | ❌ | VPC Native | ❌ | ✅ |
| Weave Net | VXLAN | ❌ | ❌ | ❌ |
Network Policy 기능
| 기능 | Cilium | Calico | AWS VPC CNI |
|---|---|---|---|
| Ingress Policy | ✅ | ✅ | ✅ |
| Egress Policy | ✅ | ✅ | ✅ |
| L7 Policy (HTTP) | ✅ | ❌ | ❌ |
| DNS-based Policy | ✅ | ✅ | ❌ |
| FQDN Policy | ✅ | ✅ | ❌ |
| Host Policy | ✅ | ✅ | ❌ |
| Global Policy | ✅ | ✅ | ❌ |
| Policy Tiers | ✅ | ✅ | ❌ |
성능 벤치마크 (상대적 비교)
CNI 선택 가이드
의사결정 플로우차트
사용 사례별 권장 CNI
1. AWS EKS 프로덕션 환경
권장: AWS VPC CNI + Calico (Network Policy)
# eksctl 클러스터 구성 예시
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
name: production-cluster
region: ap-northeast-2
vpc:
cidr: "10.0.0.0/16"
addons:
- name: vpc-cni
version: latest
configurationValues: |
enableNetworkPolicy: "true"
- name: coredns
- name: kube-proxy2. 고급 보안 요구사항
권장: Cilium
- L7 Network Policy 지원
- DNS 기반 정책
- 프로세스/파일 수준 보안 정책
- 암호화된 통신 (WireGuard)
3. 온프레미스/베어메탈 환경
권장: Calico (BGP 모드)
- 기존 네트워크 인프라와 통합
- ToR 스위치와 BGP 피어링
- 높은 성능 (오버레이 없음)
4. 개발/테스트 환경
권장: Flannel
- 간단한 설치 및 구성
- 낮은 리소스 사용량
- 충분한 기본 기능
5. Service Mesh 통합 환경
권장: Cilium (Sidecar-less Service Mesh)
- Istio/Envoy 대체 가능
- mTLS, 트래픽 관리
- 낮은 오버헤드
EKS 네트워킹 기본 사항
EKS 기본 네트워킹 아키텍처
VPC CNI 동작 방식
AWS VPC CNI는 각 Pod에 VPC의 실제 IP 주소를 할당합니다.
ENI 및 IP 제한
| 인스턴스 유형 | 최대 ENI | ENI당 IPv4 | 최대 Pod (권장) |
|---|---|---|---|
| t3.medium | 3 | 6 | 17 |
| t3.large | 3 | 12 | 35 |
| m5.large | 3 | 10 | 29 |
| m5.xlarge | 4 | 15 | 58 |
| m5.2xlarge | 4 | 15 | 58 |
| c5.4xlarge | 8 | 30 | 234 |
EKS 네트워킹 고려사항
IP 주소 관리
# VPC CNI 구성 - IP 프리픽스 위임
apiVersion: v1
kind: ConfigMap
metadata:
name: amazon-vpc-cni
namespace: kube-system
data:
enable-prefix-delegation: "true"
warm-prefix-target: "1"
minimum-ip-target: "5"
warm-ip-target: "2"사용자 정의 네트워킹
# ENIConfig를 사용한 사용자 정의 서브넷
apiVersion: crd.k8s.amazonaws.com/v1alpha1
kind: ENIConfig
metadata:
name: ap-northeast-2a
spec:
securityGroups:
- sg-0123456789abcdef0
subnet: subnet-0123456789abcdef0
---
apiVersion: crd.k8s.amazonaws.com/v1alpha1
kind: ENIConfig
metadata:
name: ap-northeast-2b
spec:
securityGroups:
- sg-0123456789abcdef0
subnet: subnet-fedcba9876543210f네트워킹 하위 페이지
이 섹션에서는 다음 주제들을 상세히 다룹니다:
VPC CNI
EKS 기본 CNI. 각 Pod에 VPC IP를 할당하여 네이티브 VPC 네트워킹 제공.
Cilium 딥다이브
eBPF 기반의 고성능 CNI 솔루션. L7 Network Policy, Service Mesh, 관측성(Hubble) 등 고급 기능 제공.
Calico 딥다이브
가장 널리 사용되는 CNI 중 하나. 강력한 Network Policy, BGP 지원, 엔터프라이즈 기능. 소개, 아키텍처, 네트워킹 모드, BGP 심화, Network Policy, eBPF, 고급 주제, EKS 통합, 운영 가이드를 다룹니다.
VPC Lattice
AWS의 관리형 애플리케이션 네트워킹 서비스. 크로스 VPC, 크로스 계정 서비스 간 통신.
AWS Load Balancer Controller
Kubernetes Service와 Ingress를 AWS ELB(ALB/NLB)와 통합.
Gateway API
차세대 Kubernetes 인그레스 API. 표준화된 리소스 모델과 역할 기반 구성.
네트워크 트러블슈팅
일반적인 문제와 해결 방법
Pod 간 통신 실패
# 1. Pod IP 확인
kubectl get pods -o wide
# 2. 네트워크 연결 테스트
kubectl exec -it <pod-name> -- ping <target-pod-ip>
# 3. DNS 해석 테스트
kubectl exec -it <pod-name> -- nslookup <service-name>
# 4. CNI 로그 확인
kubectl logs -n kube-system -l k8s-app=aws-node
kubectl logs -n kube-system -l k8s-app=ciliumService 접근 불가
# 1. Service 상태 확인
kubectl get svc <service-name> -o yaml
# 2. Endpoints 확인
kubectl get endpoints <service-name>
# 3. kube-proxy 로그 확인
kubectl logs -n kube-system -l k8s-app=kube-proxyNetwork Policy 디버깅
# Cilium의 경우
kubectl exec -n kube-system -it <cilium-pod> -- cilium policy get
kubectl exec -n kube-system -it <cilium-pod> -- cilium endpoint list
# Calico의 경우
kubectl get networkpolicy -A
kubectl get globalnetworkpolicy
calicoctl get policy -o yaml네트워크 성능 테스트
# iperf3를 사용한 네트워크 성능 테스트
apiVersion: v1
kind: Pod
metadata:
name: iperf-server
labels:
app: iperf-server
spec:
containers:
- name: iperf
image: networkstatic/iperf3
command: ["iperf3", "-s"]
ports:
- containerPort: 5201
---
apiVersion: v1
kind: Pod
metadata:
name: iperf-client
spec:
containers:
- name: iperf
image: networkstatic/iperf3
command: ["sleep", "infinity"]# 테스트 실행
kubectl exec -it iperf-client -- iperf3 -c <iperf-server-ip> -t 30모범 사례
1. IP 주소 계획
- CIDR 블록을 충분히 크게 설계
- Pod 네트워크와 Service 네트워크 분리
- 향후 확장을 고려한 서브넷 설계
2. Network Policy 적용
- 기본 거부 정책 적용 (Zero Trust)
- 필요한 트래픽만 명시적으로 허용
- 네임스페이스 간 격리
# 기본 거부 정책 예시
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny-all
namespace: production
spec:
podSelector: {}
policyTypes:
- Ingress
- Egress3. 성능 최적화
- 적절한 CNI 선택 (워크로드에 맞는)
- MTU 최적화
- 커널 파라미터 튜닝
4. 보안 강화
- 암호화된 통신 (WireGuard, IPsec)
- mTLS 적용
- 정기적인 보안 감사
5. 관측성 확보
- 네트워크 메트릭 수집
- 플로우 로그 활성화
- 분산 추적 구현
다음 단계
- VPC CNI - EKS 기본 CNI
- Cilium 딥다이브 - eBPF 기반 네트워킹
- Calico 딥다이브 - 엔터프라이즈 CNI
- VPC Lattice - AWS 관리형 네트워킹
- AWS Load Balancer Controller - ELB 통합
- Gateway API - 차세대 인그레스