Google Kubernetes Engine (GKE)

解決する課題

Kubernetes はコンテナのデプロイ・スケール・自己修復を宣言的に行える強力な基盤ですが、コントロールプレーン（API サーバー・etcd・スケジューラ）を自前で構築・運用するのは重い負担です。GKE はこの運用を肩代わりします。

• Kubernetes のコントロールプレーンを自前で構築・パッチ・冗長化したくない → Google が完全マネージドで運用
• Kubernetes の標準 API やエコシステム（Helm / Operator / Istio / Argo など）をそのまま使いたい
• 負荷に応じて Pod とノードを自動でスケールしたい（HPA・クラスターオートスケーラー）
• マルチクラウド・オンプレを含めた移植性の高いワークロードを動かしたい
• ノードの管理すら任せて、Pod を書くことに集中したい → Autopilot

AWS でいえば Amazon EKS に相当します。EKS と同じく「マネージドな Kubernetes」という位置づけで、コンテナを K8s 前提で運用したいケースに向きます。

主要概念と用語

• クラスター: Google 管理のコントロールプレーンと、ワークロードを動かすノード群の集合
• Autopilot モード: Google がノードのプロビジョニング・サイズ・スケール・セキュリティ設定まで管理し、利用者は Pod のリソース要求を書くだけ。Pod が要求したリソース単位で課金
• Standard モード: ノードプールを自分で管理し、マシンタイプ・台数・Spot 利用などを細かく制御できる
• ノードプール: 同一構成のノードをまとめた束。マシンタイプや Spot/オンデマンドなどの属性を指定
• Zonal / Regional クラスター: コントロールプレーンとノードを単一ゾーンに置く Zonal と、複数ゾーンに冗長化する Regional。本番は Regional が推奨
• Pod / Deployment / Service / Ingress / Gateway: Kubernetes 標準リソース。GKE では Service や Ingress が Cloud Load Balancing と統合される
• HPA（Horizontal Pod Autoscaler）: メトリクスに応じて Pod レプリカ数を増減
• クラスターオートスケーラー: Pod の需要に応じてノード数を増減（Standard）
• Workload Identity Federation for GKE: Kubernetes ServiceAccount を主体として、鍵ファイルなしで Google Cloud API へ認証する仕組み（AWS の IRSA に相当）
• GKE リリースチャンネル: Rapid / Regular / Stable などのチャンネルでバージョン更新の速度と安定性のバランスを選ぶ

仕様・制限・クォータ

• クラスターはリージョン × ゾーンに配置。コントロールプレーンの可用性に応じて Zonal / Regional を選ぶ
• Autopilot では Pod がリソース要求（requests）を明示する必要があり、特権コンテナや一部のホストアクセスなどに制約がある
• Standard ではノードの OS パッチや K8s バージョン更新を計画的に行う必要がある（自動アップグレードも設定可能）
• 1 クラスターあたりのノード数・Pod 数・ノードあたり Pod 数に上限があり、バージョンや構成によって変動する
• vCPU・IP アドレス・ロードバランサー等にプロジェクト／リージョン単位のクォータがあり、引き上げ申請が可能
• Pod に割り当てる IP の枯渇を避けるため、VPC ネイティブ（エイリアス IP） での IP レンジ設計が重要

具体的な上限値やバージョン番号はリリースで変動するため、設計時は公式ドキュメントで最新値を確認してください。

内部の仕組み

GKE は Google がコントロールプレーン（API サーバー・etcd・スケジューラ・コントローラ）を完全マネージドで運用します。利用者は Kubernetes API に対してマニフェストを適用し、宣言した状態へクラスターが収束していきます。

Autopilot モードでは、Pod のリソース要求に基づいて Google が裏側でノードを自動的にプロビジョニング・配置・スケールします。利用者はノードの存在をほぼ意識せず、Pod を中心に運用できます。Standard モードでは、利用者がノードプールを設計・保有し、マシンタイプや Spot 利用、台数、配置ゾーンを自分で決められるため、集約効率の最適化や特殊要件への対応がしやすくなります。

スケールは二段構えです。Pod レベルでは HPA が負荷に応じてレプリカ数を増減し、ノードレベルでは（Standard では）クラスターオートスケーラーが Pod の需要に応じてノードを増減します。Service や Ingress、Gateway は Cloud Load Balancing と統合され、外部・内部のロードバランサーが自動でプロビジョニングされます。

設計パターン / ベストプラクティス

• まずは Autopilot を検討し、ノード運用を任せる。細かい制御が要るときだけ Standard
• 本番クラスターは Regional で構成し、ゾーン障害に耐える可用性を確保
• VPC ネイティブクラスターを使い、Pod / Service の IP レンジを余裕を持って設計（IP 枯渇を回避）
• リリースチャンネルを有効化し、自動アップグレードで K8s バージョンを計画的に最新化
• Pod には必ず リソース requests / limits を設定し、スケジューリングと安定性を担保
• 中断を許容できるバッチやステートレス処理は Spot ノードでコスト削減（Standard）
• PodDisruptionBudget を設定し、アップグレードやノード入れ替え時の可用性を維持
• 権限付与は鍵ファイルではなく Workload Identity Federation for GKE を使う

運用・監視

• Cloud Monitoring / Cloud Logging がクラスターと統合され、ノード・Pod・コンテナのメトリクスとログを自動収集できる
• GKE のダッシュボードでクラスター・ワークロードの状態、リソース使用率、イベントを把握
• Pod が CrashLoopBackOff のときは kubectl logs と kubectl describe pod でログとイベントを確認
• Pod が Pending のままのときは、ノードのリソース不足やスケジューリング制約、Autopilot のリソース要求を確認
• 自動アップグレード・自動修復を有効にし、ノードの健全性を維持
• メンテナンスウィンドウとメンテナンス除外で、アップグレードのタイミングを業務影響の少ない時間帯に制御

コスト

課金は「コントロールプレーンのクラスター管理料」と「ワークロードを動かすコンピューティング費用」の積み上げで考えます。モードによって課金の単位が変わる点が要注意です。

Standard ではノードの稼働ぶんが常に課金されるため、過剰にプロビジョニングしたノードは無駄になりやすい点に注意します。Autopilot は Pod が要求したリソースで課金されるため、要求値の適正化がそのままコスト最適化につながります。

セキュリティ

• 権限付与は Workload Identity Federation for GKE を使い、Kubernetes ServiceAccount に Google Cloud の権限をひも付ける。鍵ファイルのハードコードを避ける（AWS の IRSA 相当）
• イメージは Artifact Registry に保存し、脆弱性スキャンを有効化。Binary Authorization で署名済みイメージのみデプロイを許可
• Network Policy で Pod 間通信を最小化し、ラテラルムーブメントを抑える
• シークレットは Secret Manager で管理し、アプリへ安全に注入する
• コントロールプレーンへのアクセスは承認済みネットワークやプライベートクラスターで制限し、ノードにシールドノードなどの保護を適用
• IAM とロールベースアクセス制御（RBAC）を組み合わせ、クラスター操作の権限を最小化

Well-Architected の観点

• 信頼性（reliability）: Regional クラスターでゾーン障害に耐え、HPA とクラスターオートスケーラーで負荷変動を吸収。PodDisruptionBudget と自動修復で可用性を維持
• 運用上の優秀性（operational）: Autopilot とリリースチャンネルで運用を自動化し、ノードのパッチ・スケール・アップグレードの手作業を削減
• パフォーマンス効率（performance）: ワークロード特性に合うマシンタイプやノードプールを選び、リソース requests/limits を適正化してスケジューリング効率を高める

試験で問われるポイント

関連サービス・比較

GKE はマネージド Kubernetes ですが、Google Cloud にはよりサーバーレスなコンテナ実行基盤として Cloud Run もあります。Kubernetes の機能が本当に必要かどうかで選択が変わります。AWS との対応もあわせて整理します。

ハンズオン / CLI例

# Autopilot クラスターを作成（ノード運用は Google に委任）
gcloud container clusters create-auto demo-cluster \
  --region=asia-northeast1

# 認証情報を取得して kubectl をクラスターに向ける
gcloud container clusters get-credentials demo-cluster \
  --region=asia-northeast1

# Artifact Registry のイメージから Deployment を作成
kubectl create deployment web \
  --image=asia-northeast1-docker.pkg.dev/PROJECT_ID/repo/web:latest

# Service（ロードバランサー）で外部公開し、HPA で自動スケール
kubectl expose deployment web --type=LoadBalancer --port=80 --target-port=8080
kubectl autoscale deployment web --min=2 --max=10 --cpu-percent=70

# 参考: Standard クラスターを Regional・Spot ノードプールで作成する場合
gcloud container clusters create std-cluster \
  --region=asia-northeast1 \
  --num-nodes=1 \
  --release-channel=regular
gcloud container node-pools create spot-pool \
  --cluster=std-cluster \
  --region=asia-northeast1 \
  --spot \
  --machine-type=e2-standard-4