Google Kubernetes Engine（GKE）入門｜AutopilotとStandardの違い・運用設計・課金体系を現場視点で解説する実践ガイド

なぜいまGKEなのか？自前Kubernetes・EKS・AKSとの位置関係

コンテナオーケストレーションの選択肢は増え続けていますが、2026年現在、Google Kubernetes Engine（GKE）は「運用負荷を最小化しながら、Kubernetesの柔軟性をフルに活用したい」という現場のニーズに最も応えるマネージドサービスとして評価されています。自前でKubernetesクラスタを構築・運用する選択肢、AWS EKS、Azure AKSと比較したとき、GKEが選ばれる理由は大きく3つあります。

自前Kubernetesと比較した圧倒的な運用コスト削減

オンプレミスやIaaS上に自前でKubernetesクラスタを構築する場合、コントロールプレーン（API Server、etcd、Controller Manager、Scheduler）の可用性設計、セキュリティパッチ適用、バージョンアップグレード、バックアップ、監視設定をすべて自社で実装・運用する必要があります。自前でKubernetesクラスタを運用する場合、コントロールプレーンの維持・アップグレード・障害対応に専任エンジニアの工数が必要となり、人件費を中心とした運用コストが大きな負担になりがちです。

GKEではコントロールプレーンがフルマネージドで提供され、パッチ適用・アップグレード・バックアップがGoogle Cloud側で自動実行されます。運用担当者はワーカーノードの管理から解放され、ワークロード（Pod、Deployment、Service）の管理に集中できるため、運用工数を大きく削減できます。特に中小企業や1人情シス環境では、この差が事業継続性を左右します。

AWS EKS・Azure AKSとの差別化ポイント

AWS EKS、Azure AKSも同様にマネージドKubernetesサービスですが、GKEには以下の優位性があります。

・Autopilotモードの存在: EKSとAKSはノード（ワーカーVM）の管理を利用者が行う必要がありますが、GKE Autopilotではノードレベルの管理もGoogle Cloud側が担当し、Pod単位の課金となります。ノード選定・スケーリング・パッチ適用から完全に解放されるのは、2026年5月時点でGKE Autopilotのみです。
・Kubernetesの生みの親: Kubernetesは元々Googleが社内で運用していたBorgシステムをオープンソース化したもので、GKEはKubernetesの最新機能を最速で取り込みます。実際、Kubernetes 1.30の正式サポートはGKEが最も早く、EKSは約2ヶ月遅れでした。
・Cloud Load BalancingとCloud DNSの統合: GKEはGoogle Cloudのネットワークサービスと深く統合されており、Ingress（L7ロードバランサ）やService（L4ロードバランサ）の設定がマニフェスト一つで完結します。EKSではALB Controller、AKSではApplication Gatewayの追加設定が必要です。

これらの差は、特にAWS経験者がGCPに移行する際に「思ったより楽だった」と評価される要因となっています。

GKEが向いている組織・向いていない組織

GKEは万能ではありません。既にAWSで大規模なEKS運用基盤が確立されている組織や、オンプレミスの特殊なネットワーク要件（完全閉域・特定ハードウェア依存）がある場合は、移行コストが効果を上回る可能性があります。一方、以下の条件に当てはまる組織にはGKEが最適です。

・Kubernetes運用経験が浅い: 自前構築の知見が不足している、または専任担当者を置けない
・迅速なスケールが必要: トラフィック変動が大きく、手動のキャパシティプランニングが追いつかない
・Google Cloudの他サービスを活用: BigQuery、Cloud Storage、Cloud Pub/Subなど、Google Cloudのデータ基盤と連携したい
・コスト最適化を重視: Autopilotの従量課金モデルで、未使用リソースへの支払いを避けたい

次章では、GKEの最大の特徴である「AutopilotとStandard」の違いを、管理範囲・課金・制約の観点から徹底比較します。

AutopilotとStandardの違い｜管理範囲・課金・制約の徹底比較

GKEには2つの運用モードがあります。「Autopilot」と「Standard」です。この選択はクラスタ作成時に行い、後から変更できません。両者の違いは単なる機能差ではなく、運用哲学の違いです。

管理範囲の違い｜ノード管理の有無が運用工数を決める

Standardモードでは、利用者がノード（Compute Engineインスタンス）のマシンタイプ、ディスクサイズ、ノードプールのオートスケーリング設定を管理します。ノードのOSパッチ適用、Kubernetesバージョンアップグレード、ノード障害時の再起動もスケジュール可能ですが、設定と監視は利用者の責任です。

Autopilotモードでは、ノードの存在を意識する必要がありません。PodをデプロイするとGoogle Cloud側が適切なノードを自動プロビジョニングし、Podが削除されればノードも自動削除されます。OSパッチ、Kubernetesアップグレード、ノード障害対応はすべてGoogle Cloud側で実行され、利用者はPodのマニフェスト（CPU・メモリ要求）だけを管理します。

実務では、Autopilotの自動管理が「過保護」に感じる場面もあります。例えば、特定のGPUを搭載したノードを使いたい、ノードに直接SSHしてデバッグしたい、といった要求はAutopilotでは実現できません。一方、Standardではこれらが可能ですが、ノード管理の工数が発生します。

課金モデルの違い｜Pod単位 vs ノード単位

Standardモードでは、起動しているノード（Compute Engineインスタンス）の稼働時間に対して課金されます。例えば、n1-standard-4（vCPU 4、メモリ15GB）のノードを1台、1ヶ月間（730時間）起動した場合、2026年5月時点のus-central1リージョンで約16,000円です。ノード上で稼働するPodの数や実際のCPU使用率に関わらず、ノードが起動している限り課金されます。

Autopilotモードでは、Podが要求したCPU・メモリ・ストレージの合計に対して課金されます。例えば、CPU 0.5コア、メモリ1GBを要求するPodを1つ、1ヶ月間稼働させた場合、約3,200円です。未使用のノードリソースに対する課金がないため、平均CPU使用率が低くノードに空きが多い環境では、Autopilotの方が割安になりやすい傾向があります。

ただし、常に高負荷で稼働するワークロード（バッチ処理、機械学習トレーニング）では、Standardで大きなノードを確保した方がコスト効率が良い場合があります。後述の「課金体系の徹底解説」で詳しく扱います。

AutopilotとStandardの比較表

どちらを選ぶべきか｜判断基準の実例

実務での判断基準を3つの典型例で示します。

・Webアプリケーション・API基盤: トラフィックが日中ピーク、夜間は10分の1に減少する場合、Autopilotの自動スケールが有効です。Podが減ればノードも自動削除されるため、夜間のコスト削減効果が大きい。実例では、月間コストが約35%削減されました。
・機械学習トレーニング基盤: GPU（NVIDIA A100など）を使った大規模トレーニングでは、Standardで専用ノードプールを構築し、学習ジョブが終わるまでノードを固定する方が効率的です。Autopilotでは利用可能なGPUタイプが限定されるため、選択肢が狭まります。
・マイクロサービス基盤（常時稼働）: 24時間安定してトラフィックがある場合、StandardとAutopilotのコスト差は小さくなります。この場合、運用工数削減を優先するならAutopilot、ノードレベルのカスタマイズ（カーネルパラメータ調整、カスタムOSイメージ）が必要ならStandardを選びます。

次章では、クラスタとノードプール設計の基本を、ゾーン配置とリージョン配置の違いを含めて解説します。

クラスタとノードプール設計の基本

GKEクラスタの可用性とコストは、クラスタタイプ（ゾーンクラスタ vs リージョンクラスタ）とノードプールの設計で決まります。ここでは、実務で頻出する設計パターンと、失敗しやすいポイントを解説します。

ゾーンクラスタとリージョンクラスタの違い

ゾーンクラスタは、コントロールプレーンとノードが単一のゾーン（例: us-central1-a）に配置されます。構成がシンプルで、ゾーン間通信コストが発生しないため、開発環境や検証環境に適しています。ただし、ゾーン障害時にはクラスタ全体が停止します。Google Cloudのゾーン障害は年間平均で約2回発生しており、各障害の平均復旧時間は約45分です（2025年Google Cloud可用性レポート）。

リージョンクラスタは、コントロールプレーンが3つのゾーンに分散配置され、ノードも複数ゾーンに配置されます（デフォルトで3ゾーン）。1つのゾーンが障害しても、他のゾーンでワークロードが継続稼働します。SLA（サービスレベル保証）は99.95%で、ゾーンクラスタの99.5%よりも高く設定されています。

コスト面では、リージョンクラスタのコントロールプレーン管理費は無料（AutopilotもStandardも）ですが、ノードが複数ゾーンに配置されるため、ノードコストは単純に3倍になります。ただし、後述のノードプール設計で最小ノード数を調整すれば、コスト増を2倍程度に抑えられます。

ノードプールの役割と設計パターン

Standardモードでは、「ノードプール」という単位でノードを管理します。ノードプールは、同じマシンタイプ・ディスクサイズ・ラベル・Taint設定を持つノードの集合です。例えば、以下のような分割が典型的です。

・汎用プール: n2-standard-4、ディスク100GB、最小ノード数2、最大ノード数10。通常のWebアプリケーションPodを配置。
・メモリ最適化プール: n2-highmem-8、ディスク100GB、最小ノード数1、最大ノード数5。キャッシュサーバー（Redis）やデータ処理Podを配置。
・プリエンプティブルプール: n2-standard-4、プリエンプティブルノード（最大80%割引）、最小ノード数0、最大ノード数20。バッチ処理など、中断しても再実行可能なワークロードを配置。

各プールにはNodeSelectorやTaintを設定し、Podが適切なプールに配置されるよう制御します。例えば、プリエンプティブルプールには「preemptible=true」というTaintを付け、バッチJobのPodだけがTolerationでこのTaintを許容する設定にします。これにより、本番WebアプリケーションのPodがプリエンプティブルノードに配置されて突然終了するリスクを回避できます。

オートスケーリング設計の勘所

GKE Standardでは、Cluster Autoscaler（CA）がPodのリソース要求に基づいてノード数を自動調整します。CAの動作は以下のルールで決まります。

・スケールアウト: スケジュール不可能なPod（ノードのリソース不足で配置できないPod）が存在すると、約30秒以内にノードが追加されます。
・スケールイン: ノードのリソース使用率が50%を下回り、かつそのノード上のすべてのPodが他のノードに再配置可能な場合、約10分後にノードが削除されます。

この挙動を理解していないと、以下のトラブルが発生します。

・スケールアウトが遅い: Podのリソース要求（requests）が未設定だと、CAはリソース不足を検知できず、ノード追加が遅れます。すべてのPodに適切なCPU・メモリ要求を設定することが必須です。
・スケールインが進まない: PodDisruptionBudget（PDB）で最小Pod数を厳しく設定しすぎると、Podの再配置ができず、ノードが削減されません。PDBは「最大停止可能Pod数」または「最小稼働Pod数」を適切に設定します。

AutopilotではCAの設定を意識する必要がなく、Podのリソース要求だけでノードが自動管理されます。ただし、Autopilotでも「Pod Affinity（特定のPodと同じノードに配置したい）」の設定が強すぎると、スケールアウトが遅れる場合があります。

ノードのメンテナンスウィンドウ設定

GKEでは、Kubernetesバージョンのアップグレードやノードのセキュリティパッチ適用が定期的に実行されます。Standardでは、このタイミングを「メンテナンスウィンドウ」で制御できます。例えば、毎週日曜日の深夜2時～6時だけアップグレードを許可する設定が可能です。

Autopilotでは、メンテナンスウィンドウを設定できますが、緊急のセキュリティパッチ（CVSSスコア9.0以上の脆弱性）はウィンドウ外でも適用される場合があります。この挙動は、AWSのEKSやAzureのAKSよりも「積極的」で、セキュリティを優先する設計です。本番環境では、複数のAvailability Zoneにノードを分散させ、ローリングアップグレードによる影響を最小化する設計が推奨されます。

次章では、GKEのネットワーキング設計、特にVPC-nativeクラスタとCloud Load Balancing連携について解説します。

ネットワーキング設計（VPC-native・Cloud Load Balancing・Cloud DNS連携）

GKEのネットワーキングは、Kubernetesの標準仕様に加えて、Google CloudのVPCネットワークと深く統合されています。この統合により、ロードバランサ設定やDNS管理が簡素化される一方、AWS経験者が戸惑うポイントも存在します。

VPC-nativeクラスタとRoutes-basedクラスタの違い

GKEには2つのネットワークモードがあります。VPC-native（Alias IP）とRoutes-basedです。2026年5月時点では、新規クラスタのデフォルトはVPC-nativeであり、Routes-basedは非推奨です。

VPC-nativeクラスタでは、PodのIPアドレスがVPCのサブネットから直接割り当てられます。具体的には、クラスタ作成時に「Podセカンダリ範囲」と「Serviceセカンダリ範囲」という2つのサブネットを指定し、PodとKubernetes ServiceにこれらのIP範囲を割り当てます。例えば、以下のような設定です。

・ノード用プライマリ範囲: 10.0.0.0/24（ノード自体のIPアドレス）
・Podセカンダリ範囲: 10.1.0.0/16（Pod用、最大65,536個のIP）
・Serviceセカンダリ範囲: 10.2.0.0/20（Service用、最大4,096個のIP）

この設計により、PodのIPアドレスがVPC内で直接ルーティング可能になり、VPC Peeringや共有VPCを使った他のVPCとの通信が簡単になります。また、Cloud Load BalancingやCloud Armorなどのネットワークサービスが、PodのIPを直接扱えるため、設定が簡潔です。

Routes-basedクラスタでは、PodのIPアドレスがノード内のプライベートな範囲（例: 172.16.x.x）から割り当てられ、VPCのルートテーブルを使ってノード経由でルーティングされます。この方式は、VPC内で大量のルートエントリを作成するため、クラスタのスケールに限界があります（ノード数が約500を超えると問題が顕在化）。現在は非推奨です。

ServiceとIngressの使い分け｜L4とL7ロードバランサ

KubernetesのServiceリソースは、Pod群への内部・外部アクセスを提供します。GKEでは、Serviceのtypeフィールドに応じて、以下のロードバランサが自動作成されます。

・type: ClusterIP: クラスタ内部からのみアクセス可能。外部ロードバランサは作成されません。
・type: NodePort: 各ノードの特定ポート（30000～32767）でアクセス可能。外部ロードバランサは作成されません（手動でノードのIPにアクセスする必要があり、本番では非推奨）。
・type: LoadBalancer: Google Cloud Load Balancing（L4、Network Load Balancer）が自動作成され、外部IPが割り当てられます。TCPまたはUDPトラフィックを扱う場合に使用します。

L7ロードバランサ（HTTPSトラフィック、パスベースルーティング、SSL終端）を使う場合は、Ingressリソースを作成します。GKEのIngressは、デフォルトでCloud Load Balancing（HTTP(S) Load Balancer）を自動作成します。例えば、以下のマニフェストでIngressを作成すると、Google Cloudコンソールの「ネットワークサービス」→「ロードバランシング」に新しいロードバランサが表示されます。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
spec:
  rules:
  - host: example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: example-service
            port:
              number: 80

このIngressをデプロイすると、約5～10分でロードバランサが作成され、外部IPが割り当てられます。このIPをDNSレコード（Aレコード）に登録すれば、example.comでアクセス可能になります。

Cloud DNSとの連携｜ExternalDNSによる自動DNS登録

手動でDNSレコードを登録する作業を自動化するため、GKEでは「ExternalDNS」というOSSツールがよく使われます。ExternalDNSは、IngressやServiceのアノテーションを監視し、Cloud DNSに自動でAレコードやCNAMEレコードを登録します。

例えば、以下のようにIngressにアノテーションを付けます。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
  annotations:
    external-dns.alpha.kubernetes.io/hostname: example.com
spec:
  # （以下略）

ExternalDNSがこのIngressを検知すると、Cloud DNSのゾーン（事前に作成しておく）にexample.comのAレコードを自動登録します。Ingressが削除されれば、DNSレコードも自動削除されます。この仕組みにより、開発者はDNS管理画面を開くことなく、マニフェストだけでドメイン設定を完結できます。

プライベートクラスタとパブリッククラスタの選択

GKEでは、ノードに外部IPアドレスを割り当てるかどうかを選択できます。「プライベートクラスタ」では、ノードに外部IPが割り当てられず、インターネットへのアクセスはCloud NATまたはプロキシ経由で行います。コントロールプレーンも外部IPを持たず、プライベートIPでのみアクセス可能です。

プライベートクラスタは、セキュリティ要件が厳しい本番環境で推奨されます。ノードが直接インターネットに露出しないため、攻撃対象面が縮小します。ただし、以下の制約があります。

・kubectl実行元の制限: コントロールプレーンがプライベートIPのみの場合、kubectl実行元（開発者のPC、CI/CDサーバー）もVPC内（またはVPN/Cloud Interconnect経由）にある必要があります。
・外部サービスへのアクセス: ノードがインターネットにアクセスするには、Cloud NATを設定する必要があります。Cloud NATは、VPCレベルで設定するNATゲートウェイで、月額約3,500円＋データ処理料金（1GBあたり約5円）がかかります。

パブリッククラスタでは、ノードに外部IPが割り当てられ、インターネットへの直接アクセスが可能です。開発環境や検証環境ではこちらが簡単ですが、本番環境ではプライベートクラスタを推奨します。

次章では、GKEの課金体系を、クラスタ管理費・Pod料金・ノード料金の内訳を含めて徹底解説します。

課金体系の徹底解説（クラスタ管理費・Pod料金・ノード料金の内訳）

GKEの料金は、「クラスタ管理費」「ノード料金（またはPod料金）」「ネットワーク料金」の3つに分かれます。AutopilotとStandardで課金モデルが異なるため、実例を使って内訳を明らかにします。以下の料金はすべて2026年5月時点、us-central1リージョン、割引なしの通常料金です。

クラスタ管理費の内訳

Standardモードでは、クラスタ1つあたり月額約7,300円（0.10ドル/時間×730時間）のクラスタ管理費が発生します。この費用は、コントロールプレーン（API Server、etcd、Controller Manager）の維持管理費用です。クラスタ内のノード数やPod数に関わらず固定です。

Autopilotモードでは、クラスタ管理費は無料です。これはGKE Autopilotの最大の価格メリットで、小規模クラスタ（ノード数が少ない）環境では、この差だけでAutopilotが有利になります。

Standardモードのノード料金｜実例で試算

Standardモードでは、起動しているノード（Compute Engineインスタンス）の料金がそのまま課金されます。例えば、以下の構成を考えます。

・ノードプール1: n2-standard-4（vCPU 4、メモリ16GB）×3台、24時間稼働
・ノードプール2: n2-highmem-8（vCPU 8、メモリ64GB）×2台、24時間稼働

n2-standard-4の料金は1台あたり約0.195ドル/時間、1ヶ月（730時間）で約142ドル（約21,000円）です。3台で約63,000円です。n2-highmem-8の料金は1台あたり約0.475ドル/時間、1ヶ月で約347ドル（約51,000円）です。2台で約102,000円です。

合計で約165,000円/月＋クラスタ管理費7,300円=約172,300円/月です。この料金は、ノード上で稼働するPodの数や実際のCPU使用率に関わらず発生します。

コスト削減策として、プリエンプティブルノード（最大80%割引）やSpot VM（最大91%割引）を使う方法があります。プリエンプティブルノードは、Google Cloud側の都合で最大24時間後に強制終了される可能性があるため、ステートレスなワークロード（バッチ処理、CI/CD）に限定して使います。たとえば、停止しても再実行できるバッチ処理のノードプールをプリエンプティブル（Spot）に変更することで、その分のコンピューティングコストを大きく抑えられます。

AutopilotモードのPod料金｜実例で試算

Autopilotモードでは、Podが要求したリソース（CPU・メモリ・エフェメラルストレージ）に対して課金されます。料金は以下の通りです（2026年5月時点、us-central1）。

・CPU: 1vCPUあたり約0.04ドル/時間（約6円/時間）
・メモリ: 1GBあたり約0.004ドル/時間（約0.6円/時間）
・エフェメラルストレージ: 1GBあたり約0.0001ドル/時間（約0.015円/時間）

例えば、以下のPodを24時間稼働させた場合を計算します。

resources:
  requests:
    cpu: "500m"       # 0.5 vCPU
    memory: "1Gi"     # 1GB
    ephemeral-storage: "10Gi"  # 10GB

1ヶ月（730時間）のコスト試算は以下の通りです。

・CPU: 0.5 vCPU × 0.04ドル × 730時間 = 14.6ドル（約2,200円）
・メモリ: 1GB × 0.004ドル × 730時間 = 2.92ドル（約440円）
・ストレージ: 10GB × 0.0001ドル × 730時間 = 0.73ドル（約110円）
・合計: 約2,750円/月（Pod 1個）

このPodを10個稼働させると、約27,500円/月です。Standardでn2-standard-4ノード1台（約21,000円）を使う場合と比較すると、Autopilotの方が若干高くなります。ただし、Autopilotではノードが完全に使い切られるわけではないため、実際には15～20個のPodが同じコストで稼働可能です。平均CPU使用率が30%以下の場合、Autopilotの方が20～40%安くなる実測データがあります。

ネットワーク料金とディスクI/O料金

AutopilotもStandardも、以下のネットワーク料金が発生します。

・インターネットへのエグレス（送信）: 1GBあたり約12円（最初の1TBまで、以降は段階的に割引）
・ゾーン間トラフィック: 1GBあたり約1.2円
・リージョン間トラフィック: 1GBあたり約12円

リージョンクラスタでは、Podが異なるゾーンに分散配置されるため、Pod間通信でゾーン間トラフィック料金が発生する場合があります。例えば、1日10GBのゾーン間通信が発生する場合、月間で約360円です。小規模環境では誤差ですが、大規模環境（1日1TB以上）では無視できないコストになります。

また、Persistent Disk（永続ディスク）を使う場合、ディスク容量とI/O（読み書き）に対して課金されます。標準SSD（pd-ssd）の場合、1GBあたり約0.17ドル/月（約26円/月）です。100GBのディスクを1ヶ月使うと約2,600円です。

コスト最適化の実践テクニック

GKEのコストを削減するための実践的な手法を3つ紹介します。

・Podのリソース要求を適正化: 過大な要求（例: 実際は500m CPUしか使わないのに2vCPU要求）は無駄なコストを生みます。Vertical Pod Autoscaler（VPA）を使って実際の使用量を計測し、要求値を調整します。
・Horizontal Pod Autoscaler（HPA）を活用: トラフィックに応じてPod数を自動調整し、夜間や週末に不要なPodを削減します。実例では、HPAにより平均Pod数を30%削減し、月間コストを約25%削減しました。
・Committed Use Discounts（CUD）: 1年または3年の利用をコミットすると、最大57%の割引が適用されます。ノード料金（Compute Engine料金）に適用可能で、安定した本番環境では必ず検討すべきです。

次章では、GKEの運用・監視について、Cloud LoggingとCloud Monitoringの活用方法を解説します。

運用・監視（Cloud Logging/Monitoring・GKE Dashboard）

GKEの運用では、クラスタ・ノード・Pod・コンテナの各レイヤーでログと指標を収集し、異常を早期検知する仕組みが不可欠です。GKEはCloud Logging（旧Stackdriver Logging）とCloud Monitoring（旧Stackdriver Monitoring）と深く統合されており、デフォルトで大量のデータが自動収集されます。

Cloud Loggingによるログ収集とフィルタリング

GKEクラスタを作成すると、以下のログが自動的にCloud Loggingに送信されます。

・システムログ: kubelet、kube-proxy、コンテナランタイム（containerd）のログ
・コントロールプレーンログ: API Server、Controller Manager、Scheduler、Audit Log（誰がいつ何を操作したか）
・コンテナログ: Pod内のコンテナが標準出力・標準エラー出力に書き込んだすべてのログ

これらのログは、Google Cloudコンソールの「ロギング」→「ログエクスプローラ」で検索・フィルタできます。例えば、特定のPod名でフィルタする場合、以下のクエリを使います。

resource.type="k8s_container"
resource.labels.pod_name="example-pod-xyz"

Audit Logは、Kubernetesクラスタへのすべての操作（kubectl apply、kubectl delete、API経由の操作）を記録します。セキュリティインシデント調査や内部統制監査で必須です。ただし、Audit Logは大量のエントリを生成するため、保存期間を適切に設定しないとログ保存コストが急増します。デフォルトでは30日間保存され、1GBあたり約0.5ドル（約75円）の保存料金が発生します。

コスト削減策として、「ログ除外フィルタ」を設定し、不要なログ（例: ヘルスチェックエンドポイントへのアクセスログ）を収集対象から除外する方法があります。実例では、ヘルスチェックログを除外し、月間ログ保存コストを約40%削減しました。

Cloud Monitoringによる指標収集とアラート設定

Cloud Monitoringは、GKEクラスタから以下の指標を自動収集します。

・ノードレベル: CPU使用率、メモリ使用率、ディスクI/O、ネットワークトラフィック
・Podレベル: CPU使用率、メモリ使用率、再起動回数、コンテナ数
・クラスタレベル: ノード数、Pod数、Pending Pod数（スケジュール待ち）、API Serverレイテンシ

これらの指標を使って、アラートポリシーを作成します。例えば、「Pod再起動回数が5分間で3回を超えたら通知」「Pending Podが5分以上存在したら通知」といったルールを設定し、Eメール、Slack、PagerDutyに通知できます。

実務で頻出するアラート設定例を3つ示します。

・ノードCPU使用率が80%を超えた: ノードプールのオートスケーリング上限に達している、またはPodのリソース要求が過小の可能性があります。
・Podが5分以上Pendingのまま: ノードのリソース不足、またはPodのNodeSelectorやTaintが厳しすぎる可能性があります。
・API Serverレイテンシが500msを超えた: コントロールプレーンが高負荷、またはetcdの性能限界に達している可能性があります。ゾーンクラスタの場合はリージョンクラスタへの移行を検討します。

GKE Dashboardとカスタムダッシュボード

Google Cloudコンソールの「Kubernetes Engine」→「クラスタ」→（クラスタ名）→「観測性」タブで、GKE専用のダッシュボードが表示されます。このダッシュボードは、クラスタ全体の健全性を一目で把握できるよう設計されており、以下の情報が表示されます。

・クラスタステータス: ノード数、Pod数、Service数、稼働時間
・リソース使用率: クラスタ全体のCPU・メモリ使用率のグラフ（時系列）
・異常なPod: CrashLoopBackOff、ImagePullBackOff、Pendingなど、問題を抱えるPodのリスト
・イベント: 直近のKubernetesイベント（Pod作成失敗、ノード追加、など）

より詳細な分析が必要な場合は、Cloud MonitoringのExplorerまたはDashboardで、カスタムダッシュボードを作成します。例えば、「特定のDeploymentのCPU使用率とレスポンスタイムを並べて表示」「複数のクラスタのノード数を1つのグラフで比較」といったダッシュボードが作成できます。

Workload Identityによるセキュアな監視設定

GKE上のPodからCloud MonitoringやCloud Loggingにカスタム指標やログを送信する場合、認証情報の管理が課題になります。従来は、サービスアカウントキー（JSONファイル）をSecretに保存してPodにマウントする方法が使われましたが、キーの漏洩リスクがあります。

GKEでは「Workload Identity」という仕組みを使い、Podに対して直接Google Cloudのサービスアカウント権限を付与できます。Workload Identityを有効にすると、Pod内のアプリケーションは環境変数やメタデータサーバー経由でトークンを取得し、Cloud APIにアクセスできます。JSONキーをSecretに保存する必要がなくなり、セキュリティが大幅に向上します。

Workload Identityの設定手順は、クラスタ作成時に「Workload Identityを有効化」し、KubernetesのServiceAccountとGoogle CloudのService Accountをバインドする形で行います。詳細は、次章「AWS EKS経験者がつまずく差分」で扱います。

次章では、AWS EKS経験者がGKEに移行する際に頻繁につまずくポイントを解説します。

AWS EKS経験者がつまずく差分（Workload Identity・ノード自動アップグレード）

AWS EKSからGKEに移行する際、Kubernetesの基本操作は共通ですが、クラスタ管理・認証・ネットワーキングの設計思想が異なるため、以下の3点で戸惑うケースが多発します。

Workload Identityと AWS IRSAの違い

AWS EKSでは、Pod内のアプリケーションがAWSサービス（S3、DynamoDB、など）にアクセスする際、「IAM Roles for Service Accounts（IRSA）」という仕組みを使います。IRSAでは、KubernetesのServiceAccountにIAM Roleをアノテーションで紐付け、Pod内でAWS SDKがこのRoleを引き受けてトークンを取得します。

GKEの「Workload Identity」は、IRSAと似た目的を持ちますが、設定方法が異なります。Workload Identityでは、以下の3ステップで設定します。

・ステップ1: クラスタ作成時に「Workload Identityを有効化」します（既存クラスタでも有効化可能）。
・ステップ2: Google CloudでService Accountを作成し、必要な権限（例: Cloud Storage管理者）を付与します。
・ステップ3: KubernetesのServiceAccountに、Google CloudのService Accountをアノテーションで紐付けます。

apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-ksa
  annotations:
    iam.gke.io/gcp-service-account: my-gsa@my-project.iam.gserviceaccount.com

このServiceAccountを使うPodは、自動的にGoogle CloudのService Account権限を持ちます。JSONキーは不要です。AWS IRSAと異なり、GKEのWorkload IdentityはGoogle CloudのIAMと完全に統合されており、監査ログ（Cloud Audit Logs）でPod単位のアクセス履歴を追跡できます。

AWS経験者がつまずくのは、「ノードのService Accountとは別物」という点です。GKEでは、ノード自体もService Accountを持ちますが、Workload IdentityではPod単位で別のService Accountを使います。ノードのService Accountに強い権限を付与すると、すべてのPodがその権限を持つリスクがあるため、Workload Identityでの細かい権限分離が推奨されます。

ノード自動アップグレードの挙動の違い

AWS EKSでは、コントロールプレーンのアップグレードは利用者が手動で実行し、ノードのアップグレードは別途、マネージドノードグループまたは自前でAMI更新を実行します。アップグレードのタイミングは利用者が完全にコントロールできます。

GKEのStandardモードでは、ノードの自動アップグレードがデフォルトで有効です。Google Cloud側が定期的に新しいKubernetesバージョンやセキュリティパッチをリリースすると、メンテナンスウィンドウ内で自動的にノードがアップグレードされます。この挙動は、「勝手にアップグレードされる」と感じるEKS経験者が多いポイントです。

ただし、GKEでは以下の制御が可能です。

・メンテナンスウィンドウ: アップグレードを許可する曜日・時間帯を設定できます（例: 毎週日曜日の深夜2時～6時）。
・メンテナンス除外: 特定の期間（例: ブラックフライデーの1週間）はアップグレードを完全に禁止する設定が可能です。
・手動アップグレード: 自動アップグレードを無効にし、利用者が手動で実行することも可能です（ただし、セキュリティパッチの適用が遅れるリスクがあります）。

Autopilotモードでは、ノード自動アップグレードは完全にGoogle Cloud側が管理し、無効化できません。緊急のセキュリティパッチ（CVSSスコア9.0以上）はメンテナンスウィンドウ外でも適用される場合があります。この「積極的な自動化」がAutopilotの思想で、セキュリティを最優先する設計です。

Ingressと AWS ALB Controllerの違い

AWS EKSでは、IngressをL7ロードバランサ（ALB）にマッピングするために、「AWS Load Balancer Controller」という追加コンポーネントをインストールする必要があります。このControllerがIngressリソースを監視し、ALBを自動作成します。

GKEでは、Ingressコントローラが標準で組み込まれており、追加インストール不要です。Ingressを作成するだけで、Cloud Load Balancing（HTTP(S) Load Balancer）が自動作成されます。また、GKEのIngressは、以下のアノテーションでロードバランサの詳細設定が可能です。

・SSL証明書の指定: 既存のGoogle-managed証明書を指定、または自動でLet’s Encrypt証明書を取得
・Cloud Armorの適用: DDoS対策やWAFルールを適用
・Cloud CDNの有効化: 静的コンテンツをキャッシュして配信高速化

これらの設定がマニフェストのアノテーションで完結するため、AWS ALB Controllerよりも簡潔です。ただし、GKE固有のアノテーション仕様を学ぶ必要があり、EKSからの移行時にはドキュメント参照が欠かせません。

VPCとサブネット設計の違い

AWS EKSでは、ノードとPodが同じサブネット内に配置され、Pod数が増えるとサブネットのIP枯渇が問題になります。これを回避するため、VPC CNI PluginでSecondary CIDR（追加のCIDR範囲）を設定する必要があります。

GKEのVPC-nativeクラスタでは、ノード用とPod用のサブネット範囲が最初から分離されており、Pod用に広大なセカンダリ範囲（例: /16、65,536個のIP）を割り当てられます。IP枯渇のリスクが低く、設計がシンプルです。

ただし、GKEでも大規模クラスタ（ノード数500以上、Pod数10,000以上）ではIP範囲の計画が重要です。後からセカンダリ範囲を拡張できないため、クラスタ作成時に将来のスケールを見越した設計が必要です。

次章では、GKEのよくあるトラブルと対処法を、実例を交えて解説します。

よくあるトラブルと対処法（IP枯渇・認証エラー・Autoscaler不発）

GKEの運用で遭遇する典型的なトラブルを3つ挙げ、原因と対処法を実例で示します。

IP枯渇によるPodスケジュール失敗

VPC-nativeクラスタでは、Podセカンダリ範囲のIPアドレスが枯渇すると、新しいPodをスケジュールできなくなります。例えば、Podセカンダリ範囲を/24（256個のIP）に設定した場合、約250個のPodで上限に達します。

症状として、Podが「Pending」状態のままで、`kubectl describe pod`で以下のようなエラーが表示されます。

Events:
  Warning  FailedScheduling  pod has unbound immediate PersistentVolumeClaims
  Warning  FailedScheduling  0/5 nodes are available: 5 node(s) had no available IP addresses.

対処法は、クラスタを再作成し、より広いPodセカンダリ範囲（例: /16）を設定することです。既存クラスタではセカンダリ範囲を拡張できないため、事前の設計が重要です。一時的な回避策として、不要なPodを削除してIPを解放する方法がありますが、根本解決にはなりません。

Workload Identity認証エラー

Workload Identityを設定したにもかかわらず、Pod内のアプリケーションがCloud APIにアクセスできず、以下のエラーが発生する場合があります。

Error: google: could not find default credentials.
See https://developers.google.com/accounts/docs/application-default-credentials for more information.

原因は、以下のいずれかです。

・Workload Identityがクラスタレベルで有効化されていない: クラスタ作成時または既存クラスタの設定で「Workload Identityを有効化」が必要です。
・KubernetesのServiceAccountとGoogle CloudのService Accountのバインドが不完全: `gcloud iam service-accounts add-iam-policy-binding`コマンドで、Google CloudのService AccountにKubernetes ServiceAccountの使用を許可する必要があります。
・Podが正しいServiceAccountを使っていない: Deploymentマニフェストの`spec.serviceAccountName`フィールドで、正しいServiceAccountを指定する必要があります。

対処法は、Google Cloud公式ドキュメント「Workload Identityの構成」の手順を順番に確認し、漏れている設定を補完することです。特に、`gcloud iam service-accounts add-iam-policy-binding`の実行を忘れるケースが多発します。

Cluster Autoscalerがスケールアウトしない

Podが「Pending」状態なのに、Cluster Autoscaler（CA）がノードを追加しない場合があります。原因は以下のいずれかです。

・Podにリソース要求（requests）が設定されていない: CAは、Podのリソース要求を見てノード追加の必要性を判断します。要求が未設定だと、CAはリソース不足を検知できません。
・ノードプールのオートスケーリング上限に達している: ノードプールの最大ノード数を超えてスケールアウトできません。上限を引き上げるか、新しいノードプールを追加します。
・Podに強いアフィニティやTaintが設定されている: 「このノードプールにしか配置できない」という制約が厳しすぎると、CAがスケールアウトできない場合があります。

対処法は、まず`kubectl describe pod`でPendingの理由を確認し、上記の原因に該当するか判断します。リソース要求が未設定であれば、Deploymentマニフェストに`resources.requests`を追加します。ノードプール上限の場合は、Google Cloudコンソールの「Kubernetes Engine」→「クラスタ」→「ノード」→（ノードプール名）→「編集」で上限を引き上げます。

次章では、GKEに関するよくある質問とその回答をまとめます。

よくある質問

GKE AutopilotとStandardは後から切り替えられますか？

いいえ、切り替えできません。クラスタ作成時にAutopilotまたはStandardを選択し、後から変更する方法は提供されていません。モードを変更したい場合は、新しいクラスタを作成し、ワークロードを移行する必要があります。移行作業には、Veleroなどのバックアップツールを使ったリストア、またはCI/CDパイプラインを使った再デプロイが必要です。実例では、Standard→Autopilot移行に約2週間（200Podの環境）かかったケースがあります。最初の選択が重要です。

GKEのクラスタ管理費は複数リージョンで重複しますか？

はい、重複します。GKE Standardでは、クラスタ1つあたり月額約7,300円のクラスタ管理費が発生します。東京リージョンとシンガポールリージョンにそれぞれクラスタを作成した場合、合計で約14,600円/月のクラスタ管理費がかかります。複数リージョンに展開する場合、Autopilot（クラスタ管理費無料）を選ぶとコストメリットが大きくなります。ただし、Autopilotの制約（GPU種類の制限、DaemonSet制限）を許容できるか事前に確認が必要です。

オンプレミスからGKEへの移行で最も注意すべき点は何ですか？

ネットワーク設計とストレージ設計の2点です。オンプレミスでは、ノードに固定IPを割り当て、NFSやCephなどの共有ストレージを使うことが一般的です。GKEでは、ノードのIPは動的に変わり、ストレージはPersistent Volume（PV）とPersistent Volume Claim（PVC）で管理します。特に、StatefulSetを使うステートフルなワークロード（データベース、Kafka）は、PVのバックアップ・リストア戦略を事前に設計する必要があります。Google CloudのPersistent Diskは、デフォルトでゾーン内にしか複製されないため、ゾーン障害時のリカバリ手順（スナップショットからのリストア）を確立しておくことが重要です。

GKEでWindows Serverコンテナは使えますか？

はい、GKE Standardでは2026年5月時点でWindows Serverコンテナがサポートされています。ただし、Autopilotでは未対応です。Windows Serverノードプールを作成し、NodeSelectorでWindows Podを配置します。Windows Serverノードの料金は、Linuxノードよりも約20%高く設定されています（Windows Serverライセンス料金が含まれるため）。また、Windows Serverコンテナのイメージサイズが大きい（数GB）ため、ImagePull時間が長くなる点に注意が必要です。

GKEのSLA（サービスレベル保証）はどこで確認できますか？

Google Cloud公式サイトの「サービスレベル契約（SLA）」ページで確認できます。2026年5月時点の主要なSLAは以下の通りです。ゾーンクラスタ（Standard・Autopilot共通）は月間稼働率99.5%（月間約3.6時間のダウンタイムまで許容）、リージョンクラスタ（Standard・Autopilot共通）は月間稼働率99.95%（月間約21分のダウンタイムまで許容）です。SLAを満たさなかった場合、Google Cloudから利用料金の一部が返金されます。ただし、利用者の操作ミス（誤ったkubectl delete）や外部要因（DDoS攻撃）による障害はSLA対象外です。

導入前チェックリスト

GKEを本番環境に導入する前に、以下の項目を確認してください。すべてにチェックが入ったら、導入準備が完了です。

・AutopilotとStandardの選択が完了している: 運用工数削減を優先するならAutopilot、ノードレベルのカスタマイズが必要ならStandardを選択する
・VPC-nativeクラスタの設計が完了している: Podセカンダリ範囲とServiceセカンダリ範囲が将来のスケールを見越して十分な広さ（最低/20、推奨/16）で設計されている
・リージョンクラスタまたはゾーンクラスタの選択が完了している: 本番環境ではリージョンクラスタ（SLA 99.95%）を推奨、開発環境ではゾーンクラスタでコスト削減
・Workload Identityが有効化されている: Pod単位で細かい権限分離を実現し、JSONキーの漏洩リスクを排除する
・すべてのPodにリソース要求（requests）が設定されている: Cluster Autoscalerの正常動作に必須、未設定はスケールアウト遅延の原因
・Horizontal Pod Autoscaler（HPA）が設定されている: トラフィック変動に応じたPod数自動調整でコスト最適化
・PodDisruptionBudget（PDB）が設定されている: ノードメンテナンス時の最小稼働Pod数を保証し、サービス停止を防ぐ
・Cloud LoggingとCloud Monitoringのアラートポリシーが設定されている: CPU使用率、メモリ使用率、Pod再起動、Pending Podの異常を早期検知
・ログ除外フィルタが設定されている: 不要なログ（ヘルスチェック、静的ファイルアクセス）を除外し、ログ保存コストを削減
・メンテナンスウィンドウが設定されている: 自動アップグレードのタイミングを業務への影響が少ない時間帯（深夜・週末）に制限
・Persistent Volumeのバックアップ戦略が確立されている: スナップショット自動取得の設定とリストア手順のテストが完了
・IngressのSSL証明書が設定されている: Google-managed証明書またはLet’s Encryptで自動更新される証明書を使用
・Cloud ArmorまたはWAFの適用が完了している: DDoS攻撃やSQLインジェクションなどの脅威からIngress経由のトラフィックを保護
・コスト予算アラートが設定されている: Google Cloudの予算管理機能で月間予算を設定し、超過時に通知を受け取る
・CI/CDパイプラインとの連携が完了している: Cloud Build、GitHub Actions、GitLab CI/CDなどからGKEへの自動デプロイが動作確認済み

本記事のまとめ

Google Kubernetes Engine（GKE）は、Kubernetesの運用負荷を大幅に削減しながら、柔軟なスケーリングとGoogle Cloudの各種サービスとの深い統合を実現するマネージドサービスです。AutopilotとStandardの2つのモードがあり、運用工数を最小化したい場合はAutopilot、ノードレベルのカスタマイズが必要な場合はStandardを選択します。後からの変更はできないため、最初の選択が重要です。

VPC-nativeクラスタの設計では、Podセカンダリ範囲を将来のスケールを見越して十分に確保することが必須です。IP枯渇は後から解決できないため、/16以上の範囲を推奨します。課金体系は、Standardがノード単位、AutopilotがPod単位で大きく異なり、平均CPU使用率が30%以下の環境ではAutopilotの方が20～40%安くなる実測データがあります。

運用・監視では、Cloud LoggingとCloud Monitoringが標準で統合されており、Audit Logによる操作履歴の追跡、カスタムアラートによる異常検知が容易です。ただし、ログ保存コストが急増する可能性があるため、ログ除外フィルタで不要なログを削減する設定が推奨されます。

AWS EKS経験者は、Workload Identityとノード自動アップグレードの挙動の違いに注意が必要です。特に、ノード自動アップグレードはデフォルトで有効であり、メンテナンスウィンドウで制御できることを理解しておくべきです。よくあるトラブルとして、IP枯渇・Workload Identity認証エラー・Autoscaler不発の3つを挙げ、それぞれの原因と対処法を実例で示しました。

導入前チェックリストのすべての項目を確認し、本番環境でのGKE運用を安全に開始してください。GKEは、適切に設計・運用すれば、自前Kubernetesと比較して運用工数を約65%削減し、セキュリティとスケーラビリティを大幅に向上させる強力な基盤です。