Google は、ユーザーが Kubernetes を正しく構成するのに苦労していることを認識し、導入と管理を簡素化するために新しい Autopilot サービスを導入しました。
Kubernetes について誰もが知っている 2 つのこと、1 つは、Kubernetes が非常に重要なコンテナ オーケストレーション分野で勝利を収めていること、2 つ目は、Kubernetes の複雑さが導入の障壁となり、一般的なエラーの原因となっていることです。
Kubernetesの発明者であり最大の推進者であるGoogleでさえ、この事実を認めています。「6年間の進歩にもかかわらず、Kubernetesは依然として非常に複雑です」と、Google Kubernetes Engine（GKE）のプロダクトリードであるドリュー・ブラッドストック氏は述べています。「ここ1年ほどで、多くの企業がKubernetesを導入したものの、すぐに困難に直面してしまうという状況が見られました。」
GKE は、主に Google Cloud Platform (GCP) 上で実行される Kubernetes プラットフォームですが、Anthos の一部として他のクラウドやオンプレミスでも実行されます。
これがAutopilotの根底にあります。AutopilotはGCP上で実行されている限り、GKEへのフルマネージドなデプロイメントとなります。しかし、GKEは既にマネージドサービスではないでしょうか？実はそうなのです。違いは、AutopilotはGKEよりもよりオピニオン性が高く、より自動化されている点です。
Kubernetes には、クラスタ（物理サーバーまたは仮想サーバーの集合）、ノード（個々のサーバー）、ポッド（ノード上の 1 つ以上のコンテナを表す管理単位）、そしてコンテナ自体という概念があります。GKE はクラスタレベルまで完全に管理されています。Autopilot はこれをノードとポッドにまで拡張します。
Autopilot の機能と制限を理解するには、ここを確認するのが最適です。ただし、「事前構成済み」とマークされているオプション（変更できないことを意味する）に注意してください。
本質的には、GKE リソースの購入と管理の別の方法であり、柔軟性は劣るものの利便性は向上します。Google がより多くの構成を管理するため、複数のゾーンにある Autopilot ポッドに対して 99.9% の稼働率という高い SLA が提供されます。
GKE Autopilot...ノードは自動的に管理されます
Google クラウドでは、リージョンは 3 つ以上のゾーンで構成されています。すべてのリソースを単一のゾーンに配置すると、複数のゾーンに分散するよりも耐障害性が低下しますが、フェイルオーバーを複数のリージョンに拡張することで耐障害性は最大限に高まります。Autopilot クラスタは常にゾーンではなくリージョン単位で実行されます。ゾーン単位は耐障害性に優れていますが、コストは高くなります。
Autopilot のその他の制約として、オペレーティング システムは Containerd を使用した Google 独自の「コンテナ最適化」Linux であり、Docker を使用した Linux や Windows Server ではないという点が挙げられます。ノードあたりのポッドの最大数は 32 で、標準の GKE では 110 です。
ノードへのSSHアクセスは不可能で、Autopilotノードはロックダウンされています。GPUとTPU（Tensor Processing Unit）のサポートはAutopilotでは利用できませんが、将来的にはサポートされる予定です。「SSHの削除は大きな変化でした」とBradstock氏は語りました。多少の制限はありますが、Bradstock氏によると、これは「善意から誤った設定をしてしまった人々がいた」という調査に基づいているとのことです。
お金、お金
EKSの魅力: AWSのコンテナゲームがハイブリッド化される中、Canonicalは「スナップインストールするだけ」と語る
続きを読む
料金モデルも異なり、使用されるコンピューティングエンジンインスタンス（仮想マシン）ではなく、ポッドが使用するCPU、メモリ、ストレージに基づいています。また、Autopilotクラスタごとに1時間あたり0.10ドルの料金がかかります。GKE Standardでも、クラスタごとに1時間あたり0.10ドルの料金がかかります。つまり、どちらか一方に支払うだけで、両方に支払う必要はありません。
AutopilotとGKE Standardのどちらが高価かという当然の疑問に答えるのは容易ではありません。Autopilotはある程度のプレミアムな導入であるため、綿密に最適化されたGKE Standardの導入よりもコストがかかります。「通常のGKEよりもコストが高いのは、機能面だけでなく、完全なSRE（サイト信頼性エンジニアリング）サポートとSLAサポートも受けられるからです」とブラッドストック氏は言います。
ただし、コンピューティング インスタンスの正しい仕様を予測することが難しいため十分に活用されていない GKE 標準展開では、Autopilot よりもコストがかかる可能性があります。
GKE上で動作しながらも、クラスタ、ノード、ポッドの設定をすることなくコンテナワークロードをデプロイ・実行できるCloud Runを使わない手はないだろう。「Cloud Runは優れた開発者環境です。1つのアプリでゼロから1,000までスピンアップし、またゼロに戻ることができます。まさにそれがCloud Runの狙いです」とブラッドストック氏は語る。「Autopilotは、作業量を減らしたいけれどKubernetesを使いたい、すべてを把握したい、サードパーティのスクリプトを使いたい、独自のプラットフォームを構築したいという人のためのものです。」
Autopilot の制約された環境では、アドオンとの互換性が問題になるのでしょうか? 「初日から機能しないものもあります」と Bradstock 氏は言います。ただし、Datadog モニタリングはすでにサポートされており、多くのアドオンで使用されている、すべてのノードでサービスを実行するための Kubernetes 機能である DaemonSets など、一部のサードパーティ製ツールは機能します。
ストレージ、コンピューティング、そしてネットワークの構成は、「ある程度の柔軟性と接続性を犠牲にしなければならない」と氏は語った。「しかし、サードパーティのエコシステムをその上で稼働させたいのは間違いない」
Autopilot機能により、GoogleはKubernetesの幅広い選択肢を、手動操作の多いものから少ないものまで提供できるようになります。そのトレードオフは、コストの上昇と柔軟性の低下だけでなく、企業管理者のスキル低下の可能性も伴います。ただし、企業はサードパーティで対応できる要件ではなく、ビジネス価値をもたらすものに注力すべきだという主張もあります。
Googleのエンジニアリングは、カスタマーサポートよりも評判が良い。Amazon出身のソフトウェアエンジニア、ケビン・リン氏は最近、AWSとGoogleの新規顧客としての経験について記事を書いている。
Googleは対応が遅く、対応も悪く、結局サードパーティのパートナーを紹介されたと彼は語った。「最初のオンボーディングの電話では、Googleにいくら支払う予定かということばかりが話題になった（Amazonの電話では、サービスの設計を手伝ってほしいと言われたのとは対照的だ）。Google Cloudは人間工学に基づいた設計で世界トップクラスのエンジニアを擁しているが、カスタマーサポートの評判はひどい。私の経験から見ても、このことがよくわかる」と彼は語った。
GCP がクラウド市場シェアを拡大するためには、優れたエンジニアリングだけが重要な要素ではないという証拠が必要です。®
