Kubernetesクラスタ設計・運用実践ガイド

第5章：ネットワーク設計と運用

ネットワークは到達性・隔離・性能に直結し、運用中のトラブルシュート比率が高い領域です。
本章では、CNI/Service/Ingress/DNS を中心に、設計と運用の論点を整理します。

学習目標

  • CNI の役割と、設計上の主要なトレードオフを説明できる
  • DNS/Service/Ingress の障害を切り分ける観点を整理できる
  • NetworkPolicy を導入する際の運用前提を理解する

扱う範囲 / 扱わない範囲

扱う範囲

  • CNI（IPAM、到達性、ポリシー対応）の論点
  • Service/Ingress の運用観点（外部公開、ヘルスチェック、TLS の入口）
  • DNS（CoreDNS）の運用観点
  • NetworkPolicy の入口（設計前提と運用）

扱わない範囲

  • ベンダ固有の LB 実装の詳細
  • サービスメッシュの詳細設計

定義（この章の用語）

  • CNI: Pod ネットワークを提供するプラグイン（IPAM、到達性、NetworkPolicy 対応等）
  • Service: Pod を抽象化する安定した到達先（ClusterIP 等）
  • Ingress: 外部公開の入口（L7 ルーティング、TLS 等。実体は Ingress Controller）
  • DNS（CoreDNS）: Service 名等の名前解決を担う基盤アドオン
  • NetworkPolicy: Namespace/Pod 間の通信を制御するポリシー（CNI の対応が前提）

背景（なぜ重要か）

  • ネットワーク障害は症状が似ます（「到達しない」「遅い」）。層（DNS/Service/Ingress/CNI）を分けて切り分けないと復旧が遅れます。
  • 変更の影響範囲が広いため、段階適用とロールバック手順を標準化する必要があります。

手順/例：切り分けの型（最小）

  1. 症状を分類する（DNS/Service/Ingress/Pod 間到達性/外部到達性）
  2. 直近の変更を確認する（CNI/Ingress/CoreDNS の更新、IP 設計変更、Firewall/LB/DNS の変更）
  3. 観測ポイントを揃える（Events、Ingress/Service/EndpointSlice、CoreDNS のログ、ノード/Pod の到達性）
  4. 暫定復旧を選ぶ（影響範囲を限定し、既知の良い設定へロールバックする。必要ならスケール/退避）
  5. 恒久対応へ戻す（再発防止として監視・Runbook・変更管理へ反映する）

判断の目安（例）:

  • NetworkPolicy を「既定拒否」にする前に、通信要件の棚卸しと段階導入（warn 相当→限定 enforce）を行います。
  • 強い隔離要件がある場合、NetworkPolicy だけで担保しようとせず、クラスタ分離/ノードプール分離も併せて検討します。

注意点（運用）

  • IP 枯渇は顕在化すると影響が大きいため、早期に検知できる監視と拡張手順（要確認）を用意します。
  • DNS はアプリ不調に見えやすい領域です。CoreDNS の健全性（失敗率/レイテンシ/欠測）をクラスタ標準で監視します。

実務チェック観点（最低5項目）

  • IP 設計（Pod/Service CIDR、IP 枯渇）の監視と拡張方針がある
  • DNS（CoreDNS）の健全性（失敗率/レイテンシ）を監視している
  • 外部公開（Ingress/LB）の責任範囲、証明書管理、変更手順が定義されている
  • NetworkPolicy 導入時の段階的ロールアウト手順（deny 既定化の判断）がある
  • 典型障害（DNS 不調、到達不可、TLS 失敗）の Playbook が整備されている

よくある落とし穴

  • IP 枯渇が顕在化してから対応し、影響範囲が大きくなる
  • DNS 障害をアプリ障害と誤判定し、復旧が遅れる

まとめ / 次に読む

Edit this page on GitHub