Kubernetesネットワーキングの大転換：専門家でも見落としがちな5つの重要変化

• 1. 導入：私たちが知っていたKubernetesネットワーキングはもう存在しない
• 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. 結論：次世代のKubernetesに備える姿勢
• References

1. 導入：私たちが知っていたKubernetesネットワーキングはもう存在しない

Kubernetesエコシステムの複雑さは、運用者にとって常に巨大な山のようでした。しかし今、その山の地形そのものが変わりつつあります。最新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）。これは単なる世代交代ではなく、Linuxカーネルネットワーキングスタックの進化に伴う必然的な結果です。

kube-proxyモード進化タイムライン：

2.2 iptables vs IPVS vs nftables 技術比較

従来のiptablesはルール数が増加するにつれ全ルールを線形探索する必要があるO(N)複雑度と、ルール更新のたびに発生するグローバルロックボトルネックにより、大規模環境で深刻なパフォーマンス低下が問題でした。

IPVSはハッシュマップベースの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）**プロキシモデルが衰退しつつあります。すべてのPodに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か月間共同開発しました。

コアアーキテクチャ — 2層分離：

ztunnel（Zero Trust Tunnel）：

• RustベースのI軽量プロキシ — ノード当たり~0.06 vCPU、~12 MBメモリ
• HBONE（HTTP-Based Overlay Network Environment）プロトコルによるmTLSトンネリング
• ノード当たり1つのDaemonSetとして動作
• 同一ノード内のトラフィックもztunnelを経由し均一なポリシー適用

トラフィックフロー比較：

[L4のみ - 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）は、Pod間の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へのライブマイグレーションを行う場合、必ずレガシールーティングモードを有効化する必要があります：

# 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. 結論：次世代のKubernetesに備える姿勢

Kubernetesネットワーキングは大きな転換期を迎えています：

これらの変化の終着点は、パフォーマンス最適化と運用効率性を通じた**運用卓越性（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)