Google Cloud 完全攻略 Ep.8: GKEで学ぶKubernetesクラスタ運用入門｜SESエンジニア向け実践ガイド

SES案件のインフラ・バックエンド領域で、いま最も求められているスキルの一つがKubernetesです。「Kubernetes経験者」というだけで案件の選択肢が一気に広がり、単価レンジも上がります。

Google Kubernetes Engine（GKE）は、Googleが開発したKubernetesをフルマネージドで提供するサービスです。Kubernetesそのものの生みの親であるGoogleが運用するだけあり、最新バージョンへの追従が最速で、AutopilotモードやGateway APIなど先進的な機能をいち早く利用できます。

本記事では、GKEの基本概念からクラスタ構築、ワークロードのデプロイ、オートスケーリング、セキュリティ設計、CI/CDパイプラインまで、SES現場で即使える実践的な知識を体系的に解説します。

GKEの基本概念——StandardモードとAutopilotモード

Kubernetesとは

Kubernetesは、コンテナ化されたアプリケーションのデプロイ・スケーリング・管理を自動化するオーケストレーションプラットフォームです。Ep.2のCloud Runがサーバーレスコンテナの「お手軽路線」だとすれば、GKEはフルコントロール路線です。

比較項目	Cloud Run	GKE
管理負荷	ほぼゼロ	中〜高
カスタマイズ性	限定的	フルコントロール
ステートフルワークロード	非対応	対応（StatefulSet）
ネットワーク制御	基本的	完全なPod/Service制御
適するユースケース	Webアプリ、API	マイクロサービス基盤、ML、ステートフルDB

StandardモードとAutopilotモード

GKEには2つの運用モードがあります。

Standardモードは、ノード（VM）の構成や数を自分で管理する従来型のモードです。ノードプールの設定、マシンタイプの選定、OSイメージの選択など、細かなチューニングが可能です。

Autopilotモードは、2021年に導入されたGKE独自の運用モードで、ノード管理をGoogleに完全委任します。開発者はPodのリソース要求だけ定義すれば、GKEが最適なノード構成を自動でプロビジョニングします。

# Autopilotクラスタの作成（推奨）
gcloud container clusters create-auto prod-cluster \
    --region=asia-northeast1 \
    --release-channel=regular \
    --network=prod-vpc \
    --subnetwork=prod-gke-subnet \
    --enable-master-authorized-networks \
    --master-authorized-networks=203.0.113.0/24

# Standardクラスタの作成（詳細制御が必要な場合）
gcloud container clusters create prod-standard-cluster \
    --region=asia-northeast1 \
    --num-nodes=2 \
    --machine-type=e2-standard-4 \
    --enable-autoscaling \
    --min-nodes=1 \
    --max-nodes=5 \
    --network=prod-vpc \
    --subnetwork=prod-gke-subnet \
    --enable-ip-alias \
    --release-channel=regular

SES案件での使い分け指針:

• Autopilot推奨: 新規案件、Pod数が変動しやすいWebサービス、運用チームが少ない案件
• Standard推奨: GPU/TPUワークロード、DaemonSetが必須のモニタリング基盤、既存Standardクラスタの保守案件

クラスタ構築——本番環境を意識した初期設定

VPCネイティブクラスタ（必須）

GKEクラスタは必ず**VPCネイティブ（IP alias）**で作成してください。Ep.7のVPC設計で解説したCIDR設計が、ここで活きてきます。

# VPCネイティブクラスタに必要なセカンダリレンジの作成
gcloud compute networks subnets update prod-gke-subnet \
    --region=asia-northeast1 \
    --add-secondary-ranges=pod-range=10.4.0.0/14,service-range=10.8.0.0/20

# セカンダリレンジを指定してクラスタ作成
gcloud container clusters create-auto prod-cluster \
    --region=asia-northeast1 \
    --network=prod-vpc \
    --subnetwork=prod-gke-subnet \
    --cluster-secondary-range-name=pod-range \
    --services-secondary-range-name=service-range

プライベートクラスタの構成

本番環境では、ノードに外部IPを持たせないプライベートクラスタが必須です。

gcloud container clusters create-auto prod-private-cluster \
    --region=asia-northeast1 \
    --network=prod-vpc \
    --subnetwork=prod-gke-subnet \
    --enable-private-nodes \
    --enable-private-endpoint \
    --master-ipv4-cidr=172.16.0.0/28 \
    --enable-master-authorized-networks \
    --master-authorized-networks=10.1.0.0/20

プライベートクラスタではEp.7で設定したCloud NATが必須です。ノードがコンテナイメージをpullしたり、外部APIに接続するために使用します。

kubectlの認証設定

# クラスタの認証情報を取得
gcloud container clusters get-credentials prod-cluster \
    --region=asia-northeast1

# 接続確認
kubectl cluster-info
kubectl get nodes

GKEはGoogle Cloud IAMと統合されているため、Ep.6のIAM設計で学んだサービスアカウントとRBACを組み合わせてアクセス制御を行います。

ワークロードのデプロイ——Podからサービス公開まで

Deployment（ステートレスアプリケーション）

# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
  labels:
    app: web-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web-app
  template:
    metadata:
      labels:
        app: web-app
    spec:
      containers:
      - name: web-app
        image: asia-northeast1-docker.pkg.dev/my-project/my-repo/web-app:v1.0.0
        ports:
        - containerPort: 8080
        resources:
          requests:
            cpu: "250m"
            memory: "512Mi"
          limits:
            cpu: "500m"
            memory: "1Gi"
        livenessProbe:
          httpGet:
            path: /healthz
            port: 8080
          initialDelaySeconds: 10
          periodSeconds: 15
        readinessProbe:
          httpGet:
            path: /ready
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 10
      serviceAccountName: web-app-sa

# デプロイ
kubectl apply -f deployment.yaml

# 状態確認
kubectl get deployments
kubectl get pods -l app=web-app
kubectl describe deployment web-app

Autopilotモードの場合、resources.requestsの値がそのまま課金対象になります。過大なリソース要求はコスト増に直結するため、適切なサイジングが重要です。

Service / Ingress（サービス公開）

# service.yaml
apiVersion: v1
kind: Service
metadata:
  name: web-app-service
  annotations:
    cloud.google.com/neg: '{"ingress": true}'
spec:
  type: ClusterIP
  selector:
    app: web-app
  ports:
  - port: 80
    targetPort: 8080
---
# ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web-app-ingress
  annotations:
    kubernetes.io/ingress.class: "gce"
    kubernetes.io/ingress.global-static-ip-name: "web-app-ip"
    networking.gke.io/managed-certificates: "web-app-cert"
spec:
  defaultBackend:
    service:
      name: web-app-service
      port:
        number: 80

GKE IngressはGoogle Cloud Load Balancerと統合されており、マネージドSSL証明書や**Cloud Armor（WAF）**との連携が容易です。

ConfigMapとSecret

# configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  DATABASE_HOST: "10.1.2.3"
  LOG_LEVEL: "info"
---
# Secretの作成（CLIから）
kubectl create secret generic db-credentials \
    --from-literal=DB_USER=app_user \
    --from-literal=DB_PASSWORD=secure_password_here

本番環境では、Secret Managerとの連携を推奨します。GKEのWorkload Identityと組み合わせることで、Podから安全にシークレットを参照できます。

オートスケーリング——負荷に応じた自動調整

Horizontal Pod Autoscaler（HPA）

# hpa.yaml
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web-app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web-app
  minReplicas: 2
  maxReplicas: 20
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  - type: Resource
    resource:
      name: memory
      target:
        type: Utilization
        averageUtilization: 80
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 60
      policies:
      - type: Pods
        value: 4
        periodSeconds: 60
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
      - type: Percent
        value: 25
        periodSeconds: 120

behaviorフィールドでスケールアップ・ダウンの速度を細かく制御できます。急激なスケールダウンによるサービス影響を防ぐために、stabilizationWindowSecondsの設定が重要です。

# HPAの状態確認
kubectl get hpa
kubectl describe hpa web-app-hpa

# 負荷テストでスケーリング動作を確認
kubectl run load-test --image=busybox --restart=Never -- \
    /bin/sh -c "while true; do wget -q -O- http://web-app-service; done"

Vertical Pod Autoscaler（VPA）

# vpa.yaml
apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: web-app-vpa
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web-app
  updatePolicy:
    updateMode: "Off"  # まずは推奨値の確認から

VPAのupdateMode: "Off"は、Podのリソースを変更せずに推奨値だけを表示するモードです。まずこのモードで適切なリソース値を把握してから、HPAと組み合わせて本番運用に移行するのがベストプラクティスです。

# VPAの推奨値を確認
kubectl describe vpa web-app-vpa

Cluster Autoscaler（Standardモードのみ）

Standardモードでは、ノードプールのオートスケーリングも設定します。

# ノードプールのオートスケーリング設定
gcloud container clusters update prod-standard-cluster \
    --region=asia-northeast1 \
    --enable-autoscaling \
    --min-nodes=1 \
    --max-nodes=10 \
    --node-pool=default-pool

AutopilotモードではCluster Autoscalerが自動で動作するため、この設定は不要です。

セキュリティ設計——Workload Identityとネットワークポリシー

Workload Identity（必須）

Workload Identityは、KubernetesのサービスアカウントとGoogle CloudのIAMサービスアカウントを紐付ける仕組みです。Podからキーファイルなしで安全にGCPサービスにアクセスできます。

# GCP側のサービスアカウント作成
gcloud iam service-accounts create web-app-sa \
    --display-name="Web App Service Account"

# 必要な権限の付与（Cloud SQLクライアント）
gcloud projects add-iam-policy-binding my-project \
    --member="serviceAccount:[email protected]" \
    --role="roles/cloudsql.client"

# Workload Identityバインディング
gcloud iam service-accounts add-iam-policy-binding \
    [email protected] \
    --role="roles/iam.workloadIdentityUser" \
    --member="serviceAccount:my-project.svc.id.goog[default/web-app-ksa]"

# Kubernetes側のサービスアカウント
apiVersion: v1
kind: ServiceAccount
metadata:
  name: web-app-ksa
  annotations:
    iam.gke.io/gcp-service-account: [email protected]

Ep.6のIAM設計で解説した最小権限の原則を、Pod単位で実現できるのがWorkload Identityの最大のメリットです。

ネットワークポリシー

# network-policy.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-ingress
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Ingress
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-web-to-api
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: api-server
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: web-app
    ports:
    - protocol: TCP
      port: 8080

デフォルトDeny + 必要な通信だけ許可のパターンが、Ep.7のファイアウォール設計と同様にGKEネットワークポリシーでも推奨されます。

Binary Authorization

# Binary Authorizationの有効化
gcloud container clusters update prod-cluster \
    --region=asia-northeast1 \
    --enable-binauthz

# ポリシーの設定（信頼されたレジストリからのみデプロイ許可）
gcloud container binauthz policy export > /tmp/policy.yaml

Binary Authorizationを使えば、署名済みのコンテナイメージのみをGKEにデプロイするよう強制できます。CI/CDパイプラインで自動署名し、未署名イメージのデプロイを拒否する仕組みを構築できます。

CI/CDパイプライン——Cloud Buildとの連携

Artifact Registry（コンテナレジストリ）

# Artifact Registryにリポジトリを作成
gcloud artifacts repositories create my-repo \
    --repository-format=docker \
    --location=asia-northeast1 \
    --description="本番コンテナイメージ"

# イメージのビルドとプッシュ
gcloud builds submit \
    --tag=asia-northeast1-docker.pkg.dev/my-project/my-repo/web-app:v1.0.0

Cloud Buildパイプライン

# cloudbuild.yaml
steps:
  # テスト実行
  - name: 'node:20'
    entrypoint: 'npm'
    args: ['test']

  # Dockerイメージのビルド
  - name: 'gcr.io/cloud-builders/docker'
    args:
      - 'build'
      - '-t'
      - 'asia-northeast1-docker.pkg.dev/$PROJECT_ID/my-repo/web-app:$SHORT_SHA'
      - '.'

  # Artifact Registryにプッシュ
  - name: 'gcr.io/cloud-builders/docker'
    args:
      - 'push'
      - 'asia-northeast1-docker.pkg.dev/$PROJECT_ID/my-repo/web-app:$SHORT_SHA'

  # GKEにデプロイ
  - name: 'gcr.io/cloud-builders/gke-deploy'
    args:
      - 'run'
      - '--filename=k8s/'
      - '--image=asia-northeast1-docker.pkg.dev/$PROJECT_ID/my-repo/web-app:$SHORT_SHA'
      - '--location=asia-northeast1'
      - '--cluster=prod-cluster'

options:
  logging: CLOUD_LOGGING_ONLY

# GitHubリポジトリとの連携（トリガー設定）
gcloud builds triggers create github \
    --repo-name=my-app \
    --repo-owner=my-org \
    --branch-pattern="^main$" \
    --build-config=cloudbuild.yaml

このパイプラインにより、mainブランチへのプッシュでテスト → ビルド → デプロイが自動実行されます。Cloud Functions（Ep.4）のデプロイ自動化と同じ考え方ですが、GKEではKubernetesマニフェストの管理が加わります。

コスト最適化——GKEの費用を抑えるテクニック

Autopilotモードの課金体系

AutopilotモードはPodが要求したリソース（CPU/メモリ）に対して課金されます。未使用ノードの無駄がないため、多くの場合Standardモードよりコスト効率が良いです。

# クラスタのリソース使用状況確認
kubectl top nodes
kubectl top pods --all-namespaces

# リソース要求の最適化（VPAの推奨値を参考に）
kubectl describe vpa web-app-vpa | grep -A 10 "Recommendation"

Spot Pod（Autopilot）/ Spot VM（Standard）

# Spot Podの指定（Autopilot）
spec:
  nodeSelector:
    cloud.google.com/gke-spot: "true"
  terminationGracePeriodSeconds: 25
  containers:
  - name: batch-worker
    resources:
      requests:
        cpu: "1"
        memory: "2Gi"

Spot Podは通常価格の60〜91%オフで利用できます。バッチ処理やCI/CDジョブなど、中断されても問題ないワークロードに最適です。

コスト管理のベストプラクティス

テクニック	効果	適用対象
Autopilotモード	未使用リソースの排除	全般
Spot Pod/VM	60〜91%コスト削減	バッチ処理、開発環境
リソース最適化（VPA）	過大なrequestsの削減	全Pod
Namespace別リソースクォータ	チーム別の上限管理	マルチテナント環境
開発クラスタの自動停止	夜間・休日のコスト削減	開発・検証環境

SES案件で使えるGKE設計テンプレート

中規模Webサービス（Autopilot）

prod-cluster (Autopilot, asia-northeast1)
├── Namespace: production
│   ├── Deployment: web-frontend (replicas: 2-10, HPA)
│   ├── Deployment: api-server (replicas: 3-15, HPA)
│   ├── StatefulSet: redis-cache (replicas: 3)
│   └── CronJob: batch-processor (Spot Pod)
├── Namespace: monitoring
│   └── Deployment: prometheus + grafana
├── Ingress: Google Cloud Load Balancer + Managed SSL
├── Workload Identity: Pod別のIAMバインディング
└── NetworkPolicy: デフォルトDeny + 明示的Allow

マイクロサービス基盤（Standard + Autopilot混合）

本番環境:
├── prod-autopilot-cluster (Autopilot)
│   ├── ステートレスサービス群（Web, API, Worker）
│   └── CI/CDジョブ（Spot Pod）
└── prod-standard-cluster (Standard)
    ├── GPU必要なMLワークロード
    └── 特殊なDaemonSetが必要なモニタリング

共通基盤:
├── Artifact Registry: コンテナイメージ管理
├── Cloud Build: CI/CDパイプライン
├── Secret Manager: シークレット管理
└── Cloud Monitoring: メトリクス・アラート

トラブルシューティング——よくある問題と対処

Pod起動の問題

# Podのステータス確認
kubectl get pods -o wide
kubectl describe pod <pod-name>

# ログの確認
kubectl logs <pod-name> --previous  # クラッシュ前のログ
kubectl logs <pod-name> -f          # リアルタイムログ

# よくあるエラーと対処
# ImagePullBackOff → イメージ名/タグの誤り、Artifact Registryの権限不足
# CrashLoopBackOff → アプリのエラー、ヘルスチェック失敗
# Pending → リソース不足（Autopilotなら自動解消、Standardならノード追加）
# OOMKilled → メモリのlimitsを増やす

ネットワークの問題

# サービスの疎通確認
kubectl run debug --image=busybox --restart=Never -it -- \
    wget -qO- http://web-app-service:80

# DNS解決の確認
kubectl run debug --image=busybox --restart=Never -it -- \
    nslookup web-app-service.default.svc.cluster.local

# NetworkPolicyの確認
kubectl get networkpolicies -A

まとめ——GKEはSESエンジニアの市場価値を確実に上げる

GKEとKubernetesの知識は、SESエンジニアにとって最も投資対効果の高いスキルの一つです。本記事で解説した内容を振り返ります。

• Autopilotモードはノード管理不要でKubernetes運用の敷居を大幅に下げる
• VPCネイティブ + プライベートクラスタが本番環境の標準構成
• HPA/VPAを組み合わせたオートスケーリングで負荷変動に自動対応
• Workload IdentityでPod単位のIAMアクセス制御を実現
• ネットワークポリシーでPod間通信をゼロトラストに設計
• Cloud Build + Artifact RegistryでCI/CDパイプラインを構築
• Spot Podやリソース最適化でコストを大幅削減

まずはEp.1でプロジェクトを作成し、Autopilotクラスタを立ち上げるところから始めましょう。Ep.7のVPC設計でネットワーク基盤を整え、Ep.6のIAM設計でWorkload Identityを正しく構成すれば、セキュアなGKE環境が完成します。

Kubernetes経験は、SES市場でのポジショニングを大きく変えます。「GKE設計・構築・運用」を武器に、より高単価な案件を獲得しましょう。

次回のGoogle Cloud 完全攻略もお楽しみに！

---

出典・参考資料

• Google Kubernetes Engine の概要 — Google Cloud
• Autopilot の概要 — Google Cloud
• GKE クラスタの作成 — Google Cloud
• Workload Identity — Google Cloud
• ネットワークポリシー — Google Cloud
• GKE のコスト最適化 — Google Cloud
• Cloud Build と GKE — Google Cloud

関連記事

• GCPの基礎知識とプロジェクト作成
• Cloud RunとCloud SQLで実現するスケーラブルなコンテナ運用
• BigQueryではじめるデータ分析入門
• Cloud Functionsで学ぶサーバーレスアーキテクチャ入門
• Cloud Storageで学ぶオブジェクトストレージ運用入門
• IAMとセキュリティ設計で学ぶクラウド権限管理
• VPCネットワーク設計入門