午前2時のオンコール対応
それはデプロイの失敗から始まります。Podが10分間 ContainerCreating のまま動かないことに気づきます。 kubectl describe pod を実行すると、次のような恐ろしいメッセージが表示されます。
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning FailedCreatePodSandBox 2m (x15 over 12m) kubelet Failed to create pod sandbox: rpc error: code = Unknown desc = failed to set up sandbox container network: no IP addresses available
CNI（Container Network Interface）のIPアドレスが不足しています。新しいPodにネットワークIDを割り当てることができません。これにより、AWS EKS、Azure AKS、またはベアメタルのCalico構成であっても、クラスターが実質的に麻痺してしまいます。
要約：クイックフィックス
- AWS VPC CNI: サブネットが枯渇している可能性があります。VPCコンソールを確認してください。セカンダリCIDRを追加するか、ノードがIPを溜め込んでいる場合は
WARM_IP_TARGETを下げる必要があるかもしれません。 - Calico:
IPPoolが上限に達しています。すぐに、より大きな新しいIPPoolブロックを追加してください。 - Azure CNI: ノードあたりの事前割り当てIP制限に達しています。これを解決するには、通常、より広いサブネットでノードプールを再デプロイする必要があります。
- 緊急避難的措置: 非クリティカルなデプロイをスケールダウンしてください。開発用アプリのレプリカを20個削除するだけで、根本的なネットワークの問題を解決するための十分な猶予を確保できることがよくあります。
ステップ1：ボトルネックの特定
問題は特定のノードに限定されていますか、それともネットワーク全体に及んでいますか？
個々のノードのキャパシティを確認する
ハードウェアの制限に達すると、単一のノードが失敗することがあります。例えば、AWSの t3.medium インスタンスは、3つのENIと1つのENIにつき6つのIPしかサポートしていません。その上で18個のPodを実行しようとすると、上限に達します。CNIのログを確認して、ローカルリソースの割り当てに苦労していないか確認してください：
kubectl logs -n kube-system -l k8s-app=aws-node
# Calicoユーザーの場合
kubectl logs -n kube-system -l k8s-app=calico-node
サブネット全体の枯渇を確認する
クラスター内のすべてのノードでエラーが発生している場合、VPCサブネットが使い果たされている可能性があります。 /24 サブネットでは、AWSやAzureが予約する分を除くと、使用可能なアドレスは251個しかありません。クラウドコンソールのVPCセクションで「利用可能なIPアドレス」の数を確認してください。
ステップ2：修正の適用
シナリオA：AWS VPC CNI (EKS)
EKSはVPCサブネットからPodのIPを直接マッピングします。これによりネットワークは高速になりますが、IPの消費も早くなります。
修正1：WARM_IP_TARGETの調整CNIは、Podを素早く起動するためにIPの「ウォーム」プールを保持しています。この数値が高すぎると、Podを2つしか実行していなくても、1つのノードが10個のIPを予約してしまうことがあります。 aws-node DaemonSetを編集することで、この値を下げることができます：
kubectl set env daemonset aws-node -n kube-system WARM_IP_TARGET=3
修正2：セカンダリCIDRの追加VPCの空き容量が本当になくなった場合は、セカンダリCIDRブロック（例： 100.64.0.0/16）をVPCにアタッチします。その後、カスタムネットワーク（Custom Networking）を介して、Podにこの新しい範囲を使用するようにCNIを設定します。
シナリオB：Calico IPPools
CalicoはCIDRをブロック（通常は64個のIPを許可する /26）に分割し、それをノードに渡します。小さなノードがたくさんある場合、合計のIP数に余裕があるように見えても、ブロックが不足することがあります。
プールの使用状況を確認します：
calicoctl get ippool -o wide
使用率が100%に近い場合は、より広い範囲を持つ新しい IPPool を定義して適用します：
apiVersion: projectcalico.org/v3
kind: IPPool
metadata:
name: expansion-pool
spec:
cidr: 192.168.64.0/18
ipipMode: Always
natOutgoing: true
ステップ3：復旧の確認
範囲を拡張した後、Podの状態を監視します。イベントログから FailedCreatePodSandBox エラーが消えるはずです。
# PodがPendingからRunningに移行するのを監視
kubectl get pods -A -w | grep -v Running
成功メッセージのログを追跡して、CNIが実際に動作していることを確認します：
kubectl logs -n kube-system [CNI_POD_NAME] | grep "Successfully assigned IP"
予防のためのプロのヒント
IPの枯渇は、通常は単なる計算ミスです。新しいノードグループを起動する前に、Pod密度のピークを計算してください。ローリングアップデートも考慮に入れる必要があります。デプロイ中、Podの数が一時的に2倍になり、2倍のIPが必要になることがあります。
私は、 /24 や /22 が実際にどれだけのPodを保持できるかを可視化するためにサブネット計算機を使用しています。その合計からノードのIPと予約済みのアドレスを引くことを忘れないでください。個人的には、ToolCraftのサブネット計算機を使用しています。高速でブラウザで動作し、ネットワークデータのプライバシーも保たれます。新しい IPPool を適用する前に、CIDRの計算を再確認するのに最適な方法です。
「ゾンビ」IPの消去
ノードがクラッシュし、CNIがそのIPを解放できないことがあります。これにより、スペースを占有する「ゾンビ」割り当てが発生します。通常、CNIのPodを再起動すると再同期がトリガーされ、これらがクリーンアップされます：
kubectl rollout restart ds aws-node -n kube-system
ベアメタルの場合は、ホストノード上の /var/lib/cni/networks/ を確認してください。削除されなかった古い割り当てを示す古いファイルが見つかることがあります。
最後に
IP範囲の拡張は当面のクラッシュを解決しますが、ファイアウォールの確認も忘れないでください。セキュリティグループやオンプレミスのファイアウォールが、新しい CIDR範囲からのトラフィックを許可していることを確認してください。このステップを忘れると、Podは起動しますが、どこにも通信できなくなります。