GKE のデフォルト運用モードになった Autopilot とその概要
Google Cloud Japan Team
※この投稿は米国時間 2023 年 4 月 6 日に、Google Cloud blog に投稿されたものの抄訳です。
Kubernetes はパワフルなツールですが、習得して使いこなすにはかなりの努力が必要です。誰もがそのメリットを活用したいと望んでいても、そのような努力が大好き、という人はいないと思います。インフラストラクチャの抽象化とスケーリングは素晴らしいものですが、手動によるノードの形状設定や、コスト最適化のための果てしないビンパッキングは誰もが避けたいと思っているはずです。
まさにこの煩雑さに対処すべく、2021 年、Google Kubernetes Engine（GKE）に導入されたのが Autopilot モードです。Autopilot は、ごく普通のユーザーにとっても Kubernetes を身近なものにするクラスタ運用モードです。当初から Autopilot モードを試している方も、まだ導入を待っている方も、かなり変化した Autopilot モードを、ここで改めて確認しておきましょう。というのも、今や Autopilot は大いに発展し、クラスタ作成インターフェースにおいて推奨されるデフォルトの GKE クラスタ運用モードとして公式に認められています。
Google が Autopilot を推奨する理由
平たく言えば、私たちはほとんどの Kubernetes ユースケースに Autopilot が最適であると確信しています。
このブログ投稿は、GKE Autopilot が推奨運用モードになった理由を詳しく探るシリーズの第 1 回です。Autopilot のメリットを最大限に活用できるよう、シリーズ全体を通してそのユースケースと実装パターンについて説明します。今回のブログ投稿では、Autopilot モードを推奨する理由を、ユーザーにとっての価値という視点から見ていきます。
要約すると、Autopilot には次のようなメリットがあります。
製品化までの時間の短縮
常時利用できる信頼性
セキュリティ体制の強化
Kubernetes の総所有コスト（TCO）の最小化
以上のメリットを一つずつ詳しく見ていきましょう。
製品化までの時間の短縮
GKE Autopilot は Kubernetes の運用とデベロッパーの作業を合理化し、その結果として構築とデプロイの時間が短縮されます。裏付けを示しましょう。Autopilot を使用している企業についてForrester Research が最近実施した分析によると、それらの企業ではデベロッパーの生産性が 45% 向上しました。つまり Autopilot を使用するチームは、Kubernetes の運用で差別化につながらない作業負担を Google に任せ、自分たちはビジネス価値をもたらすアクティビティに注力できたのです。
正確に言うと、Autopilot ではコンピューティング クラスで使用量モデルが簡略化され、デベロッパーたちは幅広いリソースとターゲット CPU プラットフォームをワークロード定義（podSpec）で直接プロビジョニングできます。必要なインフラストラクチャの起動も、必要な taint と toleration の構成も、すべて Autopilot が自動的に行ってくれるので、プラットフォーム チームはこうした作業を安心してデベロッパーに任せることができます。
Kubernetes クラスタ管理に関する深い専門知識は不要: Google は、経験が浅いチームでも簡単に Autopilot を操作できるようにしました。Autopilot クラスタは、本番環境のほとんどのユースケースに適切なデフォルト構成でプロビジョニングされます。そのため Kubernetes の学習曲線はかなり縮小され、Kubernetes をこれまで利用したことがないユーザーでも自信を持って Kubernetes を導入できます。競合プラットフォームと比べると、Autopilot を使うことで、コンテナ化されたアプリケーションを 2.6 倍の速さでデプロイできます1。
Day 2（運用段階）の運用オーバーヘッドを削減: Kubernetes ノードプールとノードは Google が管理します。もう少し掘り下げると、ノードのプロビジョニング、スケーリング、メンテナンス、セキュリティは Google SRE がお客様に代わってすべて行います。お客様のプロジェクト範囲でノードは引き続き存在しますが、ノードの管理について懸念する必要はありません。
常時利用できる信頼性
Google SRE によって支えられたワークロード SLA: GKE Standard モードで提供される卓越した SLA に加え、Autopilot モードでは Google SRE に基づく Pod（ワークロード）レベルの SLA も提供されます。Google が Autopilot クラスタ全体（コントロール プレーン、ワーカーノード、Kubernetes コア システム コンポーネント）をモニタリングすることで、お客様の Pod は常にスケジュールされます。
自動プロビジョニングと自動スケーリング: ワークロード用の最適化を通して、Autopilot はユーザーのワークロードに必要なリソースを自動的かつ適切にプロビジョニングします。ユーザーはノードのサイズや形状を考慮する必要がありません。その後、Autopilot は需要に応じてワークロードをスケーリングします。その際、HPA や VPA などのお馴染みの Kubernetes ツールが使用されます。
柔軟なメンテナンス オプション: ユーザーは引き続き、メンテナンスの時間枠と除外を柔軟に使用できます。Pod Disruption Budget と組み合わせれば、ノードのメンテナンスが行われるタイミングと方法を効果的に制御でき、不都合なサービス停止を回避できます。
これらすべてがワークロードの稼働時間と成果の向上につながります。そして重要な点として、Autopilot ではフリート全体でクラスタとノードの健全性の向上が見られます。
セキュリティ体制の強化
Kubernetes のセキュリティが手ごわい課題であることは事実です。プラットフォーム チームは、しばしば相当な時間をかけてデベロッパー向けの安全な環境を作ります。Autopilot ではセキュリティ強化バージョンの Kubernetes をそのまますぐに使用でき、適切なセキュリティ設定がデフォルトで有効になっています。これにより、攻撃対象となる領域が縮小され、CVE の影響や構成エラーが最小限に抑えられます。
強化されたデフォルト クラスタ構成: Autopilot では、強固なセキュリティ ベスト プラクティスが最初から実装されています。その中には、クラスタのセキュリティの強化で説明されている Google 推奨手法の多くが含まれています。
ノードは可視化されていますが、ワークロードやユーザーによる特権アクセスは許可されません。ノードへの root アクセスや Kubernetes の特権付きコンテナを使用する正当な理由があるユースケースは、ほとんどありません。Autopilot では初めからこれが適用されますが、許可リストに登録されたパートナー ワークロードを例外扱いできます。
シールドされたノード: GKE Autopilot のデフォルト設定では、シールドされたノードによって強力かつ検証可能なノード ID と整合性が確保され、GKE ノードのセキュリティが強化されます。
Workload Identity: Autopilot では Workload Identity をそのまますぐに使用できます。GKE 上で稼働するワークロードから安全かつ管理可能な方法で Google Cloud サービスにアクセスするには、Workload Identity の使用が推奨されます。
単一のテナント: ガバナンス要件を満たす目的で、Autopilot によってプロビジョニングされるノードはプロジェクト範囲に維持されます。これによりガバナンスの制限事項へのコンプライアンスが確保されると同時に、マルチテナント アーキテクチャよりも優れた柔軟性が備わります。
Kubernetes の TCO の最小化
従来のマネージド Kubernetes では、使用量にかかわらず、プロビジョニングされたインフラストラクチャ全体に対して課金されます。ほとんどのお客様はスケーリングに備えてクラスタをオーバープロビジョニングしますが、ノードを効率的に「ビンパッキング」しません。そのため、使用していないインフラストラクチャに対しても料金を支払うことになります。
Autopilot では、使用したものに対してのみ料金（Pod 料金）が発生します。請求額は podspec で行われたリソース リクエストに基づいて計算され、他のインフラストラクチャ費用は発生しません。ですから非効率的なビンパッキングのリスクはまったく存在しません。
最大限の利用効率: 従来のマネージド Kubernetes では、システム ワークロード用に各ノードでリソースを予約し、その料金もユーザーが支払います。Autopilot はこの無駄も排除します。Autopilot では、基盤となる VM インフラストラクチャ全体に対してではなく、ワークロード リソース リクエストに対してのみ料金が発生するためです。
運用費用の削減: すでに述べたとおり、ノードのプロビジョニング、スケーリング、メンテナンスに関して Day 0（設計段階）と Day 2（運用段階）のかなりの運用負担を Google が引き受けます。これは、既存のマネージド コントロール プレーンと Standard モードに備わるシステム リソースに追加される機能です。また、Autopilot 導入時の Kubernetes 専門知識という点でも、チームのニーズは大幅に減ります。
Kubernetes の費用を最適化するには、しばしば継続的な取り組みが必要です。なぜならワークロードのチャーンによって「ビンパッキング」が断片化されるからです。Autopilot ではお客様がビンパッキングを行う必要が一切なくなり、ビンパッキングに伴う作業のオーバーヘッドも排除されます。
Forrester Research によると、Autopilot を使用しているチームは運用コストを最大 85% 削減できます。
Autopilot で可能になることは？
手短に言えば、ほぼすべてです。
GKE Autopilot は当初から、「Autopilot は GKE である」という一つの基本原則に従っています。つまり、Google はこれまで、Autopilot が Kubernetes 仕様から分岐したり GKE 自体から逸れたりしないように、あらゆる設計上の決定を行ってきました。したがって Autopilot は Kubernetes に準拠し、ほとんどの Kubernetes ワークロードをサポートします。これには StatefulSet（ブロック ストレージ デバイスを使用）、DaemonSet（Palo Alto Networks、DataDog、Sysdig などの主なパートナー ワークロードを含む）、AI / ML 用の GPU などが含まれます。さらに、Anthos Service Mesh、IP マスカレード、Binary Authorization、OPA / Gatekeeper、Policy Controller、変更用 Webhook、Google マネージド Prometheus、ネットワーク タグをはじめ、ワークロードの実行に必要な多数の優れた機能もサポートします。
GKE Autopilot に関するこのシリーズの次回のブログ投稿では、Autopilot が役立ついくつかのユースケースを取り上げ、手こずることなく Kubernetes の力を活用する方法を明らかにする例をご紹介します。それまでの間、GKE Autopilot の導入をご検討いただき、Twitter スペースでの GKE Autopilot ライブ ディスカッションにぜひご参加ください。
1. Google Developer Experience - Competitive Benchmark Report 2022 by User Research International
- プロダクト マネージャー Victor Szalvay
- Google Kubernetes Engine、プロダクト マネージャー William Denniss
