Kubernetesの未来はサーバーレス

コンテナ革命の始まりから、2 つのことが明らかになりました。まず、テクノロジー スタックのレイヤーの分離により、明確な合意、所有権、責任を伴う、明確で原則的なレイヤー化の概念が生まれました。 2 番目に、これらのレイヤーを導入することで、開発者は自分にとって重要なもの、つまりアプリケーションに集中できるようになります。

公平に言えば、これはすでに起こっており、開発者が「サーバーレス コンピューティング」アーキテクチャを採用できるように正式に設計された第 1 世代の Platform as a Service (PaaS) があります。問題は、多くの第一波の製品と同様に、重複する概念があまりにも多く、単一のモノリシックな製品に混在していたことです。第一世代の PaaS のほとんどでは、開発者エクスペリエンス、サーバーレス コンピューティング、価格モデル (リクエストベース) がすべて、不可分な全体として混在しています。その結果、サーバーレス コンピューティングを導入したいが、開発者要件 (特定のプログラミング言語など) がある、または大規模なアプリケーションに対してよりコスト効率の高い価格モデルを望んでいるユーザーは、サーバーレス コンピューティングを諦めざるを得なくなります。

[[238309]]

コンテナの開発によりすべてが変わり、開発者の要件がサーバーレス コンピューティング ランタイムから切り離されました。しかし、過去 1 年間にサーバーレス コンピューティング コンテナ インフラストラクチャが成長したことは驚くことではありません。昨年 7 月、Azure は主要なパブリック クラウドにおける最初のサーバーレス コンピューティング コンテナー製品である Azure Container Instances をリリースしました。サーバーレス コンピューティング インフラストラクチャに対するユーザーの関心の高さを見て、他のパブリック クラウドも Azure に追随し、6 か月後の RE:Invent 2017 で Fargate が発表されました。サーバーレス コンピューティング コンテナー インフラストラクチャがすべてのパブリック クラウドで利用できるようになるのは時間の問題だと思いました。

今後、少なくとも私にとっては、将来はコンテナ化され、それらのコンテナがサーバーレス コンピューティング インフラストラクチャ上で実行されるようになることがますます明らかになります。

この文脈では、当然の疑問は、「サーバーレス コンピューティングの将来において、オーケストレーションはどのようになるのでしょうか?」です。

Kubernetes は、サーバーレス コンピューティングのニーズを満たすためにコンテナを実行するために開発されたテクノロジーです。しかし実際には、低レベルでは、Kubernetes アーキテクチャ自体は単一のマシンをサポートしており、スケジューラからコントローラ マネージャーまでのコンポーネントは、Kubernetes 内のコンテナが認識可能なマシン上で実行されることを想定しています。

Azure Container Instances のようなサーバーレス コンテナー インフラストラクチャは、生のインフラストラクチャです。これはいくつかのコンテナを簡単に実行するには優れた方法ですが、複雑なシステムを構築するには、サービス、デプロイメント、シークレットなどのより高レベルの概念を導入するオーケストレーターを開発する必要があります。

これらのサーバーレス コンピューティング プラットフォーム用にまったく新しいオーケストレーターを開発することは魅力的かもしれませんが、実際には、世界は Kubernetes オーケストレーション API を中心に統合されており、既存の Kubernetes ツールとのシームレスな統合は非常に魅力的です。さらに、近い将来、ほとんどの人の Kubernetes クラスターは、専用マシンとサーバーレス コンピューティング コンテナ インフラストラクチャのハイブリッドになると予想されます。専用マシンは、比較的静的な使用量の安定したサービスや、FPGA や GPU などの特殊なハードウェアに使用され、サーバーレス コンテナーはバースト性または一時的なワークロードに使用されます。

Kubernetes とサーバーレス コンテナを組み合わせた仮想 Kubelet

Kubernetes コミュニティが直面している興味深い問題は、サーバーレス コンピューティング コンテナ インフラストラクチャと、より高レベルの Kubernetes コンセプトをどのように組み合わせるかということです。最近、オープンソースの仮想 kubelet プロジェクトの開発により、Kubernetes ノードおよびスケジューリング Special Interest Group (SIG) 内でこの議論が進みました。

その中核となる仮想 kubelet プロジェクトは、サーバーレス コンピューティング コンテナーと Kubernetes API 間のギャップを埋めることを目的としています。名前が示すように、仮想 kubelet は、Kubernetes クラスターに仮想ノードを投影する Kubernetes kubelet デーモンの代替実装です。この仮想ノードはサーバーレス コンテナ インフラストラクチャを表し、Kubernetes スケジューラに、コンテナをサーバーレス コンテナ API にスケジュールできることを認識させます。

仮想 kubelet が起動すると、Kubernetes API サーバーに自身を登録し、Kubernetes API サーバーとのハートビート プロトコルを直ちに開始して、Kubernetes に追加された仮想ノードが正常であるように見えるようにします。このプロセスは以下のスクリーンショットで確認できます。最初は、クラスター内に 3 つの実際のノードが存在する標準の Kubernetes クラスターがあります。次に、このクラスター内のコンテナとして仮想 kubelet の実行を開始し、クラスターに 4 番目のノードを追加します。この 4 番目のノードは、サーバーレス コンピューティング コンテナー インフラストラクチャを表す仮想ノードです。もちろん、このノードは実際にはかなり特別なノードであり、Azure Container Instances などのサーバーレス インフラストラクチャ上でコンテナーを実行するための最大容量を表します。

サーバーレス コンピューティング インフラストラクチャで実行されるコンテナと Kubernetes マシンで実行されるコンテナの価格と機能の違いを考慮すると、仮想 kubelet では、ユーザーが新しい仮想ノードでコンテナを実行することを明示的に選択する必要があります。これを実現するために、仮想 kubelet は Kubernetes の概念と許容範囲を使用します。追加されると、仮想ノードは Kubernetes 汚染としてマークされ、ポッドが仮想ノードに配信されなくなります。ポッドがこのサーバーレス テイントを許容する意思を示した場合にのみ、仮想ノードへのスケジュール設定が考慮されます。

ポッドがサーバーレス コンピューティング仮想ノードにスケジュールされると、仮想 kubelet はこれを認識し、サーバーレス インフラストラクチャ内に実際にコンテナを作成します。サーバーレス コンピューティング インフラストラクチャで Pod が正常に作成された後、仮想 Kubelet は、すべての API とツールが期待どおりに動作するように、ヘルスとステータス情報を Kubernetes API サーバーに報告する役割も担います。

Kubernetes とサーバーレス コンピューティング コンテナ インフラストラクチャのこの統合には、バッチ処理やバースト ワークロード向けのさまざまな実際の使用例があります。たとえば、画像処理を行っている顧客は、共有ストレージへの最近の画像のアップロードを処理するために大量のコンテナをすばやく起動し、インフラストラクチャがない状態から数百のコンテナで数秒以内に画像を処理する状態に移行し、この処理が完了するとすぐに容量の支払いに戻ることができます。これは、仮想マシン上で実行される Kubernetes クラスターとはまったく対照的です。仮想マシン上で実行される Kubernetes クラスターでは、マシンが使用されているかどうかに関係なく、マシンの実行コストは一定です。同時に、この画像処理の実際のオーケストレーションは、これらすべての画像処理コンテナをスケジュールできる Job オブジェクトなどの標準の Kubernetes 概念を使用して実装できます。

Kubernetes をサーバーレス コンテナと互換性のあるものにする

スタートアップからパブリック クラウドまで、さまざまなパートナーが参加し、サーバーレス コンテナーを Kubernetes と統合するというビジョンに貢献し、仮想 kubelet プロジェクトがクラウド コンピューティング業界で発展し、勢いを増していく様子を見るのは、とてもエキサイティングなことです。

もちろん、すべてが順調だったわけではありません。私たちと同じように

Kubernetes とサーバーレス コンピューティングの未来

Kubernetes は、開発者がマシンやマシン管理の詳細を気にせずに済む、クリーンなアプリケーション指向の API を提供するために構築されました。しかし、実際には、この API の表面の下には、まだ仕組みが残っています。サーバーレス コンテナ インフラストラクチャの開発により、これらのマシンを完全に忘れることが可能になりましたが、大規模なアプリケーションでサーバーレス コンテナをうまく使用するには、オーケストレーターの開発が必要です。したがって、Kubernetes オーケストレーション層とサーバーレス コンテナ インフラストラクチャの統合は、Kubernetes とサーバーレス インフラストラクチャの将来の成功にとって重要です。

将来的には、将来の Kubernetes クラスターは、専用マシン上で実行されるコンテナとサーバーレス コンピューティング インフラストラクチャからの脱却の組み合わせで構成されるようになると私は確信しています。しかし、将来の目的地は私の頭の中では明確ですが、そこに到達する道筋と詳細はまだ決まっていません。 Kubernetes コミュニティとオープンな議論を行えることを非常に嬉しく思います。参加にご興味がおありの場合は、仮想 kubelet github プロジェクトに参加するか、SIG-Node および SIG-Scheduling のメーリング リストまたは会議にご参加ください。次世代のコンテナ オーケストレーションを共同で構築できることを非常に嬉しく思っています。これがコンテナ化されたサーバーレスの未来です!

著者について:

Kubernetes の共同創設者である Brendan Burns 氏は、現在 Microsoft の分散エンジニアです。 Microsoft Azure クラウド コンテナーの開発、Azure コンテナーのインスタンス化、Azure クラウド シェル、およびリソース管理を主導します。ワシントン州シアトル在住。