GKE StandardからAutopilotへの移行

この記事は、「ウェブクルー Advent Calendar 2025」の18日目の記事です。
昨日は@wc-tatsumiさんの「【AI時代に効く“なんとなく読書”】バラバラに本を読んでいたら、ある日ぜんぶつながってデザインの仕事が変わった話」でした。

はじめに

本記事では、私たちのチームが実施したGKE StandardクラスタからAutopilotクラスタへの移行プロジェクトについて、その背景、技術的課題、そして具体的な成果を解説します。

1. 移行の背景と目的

移行前のGKE Standardクラスタ運用には、主に2つの課題がありました。

• 運用負荷：頻繁なノードアップグレード作業が特定の担当者に集中し、属人化と高い負荷が問題でした。この運用負荷の削減が、本プロジェクトの最大の目的でした。
• コスト効率：リソース使用率が低い環境でノードが常時稼働するため、コストが最適化されていない状況を肌感覚で認識していました。

2. プロジェクト概要

• 期間：2024年10月〜2025年7月
• 対象：15クラスタ、約200ワークロード
• 体制：2名（筆者とインフラメンバー）
• 制約: 2025年7月のCUD（確約利用割引）更新前に、コスト二重化を避けるため旧Standardクラスタの完全削除が必須でした。

3. 移行における主要な技術課題と解決策

移行は単純なプラットフォーム変更ではなく、複数の技術的課題への対応が必要でした。

3.1. 既存マニフェストの更新

約200のワークロードを移行するため、既存のKubernetesマニフェストファイル全てに手を入れる必要がありました。以下に注力した内容について記載しました。

• コスト最適化の取り組み
  • リソース最適化
    • 全ワークロードのCPUとメモリの要求値を修正しました。
    • 既存の実績をもとに最適な値を設定しました。
  • Spot Podの積極活用
    • コストをさらに削減するため、開発(develop)・ステージング(staging)環境では、中断されても問題ないワークロードに対してSpot Podを積極的に利用しました。
  • Podバースト機能の活用
    • リソース最適化からの応用として、Podバースト機能を導入し、一時的な負荷増大にも耐えられる設計としました。
    • 本機能は便利ですが、リソースの要求と上限の差が大きい状態で一時的な負荷増大が発生するとスケールする前にPodが異常終了することがあり、扱いが難しいと思いました。
• Pod Disruption Budget(PDB) の設定
  • サービスの可用性を担保するため、minAvailable を指定したPDBを各ワークロードに設定しました。
  • AutopilotではNodeがGoogle Cloudの自動管理のため、PDBの設定がない場合、制限なくエビクション可能な状態となってしまうため、必要な対応でした。

3.2. ネットワーク：NodePortからNEGへの移行

Standardで標準だったNodePort Service + 内部パススルーネットワークロードバランサ(ILB)構成が、Autopilotでは利用できません。Podに直接トラフィックをルーティングするNetwork Endpoint Group(NEG)への移行が必須でした。

このNEGへの理解不足が原因で、サービス停止障害が発生しました。

• 発生した課題：当初、NEGを手動で作成しLBに紐付けていました。Podが特定の1ゾーンにしか存在しなかったため、そのゾーンのNEGしか登録していませんでした。その後、Podが別のゾーンにエビクションした際、LBはPodのいない古いゾーンを見続けたため、通信ができなくなりました。
• 解決策：LBのバックエンドサービスに、あらかじめ全ゾーンのNEGを登録しておくように変更しました。Podが存在しないゾーンのNEGはGKEが自動で異常と判断するため、Podの移動に追従できます。また、新規でLBを作成する際にはGatewayAPIを利用して自動作成するようにしています。

3.3. 外部通信：Egress IPの枯渇

移行途中に以下課題が発生しました。

• 発生した課題：移行途中はStandardクラスタとAutopilotクラスタの並行運用をしており、Google Cloud内部から外部へのトラフィック増加が発生し、Google Cloud全体で共有していたCloud NATの送信元IPアドレスが枯渇し、外部連携に失敗するケースが発生しました。
• 解決策：Cloud NATゲートウェイを追加しました。

4. 移行の成果

移行を完了させた結果、以下の成果を得ました。

• 運用負荷の削減：ノードのアップグレードやセキュリティパッチ適用が不要になり、担当者の負荷が大幅に軽減されました。
• 年間約2,000万円のコスト削減見込み：当初の主目的ではありませんでしたが、移行を機に全ワークロードのリソースを最適化した結果、大幅なコスト削減に繋がりました。これは副次的ながら最大の成果となりました。

5. まとめ

GKE Autopilotへの移行は、運用負荷とコストという課題を解決する有効な手段です。本プロジェクトでは、技術的な課題を乗り越え、大きな成果を得ることができました。
今回はなるべく簡潔にプロジェクト全体について記載したので、技術的な詳細などは書けていません。時間があるときに書きたいなあという気持ちです。

個人的に、Kubernetesという好きな技術を深く追求し、ビジネスに貢献できたことは貴重な経験であり、私に任せていただいたマネージャーには感謝しかありません。この記事が、同様の課題を持つ方々の参考になれば幸いです。

---

明日は@yuko-tsutsuiさんの投稿になります。よろしくお願いします。