쿠버네티스 네트워킹의 대전환: 전문가도 놓치기 쉬운 5가지 핵심 변화

• 1. 도입부: 우리가 알던 쿠버네티스 네트워킹은 이제 없다
• 2. IPVS의 퇴장과 nftables의 화려한 등장
  • 2.1 왜 IPVS가 퇴장하는가
  • 2.2 iptables vs IPVS vs nftables 기술 비교
  • 2.3 성능 벤치마크: nftables의 압도적 우위
  • 2.4 실무 마이그레이션 가이드: IPVS에서 nftables로
    • 사전 요구사항
    • Step 1: 현재 모드 확인
    • Step 2: kube-proxy ConfigMap 수정
    • Step 3: kube-proxy DaemonSet 재시작
    • Step 4: nftables 모드 활성화 확인
    • Step 5: 노드에서 nftables 규칙 확인
    • Step 6: Calico CNI 사용 시 — nftables 데이터 플레인 전환
    • AKS(Azure) 클러스터의 경우
  • 2.5 마이그레이션 주의사항
• 3. "사이드카는 이제 안녕" — Istio Ambient Mesh의 혁신
  • 3.1 사이드카 모델의 한계
  • 3.2 Ambient Mode 아키텍처
  • 3.3 성능 비교: Ambient vs Sidecar
  • 3.4 실무 배포 가이드
    • 사전 요구사항
    • 방법 1: istioctl (빠른 시작)
    • 방법 2: Helm (프로덕션 권장)
    • 워크로드를 메쉬에 등록
    • Waypoint 프록시 배포 (L7 기능 필요 시)
  • 3.5 Ambient vs Sidecar: 언제 무엇을 선택할 것인가
• 4. 자격증 시험의 진화: 이론보다 무서운 '실무 100%'의 시대
  • 4.1 CKA (Certified Kubernetes Administrator)
  • 4.2 CKAD (Certified Kubernetes Application Developer)
  • 4.3 ICA (Istio Certified Associate) — 신설 자격증
• 5. Ingress를 넘어선 Gateway API: 새로운 라우팅 표준
  • 5.1 Ingress의 한계
  • 5.2 역할 기반 리소스 분리 (Role-Oriented Design)
  • 5.3 핵심 리소스 가이드
  • 5.4 실전 YAML 예시
    • 카나리 배포 — 트래픽 분할 (90/10)
    • A/B 테스트 — 헤더 기반 라우팅
    • 테스트 트래픽 + 프로덕션 분할 결합
  • 5.5 Ingress에서 Gateway API로 마이그레이션
• 6. CNI는 이제 단순한 '파이프'가 아니다: 관측 가능성의 중심
  • 6.1 Cilium: eBPF 기반의 차세대 CNI
  • 6.2 Hubble: 블랙박스 네트워크의 시각화
  • 6.3 Cilium의 핵심 보안 기능
  • 6.4 CNI 비교: Flannel vs Calico vs Cilium
  • 6.5 CNI 마이그레이션 팁: Calico에서 Cilium으로
• 7. 결론: 다음 세대의 쿠버네티스를 준비하는 자세
• References

1. 도입부: 우리가 알던 쿠버네티스 네트워킹은 이제 없다

쿠버네티스 생태계의 복잡성은 운영자들에게 언제나 거대한 산과 같았습니다. 하지만 이제 그 산의 지형 자체가 바뀌고 있습니다. 최신 v1.35 버전의 등장은 단순한 기능 추가를 넘어, 지난 10년간 우리가 당연하게 여겼던 네트워킹 표준들의 종언을 고하고 있습니다.

"왜 지금 이 변화를 알아야 하는가?"라는 질문에 대한 답은 명확합니다. 과거의 유산에 안주하는 것은 곧 통제할 수 없는 기술 부채와 직결되기 때문입니다. 아키텍트의 시선으로, 현재 진행 중인 파괴적 혁신의 본질을 꿰뚫어 보아야 할 때입니다.

이 글에서 다루는 5가지 핵심 변화는 다음과 같습니다:

1. IPVS 지원 중단과 nftables의 등장 (KEP-5495, KEP-3866)
2. Istio Ambient Mesh로의 전환 — 사이드카 없는 서비스 메쉬
3. 자격증 시험의 실무 100% 전환 — ICA 신설과 CKA/CKAD 변화
4. Gateway API — Ingress를 대체하는 새로운 라우팅 표준
5. Cilium eBPF CNI — 관측 가능성의 중심이 된 네트워크 인터페이스

2. IPVS의 퇴장과 nftables의 화려한 등장

2.1 왜 IPVS가 퇴장하는가

오랫동안 대규모 클러스터의 고성능 부하 분산을 책임졌던 IPVS(IP Virtual Server)가 **Kubernetes v1.35를 기점으로 공식 지원 중단(Deprecated)**되었습니다 (KEP-5495). 이는 단순한 세대교체가 아닌, 리눅스 커널 네트워킹 스택의 진화에 따른 필연적인 결과입니다.

kube-proxy 모드 진화 타임라인:

2.2 iptables vs IPVS vs nftables 기술 비교

기존 iptables는 규칙이 증가할수록 전체 규칙을 선형 탐색해야 하는 O(N) 복잡도와, 규칙 업데이트 시마다 발생하는 **글로벌 락 병목 현상(Global lock bottleneck)**으로 인해 대규모 환경에서 성능 저하가 심각했습니다.

IPVS는 해시맵(Hashmap) 기반의 O(1) 성능으로 이를 해결했지만, 네트워킹을 위해 완전히 별개의 커널 서브시스템을 유지해야 한다는 구조적 부채를 안고 있었습니다.

nftables는 이 두 방식의 장점을 결합하여, 현대적인 통합 커널 API 내에서 유연성과 성능을 동시에 확보한 차세대 표준입니다.

2.3 성능 벤치마크: nftables의 압도적 우위

공식 Kubernetes 블로그에서 발표된 벤치마크에 따르면, nftables의 데이터 플레인 레이턴시는 서비스 수에 관계없이 일정하게 유지됩니다:

데이터 플레인 레이턴시 (첫 번째 패킷, p50):

이 차이의 핵심은 Verdict Map 자료구조에 있습니다. iptables가 서비스마다 개별 규칙 체인을 생성하는 반면, nftables는 단일 해시 테이블로 모든 서비스를 관리합니다:

iptables 방식 (서비스당 개별 규칙):

-A KUBE-SERVICES -m comment --comment "ns1/svc1:p80 cluster IP" \
  -m tcp -p tcp -d 172.30.0.41 --dport 80 -j KUBE-SVC-XPGD46QRK7WJZT7O
-A KUBE-SERVICES -m comment --comment "ns2/svc2:p443 cluster IP" \
  -m tcp -p tcp -d 172.30.0.42 --dport 443 -j KUBE-SVC-GNZBNJ2PO5MGZ6GT

nftables 방식 (단일 Verdict Map):

table ip kube-proxy {
    map service-ips {
        type ipv4_addr . inet_proto . inet_service : verdict
        elements = {
            172.30.0.41 . tcp . 80 : goto service-ns1/svc1/tcp/p80,
            172.30.0.42 . tcp . 443 : goto service-ns2/svc2/tcp/p443,
        }
    }
    chain services {
        ip daddr . meta l4proto . th dport vmap @service-ips
    }
}

2.4 실무 마이그레이션 가이드: IPVS에서 nftables로

사전 요구사항

• Kubernetes v1.31 이상 (v1.33+ 권장 — nftables GA)
• Linux 커널 5.13 이상 (RHEL 9+, Ubuntu 22.04+, Debian 12+)
• Calico 사용 시: v3.30 이상
• 유지보수 윈도우에서 수행 권장

Step 1: 현재 모드 확인

kubectl logs -n kube-system daemonset/kube-proxy | grep -i ipvs
# 기대 출력: "Using ipvs Proxier"

Step 2: kube-proxy ConfigMap 수정

kubectl edit configmap -n kube-system kube-proxy

mode: ipvs를 mode: nftables로 변경합니다.

또는 kubeadm 기반 클러스터의 경우, 클러스터 초기화 시 다음 설정을 사용합니다:

apiVersion: kubeadm.k8s.io/v1beta4
kind: InitConfiguration
---
kind: ClusterConfiguration
apiVersion: kubeadm.k8s.io/v1beta4
kubernetesVersion: v1.33.0
networking:
  podSubnet: '192.168.0.0/16'
---
apiVersion: kubeproxy.config.k8s.io/v1alpha1
kind: KubeProxyConfiguration
mode: nftables

Step 3: kube-proxy DaemonSet 재시작

kubectl rollout restart -n kube-system daemonset/kube-proxy

주의: ConfigMap 변경만으로는 적용되지 않습니다. 반드시 DaemonSet을 재시작해야 합니다.

Step 4: nftables 모드 활성화 확인

kubectl logs -n kube-system daemonset/kube-proxy | grep -i nftables

Step 5: 노드에서 nftables 규칙 확인

sudo nft list chain ip kube-proxy services

Step 6: Calico CNI 사용 시 — nftables 데이터 플레인 전환

kubectl patch installation default --type=merge \
  -p '{"spec":{"calicoNetwork":{"linuxDataplane":"Nftables"}}}'

kubectl logs -f -n calico-system daemonset/calico-node | grep -i nftables
# 기대 출력: "Parsed value for NFTablesMode: Enabled"

AKS(Azure) 클러스터의 경우

{
  "enabled": true,
  "mode": "NFTABLES"
}

az aks update \
  --resource-group <resourceGroup> \
  --name <clusterName> \
  --kube-proxy-config kube-proxy.json

2.5 마이그레이션 주의사항

"IPVS 지원이 종료됨에 따라 이를 계속 사용하는 것은 단순히 구형 기술을 유지하는 문제가 아닙니다. 업스트림 지원이 줄어들면 테스트와 버그 수정이 적어지고, 이는 결국 예기치 않은 장애와 최신 기능과의 호환성 결여로 이어집니다." — From IPVS to NFTables: A Migration Guide for Kubernetes v1.35

3. "사이드카는 이제 안녕" — Istio Ambient Mesh의 혁신

3.1 사이드카 모델의 한계

서비스 메쉬의 정의와도 같았던 사이드카(Sidecar) 프록시 모델이 저물고 있습니다. 모든 파드에 Envoy 프록시를 주입하던 방식은 다음과 같은 한계에 부딪혔습니다:

• 리소스 낭비: Pod당 ~0.20 vCPU, ~60 MB 메모리의 프록시 오버헤드
• 복잡한 업그레이드: Envoy 버전 변경 시 모든 Pod 재시작 필요
• 애플리케이션 수명 주기 개입: 사이드카 주입이 Pod 배포와 결합

3.2 Ambient Mode 아키텍처

Istio의 Ambient Mode는 Istio v1.24 (2024년 11월)에 GA를 달성했으며, 이러한 제약을 혁신적으로 제거합니다. 2022년 9월 발표 후 Solo.io, Google, Microsoft, Intel 등이 26개월간 공동 개발했습니다.

핵심 아키텍처 — 두 계층 분리:

ztunnel (Zero Trust Tunnel):

• Rust 기반 경량 프록시 — 노드당 ~0.06 vCPU, ~12 MB 메모리
• HBONE (HTTP-Based Overlay Network Environment) 프로토콜로 mTLS 터널링
• 노드당 하나의 DaemonSet으로 동작
• 같은 노드 내 트래픽도 ztunnel을 경유하여 균일한 정책 적용

트래픽 흐름 비교:

[L4 Only - Waypoint 없음]
Source Pod → ztunnel(source) ──HBONE/mTLS──→ ztunnel(dest) → Dest Pod

[L7 - Waypoint 사용]
Source Pod → ztunnel(source) ──HBONE──→ Waypoint ──HBONE──→ ztunnel(dest) → Dest Pod

3.3 성능 비교: Ambient vs Sidecar

레이턴시 (1KB HTTP 요청, Istio v1.24 벤치마크):

리소스 사용량 (1,000 req/s, 1KB 페이로드):

실제 절감 효과:

• Ambient 모드 전환 시 CPU 73% 감소 (Solo.io 측정)
• 네임스페이스당 약 1.3 CPU 코어 절약
• 일부 사용 사례에서 90%+ 오버헤드 감소
• 한 사용자는 AWS App Mesh에서 전환 후 컨테이너 수 45% 감소 달성

3.4 실무 배포 가이드

사전 요구사항

# Gateway API CRDs 설치
kubectl get crd gateways.gateway.networking.k8s.io &> /dev/null || \
  kubectl apply --server-side -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.4.0/experimental-install.yaml

방법 1: istioctl (빠른 시작)

istioctl install --set profile=ambient --skip-confirmation

방법 2: Helm (프로덕션 권장)

# 1. Base 차트 설치
helm install istio-base istio/base -n istio-system --create-namespace --wait

# 2. istiod (컨트롤 플레인) 설치
helm install istiod istio/istiod -n istio-system --set profile=ambient --wait

# 3. CNI 에이전트 설치
helm install istio-cni istio/cni -n istio-system --set profile=ambient --wait

# 4. ztunnel DaemonSet 설치
helm install ztunnel istio/ztunnel -n istio-system --wait

워크로드를 메쉬에 등록

# 네임스페이스 단위 등록 — Pod 재시작 불필요!
kubectl label namespace default istio.io/dataplane-mode=ambient

# 개별 Pod 제외
kubectl label pod <pod-name> istio.io/dataplane-mode=none

Waypoint 프록시 배포 (L7 기능 필요 시)

# 네임스페이스에 Waypoint 배포
istioctl waypoint apply -n default --enroll-namespace

# 서비스별 Waypoint 배포
istioctl waypoint apply -n default --name reviews-svc-waypoint
kubectl label service reviews istio.io/use-waypoint=reviews-svc-waypoint

Waypoint Gateway API YAML 예시:

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  labels:
    istio.io/waypoint-for: service
  name: waypoint
  namespace: default
spec:
  gatewayClassName: istio-waypoint
  listeners:
    - name: mesh
      port: 15008
      protocol: HBONE

3.5 Ambient vs Sidecar: 언제 무엇을 선택할 것인가

4. 자격증 시험의 진화: 이론보다 무서운 '실무 100%'의 시대

기술의 변화는 자격증 트렌드에도 즉각 반영되고 있습니다. CKA와 CKAD는 이미 실무 중심(Performance-based) 시험으로 완전히 자리 잡았습니다.

4.1 CKA (Certified Kubernetes Administrator)

4.2 CKAD (Certified Kubernetes Application Developer)

4.3 ICA (Istio Certified Associate) — 신설 자격증

특히 주목할 변화는 **ICA(Istio Certified Associate)**의 등장입니다. 이는 단순한 자격증 추가가 아니라, Ambient Mesh와 같은 사이드카 없는 아키텍처로의 전환에 필요한 기초 지식을 검증하기 위한 필수 관문으로 설계되었습니다.

2025년 8월 12일 업데이트된 ICA 시험 도메인:

시험 상세 정보:

합격 팁: 태스크당 약 6-8분이 주어집니다. 익숙한 태스크부터 해결하여 점수를 확보하고, VirtualService/DestinationRule/AuthorizationPolicy 설정에 대한 실습이 핵심입니다. 2-3개월의 실무 경험을 권장합니다.

5. Ingress를 넘어선 Gateway API: 새로운 라우팅 표준

5.1 Ingress의 한계

기존의 Ingress는 L4 프로토콜 지원이 부족하여 NGINX의 ConfigMap이나 복잡한 주석(Annotation)을 활용한 해킹에 의존해야 했습니다. Gateway API는 이러한 한계를 극복하고 트래픽 관리를 선언적이고 구조적인 방식으로 진화시켰습니다.

Gateway API는 v1.0 (2023년 10월)에 GA를 달성했으며, 최신 v1.4 (2025년 11월)까지 지속 발전 중입니다.

5.2 역할 기반 리소스 분리 (Role-Oriented Design)

Gateway API의 가장 혁신적인 특징은 역할별 리소스 분리입니다:

5.3 핵심 리소스 가이드

리소스 관계: GatewayClass → Gateway → Routes → Services

5.4 실전 YAML 예시

카나리 배포 — 트래픽 분할 (90/10)

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: canary-split
spec:
  parentRefs:
    - name: production-gateway
  hostnames:
    - 'app.example.com'
  rules:
    - backendRefs:
        - name: app-v1
          port: 8080
          weight: 90
        - name: app-v2
          port: 8080
          weight: 10

A/B 테스트 — 헤더 기반 라우팅

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: ab-testing
spec:
  parentRefs:
    - name: main-gateway
  hostnames:
    - 'api.example.com'
  rules:
    # X-API-Version: v2 헤더가 있는 요청 → v2로 라우팅
    - matches:
        - headers:
            - name: X-API-Version
              value: 'v2'
      backendRefs:
        - name: api-v2
          port: 8080
    # 기본 요청 → v1로 라우팅
    - backendRefs:
        - name: api-v1
          port: 8080

테스트 트래픽 + 프로덕션 분할 결합

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: combined-routing
spec:
  parentRefs:
    - name: production-gateway
  hostnames:
    - 'app.example.com'
  rules:
    # traffic: test 헤더 → v2로 직접 라우팅
    - matches:
        - headers:
            - name: traffic
              value: test
      backendRefs:
        - name: app-v2
          port: 8080
    # 프로덕션 트래픽 → 90/10 분할
    - backendRefs:
        - name: app-stable
          port: 8080
          weight: 90
        - name: app-canary
          port: 8080
          weight: 10

5.5 Ingress에서 Gateway API로 마이그레이션

ingress2gateway 도구를 활용한 자동 변환:

# 도구 설치
go install github.com/kubernetes-sigs/ingress2gateway@latest

# 기존 Ingress 리소스를 Gateway API로 변환
ingress2gateway print

마이그레이션 전략:

1. Gateway API CRDs 설치
2. Gateway API 구현체 선택 (Istio, Envoy Gateway, NGINX Gateway Fabric 등)
3. ingress2gateway로 기존 Ingress 자동 변환
4. Gateway API와 Ingress를 병행 운영하여 검증
5. 트래픽 전환 후 기존 Ingress 제거

6. CNI는 이제 단순한 '파이프'가 아니다: 관측 가능성의 중심

6.1 Cilium: eBPF 기반의 차세대 CNI

CNI(Container Network Interface)는 이제 파드 간의 IP를 연결하는 단순한 파이프 역할을 넘어섰습니다. eBPF 기술을 기반으로 하는 Cilium은 네트워킹, 보안, 그리고 관측 가능성(Observability)을 하나로 통합합니다.

Cilium의 kube-proxy 대체 — eBPF로 완전 교체:

helm install cilium cilium/cilium --version 1.19.1 \
   --namespace kube-system \
   --set kubeProxyReplacement=true \
   --set k8sServiceHost=${API_SERVER_IP} \
   --set k8sServicePort=${API_SERVER_PORT}

지원 서비스 타입: ClusterIP, NodePort, LoadBalancer, externalIPs, hostPort

로드 밸런싱 알고리즘:

• Random (기본): 무작위 백엔드 선택
• Maglev: 일관된 해싱 — 백엔드 변경 시 최소 중단 (loadBalancer.algorithm=maglev)

포워딩 모드:

• SNAT (기본): 표준 소스 NAT
• DSR (Direct Server Return): 백엔드가 클라이언트에 직접 응답 — 추가 홉 제거
• Hybrid: TCP는 DSR, UDP는 SNAT

6.2 Hubble: 블랙박스 네트워크의 시각화

Cilium의 Hubble은 블랙박스 같았던 네트워크 내부를 L7 트래픽 수준까지 시각화합니다:

모니터링 범위:

• L3/L4: 소스/목적지 IP, 포트, TCP 연결 상태, DNS 해석 문제, 연결 타임아웃
• L7: HTTP 요청/응답 (메서드, 경로, 상태 코드), Kafka 토픽, gRPC 호출, DNS 쿼리
• 암호화된 트래픽 필터링 지원
• 자동 서비스 의존성 그래프 발견

Hubble 활성화 설치:

helm install cilium cilium/cilium --version 1.19.1 \
   --namespace kube-system \
   --set kubeProxyReplacement=true \
   --set k8sServiceHost=${API_SERVER_IP} \
   --set k8sServicePort=${API_SERVER_PORT} \
   --set hubble.enabled=true \
   --set hubble.relay.enabled=true \
   --set hubble.ui.enabled=true

6.3 Cilium의 핵심 보안 기능

NetworkPolicy 강화:

• Kubernetes 표준 NetworkPolicy + Cilium 전용 CiliumNetworkPolicy / CiliumClusterwideNetworkPolicy
• L3, L4, L7 수준의 정책 적용 (예: GET /api/v1/users만 허용)
• IP 기반이 아닌 Identity 기반 정책 — Pod 변경에도 안정적

Transparent Encryption (3가지 옵션):

6.4 CNI 비교: Flannel vs Calico vs Cilium

선택 가이드:

• Flannel: 소규모 개발/테스트 클러스터, NetworkPolicy 불필요 시
• Calico: BGP 피어링이 필요한 온프레미스/하이브리드 환경, 안정적인 L3/L4 정책
• Cilium: 대규모 고성능 환경, L7 정책/관측성 필요, kube-proxy 제거 원할 때

6.5 CNI 마이그레이션 팁: Calico에서 Cilium으로

여기서 아키텍트가 놓치지 말아야 할 핵심 포인트가 있습니다. Calico에서 Cilium으로 라이브 마이그레이션할 경우, 반드시 legacy routing 모드를 활성화해야 합니다:

# Cilium 마이그레이션 Helm 값
ipam:
  mode: 'cluster-pool'
  operator:
    clusterPoolIPv4PodCIDRList: ['10.245.0.0/16'] # Calico와 다른 CIDR
cni:
  customConf: true
  uninstall: false
policyEnforcementMode: 'never' # 마이그레이션 중 정책 비활성화
bpf:
  hostLegacyRouting: true # 핵심! Linux 라우팅 스택 사용
tunnelPort: 8473 # Calico 기본 포트(8472)와 다른 포트

마이그레이션 프로세스 (노드 단위):

1. Cilium을 보조 모드로 설치 (CNI 관리 없이)
2. 각 노드별: cordon → drain → Cilium 라벨 지정 → Cilium 에이전트 재시작 → 리부트
3. 각 노드에서 새 Cilium CIDR의 Pod 확인
4. 전체 마이그레이션 완료 후: 정책 활성화, Calico 제거, iptables 규칙 정리 (리부트 시 자동)

"적절한 CNI 플러그인을 선택하는 것은 단순한 연결 방식의 문제가 아닙니다. 이는 클러스터의 전체적인 성능, 보안 태세, 그리고 운영의 복잡성을 결정짓는 가장 중대한 아키텍처적 결정입니다." — Comparing Kubernetes CNI Plugins: Calico, Cilium, Flannel, and Weave

7. 결론: 다음 세대의 쿠버네티스를 준비하는 자세

쿠버네티스 네트워킹은 거대한 전환기를 지나고 있습니다:

이러한 변화의 종착역은 결국 성능 최적화와 운영 효율성을 통한 **운영 우수성(Operational Excellence)**의 확보입니다.

변화는 이미 시작되었고, 유예 기간은 생각보다 짧습니다. 당신의 클러스터는 IPVS의 퇴장에 대비가 되어 있습니까? 지금이 바로 미래지향적인 아키텍처로의 전환을 결정해야 할 골든타임입니다.

References

• KEP-3866: nftables-based kube-proxy backend
• KEP-5495: Deprecate ipvs mode in kube-proxy
• NFTables mode for kube-proxy (Kubernetes Official Blog)
• Virtual IPs and Service Proxies (Kubernetes Docs)
• Kubernetes v1.35 Release Highlights
• From IPVS to NFTables: A Migration Guide (Tigera)
• Istio Ambient Mode GA Announcement
• Istio Ambient Mode Architecture
• Istio Ambient Install Guide
• Sidecar or Ambient? (Istio Docs)
• ICA Certification (Linux Foundation)
• Changes Coming to ICA Exam
• Gateway API Official Docs
• Gateway API v1.0 GA Announcement
• ingress2gateway Tool
• Cilium Documentation
• Cilium kube-proxy Replacement
• Hubble Observability
• Cilium Transparent Encryption
• Migrating a Cluster to Cilium
• CNI Comparison: Calico vs Cilium vs Flannel (2025)
• Configure kube-proxy (AKS)