GKE — マネージド Kubernetes

GKE の全体像 — クラスタ・モード・料金

GKE（Google Kubernetes Engine）は、オープンソースのコンテナオーケストレータ Kubernetes のマネージド実装です。第 4 章の Compute Engine が「VM を自分で並べる」世界だったのに対し、GKE では「コンテナのあるべき状態」を宣言すると、配置・復旧・スケールを Kubernetes が継続的に調整します。PCA 試験ではコンピューティング選択の主要な選択肢として、Cloud Run（第 7 章）との使い分けが繰り返し問われます。

クラスタ = コントロールプレーン + ノード

GKE クラスタは、Kubernetes API サーバー・スケジューラ・コアリソースコントローラを実行するコントロールプレーンと、コンテナが実際に動くノード（Compute Engine VM）で構成されます。コントロールプレーンは作成から削除まで Google が全面管理し、クラスタ状態の保存には etcd または Spanner ベースのストレージが使われます。ノードには kubelet（ノードエージェント）とコンテナランタイムが載り、ログ収集やクラスタ内ネットワークを担うシステムコンテナも動きます。

可用性はモードと構成で変わります。2026-08 時点の SLA は、Autopilot クラスタとリージョン Standard クラスタのコントロールプレーンが 99.95%、ゾーン Standard クラスタのコントロールプレーンが 99.5%、複数ゾーンに配置された Autopilot Pod が 99.9% です。本番クラスタでゾーン構成を選ばない、という判断軸をまず覚えてください。

Autopilot と Standard — 2 つの運用モード

GKE には 2 つの運用モードがあります。Autopilot は Google がノード・スケーリング・セキュリティ設定まで管理し、ワークロードの記述に集中できるモードで、公式ドキュメントも Autopilot の利用を推奨しています。Standard はノードプール（同一構成のノードのグループ）を自分で設計・運用するモードで、マシンタイプや OS などノードレベルの細かい制御が必要な場合に選びます。

料金は 2026-08 時点で、モードやトポロジによらずクラスタ管理料 $0.10/クラスタ/時（1 秒単位課金）がかかります。ただし GKE の無料枠として請求先アカウントごとに月 $74.40 のクレジットがあり、ゾーン Standard または Autopilot クラスタ 1 つ分の管理料が実質無料になります。本章のハンズオンはこの無料枠の範囲で組み立てます。

リリースチャンネルとアップグレード

GKE はコントロールプレーンを自動アップグレードします。どの速度で新バージョンを受け取るかを決めるのがリリースチャンネルです。重要なセキュリティパッチはどのチャンネルにも配布されます。

アップグレードのタイミングはメンテナンスウィンドウと除外期間で制御できます。「マイナー / ノードのアップグレード禁止」などスコープを絞った除外はチャンネル登録済みクラスタでのみ使えます。未登録クラスタが選べるのは全アップグレードを止める除外だけで、このスコープの除外はどのクラスタでも最長 90 日です。

ワークロードの基本と公開 — Service・Gateway API

Kubernetes ではコンテナを Pod（1 つ以上のコンテナの実行単位）として動かし、Deployment が「Pod を何個、どのイメージで」という宣言を維持します。Pod は入れ替わるたびに IP が変わるため、安定した入口として Service を置きます。Service の type: LoadBalancer を指定すると、GKE が Cloud Load Balancing のロードバランサを自動作成して外部公開します。

HTTP(S) の公開は Gateway API へ

HTTP(S) レイヤの公開には長らく Ingress が使われてきましたが、現在の GKE は後継のオープン標準 Gateway API を提供しています。Gateway API は役割指向の設計が特徴で、リソースが担当者ごとに分かれます。

• GatewayClass — ロードバランサの種別テンプレート。例: gke-l7-global-external-managed（グローバル外部）、gke-l7-rilb（リージョン内部）
• Gateway — どの IP / ポートで待ち受けるか。クラスタ運用者が作成
• HTTPRoute — どのパスをどの Service に流すか。アプリ開発者が作成

Ingress ではアノテーション頼みだったヘッダーマッチングやトラフィックの重み付けが組み込み機能になり、既存の Ingress リソースは Gateway と HTTPRoute に変換できます。公式ドキュメントも時間をかけた移行を推奨しているため、新規設計は Gateway API を既定にしてください。単一クラスタ向けの GKE Gateway コントローラは既定で有効です。第 5 章の Cloud Load Balancing のプロキシ型 LB が裏側で作られる、と捉えると全体がつながります。

コンテナネイティブ負荷分散

GKE の LB でもう 1 つ重要なのがコンテナネイティブ負荷分散です。従来はインスタンスグループ（ノード）にトラフィックを分散し、ノード上の kube-proxy が設定した iptables ルールで Pod へ再転送していました。コンテナネイティブ方式では GCE_VM_IP_PORT タイプの NEG（ネットワークエンドポイントグループ）に Pod の IP を直接登録するため、余分なホップが消えます。

コンテナネイティブ負荷分散は VPC ネイティブクラスタが前提です。条件（VPC ネイティブ、共有 VPC 不使用、GKE ネットワークポリシー不使用、HttpLoadBalancing アドオン有効）を満たすと、GKE は Service に cloud.google.com/neg アノテーションを自動付与してこの方式を既定にします。

スケーリングの階層 — HPA・VPA・クラスタオートスケーラ・NAP

GKE のスケーリングは「Pod を変える層」と「ノードを変える層」の 2 階建てで理解します。4 つの仕組みは競合するのではなく、連鎖して動きます。

押さえるべき挙動が 2 つあります。第一に、クラスタオートスケーラは実際の使用率ではなく Pod のリソースリクエストを基準に判断します。リクエストが過大だと、CPU が遊んでいてもノードは減りません。第二に、HPA と VPA を CPU / メモリ指標で同じワークロードに併用してはいけません（両立させたい場合は多次元 Pod 自動スケーリングを使います）。VPA には推奨値の提示だけを行う Off モードがあるので、まず推奨値を見てリクエストを手動調整するのが安全な入口です。

Autopilot ではインフラ層の 2 つを意識する必要がありません。ノードのプロビジョニングもノードプール管理も GKE が自動で行うため、ユーザーが設計するのはワークロード層（HPA / VPA とリソースリクエスト）だけです。

GKE のネットワークと ID — VPC ネイティブと Workload Identity

VPC ネイティブクラスタの IP 設計

現在の GKE クラスタは既定で VPC ネイティブクラスタです。第 3 章で学んだ VPC のエイリアス IP 範囲を使い、Pod の IP を VPC 内でネイティブにルーティングします。カスタム静的ルートのクォータを消費せず、Pod IP 宛のファイアウォールルールが書け、NEG（＝コンテナネイティブ負荷分散）も VPC ネイティブでのみ動きます。IP は 3 系統を計画します。

Workload Identity Federation for GKE

Pod の中のアプリが Cloud Storage や Pub/Sub を呼ぶとき、認証はどうすべきでしょうか。サービスアカウントキーを Secret に置く方式は漏えいリスクと鍵管理の負担が大きく、ノードのサービスアカウントに権限を持たせる方式は全 Pod が同じ権限を共有してしまいます。第 2 章で触れた「キーを作らない」原則を GKE で実現するのが Workload Identity Federation for GKE です。

有効化するとプロジェクトに PROJECT_ID.svc.id.goog という Workload Identity プールが用意され、KSA を IAM から principal:// 識別子として直接参照できるようになります。つまり「この namespace のこの KSA に、このロールを付与する」という素直な IAM 設計がそのまま書けます。Autopilot クラスタでは常に有効で、Standard では --workload-pool フラグで有効化します。

gcloud services enable container.googleapis.com

gcloud container clusters create-auto hello-cluster \
    --location=asia-northeast1

gcloud container clusters get-credentials hello-cluster \
    --location=asia-northeast1

kubectl create deployment hello-server \
    --image=us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0

kubectl expose deployment hello-server \
    --type LoadBalancer \
    --port 80 \
    --target-port 8080

kubectl get pods
kubectl get service hello-server

kubectl delete service hello-server

kubectl scale deployment hello-server --replicas=3
kubectl get pods

kubectl autoscale deployment hello-server \
    --cpu-percent=60 --min=1 --max=5
kubectl get hpa

kubectl delete hpa hello-server
kubectl delete deployment hello-server

kubectl create namespace wi-demo
kubectl create serviceaccount wi-test --namespace wi-demo

PROJECT_ID=$(gcloud config get-value project)
PROJECT_NUMBER=$(gcloud projects describe "$PROJECT_ID" \
    --format="value(projectNumber)")

gcloud storage buckets create gs://$PROJECT_ID-wi-demo \
    --location=asia-northeast1

gcloud projects add-iam-policy-binding projects/$PROJECT_ID \
    --role=roles/storage.objectViewer \
    --member=principal://iam.googleapis.com/projects/$PROJECT_NUMBER/locations/global/workloadIdentityPools/$PROJECT_ID.svc.id.goog/subject/ns/wi-demo/sa/wi-test \
    --condition=None

apiVersion: v1
kind: Pod
metadata:
  name: test-pod
  namespace: wi-demo
spec:
  serviceAccountName: wi-test
  containers:
  - name: test-pod
    image: google/cloud-sdk:slim
    command: ["sleep","infinity"]
    resources:
      requests:
        cpu: 500m
        memory: 512Mi
        ephemeral-storage: 10Mi

kubectl apply -f test-pod.yaml
kubectl exec -it pods/test-pod --namespace=wi-demo -- /bin/bash

# ここから Pod 内で実行
curl -X GET -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    "https://storage.googleapis.com/storage/v1/b/BUCKET_NAME/o"

kubectl delete namespace wi-demo

gcloud projects remove-iam-policy-binding projects/$PROJECT_ID \
    --role=roles/storage.objectViewer \
    --member=principal://iam.googleapis.com/projects/$PROJECT_NUMBER/locations/global/workloadIdentityPools/$PROJECT_ID.svc.id.goog/subject/ns/wi-demo/sa/wi-test \
    --condition=None

gcloud storage buckets delete gs://$PROJECT_ID-wi-demo

gcloud container clusters delete hello-cluster \
    --location=asia-northeast1 --quiet

gcloud container clusters list

つまずきポイント

理解度チェック

まとめと次章へ

• GKE クラスタは Google 管理のコントロールプレーンと、自プロジェクトのノード（Compute Engine VM）で構成される。kubectl の相手は常に API サーバー
• モードは Autopilot が推奨。Pod のリクエスト単位課金でノード運用が不要。ノードレベルの制御が必要なときだけ Standard を選ぶ
• HTTP(S) の公開は Ingress の後継である Gateway API（GatewayClass / Gateway / HTTPRoute の役割分離）が既定。VPC ネイティブクラスタなら NEG による Pod 直達のコンテナネイティブ負荷分散が効く
• スケーリングはワークロード層（HPA / VPA）とインフラ層（クラスタオートスケーラ / NAP）の 2 階建て。判断基準はリソースリクエストであり、使用率ではない
• Pod から Google Cloud API へのアクセスは Workload Identity Federation for GKE 一択。SA キーの保存・配布を設計から消せる

次の第 7 章では Cloud Run とサーバーレスを学び、Compute Engine・GKE・Cloud Run を「どう選び分けるか」という試験最頻出のデシジョンツリーを完成させます。

参考リンク（公式ドキュメント）:

• GKE overview
• Autopilot overview
• Cluster architecture
• Release channels
• About the Gateway API
• About Workload Identity Federation for GKE
• GKE pricing