Googleは、マネージドKubernetesをさらに抽象化したGKE Autopilotを発表した。インフラストラクチャを管理し、ワークロードの変更に対応することで、ユーザが自身のアプリケーションソフトウェアに集中できるようにしてくれる。
新たに導入されたGKE Autopilotモードでは、操作不要の完全マネージドKLubernetesエクスペリエンスを目標にしており、ユーザの意識の中でクラスタインフラストラクチャ管理をより少なく、ワークロードをより多くする。GKEクラスタを生成するこのGKE Autopilotモードは標準モードを補完する位置付けのもので、Google SREとエンジニアリングエクスペリエンスから学び、実運用で鍛え上げられたベストプラクティスに基づいてクラスタを最適化する。GKEのコントロールプレーンとクラスタの管理はすでにGoogle SREが行っているが、GKE Autopilotを導入することで、ノードのプロビジョニングやメンテナンス、ライフサイクルなども同じようにGoogle SREが管理してくれるようになる。
Googleのプロダクトマネージャで、GKE Autopilotの発案者でもあるWilliam Denniss氏に話を聞くことができた。会話の中で氏は、GKEクラスタを生成するための主要な２つのモードであるGKE AutopilotとGKEの標準モードを比較して、それぞれのアプローチのメリットとデメリットについて説明してくれた。
氏の言葉を借りれば、GKE Autopilotモードでは、Googleの持つ膨大なSREエクスペリエンスを活用することによって、変化するワークロードにクラスタとクラスタサイズを適応させている。
InfoQ: Kubernetesエコシステムは拡大していますが、Kubernetesクラスタにアプリケーションをデプロイするためには、全体としてどのようなスキルが必要なのでしょうか？また、特にこの観点において、GKE Autopilotが対処しようとしているギャップは何ですか？
William Denniss: GKE/Kubernetesを2つのAPIとして捉えるならば、次のようになります。
- Deployment、StatefulSet、Jobなどを備えたKubernetes API。このAPIにはkubectl(その他のさまざまな方法)を通じてアクセスします。
- クラスタやノードプールなどのオブジェクトを備えたGoogle Cloud / GKE API。このAPIにはgcloudおよびUIコンソール(および、その他のさまざまな方法)からでアクセスします。
GKE Autopilotで私たちが目標にしているのは、GKE APIを縮小して、 "gcloud container cluster create-auto"という、ただひとつのコールにすることです。それが実現すれば、ユーザはKubernetes APIを通じたクラスタの操作を中心に、例えばPodを使ったDeploymentの生成などを行えばよくなるので、
ユーザに必要なスキルはKubernetesのスキルになります。Kubernetes自体は簡単に使えるものではありませんが、さまざまなデプロイメント形式を効率的に実現することのできる、非常にパワフルなプラットフォームです。例えば、クラスタ化されたステートフルなデータベースなどは、Kubernetesを使わなければ実現が非常に困難になります。
GKE Autopilotを使うことで、Kubernetes以外のAPI(プロビジョンの方法、ノードやノードプールといったクラスタの管理方法)を学んだり、使用したりする必要がなくなるので、GKE特有の数多くのスキルを習得する必要もなくなり、Kuernetesのスキルに集中することができるようになります。
InfoQ: 通常のGKEと比較した場合、GKE Autopilotのためのアプリケーション開発やデプロイメントのベストプラクティスというものはあるのでしょうか？
Denniss: GKE自体でも、ユーザ自身のDIYや他のマネージドサービスを使うことに比べれば、Kubernetesクラスタのセットアップや運用を簡単でコスト効率のよいものにしてくれています。ですがGKE Autopilotは、そのGKEがすでに提供している"フルマネージド"コントロールプレーンをさらに越えて、業界のベストプラクティスの適用、ノード管理に関する全操作の排除、クラスタの効率の最大化、さらに強力なセキュリティ体制の提供、といったことを実現しているのです。
GKEの目標は、常にKubernetesの簡素化にあります。それでもなお、Kubernetesクラスタ構成のカスタマイズに関心のあるユーザは、現在の操作モードを持ったGKEを使い続けることができます。このGKEは"Standard"として、現在のGKEが提供しているものと同じフレキシビリティを今後も提供します。
InfoQ: GKE Standardに関する運用上の問題で、GKE Autopilotでは解決されているものは何ですか？
Denniss: GKE Standardは、ノードへの低レベルなアクセスを提供する、完全にコンフィギュレーション可能なプロダクトです。クラスタ管理者はノードへの完全なrootアクセスを許されているので、公式にサポートされていないような独自カスタマイズのインストールも自由にできます。これは一部のユーザには便利な機能ですし、ニーズは今後も継続すると思いますが、ノードに対する可視性が制限されるため、私たちがフルマネージドなノードを提供できないというデメリットもあります。ノードの監視や運用に関しては、ユーザが部分的に責任を負うことになるのです。
InfoQ: GKE Autopilotに適していないのは、どのようなユースケースですか？
Denniss: Autopilotでは、低レベルの管理APIをいくつか無効にしています。ノードへのrootアクセスもそのひとつです。完全にマネージドなプロダクトを提供するためなのですが、この種のアクセスが必要なワークロードは動作しません。ただし、パートナのワークロードに関しては、このようなアクセスが可能な場合があります(サポート上のリスクを発生させないソリューションである、と確認できた場合など)。
InfoQ: GKE Autopilotの実装の詳細について説明してください。
Denniss: GKE Autopilotは、Node Auto Provisioning、Cluster Autoscaler、Gatekeeper(adminワークロードを制限するため)など、GKEの持つ数多くの高度な機能を活用して構築されています。これらの機能は、今回の新しい操作モードをサポートするために若干の修正を行った、特別な"autopilotモード"で動作するのですが、GKE Standardが提供する同じビルディングブロックを使って、ユーザ自身が自動スケールGKEクラスタを独自に開発することも可能です。
GKE Autopilotは、自動スケールの完全な自動化や、当社の持つすべてのベストプラクティスの適用に、GKE Autopilot独自の機能であるノード管理(99.9パーセントのノード稼働率をSLAとして達成)と新たなPodベースの課金モデルを加えた、即時使用の可能なソリューションの提供を目的としています。
私たちの目標は当初から、Autopilotがフォークや別プロダクトではなく、GKEであることでした。これはつまり、自動スケール用に開発された多くの改良がGKE AutopilotからGKEへと、あるいは逆にGKEからGKE Autopilotへと共有される、ということです。
InfoQ: コスト面についてですが、GKE AutopilotはGKE Standardよりも常にコスト効率で勝っているのでしょうか？もしそうでないとすれば、何を注意すべきでしょうか？
Denniss: ノードのリソースはおもに、オペレーティングシステムのオーバヘッド、システムポッド(ログ、監視、DNS)、ユーザワークロード、未割当のキャパシティという４つに分割できます。GKE Standardでは、これらすべてのコンポーネントを含む全ノードが課金対象なのですが、
GKE Autopilotで課金されるのはユーザのPodのみで、その他３つのカテゴリは対象外になります。CPU単位のチャージはGKE Autopilotの方が高価ですが、ユーザが料金を支払うのは自身のPodのリソースのみである、という事実によってバランスが取れています。現時点でのノード使用率がどの程度かによって異なりますが、GKE Autopilotに移行することによってコストが下がる(大部分のユーザに当てはまると思われます)か、あるいはわずかに増加する(現在ビンパッキング(bin-packing)Kubernetesノードを多用しているユーザ)結果になると思います。これにはもちろん、コスト最適化に要する労力を含む、ソリューション全体のコストは考慮されていません。
GKE Autopilotによって、ノード運用上の負担をこれまで以上にGoogleにシフトすることで、ユーザ企業のSREチームは、Google自身のSREチームが目指しているのと同じ劣線形成長(sub-linear growth)を達成することができるのです。クラスタやインフラストラクチャの責務を任せることで、ユーザは、GKE上で動作するソフトウェアを通じたビジネス価値の創造のために、自身のベストを尽くすことが可能になります。
InfoQ: GKE Autopilotのロードマップについてコメントをお願いします。パートナエコシステムや、オープンソース化についても教えてください。
Denniss: GKE Autopilotは、GKE上で実行されているワークロードと広範な互換性を持つように設計されています。パートナのソリューションとの統合もそれに含まれます。現時点ではDataDogのログ処理と監視、GitLabのCI/CDをサポートしています。パートナのワークロードがGKE Autopilotにデプロイ可能であることを認定するプログラムがあって、パートナの参加を呼び掛けています。
GKEでは、AutopilotモードでGKEクラスタを立ち上げる方法や、クラスタをデプロイ済のワークロードに適用させる方法の概略を資料化している。