GKE on LIFELOG

GKEでPodの退避を起こしたら、監視に必要なメトリクスがCloud Monitoringに来なかった

Sun, 06 Sep 2026 00:00:01 +0900

概要
#

ノードのメモリやディスクが逼迫すると、kubelet が Pod を退避（Eviction）します。退避された Pod は Failed として API 上に残り、PodGC が片付けるまで一覧に並び続けます。

監視していなければ、原因の分からない Failed Pod が増えていくだけです。

そこで退避を監視しようとして、最初につまずきました。kube_pod_status_reason{reason="Evicted"} を Cloud Monitoring で引いても、何も返ってきません。

これは kube-state-metrics が出すメトリクスで、Pod の status.reason をそのままラベルにしたものです。退避された Pod には reason="Evicted" のラベルが付きます。

Gauge なので、sum() で分かるのは現在 API 上に残っている Evicted の Pod 数です。累積の退避回数ではありませんが、退避を検知するアラートなら、まず候補に挙がります。

sum(kube_pod_status_reason{reason="Evicted"}) > 0

収集そのものは動いていました。Managed Service for Prometheus（GMP）は有効で、up{job="kube-state-metrics"} は 1 を返します。それでも、退避を数えるためのメトリクスだけが Cloud Monitoring に入っていません。

この状態でどこを見れば退避に気づけるのか。GKE で実際に退避を起こして確かめました。

対象読者
#

GKE でワークロードを動かしたことがある
kubectl describe で Pod の状態を読める

扱わないもの
#

Kubernetes と GKE の入門
Pod Disruption Budget、kubectl drain による退去（今回はノード逼迫による退避）
HorizontalPodAutoscaler、Cluster Autoscaler

退避が起きたときに、何をどこで観測できるかに絞ります。

標準出力に1行JSONを書くだけなら、GKEではFluentdサイドカーが要らなかった

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

概要
#

構造化ログをCloud Loggingに送りたいとき、Fluentdをサイドカーに置く構成があります。GKEでそれが要るのかを確かめました。

さらに、fluent.confに書いたtagやrecord_transformerが、Cloud Logging上のどのフィールドになるのかも対応が分かりません。サイドカーを入れたのに期待したキーで検索できない、という状態になりがちです。

実際に測ってみると、GKEの収集エージェントが既にJSONを解釈していました。 アプリが標準出力に1行JSONを書くなら、サイドカーは要りません。しかも挟み方を誤ると、逆に構造を失います。

ファイルに書く場合は別です。 GKEの標準収集が拾うのはコンテナの標準出力と標準エラーなので、ファイル出力を届けるには何かが要ります。

対象読者は、GKEでPodを動かしたことがあり、Cloud Loggingでログを見たことがある人です。Kubernetesの入門は扱いません。

Log Routerによる転送、Log-based metrics、Autopilotクラスタは扱いません。

検証すること
#

素のテキストとJSONで、入るフィールドが変わるか
構造化ログにFluentdサイドカーは必要か
fluent.confの設定がCloud Loggingのどのフィールドになるか
スタックトレースが1エントリにまとまるか

前提環境
#

Google Cloud CLI、Terraform
Billingが有効な検証用Google Cloud Project
GKE、Compute Engineを操作できるGoogleアカウント
検証時のバージョン：Terraform 1.14.5、google 7.46.0、GKE 1.35.7-gke.1027000、fluentd v1.16-debian-1

使用するTerraformコード
#

Advanced-Examples/24-gke-fluentd-log-format

READMEの手順でTerraformを適用し、k8s/配下の4つのマニフェストを当てます。クラスタはプライベートエンドポイント構成なので、以下のkubectlは踏み台VMから実行します。

GKEのdefault_compute_class_enabledを有効にしても何も起きなかったので調べた

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

概要
#

cluster_autoscaling.default_compute_class_enabledというスイッチがあります。Terraform Registryの説明はこうです。

If enabled, cluster autoscaler will use Compute Class with name default for all the workloads, if not overriden.

有効にすればオートスケーラがdefaultというComputeClassを使ってくれる、と読めます。ところが有効にしても何も変わりません。ノードの選ばれ方も、kubectl get computeclassesの中身も、有効にする前と同じで、期待した動作になりませんでした。

有効なのに何も変わらないので、設定が効いているのかどうかを判断できません。 そこで、切り替えながら実測して何を制御しているのかを確かめます。

名前がややこしいことも、調べにくさに拍車をかけています。

層	名前
Terraform	`cluster_autoscaling.default_compute_class_enabled`
REST API	`clusterAutoscaling.defaultComputeClassConfig.enabled`
コンソール	Autopilot compute class compatibility

同じスイッチを3通りの名前で呼んでいるので、ドキュメントを横断すると別機能に見えます。

対象読者は、GKEのStandardクラスタをTerraformで作ったことがある人です。ノード自動プロビジョニング（NAP）とオートスケーラの入門は扱いません。

Autopilotクラスタそのもの、カスタムComputeClassの設計指針、GPU/TPUの選択は扱いません。

検証すること
#

有効にすると何が変わるか
defaultというComputeClassは誰が作るのか
スイッチのON/OFFでオートスケーラのマシン選択が変わるか
切り替えはクラスタ再作成を伴うか

前提環境
#

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

使用するTerraformコード
#

Advanced-Examples/23-gke-default-compute-class

スイッチが効く場所
#

flowchart TB
    POD["Pod
nodeSelector も computeClass も指定なし"]
    POD --> SCHED["スケジューラ"]
    SCHED -->|"既存ノードに空きがない"| NAP["Node Auto Provisioning"]
    NAP --> SW{"default_compute_class_enabled"}
    SW -->|"false"| OLD["従来の選び方でマシンを決める"]
    SW -->|"true"| NEW["既定の ComputeClass に従う"]

このスイッチは何も指定していない Pod のために NAP がマシンを選ぶときにだけ効きます。既存ノードに空きがあれば、そこに載って終わりです。

GKEノードプールのSURGEアップグレードをBlue/Greenと同じ条件で測って比べてみた

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

概要
#

ノードプールのアップグレード戦略はSURGEとBLUE_GREENの2つです。どちらを選ぶべきか決めたいのに、判断材料がありません。「BLUE_GREENは安全」「SURGEは速い」といった説明はあっても、どれくらい違うのかが書かれていないので、比較ができません。

前回はBlue/Greenを測りました。今回は同じ条件でSURGEを測って、並べます。ノード数もワークロードも計測方法も前回と同一にして、違いはupgrade_settingsだけにしてあります。

あわせてmax_surge / max_unavailableの2つの組み合わせも比べます。この2つは「速さと引き換えに何を失うか」を決める設定です。

対象読者は、GKEのノードプールを運用でアップグレードする立場の人です。Kubernetesの入門は扱いません。

Autopilotクラスタ、コントロールプレーンのアップグレード戦略、メンテナンスウィンドウは扱いません。

検証すること
#

SURGEでアップグレード中にどれだけ止まるか
max_surge = 0にすると何が変わるか
一時的にノードがどれだけ増えるか
Blue/Greenとどちらを選ぶべきか

前提環境
#

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 → 1.36.2-gke.2064000（REGULARチャンネル）

使用するTerraformコード
#

Advanced-Examples/22-gke-surge-node-pool-upgrade

SURGEとBlue/Greenの進み方の違い
#

flowchart TB
    subgraph SURGE["SURGE"]
        S1["余剰ノードを max_surge 台足す"]
        S2["1バッチずつ入れ替える"]
        S3["古いノードを削る"]
        S1 --> S2 --> S3
    end
    subgraph BG["Blue/Green"]
        B1["新しいノード群を全部作る"]
        B2["batch_percentage ずつ移す"]
        B3["node_pool_soak_duration 待つ"]
        B4["古い群をまとめて消す"]
        B1 --> B2 --> B3 --> B4
    end

SURGE は少しずつ入れ替え、Blue/Green は新旧を並べてから移します。この違いが所要時間と切り戻しやすさに出ます。

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に同じ鍵を指定しています。違うのは作られた時刻だけです。

TerraformでGKEのPodにSecret Managerの値をファイルとしてマウントしてみた

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

概要
#

Terraformのwrite-only argumentでSecret Managerへ値を登録するでは、シークレットを保管するところまでを扱いました。保管した値をPodからどう取り出すかは残ったままです。

環境変数で渡す方法は手軽ですが、kubectl describe podやプロセス一覧から値が見えてしまいます。GKEのSecret Manager add-onを使うと、Podのファイルシステムにマウントする形で渡せます。

ただ「マウントできた」だけでは運用に足りません。シークレットを更新したら自動で反映されるのか。権限を剥がしたら動いているPodはどうなるのか。ログに何が残るのか。運用に入ってから調べ直すのでは遅いので、この3点を先に確かめておく必要があります。

対象読者は、GKEでPodを動かしたことがあり、Secret Managerに値を入れたことがある人です。それぞれの入門は扱いません。

環境変数への同期（secretObjects）は扱いません。シークレットの自動ローテーションも扱いません。

検証すること
#

Podの中でマウントしたファイルが読めること。Pod specに値が現れないこと
シークレットを更新したとき、稼働中のPodに自動で反映されるか
IAM権限を剥がしたとき、稼働中のPodと新しいPodがそれぞれどうなるか
Cloud Loggingに何が残るか

前提環境
#

Google Cloud CLI、Terraform、Docker
Billingが有効な検証用Google Cloud Project
GKE、Secret Manager、Compute Engineを操作できるGoogleアカウント
検証時のバージョン：Terraform 1.14.3、google 7.46.0

使用するTerraformコード
#

Advanced-Examples/19-gke-secret-manager-csi

今回の構成
#

flowchart TB
    subgraph GCP["Google Cloud"]
        SM["Secret Manager
（値はTerraform管理外）"]
        subgraph Project["Project"]
            subgraph VPC["VPC"]
                subgraph GkeSubnet["GKE Subnet（外部IPなし）"]
                    CSI["CSIドライバ
DaemonSet"]
                    Pod["Pod
/var/secrets/db-password.txt"]
                end
                Bastion["踏み台"]
            end
        end
    end

    CSI -->|"Private Google Access"| SM
    CSI -->|"ファイルとして配置"| Pod

ノードには外部IPがありません。Secret Manager APIへはPrivate Google Access経由で到達します。

TerraformでGKEのスタンドアロンNEGを消したらLBのバックエンドが戻らなかった話

Thu, 03 Sep 2026 00:00:00 +0900

概要
#

GKEのPodをInternal HTTP LB（NEG）でポート別に振り分けるでは、スタンドアロンNEGを作るところまでを扱いました。しかし運用で怖いのはその先です。「Serviceを間違って消してしまった」「クラスタを作り直した」というとき、ロードバランサは自動で復旧してくれるのでしょうか。

NEGはGKEが作り、LBのバックエンドはTerraformが管理します。作る主体が違うため、片方だけが変わると両者の認識がずれます。障害が起きてから手探りで復旧手順を探すのは避けたい。そこで、実際に壊して直るまでを先に確認しておきます。

対象読者は、GKEでNEGを使ったLB構成を組んだことがある人です。NEGそのものの入門は扱いません。

Internal LBは扱いません（前掲の記事で扱っています）。Cloud Armor、マネージドSSL証明書、Shared VPCも扱いません。

検証すること
#

正常系: 外部LB経由でPodへ到達できること
検証1: Serviceを削除するとどうなるか。再作成すればLBのバックエンドは自動で戻るか
検証2: LBを残したままGKEクラスタを作り直すとどうなるか

前提環境
#

Google Cloud CLI、Terraform、Docker
Billingが有効な検証用Google Cloud Project
GKE、Compute Engineを操作できるGoogleアカウント
検証時のバージョン：Terraform 1.14.3、google 7.46.0

使用するTerraformコード
#

Advanced-Examples/18-gke-standalone-neg-recovery

今回の構成
#

リージョナル・2ゾーンのプライベートGKEクラスタと、グローバル外部Application LBです。NEGはゾーンごとに作られるため、複数ゾーンにしています。

Peering越しのPod→VM通信が落ちる原因を、ルートだと思い込んでいた話

Wed, 02 Sep 2026 00:00:00 +0900

概要
#

複数のGoogle Cloud Projectをまたぐ構成では、「別チームのVMへ自分のPodから届かない」という壁にぶつかります。

相手側の設定を変えられない、あるいは変えたくない場面もあります。自分側だけで解決したいところです。

この記事は、いったん公開した内容を実測で覆したものです。

当初は「routes-basedなクラスタでは Pod のルートが交換されないから失敗する」と説明していました。確かめたら、どちらも違いました。

当初の説明	実測
routes-based なクラスタ	`useIpAliases: true` で VPC-native
Pod CIDR 宛のルートは交換されない	`peering-route-...` として交換されていた
失敗の原因はルートの非交換	宛先側のファイアウォール

結果そのものは変わりません。宛先側を触らず ConfigMap だけで復旧できます。変わったのは、なぜ直るのかの説明です。

Terraformの基本操作は前提としています。Dataplane V2 などのハードニング設定は前回のNetworkPolicy記事で扱っています。

検証すること
#

2プロジェクト構成で、PodからPeering先のVMへのcurlが失敗すること（Step 1: 再現）
宛先側の設定を変えず、ip-masq-agentのConfigMapだけで成功すること（Step 2: 解決）
クラスタは routes-based なのか VPC-native なのか
Pod CIDR 宛のルートは Peering で交換されているのか
失敗の原因はルートなのかファイアウォールなのか（対照実験）

前提環境
#

Google Cloud CLI、Terraform、Docker
Billingが有効な検証用Google Cloud Project 2つ
GKE、Compute Engine、VPC Peeringを操作できるGoogleアカウント
検証時のバージョン：Terraform 1.14.3、google 7.46.0

GKE・ノードイメージ・ip-masq-agent のバージョンは記録していません。ip-masq-agent が既定で入るかどうかも、既定の nonMasqueradeCIDRs も、このあたりで変わります。再現するなら次を控えておきます。

TerraformでGKE Dataplane V2を有効化し、NetworkPolicyでPod間通信を遮断してみた

Wed, 02 Sep 2026 00:00:00 +0900

概要
#

GKEプライベートクラスタと踏み台の構成は、デフォルトのデータプレーン（kube-proxy、iptablesベース）を使っていました。同じネームスペースに複数チームのアプリが同居する場合、Pod間の通信を意図したものだけに制限したい場面があります。

GKE Dataplane V2（Cilium/eBPFベース）は、NetworkPolicyの強制がビルトインされています。追加のCNI（Calico等）を用意しなくても、ラベルベースでPod間通信を制限できます。

「Dataplane V2を有効化した」ことと「NetworkPolicyが実際に意図通り機能する」ことは別です。許可したラベルのPodからは通り、許可していないPodからは遮断されることを、実際にPodを起動して確認します。

Terraformの基本操作と、前々回のGKEプライベートクラスタ＋踏み台構成は前提としています。

Filestore CSI、GCS FUSE CSI、Secret Manager CSI、NodeLocal DNSCache、詳細なLogging/Monitoring設定は扱いません。Dataplane V2とNetworkPolicyの検証に範囲を絞ります。

検証すること
#

datapath_provider = "ADVANCED_DATAPATH"でDataplane V2を有効化できること
許可したラベルのPodからは、NetworkPolicyで保護されたPodへ通信できること
許可していないPodからは、実際に通信が遮断されること（apply成功とは別の確認）

前提環境
#

Google Cloud CLI、Terraform、Docker
Billingが有効な検証用Google Cloud Project
GKE、Compute Engineを操作できるGoogleアカウント
検証時のバージョン：Terraform 1.14.3、google 7.46.0

使用するTerraformコード
#

通信がどこで遮断されるか
#

flowchart LR
    subgraph NODE["GKE ノード"]
        A["Pod A
label: role=client"]
        EBPF["Dataplane V2
eBPF による適用点"]
        B["Pod B
label: role=server"]
    end
    NP["NetworkPolicy
podSelector: role=server
ingress: role=client のみ"]
    NP -.->|"ルールを配る"| EBPF
    A -->|"許可"| EBPF --> B
    C["Pod C
label なし"] -->|"遮断"| EBPF

NetworkPolicy はルールを宣言するだけで、実際に落とすのは Dataplane V2 側です。

TerraformでGKEのノードあたり最大Pod数を小さくしすぎるとどうなるか試してみた

Wed, 02 Sep 2026 00:00:00 +0900

概要
#

GKEプライベートクラスタと踏み台の構成では、Pod用セカンダリIPレンジ（pods_cidr）を/16という余裕のあるサイズにしていました。実際の設計では、ノード数とノードあたりの最大Pod数から逆算してサイズを決める必要があります。

「レンジを大きく取れば安全」で終わらせず、ノードあたりの最大Pod数を意図的に小さくして、何が起きるかを実際に確認します。ノードあたりの最大Pod数（default_max_pods_per_node）は作成後に変更できないため、事前の見積もりを誤ると、クラスタを作り直す必要が出てきます。

Terraformの基本操作と、前々回のGKEプライベートクラスタ＋踏み台構成は前提としています。

複数ノード・複数ゾーンでの検証は扱いません。11-gke-private-bastionはゾーナル・1ノード構成のままです。services_cidrが作成後に拡張できない点も、実際の再現はせず公式ドキュメントの参照に留めます。

検証すること
#

ノードあたりの最大Pod数を小さく（8）設定してクラスタを作成できること
その上限だけで、GKEの管理コンポーネント自体がスケジュールできなくなること（apply成功とは別の確認）
ユーザーのPodも同じ理由でスケジュールに失敗すること

前提環境
#

Google Cloud CLI、Terraform、Docker
Billingが有効な検証用Google Cloud Project
GKE、Compute Engineを操作できるGoogleアカウント
検証時のバージョン：Terraform 1.14.3、google 7.46.0

使用するTerraformコード
#

新規のterraform-gcp-examplesディレクトリは作りません。今回の検証はレンジサイズと実際のPod数の関係に絞っているため、11-gke-private-bastionにmax_pods_per_node変数を追加し、既存のコードを流用しています。

TerraformでGKEのPodをInternal HTTP LB（NEG）でポート別に振り分けてみた

Tue, 01 Sep 2026 00:00:00 +0900

概要
#

GKEプライベートクラスタと踏み台を作った後、複数のアプリケーションをクラスタに同居させたくなる場面があります。リクエストをアプリごとに振り分けたい、という場面です。GKEのServiceだけではVPC内部からの経路が用意されません。Ingressを使わない場合、Podへの入り口をどう作るかが課題になります。

Internal HTTP LB（INTERNAL_MANAGED）は、GKEのPodをNetwork Endpoint Group（NEG）というバックエンドの形で直接受け取れます。Terraformが手動で作るNEGとは異なる点です。GKEのServiceにcloud.google.com/negというアノテーションを付けるだけです。GKEコントローラがNEGを自動的に作成します。

Terraformの基本操作と、前回のGKEプライベートクラスタ＋踏み台構成は前提としています。

Session Affinity（Cookie）は本記事では扱いません。外部ALB向けの構成例がterraform-gcp-examplesの10-regional-alb-session-affinityにあります（Terraformコードのみ）。Ingress（GKEのL7 LBコントローラ）や外部公開も扱いません。

検証すること
#

GKEのServiceアノテーションから、Network Endpoint Group（NEG）が自動作成されること
Internal HTTP LBで、共有VIPの3つのポート（:81/:82/:83）を、それぞれ異なるバックエンドへ振り分けられること
踏み台からVIPの3ポートへ実際に接続し、意図したバックエンドが返ること（LB作成の確認とは別）

前提環境
#

Google Cloud CLI、Terraform、Docker
Billingが有効な検証用Google Cloud Project
GKE、Compute Engine、IAMを操作できるGoogleアカウント
検証時のバージョン：Terraform 1.14.3、google 7.46.0

今回の構成
#

GKEのServiceにcloud.google.com/negアノテーションを付けると、GKEコントローラはクラスタが配置されているゾーンごとにNEGを作成します。この構成では3ゾーンにノードプールを配置しているので、1つのServiceにつき3つのNEG（ゾーンごと1つ）が対応します。

TerraformでGKEのコントロールプレーンをプライベート＋パブリックの両方から接続してみた

Tue, 01 Sep 2026 00:00:00 +0900

概要
#

GKEプライベートクラスタと踏み台の構成は、コントロールプレーンへのパブリックエンドポイントを完全に無効化していました。踏み台がないとkubectlが一切できません。開発初期の検証など、許可した自分のIPからは踏み台を経由せず直接繋ぎたい場面もあります。

GKEプライベートクラスタは、プライベートエンドポイントとパブリックエンドポイントを併用できます。パブリック側は許可IPだけに絞れるので、「VPC内は無条件、VPC外は限定IPのみ」という2段構えのアクセス制御になります。

Terraformの基本操作と、前々回のGKEプライベートクラスタ＋踏み台構成は前提としています。

Cloud VPN・Interconnect経由のオンプレミス接続は扱いません。IAM/RBACの認可設計も扱わず、接続経路の確認に絞ります。

検証すること
#

ローカルPCから、踏み台を経由せずパブリックエンドポイント経由で直接kubectlできること
許可していないIPからは接続できないこと（apply成功とは別の確認）
踏み台からは、プライベートエンドポイント経由で引き続き接続できること

前提環境
#

Google Cloud CLI、Terraform、Docker
Billingが有効な検証用Google Cloud Project
GKE、Compute Engineを操作できるGoogleアカウント
検証時のバージョン：Terraform 1.14.3、google 7.46.0

使用するTerraformコード
#

一次情報での裏取り：`enable_private_endpoint`の挙動
#

今回のコードは、別環境で検証したコードを土台にしています。ただし、そのコードはprivate_cluster_config.enable_private_endpoint = trueのままパブリックエンドポイントも使える、という前提で書かれていました。

TerraformでGKEプライベートクラスタからMemorystore for Redis Clusterへ接続してみた

Mon, 31 Aug 2026 00:00:00 +0900

概要
#

前々回はGKEプライベートクラスタと踏み台を作成しました。前回は、そこにMemorystore for Redis（BASIC）をPrivate Service Access（PSA）で接続しました。

同じMemorystoreでも、Redis Clusterの接続方式はPrivate Service Connect（PSC）です。専用のSubnetとService Connection Policyが必要になります。接続先も単一のホストではなく、Discovery Endpointです。名前が似ているため、前回のPSA接続の設定をそのまま流用しようとするとハマります。この違いを整理しておく必要があります。

Terraformの基本操作と、前々回のGKEプライベートクラスタ＋踏み台構成は前提としています。前回のRedis Instance（PSA接続）記事と読み比べると、PSAとPSCの違いが分かりやすくなります。

複数シャード構成、AUTH・転送時暗号化の有効化、レプリカ構成（HA）は最小構成のため扱いません。

検証すること
#

Private Service ConnectでGKE用VPCとRedis Clusterを接続できること
Memorystore for Redis Cluster（最小構成）を作成できること
PodからDiscovery Endpoint経由で実際に接続し、redis-cli -c（cluster mode）でPING・SET・GETが成功すること（Cluster作成の確認とは別）

前提環境
#

Google Cloud CLI、Terraform、Docker
Billingが有効な検証用Google Cloud Project
GKE、Compute Engine、IAM、Memorystoreを操作できるGoogleアカウント
検証時のバージョン：Terraform 1.14.3、google 7.46.0

今回の構成
#

Redis ClusterはPSAのようにVPC同士をPeeringしません。代わりに、Redis側のサービスをVPC内のエンドポイントとして公開します。そのために専用のSubnet（/29）と、どのSubnetをエンドポイントに使うかを定義するServiceConnectionPolicyが必要です。

TerraformでGKEプライベートクラスタからMemorystore for Redisへ接続してみた

Mon, 31 Aug 2026 00:00:00 +0900

概要
#

前回、コントロールプレーンも公開しないGKEプライベートクラスタと踏み台を作成しました。実際のアプリケーションでは、このクラスタからキャッシュやセッションストアへ接続する場面が多くあります。

Memorystore for RedisはVPCの外にあるマネージドサービスです。そのままではGKEのVPCから到達できません。Private Service Access（PSA）でVPCとサービス提供者側のネットワークをPeeringして、初めてPodから接続できます。

Terraformの基本操作と、前回のGKEプライベートクラスタ＋踏み台構成は前提としています。

Redis Cluster（PSC接続）、Redisのレプリケーションや可用性設計は扱いません。これらは別記事で扱う予定です。

検証すること
#

Private Service AccessでGKE用VPCとRedisをPeeringできること
Memorystore for Redis（BASIC）を作成できること
PodからRedisへ実際に接続し、PING・SET・GETが成功すること（Instance作成の確認とは別）

前提環境
#

Google Cloud CLI、Terraform、Docker
Billingが有効な検証用Google Cloud Project
GKE、Compute Engine、IAM、Memorystoreを操作できるGoogleアカウント
検証時のバージョン：Terraform 1.14.3、google 7.43.0

今回の構成
#

RedisはVPCの外にあるマネージドサービスです。Private Service AccessのPeering RangeとVPC Peering Connectionが、GKE用VPCとRedis側のネットワークをつなぐ経路です。

TerraformでGKEプライベートクラスタと踏み台VMを作成してみた

Mon, 31 Aug 2026 00:00:00 +0900

概要
#

これまでのGKE記事（Basic編、Workload Identity編）は、コントロールプレーンも外部から到達できるパブリックエンドポイントのクラスタでした。実務ではコントロールプレーンを公開しないプライベートエンドポイントが基本です。

ただしプライベートエンドポイントにすると、kubectlを直接実行する経路がなくなります。VPCの外からは、Clusterが存在することさえAPIを通して確認できません。

そこでVPC内に踏み台（bastion）VMを置き、kubectlはすべて踏み台経由で実行する構成にします。踏み台自体もIAP TCP forwarding経由でのみSSHでき、外部IPを持ちません。

Terraformの基本操作と、IAP SSH（GCE + IAP編）は前提としています。

Redis Memorystoreとの連携、Internal HTTP Load Balancerは扱いません。Podからの実際のWorkload Identity呼び出しも扱いません。これらは本記事の構成を土台に、別記事で扱う予定です。

検証すること
#

コントロールプレーンもノードも外部IPを持たないGKE Standardクラスタを作成できること
master_authorized_networksで接続元を踏み台Subnetだけに絞れること
踏み台VM経由でのみkubectlが実行できること
Artifact Registryのイメージが実際にPodとして配信できること（Node起動確認とは別）

前提環境
#

Google Cloud CLI、Terraform、Docker
Billingが有効な検証用Google Cloud Project
GKE、Compute Engine、IAM、Artifact Registryを操作できるGoogleアカウント
検証時のバージョン：Terraform 1.14.3、google 7.43.0

今回の構成
#

踏み台はGKE用とは別のSubnetに置きます。コントロールプレーンへの接続を、この踏み台SubnetのCIDRだけに絞るためです。IAPとArtifact RegistryはVPCの外にある、Google管理のサービスです。

TerraformでGKE Workload IdentityからCloud Storageへアクセスしてみた

Tue, 11 Aug 2026 00:00:00 +0900

概要
#

GKE PodからGoogle Cloud APIを呼ぶとき、JSON Keyを使う方法は管理の手間が増えます。Secretとしての漏洩経路にもなります。PodにKeyファイルを配りたくないところです。

Workload Identity Federation for GKEを使えば、鍵なしで権限を借用できます。Kubernetes Service Account（KSA）をGoogle Cloud Service Account（GSA）に紐づける仕組みです。ここでは実際にPodからCloud Storageへ書き込みます。

Terraformの基本操作とkubectlの基本操作は前提としています。GKEのWorkload Identityが初めての方向けです。

Private Cluster化、Network Policy、複数Namespaceでの権限分離は扱いません。

検証すること
#

Workload Identity Federationを有効にしたGKE Clusterを作成できること
Kubernetes Service AccountとGoogle Cloud Service Accountを関連付けられること
Service Account KeyなしでPodからCloud Storageへ書き込めること

前提環境
#

Google Cloud CLI、Terraform、kubectl
Billingが有効な検証用Google Cloud Project
GKE、IAM、Cloud Storageを操作できるGoogleアカウント
検証時のバージョン：Terraform 1.14.3、google 7.43.0、kubernetes 2.38.0

今回の構成
#

KubernetesのService AccountとGoogle CloudのService Accountは別物です。Workload Identityは、その2つを結びつけます。

GKE on LIFELOG

GKEでPodの退避を起こしたら、監視に必要なメトリクスがCloud Monitoringに来なかった

概要 #

対象読者 #

扱わないもの #

標準出力に1行JSONを書くだけなら、GKEではFluentdサイドカーが要らなかった

概要 #

検証すること #

前提環境 #

使用するTerraformコード #

GKEのdefault_compute_class_enabledを有効にしても何も起きなかったので調べた

概要 #

検証すること #

前提環境 #

使用するTerraformコード #

スイッチが効く場所 #

GKEノードプールのSURGEアップグレードをBlue/Greenと同じ条件で測って比べてみた

概要 #

検証すること #

前提環境 #

使用するTerraformコード #

SURGEとBlue/Greenの進み方の違い #

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

概要 #

検証すること #

前提環境 #

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

概要 #

検証すること #

前提環境 #

使用するTerraformコード #

今回の構成 #

TerraformでGKEのPodにSecret Managerの値をファイルとしてマウントしてみた

概要 #

検証すること #

前提環境 #

使用するTerraformコード #

今回の構成 #

TerraformでGKEのスタンドアロンNEGを消したらLBのバックエンドが戻らなかった話

概要 #

検証すること #

前提環境 #

使用するTerraformコード #

今回の構成 #

Peering越しのPod→VM通信が落ちる原因を、ルートだと思い込んでいた話

概要 #

検証すること #

前提環境 #

TerraformでGKE Dataplane V2を有効化し、NetworkPolicyでPod間通信を遮断してみた

概要 #

検証すること #

前提環境 #

使用するTerraformコード #

通信がどこで遮断されるか #

TerraformでGKEのノードあたり最大Pod数を小さくしすぎるとどうなるか試してみた

概要 #

検証すること #

前提環境 #

使用するTerraformコード #

TerraformでGKEのPodをInternal HTTP LB（NEG）でポート別に振り分けてみた

概要 #

検証すること #

前提環境 #

今回の構成 #

TerraformでGKEのコントロールプレーンをプライベート＋パブリックの両方から接続してみた

概要 #

検証すること #

前提環境 #

使用するTerraformコード #

一次情報での裏取り：enable_private_endpointの挙動 #

TerraformでGKEプライベートクラスタからMemorystore for Redis Clusterへ接続してみた

概要 #

検証すること #

前提環境 #

今回の構成 #

TerraformでGKEプライベートクラスタからMemorystore for Redisへ接続してみた

概要 #

検証すること #

前提環境 #

今回の構成 #

概要
#

対象読者
#

扱わないもの
#

概要
#

検証すること
#

前提環境
#

使用するTerraformコード
#

概要
#

検証すること
#

前提環境
#

使用するTerraformコード
#

スイッチが効く場所
#

概要
#

検証すること
#

前提環境
#

使用するTerraformコード
#

SURGEとBlue/Greenの進み方の違い
#

概要
#

検証すること
#

前提環境
#

概要
#

検証すること
#

前提環境
#

使用するTerraformコード
#

今回の構成
#

概要
#

検証すること
#

前提環境
#

使用するTerraformコード
#

今回の構成
#

概要
#

検証すること
#

前提環境
#

使用するTerraformコード
#

今回の構成
#

概要
#

検証すること
#

前提環境
#

概要
#

検証すること
#

前提環境
#

使用するTerraformコード
#

通信がどこで遮断されるか
#

概要
#

検証すること
#

前提環境
#

使用するTerraformコード
#

概要
#

検証すること
#

前提環境
#

今回の構成
#

概要
#

検証すること
#

前提環境
#

使用するTerraformコード
#

一次情報での裏取り：`enable_private_endpoint`の挙動
#

概要
#

検証すること
#

前提環境
#

今回の構成
#

概要
#

検証すること
#

前提環境
#

今回の構成
#

概要
#

検証すること
#

前提環境
#

今回の構成
#

概要
#

検証すること
#

前提環境
#

今回の構成
#