Google Cloudは、GKEサービスにおいて、2段階のコントロールプレーン・アップグレードが一般提供（GA）開始されたことを発表しました。これにより、ソフトウェアバイナリのアップグレードとデータ形式の移行を分離でき、マイナーバージョンの変更中にロールバック可能な期間を確保できるようになります。

なぜGKEに、より安全なパスが必要だったのか

Kubernetesのコントロールプレーンをあるマイナーバージョンから次のバージョンへアップグレードすることは、常にリスクを伴ってきました。1.33から1.34への移行は、バイナリを置き換えるだけでなく、基盤となるデータ構造も書き換えます。新しいバージョンにバグが含まれている場合、クラスターを単純に元に戻すことはできません。管理者は古いデータベースのスナップショットを復元するか、クラスター全体を再構築する必要があり、これは時間がかかり、エラーが発生しやすいプロセスです。

2段階アップグレードの仕組み

新しいフローでは、アップグレードを2つの明確なフェーズに分割します。

  • ステップ 1 – バイナリ・アップグレード（エミュレーション・モード）。 GKEは、古いデータ形式を保持したまま、コントロールプレーンのバイナリをターゲットのバージョンに切り替えます。新しいデータ構造が書き込まれないため、このフェーズの間、クラスターはロールバック可能な状態を維持します。
  • ステップ 2 – 最終化（Finalization）。 設定可能な待機期間の後、GKEは保存されているデータを新しい形式に変換します。この変換が完了すると、ロールバックには、2段階プロセスが回避するために設計されたものと同じ、スナップショットの復元作業が必要になります。

この分離により、オペレーターは不可逆的なデータ移行を実行することなく、本番環境でアップグレードされたバイナリを観察できる「ソーク・ウィンドウ（soak window）」が作成されます。

実践におけるソーク・ウィンドウ

GKEは、ソーク期間中に主要なヘルス指標（APIレイテンシ、エラー率、ポッドの健全性）を自動的に監視します。サービスが異常を検知すると、ロールアウトを停止し、クラスターをロールバックが可能な「バイナリのみの状態」に留めます。Googleは、このパターンに従ったアップグレードの成功率が99.999%であると述べています。

GKEの自動アップグレード機能を使用しているクラスターの場合、プラットフォームが手動の介入なしに2段階のシーケンス全体をオーケストレートします。完全な制御を好むユーザーは、Cloud CLIまたはTerraformを通じてプロセスを実行できます。

手動での2段階アップグレードの実行

48時間の安全期間を設けた典型的な手動アップグレードは、以下のようになります。

gcloud beta container clusters upgrade my-cluster \
  --location=us-central1 \
  --cluster-version=1.34.1-gke.1829001 \
  --control-plane-soak-duration=48h \
  --master

現在のステータスを確認するには：

gcloud container clusters describe my-cluster \
  --location=us-central1 \
  --format="yaml(rollbackSafeUpgradeStatus)"

ソーク中に欠陥が判明した場合、管理者はロールバックコマンドを発行して、データ損失なしに前のバージョンに戻すことができます。クラスターが安定していることが確認できたら、complete-control-plane-upgradeコマンドを使用して、アップグレードを早期に完了させることができます。

制限事項と要件

  • この機能は、バージョン1.33以降を実行しているGKEクラスターに適用されます。
  • 一度にアップグレードできるのは1つのマイナーバージョンのみです。バージョンのスキップはサポートされていません。
  • 2段階のプロセス中も、Autopilotおよびリージョナルクラスターは引き続き利用可能です。

潜在的なデメリット

バイナリとデータのアップグレードを分離すると、アップグレードのタイムラインに余分なステップが追加されます。これは、迅速なバージョン変更を必要とする組織にとって、全体の期間を延長させる可能性があります。また、ソーク期間は自動化されたヘルスチェックに依存しています。高度にカスタマイズされたワークロードを実行しているチームは、エッジケースのデグレ（退行）を捉えるために、GKEのモニタリングを独自のオブザーバビリティ・ツールで補完する必要があるかもしれません。

今後の注目点

Googleは、2段階モデルをメジャーバージョンのアップグレードに拡張するロードマップを公開していません。メジャーバージョンのアップグレードは、多くの場合、依然としてクラスターの完全な再作成を必要とします。今後は、ノードプールのアップグレードに対する同様のセーフティネットや、ソーク・ウィンドウのチェックを自動化できるサードパーティのCI/CDパイプラインとの統合に関する発表が注目されます。

まとめ: バイナリのアップグレードとデータ移行を切り離すことで、GKEはプラットフォームエンジニアに対し、マイナーバージョンの変更における実用的なロールバック・ウィンドウを提供します。これにより、ダウンタイムを最小限に抑えつつ、クラスターメンテナンスの運用コストを削減できます。