Google Kubernetes Engine（GKE）は、2014年11月にGoogleが発表しその後2015年に一般提供を開始した、Kubernetesをマネージドで動かすクラウドサービスである。Kubernetes自体がGoogle社内コンテナ基盤「Borg」を源流に持つため、GKEは「Kubernetesの本家本元が運営するマネージド版」と表現されることが多い。AWSのEKS（2018年）、AzureのAKS（2018年）に先んじて世に出た「マネージドKubernetesの元祖」であり、自動アップグレード、自動修復、自動スケールといった運用機能が早期から組み込まれていた。本記事ではGKEのアーキテクチャ、StandardとAutopilotの二面性、Anthosとの関係までを整理する。
この記事の目次
- Borgを起点とするKubernetesの系譜
- StandardとAutopilot、二つの運用モード
- 運用を楽にする自動化機能群
- Anthosとマルチクラウドへの広がり
- まとめ
Borgを起点とするKubernetesの系譜
GKEを語るには、Google社内で2003年頃から稼働していたコンテナオーケストレーション基盤「Borg」と、その後継研究「Omega」の存在を欠かせない。Borgは数万台規模のサーバ上でGoogle検索やGmail、YouTubeといった主要サービスを動かしてきた巨大スケジューラで、コンテナによる隔離と密パッキングという思想を初期から実装していた。Kubernetesは、このBorgで培われたアイディアを社外向けに再設計したオープンソース版として2014年6月に発表された。
Kubernetes公開直後の2014年11月にはGKEのα版が告知され、2015年8月にはGAに到達している。「Kubernetesを書いた人たちが運営するマネージドKubernetes」というブランドは強力で、AWS EKSが登場するまでの数年間、本格的なマネージドKubernetesといえばGKE一強の状況だった。Borg伝統のリソース密パッキングと運用自動化のノウハウが、ノードプールのオートスケールやアップグレード戦略に色濃く反映されている。
StandardとAutopilot、二つの運用モード
GKEには「Standardモード」と「Autopilotモード」という2つの運用形態がある。Standardは2015年以来の伝統的なモードで、利用者がノードプール（VMの集合）を自分で設計しサイズを決める。CPUやメモリ、GPU、Spot VMの活用などを細かく調整できる一方、ノード障害や容量設計の責任もユーザーが負う形だ。クラウド従量請求もVMノード単位となり、Podが空でもノードが立っていれば課金される。
2021年に登場したAutopilotは、ノードという概念をGKE側に完全に押し込め、利用者にはPodだけを見せる方針を採る。vCPU・メモリ・ディスク要求量に応じてPod単位で課金され、ノードのプロビジョニングやセキュリティパッチ適用は全自動。rootユーザーでの実行や特権コンテナといった危険な構成はマニフェスト時点で拒否され、安全側のデフォルトが強制されるのも特徴である。
運用を楽にする自動化機能群
GKEは「マネージド」を名乗るだけあって、Kubernetes素のままでは運用が大変な領域に多数の自動化機能を載せている。Cluster AutoscalerはPodのスケジューリング失敗を検知してノードを増やし、Node Auto-Provisioningはそもそも必要なマシンタイプのノードプールを自動生成する。HorizontalPodAutoscalerはレプリカ数を、VerticalPodAutoscalerはCPU・メモリ要求量を自動調整し、リクエストの波に追随する。
アップグレードはRapid、Regular、Stableという3階層の「Release Channels」から選び、月次でControl Planeが自動更新される。Workload Identityを使えば、PodにGoogle Cloud IAMの権限を直接結びつけられ、サービスアカウントキーをSecretに置く必要がなくなる。これらは「Kubernetesは便利だが運用が辛い」という伝統的な不満に対する回答であり、内製チームでvanilla Kubernetesを抱える組織と比べると工数差は無視できない。
Anthosとマルチクラウドへの広がり
GKEはGoogle Cloud内部にとどまらず、「Anthos」ブランド（現GKE Enterprise）として他クラウドやオンプレミスにも展開できる。AWSやAzureのVM上にGKE互換のクラスタを構築し、Google Cloud Consoleから一元管理する。VMware vSphere上に展開する「GKE on VMware」、ベアメタル版もラインナップされている。クラスタ間で同じKubernetesマニフェスト、同じConfig Sync、同じポリシーを適用できる点が「ハイブリッド・マルチクラウドを単一プレーンで」という訴求につながる。
ライバルのEKSやAKSも自社クラウド外への拡張を進めているが、Kubernetes本流のメンテナを多数抱えるGoogleが、Istio由来のサービスメッシュやConfigConnectorなど周辺ツールまで束ねて提案できる点はGKEならではの強みだ。Kubernetesを軸にクラウドを横断したい組織にとって、GKE/GKE Enterpriseは依然として有力な選択肢である。
まとめ
GKEはKubernetesの発祥地であるGoogleが、Borgで培ったコンテナ運用ノウハウとともに2015年から提供し続けてきたマネージドサービスである。StandardとAutopilotという二つの運用モード、豊富な自動化機能、そしてGKE Enterpriseによるマルチクラウド展開が組み合わさり、「Kubernetesを採用するならまず触ってみる選択肢」という地位を保ち続けている。コンテナ運用の労力をどこまでクラウド側に預けたいかを軸に、自社のチーム規模と相談して採用形態を選びたい。
※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。
コメント