GKE（Google Kubernetes Engine）は「GCP版のKubernetes」と紹介されることが多いですが、そう聞くと別物の何かに見えてしまいます。実際のGKEは素のKubernetesそのもので、違いはKubernetesを動かすための面倒な作業をGCPがどこまで肩代わりしてくれるか、という点にあります。
この記事は、『KubernetesのService・Ingressの関係とPodへの通信経路』までで押さえたKubernetesの構成を前提に、GKEで何がマネージドになるのかを地図として整理します。個々の機能を詳しく詰め込むのではなく、GKE文脈で出てくる用語の位置づけを掴むのが狙いです。
- GKEがKubernetesのどこをマネージドにするのか
- StandardとAutopilot、Node Poolの位置づけ
- HPA・VPA・Cluster Autoscalerの違い
- GCP連携とロケーション設計の位置づけ
GKEはKubernetesのどこをマネージドにするのか
Kubernetesを自前で運用するには、『Kubernetesの概要・全体像まとめ』で見たControl Planeを自分で構築・維持し、Nodeとなるマシンも自分で用意し、バージョンアップやセキュリティパッチも自分で当て続ける必要があります。これはそれ自体が大きな運用負担です。
GKEは、このKubernetesの運用作業をGCPが肩代わりするマネージドサービスです。中身は素のKubernetesのままで、次のような部分が自動化されます。
- Control Planeの構築・冗長化・バージョン管理
- Nodeの用意やアップグレード
- GCPの他サービス（ネットワーク・監視・認証）との連携
利用者はKubernetesのリソース（DeploymentやServiceなど）を宣言することに集中でき、その土台の面倒を見る部分をGKEに任せられます。
GKE StandardとAutopilotの違い
GKEには、Nodeをどこまで自分で管理するかで2つの運用モードがあります。
flowchart TB
subgraph Standard["Standard cluster"]
Deploy["Deployment"]
CP["Control Plane"]
subgraph UserArea["利用者が設定する場所"]
subgraph Node["Node"]
Pod["Pod"]
end
end
Deploy -->|"宣言を渡す"| CP
CP -->|"Podを配置・監視"| Pod
end
flowchart TB
subgraph Autopilot["Autopilot cluster"]
Deploy["Deployment"]
CP["Control Plane"]
subgraph Managed["GKEが管理する場所"]
subgraph Node["Node"]
Pod["Pod"]
end
end
Deploy -->|"宣言を渡す"| CP
CP -->|"Podを配置・監視"| Pod
end
- Standard
- Nodeを自分で管理するモード。Nodeの数・マシンタイプ・Node Poolの構成を自分で決める。細かく制御したい場合に向く
- Autopilot
- Nodeの管理をGKEに任せるモード。Podを動かすのに必要なリソースはGKEが自動で用意し、利用者はNodeを意識しない。運用をできるだけ任せたい場合に向く
どちらも中身はKubernetesで、動かすワークロード（DeploymentやPod）の書き方は基本的に同じです。違いは「Nodeという土台を自分で握るか、任せるか」です。まず任せて始めたいならAutopilot、Nodeレベルの制御が必要ならStandard、という選び方になります。
StandardではNode Poolでノードをまとめて管理する
Node Poolは、StandardでNodeをどう用意するかを決める設定単位です。Kubernetesの概要図で出てきたCluster・Control Plane・Node・Podの関係が変わるわけではなく、GKEでNodeをまとめて作成・更新・増減するための管理単位がNode Poolです。
前提として、Podはアプリケーションが実際に動く最小単位です。DeploymentやReplicaSetは、このPodを何個動かすかを維持します。
一方で、NodeはPodを動かすためのマシンです。NodeにはCPUやメモリの容量があるため、Podを増やしたくても、載せるNodeに空きがなければ動かせません。
ここで出てくるのがNode Poolです。Node Poolは、Nodeを用途や設定ごとにまとめて用意するための単位です。
Node Poolがない図として見ると、Clusterの中にNodeがそのまま並びます。
flowchart TB
subgraph Cluster["Cluster"]
CP["Control Plane"]
subgraph Node1["Node"]
Pod1["Pod"]
Pod2["Pod"]
end
subgraph Node2["Node"]
Pod3["Pod"]
Pod4["Pod"]
end
CP -->|"配置・監視"| Node1
CP -->|"配置・監視"| Node2
end
Node Poolを加えると、Nodeそのものの位置づけは変わりません。Clusterの中にあるNodeを「通常処理用」「GPU処理用」のようなまとまりで扱えるようになります。
flowchart TB
subgraph Cluster["GKE Cluster"]
CP["Control Plane"]
subgraph PoolA["Node Pool（通常処理用）"]
subgraph NodeA1["Node"]
PodA1["Pod"]
PodA2["Pod"]
end
subgraph NodeA2["Node"]
PodA3["Pod"]
PodA4["Pod"]
end
end
subgraph PoolB["Node Pool（GPU処理用）"]
subgraph NodeB1["Node"]
PodB1["Pod"]
PodB2["Pod"]
end
end
CP -->|"配置・監視"| NodeA1
CP -->|"配置・監視"| NodeA2
CP -->|"配置・監視"| NodeB1
end
用途に応じて複数のNode Poolを持たせることもできます。たとえば、一般的な処理用のNode Poolと、GPUが必要な処理用のNode Poolを分ける、といった構成です。Podの数はDeploymentやReplicaSetが管理しますが、そのPodを載せるNodeの種類・台数・更新設定はNode Poolでまとめて管理します。
Node Poolを用意するメリットは、Nodeを1台ずつ個別に扱わず、用途ごとのまとまりで運用できることです。
- 用途別にNodeを分けられる
- 通常処理用、GPU処理用、メモリ多めの処理用のように、Podを載せる土台を分けられる
- スケール範囲を分けられる
- 通常処理用は2〜10台、GPU処理用は0〜2台のように、Node Poolごとに増減の範囲を変えられる
- 更新や入れ替えの単位を分けられる
- すべてのNodeを同じ扱いにせず、用途ごとのNode Pool単位で更新計画を考えられる
3種類のオートスケール
GKE（Kubernetes）のオートスケールは3種類あり、それぞれ増やす対象が違います。ここが混ざりやすいので、何を増やすのかで区別します。
flowchart LR
subgraph Before["Before"]
B1["Pod"]
B2["Pod"]
end
subgraph After["After"]
A1["Pod"]
A2["Pod"]
A3["Pod"]
A4["Pod"]
end
Before -->|"HPA\nPod数を増やす"| After
flowchart LR
subgraph Before["Before"]
BPod["Pod\nCPU: 500m\nMemory: 512Mi"]
end
subgraph After["After"]
APod["Pod\nCPU: 1\nMemory: 1Gi"]
end
Before -->|"VPA\nPod 1個あたりを大きくする"| After
flowchart LR
subgraph Before["Before"]
subgraph BNode1["Node"]
BPod1["Pod"]
end
subgraph BNode2["Node"]
BPod2["Pod"]
end
end
subgraph After["After"]
subgraph ANode1["Node"]
APod1["Pod"]
end
subgraph ANode2["Node"]
APod2["Pod"]
end
subgraph ANode3["Node"]
APod3["Pod"]
end
end
Before -->|"Cluster Autoscaler\nNodeを増やす"| After
| 仕組み | 増やす対象 | 効くケース |
|---|---|---|
| HPA（Horizontal Pod Autoscaler） | Podの数 | 負荷が増えたので、同じPodを増やして捌きたい |
| VPA（Vertical Pod Autoscaler） | Pod1個あたりのリソース | Podに割り当てるCPU・メモリが足りない／余っている |
| Cluster Autoscaler | Nodeの数 | Podを増やしたいが、載せるNodeの空きが足りない |
3つは競合するものではなく、層が違います。HPAがPodを増やそうとしても載せるNodeが足りなければ、Cluster AutoscalerがNodeを増やす、というように組み合わせて働きます。「Podを増やす（HPA）」「Podを太らせる（VPA）」「Nodeを増やす（Cluster Autoscaler）」と対象で覚えると混ざりません。
参考: GCP連携と可用性設計
ここからは、GKEそのものの基本構造から少し広げて、GCP上でGKEを使うときに出てくる連携機能とロケーション設計を整理します。GKEの中心はKubernetesのマネージド運用ですが、実運用では認証・監視・可用性もあわせて考える必要があります。
Workload IdentityでGoogle APIに認証する
Kubernetes上のアプリが、Cloud StorageやPub/SubといったGCPのサービスを呼ぶには、GCPに対する認証が必要です。素朴にやると、サービスアカウントの鍵ファイルをPodに配ることになりますが、鍵ファイルは漏洩リスクがあり、管理も面倒です。
Workload Identityは、この鍵ファイルの配布をなくす仕組みです。KubernetesのサービスアカウントとGCPのサービスアカウントを対応づけ、Podは鍵ファイルを持たずにGCPのAPIを呼べます。鍵の発行・配布・ローテーションといった運用が不要になり、漏洩リスクも下げられるのが利点です。
GCP全体での認証・権限管理の位置づけは『GCPセキュリティ設計の全体像: 入口・権限・秘密情報・鍵・データ境界で考える』で扱っています。
Cloud Logging／Monitoring連携
GKEは、GCPの監視サービスと標準で連携します。
- Cloud Logging
- Pod（コンテナ）の標準出力などのログが集約される
- Cloud Monitoring
- NodeやPodのCPU・メモリ使用量などのメトリクスが収集される
自前でログ収集や監視の基盤を組まなくても、クラスタの状態やアプリのログをGCP上で確認できます。前述のHPAが参照する負荷の指標も、この監視の仕組みとつながっています。
可用性を高めるロケーション設計
GKEのClusterは、Control PlaneやNodeをどのロケーションに配置するかで可用性が変わります。1つのゾーンに寄せるzonal clusterに対し、複数ゾーンにまたがるregional clusterにすると、ゾーン障害に強くなります。
flowchart LR
subgraph Zonal["zonal cluster"]
ZCP["Control Plane"]
subgraph ZZones["zones"]
direction TB
subgraph ZoneA["zone-a"]
ZA1["Node"]
ZA2["Node"]
end
subgraph ZoneB["zone-b（Nodeなし）"]
ZBBlank[" "]
end
subgraph ZoneC["zone-c（Nodeなし）"]
ZCBlank[" "]
end
end
ZCP --> ZA1
ZCP --> ZA2
end
style ZBBlank fill:transparent,stroke:transparent,color:transparent
style ZCBlank fill:transparent,stroke:transparent,color:transparent
flowchart LR
subgraph Regional["regional cluster"]
RCP["Regional Control Plane"]
subgraph RZones["zones"]
direction TB
subgraph RZoneA["zone-a"]
RA1["Node"]
end
subgraph RZoneB["zone-b"]
RB1["Node"]
end
subgraph RZoneC["zone-c"]
RC1["Node"]
end
end
RCP --> RA1
RCP --> RB1
RCP --> RC1
end
zonal clusterは構成が単純ですが、Nodeが1つのゾーンに寄ります。regional clusterは複数ゾーンにNodeを分散できるため、1つのゾーンに障害が起きても別ゾーンのNodeで処理を続けやすくなります。
このロケーションと可用性の考え方は、GKEに限らずGCPのCompute全体で共通するため、『Compute可用性設計: GCPのRegional MIG・GKE regional cluster・複数region backendで考える』で扱っています。
ここで扱っているregional clusterは、1つのGKE Clusterを複数ゾーンにまたがって配置する話です。複数regionにGKE Clusterを分ける構成とは別の論点です。regional clusterと複数regionのGKE Cluster構成の違いは『GKE Fleet・マルチクラスタGKE・MCSの関係まとめ』で扱っています。
まとめ
GKEは素のKubernetesをGCP上で運用しやすくするマネージドサービスです。要点は以下です。
- GKEはControl Plane・Node・GCP連携の運用を肩代わりする。中身はKubernetesそのもの
- StandardはNodeを自分で管理し、AutopilotはNode管理をGKEに任せる
- StandardではNode Poolを使い、Nodeの種類・台数・更新設定をプール単位で管理する
- オートスケールは、HPA（Pod数）・VPA（Podのリソース）・Cluster Autoscaler（Node数）の3種類で対象が違う
- Workload IdentityやCloud Logging／Monitoringは、GCP上でGKEを使うときの連携機能として押さえる
- zonal clusterとregional clusterでは、Nodeをどのゾーンに置くかによって可用性の考え方が変わる