Kubernetes運用

文書基準: 2026年8月

概要

コンテナサービスで管理型Kubernetesを選択した後は、Day-2運用が始まります。クラスタアップグレード、デプロイ自動化、セキュリティポリシー、観測可能性など、継続的に管理すべき領域です。

クラスタアップグレード

Kubernetesは年3回マイナーバージョンをリリースし、各ベンダーは一定期間後に旧バージョンのサポートを終了します。

ベンダー	サービス	サポートバージョン数	アップグレード方式
AWS	EKS	直近4つ（+ Extended Supportは有料）	コントロールプレーン → ノードグループの順次
Azure	AKS	直近3つ	コントロールプレーン → ノードプールの順次。Auto-upgradeオプション
Google Cloud	GKE	直近3つ（Rapid/Regular/Stableチャネル）	Release Channelベースの自動アップグレード
OCI	OKE	直近3つ	コントロールプレーン → ノードプールの順次

アップグレード戦略:

Blue-Greenノードプール — 新バージョンのノードプールを作成 → ワークロードを移動 → 旧ノードプールを削除
Rolling — ノードを1つずつdrain → アップグレード → uncordon
GKE Autopilot — Googleが自動的にアップグレードを管理

デプロイ運用（GitOps）

Gitリポジトリを単一の真実の情報源として使用し、クラスタの状態を宣言的に管理します。GitOpsの概念とツール比較はDevOpsを始めるを、CI/CDパイプライン設計はCI/CDを参照してください。

Kubernetesプロモーション戦略:

graph LR
    A[dev] -->|自動| B[staging]
    B -->|手動承認または自動テスト通過| C[production]

セキュリティ/ポリシー

領域	ツール	役割
Admission Control	OPA Gatekeeper、Kyverno	Pod作成時にポリシーを強制（イメージソース制限、リソース制限など）
Network Policy	Calico、Cilium、ベンダーネイティブ	Pod間通信の制御（デフォルト: 全許可 → 明示的許可のみ）
Image Policy	署名検証（Cosign、Notation）	承認済みレジストリ／署名済みイメージのみデプロイを許可
Workload Identity	IRSA（AWS）、Workload Identity（Google Cloud/Azure）	PodにクラウドIAMロールをマッピング（Service Account Key不要）

プラットフォーム運用

コンポーネント	役割	代表的なツール
Ingress	外部トラフィック → クラスタ内サービスへのルーティング	NGINX Ingress、AWS ALB Controller、GKE Gateway
cert-manager	TLS証明書の自動発行/更新	Let’s Encrypt、ACM PCA連携
external-dns	サービス作成時にDNSレコードを自動登録	Route 53、Cloud DNS、Azure DNS連携
シークレット配布	外部シークレット → Podへの注入	External Secrets Operator、CSI Secret Store Driver
バックアップ	etcd + PVバックアップ	Velero

観測可能性

階層	収集対象	ツール
クラスタ	ノードCPU/メモリ、Pod状態、スケジューリング	Prometheus + Grafana、ベンダーネイティブ（Container Insights、GKE Monitoring）
アプリケーション	リクエスト遅延、エラー率、トレース	OpenTelemetry、Jaeger、X-Ray
コントロールプレーン	APIサーバー遅延、etcd状態、スケジューラー	管理型ベンダーは限定的な露出。監査ログで補完
イベント	Pod再起動、OOM Kill、スケジュール失敗	Kubernetes Events → ログ収集

VPCネットワーキング

Kubernetesクラスタは VPC サブネット上で動作し、Podネットワーキングの方式によってIP消費量とパフォーマンスが変わります。

Pod CIDRとサブネットの関係

方式	説明	ベンダー
VPCネイティブ（PodにVPC IPを割り当て）	PodがVPC IPを直接使用。VPC内の他リソースと直接通信可能	AWS VPC CNI、Azure CNI、Google Cloud Alias IP
オーバーレイネットワーク	Podに別のCIDRを割り当て。VPC IPを消費しないがカプセル化オーバーヘッドあり	Azure kubenet、Calico VXLAN、Flannel

サブネットIP枯渇問題

VPCネイティブ方式では、ノード＋Podがすべて VPC IPを消費するため、サブネットが不足する可能性があります。

ベンダー	対応方法
AWS	Prefix Delegation（ノードごとに/28ブロックを割り当て）、Secondary CIDRの追加
Azure	Azure CNI Overlay（Podにオーバーレイ IPを使用）、Azure CNI + Dynamic IP Allocation
Google Cloud	Alias IP ranges、/14デフォルトPod CIDR（十分に広い）

サービス公開パターン

段階	方式	VPCリソース
ClusterIP	クラスタ内部からのみアクセス	なし
NodePort	ノードIP＋ポートで外部公開	Security Groupルールの追加
LoadBalancer	クラウドLBを自動作成	LB + Target Group + Security Group
Ingress/Gateway	L7ルーティング（パス/ホストベース）	ALB/App Gateway/Cloud LBを自動作成

ネットワークポリシー

Pod間トラフィックを制御するKubernetesネイティブ機能です。VPC Security Groupとは役割が異なります。

区分	Network Policy（Podレベル）	Security Group（VPCレベル）
適用対象	Pod ↔ Pod	インスタンス/ENI ↔ 外部
実装	Calico、Cilium、ベンダーネイティブ	ベンダーVPC機能
デフォルト動作	全許可（ポリシーがない場合）	全拒否（インバウンド）

ベンダー別Kubernetes VPC/サブネット設計ガイド:

ベンダー別の違い

コントロールプレーンは管理型、ノードはユーザー管理（Managed Node GroupまたはFargate）
IRSAでPodごとにIAM Roleをマッピング
VPC CNI（PodにVPC IPを直接割り当て）
ALB Ingress ControllerでAWS ALBを自動作成

よくある間違い

クラスタアップグレードを先延ばしにしてサポート終了バージョンに到達 — 強制アップグレードやセキュリティパッチの停止につながります。四半期ごとにアップグレード計画を立ててください。
Network Policyなしで運用 — デフォルトではすべてのPod間通信が許可されています。侵害時に横方向移動（lateral movement）が無制限に可能になります。
VPCサブネットIPを小さく設定してPodスケジューリングに失敗 — VPC CNI環境ではノード＋Podがすべて VPC IPを消費します。初期設計時に十分なCIDR（/20以上）を割り当ててください。

チェックリスト

クラスタバージョンがベンダーのサポート範囲内にあり、アップグレードスケジュールが策定されているか?
OPA/Kyvernoなどで承認済みのイメージレジストリのみを許可するポリシーが適用されているか?
Podごとのリソースリクエスト（requests）と制限（limits）が設定されているか?