GKE Autopilot モードで IP 不足で Pod が更新できなくなった
教訓
GKE Autopilotモードでは、余裕を持って 「サブネットで Pod に使用するセカンダリ IP レンジ」を指定するべき。（推奨は/21以上）
事象
GKE 以外でも共有の VPC ネットワークを利用しており、あまり多くの IP レンジを確保したくないという理由から、最低限の IP レンジ(/24)しか設定しなかった。
その結果、下記のようなエラーで Pod の更新ができなくなってしまった。
Can’t scale up because instances in managed instance groups hosting node pools ran out of IPs
https://www.googleapis.com/compute/v1/projects/xxxxx/zones/asia-northeast1-a/instanceGroups/xxxxx
due to Other.IP_SPACE_EXHAUSTED; source errors: Instance 'xxxxx' creation failed: IP space of 'projects/xxxx/regions/asia-northeast1/subnetworks/xxxxx' is exhausted.
Autopilot モードとは、Standard モードとの違い
GKE AutopilotモードではGoogle Cloudがクラスタのノード管理を行い、Pod単位での課金が生じます。一方、Standardモードではユーザー自身がノード管理を行い、ノード単位での課金が行われます。
今回は「Autopilot ではノード管理をユーザ自身ができない」というのがかえってエラーを引き起こした原因になりました。
Node、PodへのIPの割り当て仕様
GKEでは、Pod 用のサブネット セカンダリ IP アドレス範囲がサポートできるノードの最大数は以下の数式で表されます。
Pod 用のサブネットセカンダリ IP アドレス範囲がサポートできるノードの最大数
=f(ノードあたりのPod数、サブネットのセカンダリ IP アドレス範囲のサブネットマスクサイズ)
このうち、Autopilot ではノードあたりのPod数は32で固定なので、
サブネットのセカンダリ IP アドレス範囲とノードの最大数の対応表は下記のようになります。
| サブネットのセカンダリ IP アドレス範囲 | ノードの最大数 |
|---|---|
| /24 | 4 |
| /23 | 8 |
| /22 | 16 |
| /21 | 32 |
| /20 | 64 |
| /19 | 128 |
| /18 | 256 |
| /17 | 512 |
| /16 | 1024 |
AutopilotのNodeプロビジョニング仕様
今回の事象では、.spec.replicas: 3 の Deployment が3つのような構成（通常時合計9個のPod）で、Autopilot は Node を4つ以上プロビジョニングしようとしたようでした。
しかし、サブネットのセカンダリ IP アドレス範囲は /24 で設定していたため、 Node のプロビジョニング に失敗しました。
このあたりの Node 数を調整できないのは、Standard モードと違って逆に不便かもしれません。
クラスタ内の合計 Pod 数の 1~1.5倍の Node 数がプロビジョニングされるという計算で、サブネットのセカンダリ IP アドレス範囲を設定するとよいでしょう。
解決策
割り当て IP の不足により Pod 更新ができなくなってしまった場合の対応方法は主に下記2つです。
- 追加のセカンダリ範囲を作成してクラスタに割り当てる
- セカンダリ範囲を拡張して作成し直し、クラスタを再作成する
何か間違いあれば指摘いただけると幸いです。
Discussion