どんな場面で検討するか
Kubernetesで複数サービスを配備し、共通の更新・権限・ネットワークルールを運用したい場合。ノード運用をGoogleへ寄せるAutopilotと、ノード構成を自分で制御するStandardを比較する。
組織で使う条件
Autopilotでもアプリの更新、Pod資源要求、HPA、監視、権限、バックアップを管理する。リリースチャネルとメンテナンスを確認し、Workload Identity Federationで長期キーへの依存を減らす。
採用前に試すこと
- 小規模な商品APIを配備し、CPU・メモリ要求、2Pod、最小権限を設定する。
- 合成要求100件を送信し、Podの追加と1Podの削除を試し、完了件数とスケーリング時間を記録する。
- イメージの更新・切戻しと検証資源の削除を行い、管理料金・Podまたはノード料金・追加資源を分けて記録する。
合格と判断する条件
- 同一結果を返す100件を照合でき、更新と切戻しを再現できる。
- 自動設定された資源要求が把握でき、選択したPod/ノード課金モデルと実際の明細が一致する。
見落としたくない点
- 少数のステートレスHTTPコンテナだけならCloud Runと比較する。特殊なノード制御が必要なのにAutopilotの既定動作を前提に決めない。
- 少数のステートレスHTTPコンテナだけならCloud Runと比較する。特殊なノード制御が必要なのにAutopilotの既定動作を前提に決めない。