Containers & Kubernetes

マイナーバージョンのロールバックで Kubernetes バージョンのアップグレードがより安全に

2025年11月17日

Siyuan Zhang

Software Engineer

Wenjia Zhang

Engineering Manager

Try Gemini 2.5

Our most intelligent model is now available on Vertex AI

Try now

※この投稿は米国時間 2025 年 11 月 5 日に、Google Cloud blog に投稿されたものの抄訳です。

Kubernetes クラスタのアップグレードは、常に一方通行でした。前進するしかなく、コントロールプレーンに問題が発生した場合は、修正を適用してロールフォワードするしかありませんでした。これは日常的なメンテナンスに大きなリスクをもたらします。組織が新しい AI 機能のためにアップグレードを頻繁に行うようになり、同時に最大限の信頼性を求めるようになると、この問題はさらに悪化します。このたび、Kubernetes コミュニティと連携して、この問題を解決する Kubernetes 1.33 の新機能、Kubernetes コントロールプレーンのマイナーバージョンロールバックを導入しました。コントロールプレーンのアップグレードをロールバックする信頼できる方法が初めて提供されることで、クラスタのライフサイクル管理が根本的に変わります。この機能はオープンソースの Kubernetes で利用可能で、Google Kubernetes Engine では GKE 1.33 以降で統合され、まもなく一般提供される予定です。

課題: ロールバックが困難だった理由

Kubernetes のコントロールプレーンコンポーネント、特に kube-apiserver と etcd はステートフルであり、API バージョンの変更に非常に敏感です。アップグレードすると、新しいバイナリに多くの新しい API と機能が導入されます。一部のデータは、新しい形式や API バージョンに移行される場合があります。変更を安全に元に戻すメカニズムがないため、ダウングレードはサポートされていませんでした。ダウングレードすると、データが破損し、クラスタ障害が発生するリスクがありました。

簡単な例として、既存のリソースに新しいフィールドを追加することを考えてみましょう。これまで、ストレージと API は同時に処理されていたため、クライアントは新しいフィールドにすぐにデータを書き込むことができました。回帰が検出された場合、ロールバックによってそのフィールドへのアクセスは削除されますが、書き込まれたデータはガベージコレクションされません。代わりに、etcd にサイレントに保存されます。これにより、管理者はどうすることもできない状況に陥ります。さらに悪いことに、そのマイナーバージョンに再アップグレードすると、この古い「ガベージ」データが突然「復活」し、問題が発生する可能性のある、予測不可能な動作を引き起こす場合があります。

解決策: エミュレートされたバージョン

Kubernetes Enhancement Proposal（KEP）の KEP-4330: Compatibility Versions では、コントロールプレーンの「エミュレートされたバージョン」というコンセプトが導入されています。Google 社員が提供したこの機能により、2 段階の新しいアップグレードプロセスが作成されます。

ステップ 1: バイナリをアップグレードする。コントロールプレーンのバイナリはアップグレードされますが、「エミュレートされたバージョン」はアップグレード前のバージョンと同じままです。この段階では、すべての API、機能、ストレージデータ形式は変更されません。これにより、問題が見つかった場合にコントロールプレーンを以前の安定版に安全にロールバックできます。

健全性を検証し、回帰をチェックする。最初のステップでは、安全な検証期間が作成されます。この期間中は、新しい API バージョンにコミットする前に、続行しても安全であることを確認できます。たとえば、新しいバイナリで独自のコンポーネントやワークロードが正常に実行されていることを確認したり、パフォーマンスの低下がないかチェックしたりできます。

ステップ 2: アップグレードを完了する。テストが完了したら、エミュレートされたバージョンを新しいバージョンに「バンプ」します。これにより、最新の Kubernetes リリースのすべての新しい API と機能が有効になり、アップグレードが完了します。

https://storage.googleapis.com/gweb-cloudblog-publish/images/image1_dq2nDBb.max-1400x1400.png

この 2 段階のプロセスにより、きめ細かい制御、より優れたオブザーバビリティ、ロールバックの安全な検証期間が実現します。アップグレードで予期しない問題が発生した場合、ロールフォワードのために慌てる必要はなくなります。これにより、既知の良好な状態に戻し、クラスタを安定させ、次の動きを冷静に計画するための信頼できる方法が提供されます。これらはすべて、オープンソースの Kubernetes と GKE の両方で 2 段階アップグレードの包括的なテストによって裏付けられています。

これを実現するには多大な労力が必要でしたが、テスト、コンプライアンス、機能の適応に尽力し、この高度な機能を現実のものとしたすべての Kubernetes のコントリビューターと機能のオーナーに感謝いたします。

GKE 1.33 で近日リリース予定のこの機能は、アップグレードのリスクを軽減し、予期せぬ問題からの復旧時間を大幅に短縮する新しいツールとなります。

OSS Kubernetes でのアップグレードエクスペリエンスの向上

このロールバック機能は、コミュニティ全体の Kubernetes アップグレードエクスペリエンスを向上させるための、Google の長期的な大規模投資の一環にすぎません。Google では、クラスタの運用をよりスムーズ、安全、自動化するために、他にもいくつかの重要な機能強化をアップストリームで取り組んでいます。その一例をご紹介します。

バージョンをスキップしたアップグレードのサポート: KEP-4330 に関する作業により、Kubernetes の「スキップレベル」アップグレードが可能になります。つまり、すべてのマイナーバージョンに順番にアップグレードしていく必要がなくなり（例: v1.33 から v1.34、v1.35）、古いバージョンから新しいバージョンに直接アップグレードできるようになります。場合によっては、1 つ以上の中間リリースをスキップできます（例: v1.33 から v1.35）。これにより、大規模なアップグレードに伴う複雑さを軽減してダウンタイムを削減し、クラスタオペレータにとってプロセスをより効率的で中断の少ないものにすることを目指しています。
Coordinated Leader Election（KEP-4355）: この取り組みにより、さまざまなコントロールプレーンコンポーネント（kube-controller-manager や kube-scheduler など）がアップグレード中のリーダーシップの変更を適切に処理できるようになり、Kubernetes のバージョンスキューポリシーに違反しないようになります。
Graceful Leader Transition（KEP-5366）: 上記を基に、リーダーがアップグレードのためにシャットダウンする前に、そのポジションをクリーンに引き継ぐことができるようになります。これにより、コントロールプレーンコンポーネントのダウンタイムなしの移行が可能になります。
Mixed Version Proxy（KEP-4020）: この機能は、バージョンが混在するクラスタ（アップグレード中など）における API サーバーの信頼性を向上させます。リソースを認識するサーバーにリソースリクエストをインテリジェントにルーティングすることで、誤った「NotFound」エラーを防止します。また、検出によって、バージョンが混在するクラスタ内のすべてのサーバーからすべてのリソースの完全なリストが提供されるようにします。
Component Health SLIs for Upgrades（KEP-3466）: 安全にアップグレードするには、クラスタが正常な状態かどうかを知る必要があります。この KEP では、Kubernetes のコアコンポーネントの標準化されたサービスレベル指標（SLI）を定義します。これにより、自動アップグレードのカナリア分析に使用可能な、明確なデータドリブンシグナルが提供され、クラスタ全体に影響する前に不適切なロールアウトを停止できます。