GKEノードプールをBlue/Greenでアップグレードして、soak期間中にロールバックしてみた

Sat, 05 Sep 2026 00:00:00 +0900

概要
#

ノードプールのアップグレードには3つの戦略があります。既定のSURGEは既存ノードを順番に置き換えていく方式。BLUE_GREENは新しいノード群（green）を丸ごと作ってからワークロードを移し、しばらく旧ノード群（blue）を残します。

3つ目のAutoscaled blue-greenはPreviewで、greenを0台から必要に応じて増やします。ノードが倍にならない代わりに、キャンセル後のロールバックには対応していません。この記事で測るのは標準のBLUE_GREENだけです。

この「しばらく残す」時間がnode_pool_soak_durationで、ロールバックできる猶予にあたります。満了するとblueは削除され、後戻りできません。

ところが、その窓の中で実際にどうロールバックするのかは、あまり書かれていません。試したところgcloud container node-pools rollbackを打っても拒否されました。正しい手順は別にあります。

前回はkubectl drainで手動移行し、断をゼロにするまで構成を作り込みました。今回は同じワークロードをGKEに移させて、同じものさしで測ります。

対象読者は、GKEのクラスタをTerraformで作ったことがある人です。ノードプールのアップグレードを運用でやる立場を想定しています。Kubernetesの入門は扱いません。

SURGE戦略との実測比較は次回に回します。Autopilotクラスタとコントロールプレーンのアップグレード戦略は扱いません。

検証すること
#

アップグレード中にサービスがどれだけ止まるか
soak期間中に本当にロールバックできるか。どうやるか
いまアップグレードのどの段階にいるかを、どう知るか
ブートディスクのCMEK鍵バージョンはどうなるか
アップグレード後のterraform planに差分が出ないか

前提環境
#

Google Cloud CLI、Terraform
Billingが有効な検証用Google Cloud Project
GKE、Cloud KMS、Compute Engineを操作できるGoogleアカウント
検証時のバージョン：Terraform 1.14.5、google 7.46.0
GKE 1.35.7-gke.1027000 → 1.35.7-gke.1150000（REGULARチャンネル）。この記事でノードが到達したのはここまでです。 後半に出る 1.36.2-gke.2064000 はコントロールプレーンの master_version で、2回目の移行先は記録していません

Blue/Greenアップグレード中はノードが一時的に倍になります。PodのセカンダリレンジとvCPUの割り当てに余裕が要ります。

GKEノードのブートディスクをCMEKで暗号化して鍵をローテーションしてみた

Fri, 04 Sep 2026 00:00:00 +0900

概要
#

顧客管理の暗号鍵（CMEK）でGKEノードのブートディスクを暗号化すると、鍵の管理責任がこちらに移ります。定期的なローテーションもその一つです。

ところが鍵をローテーションしても、稼働中のノードは何も変わりません。ディスクは古い鍵バージョンで暗号化されたままです。しかもterraform planは差分なしで通ります。「回したから終わり」と思って旧バージョンを無効化すると、次にノードが再起動したとき起動できません。

この記事では、鍵をローテーションしたあと何が起きるかを実測します。新しい鍵バージョンへの移し方と、移行中にサービスがどれだけ止まるかまで見ます。

対象読者は、GKEのクラスタをTerraformで作ったことがあり、Cloud KMSの鍵を触ったことがある人です。それぞれの入門は扱いません。

Blue/Greenアップグレードを使った移行は扱いません。etcdやPersistentVolumeのCMEKも扱いません。ノードのブートディスクだけを見ます。

検証すること
#

鍵をローテーションしたあと、既存ノードのブートディスクはどうなるか
ローテーション後のterraform planは差分を検知するか
新しい鍵バージョンにするには、本当にノードプールの入れ替えが必要か
ノードプールを入れ替える移行で、サービスはどれだけ止まるか
旧鍵バージョンを無効化すると何が起きるか
Cloud Loggingに何が残るか

前提環境
#

Google Cloud CLI、Terraform
Billingが有効な検証用Google Cloud Project
GKE、Cloud KMS、Compute Engineを操作できるGoogleアカウント
検証時のバージョン：Terraform 1.14.5、google 7.46.0、GKE 1.35.7-gke.1027000（REGULARチャネル）

使用するTerraformコード
#

Advanced-Examples/20-gke-cmek-node-boot-disk-rotation

今回の構成
#

flowchart TB
    subgraph GCP["Google Cloud"]
        KMS["Cloud KMS
鍵バージョン 1 / 2"]
        subgraph VPC["VPC"]
            subgraph GkeSubnet["GKE Subnet（外部IPなし）"]
                NP1["ノードプール v1
ディスク = 鍵バージョン 1"]
                NP2["ノードプール v2
ディスク = 鍵バージョン 2"]
            end
            Bastion["踏み台"]
        end
    end

    KMS -->|"作成時のprimaryで暗号化"| NP1
    KMS -->|"作成時のprimaryで暗号化"| NP2
    Bastion -->|"kubectl"| NP1

ノードプールは2つともboot_disk_kms_keyに同じ鍵を指定しています。違うのは作られた時刻だけです。

CloudKMS on LIFELOG

GKEノードプールをBlue/Greenでアップグレードして、soak期間中にロールバックしてみた

概要 #

検証すること #

前提環境 #

GKEノードのブートディスクをCMEKで暗号化して鍵をローテーションしてみた

概要 #

検証すること #

前提環境 #

使用するTerraformコード #

今回の構成 #

概要
#

検証すること
#

前提環境
#

概要
#

検証すること
#

前提環境
#

使用するTerraformコード
#

今回の構成
#