Kubernetesの未来はコンテナではなく仮想マシンにある

[[254590]]

Kubernetes は今年、私のキャリアにとって非常に重要であり、新年も引き続き重要になると信じています。古いものに別れを告げ、新しいものを迎えるにあたり、私の個人的な経験に基づいて大胆な予測をさせてください。Kubernetes の将来は、コンテナではなく仮想マシンにあります。

2018 年は中国の干支では戌年であり、技術的なレベルでは Kubernetes の初年でもあります。現在では、Kubernetesを学んでいる仲間もかなり増えており、各社のCIOも自社の「Kubernetes戦略」を策定すべく奮闘しています。一部の組織では、すでに Kubernetes 上で大規模な本番ワークロードの実行を開始しています。

Kubernetes 戦略を確立しようとしたばかりであれば、おそらくすでに失敗しているでしょう。これについては、次の投稿で詳しく説明します。

言い換えれば、ガートナーの Kubernetes に関する誇大宣伝サイクルの各段階で、多くの人が幻滅の谷間や絶望の罠に陥ったのです。

私はコンテナ技術の大ファンですが、コンテナ技術が消滅すると言っているわけではありません。 Docker は 2013 年に Linux コンテナ パッケージング ソリューションを導入し、アプリケーションの構築、パッケージ化、共有、展開を行うための印象的な新しい方法を示しました。継続的な配信の実現に真剣に取り組んでいる今、コンテナの成功はまさに絶好のタイミングでした。コンテナ モデルは、最新の配信パイプラインや PaaS に適しており、その後登場した CaaS プラットフォームとの互換性も高くなっています。

Google のエンジニアたちは、テクノロジー コミュニティがようやくコンテナの導入準備が整ったことも認識しました。 Google は長年コンテナ技術を使用してきました（そしてある程度は発明もしました）。彼らは Kubernetes の構築を開始しましたが、これは今では Google の社内 Borg プラットフォームに触発されたものであることがわかっており、プロジェクト自体はコミュニティ開発として運営されていました。

その後すぐに、主要なパブリック クラウド プロバイダーが Kubernetes に完全なプラットフォーム (GKE、AKS、EKS など) を提供しました。社内の担当者もすぐに独自の Kubernetes ベースのプラットフォーム (Pivotal Container Service や OpenShift など) を構築しました。

マルチテナントの悩み

しかし、まだ解決すべき厄介な問題が 1 つ残っており、これがコンテナの崩壊の根本的な原因にもなる可能性があると考えています。それは、マルチテナント メカニズムです。

Linux コンテナは、安全な分離されたサンドボックス (Solaris Zones や FreeBSD Jails など) を考慮して設計されていません。対照的に、コンテナはカーネル機能を活用して基本的なプロセス分離を提供する共有カーネル モードを使用します。ジェシー・フレイゼル氏が記事で指摘しているように、「コンテナは実際には存在しない」のです。

さらに悪いことに、ほとんどの Kubernetes コンポーネントはテナントに対応していません。名前空間と Pod セキュリティ ポリシーを使用できますが、API 自体はテナントに対応していません。さらに、kubelet や kube-proxy などの内部コンポーネントにも同じ問題が存在します。つまり、Kubernetes は「ソフト テナンシー」モデルのみを提供できます。

抽象化は漏れます。コンテナ上に構築されたプラットフォームは、コンテナ テクノロジのソフト テナントの多くを継承します。ハード マルチテナント仮想マシン (VMware、Amazon Web Services、OpenStack など) 上に構築されたプラットフォームも、このハード テナンシー メカニズムを継承します。

Kubernetes クラスター自体が「ハードテナント」にとって最大のハードルとなり、ほとんどのユーザーは「単一の共有」クラスターではなく、新たに登場した「マルチクラスター」モデルしか使用できなくなっています。 Google GKE サービスのユーザーは、多くの場合、複数のチームに数十の Kubernetes クラスターをデプロイする必要があり、開発者ごとに独自のクラスターがある場合があることに、多くの友人が気づいていると思います。この慣行は最終的に深刻な Kube 拡散問題を引き起こしました。

「この種の慣行は、最終的に深刻なKube拡散問題を引き起こした。」

一般的に、私たちが使用する最小のクラスターは 4 つのデバイス (または仮想マシン) で構成されます。 2 つのノードのうち 1 つ (高可用性の場合は 3 つ) が Kubernetes マスター ノードとして機能し、他の 3 つは Kubernetes ワーカー ノードとして機能します。これにより、資本コストが非常に高くなるだけでなく、システム リソースの大部分が長期間アイドル状態になります。

したがって、Kubernetes を何らかの方法でハード テナンシー モデルに変換する必要があります。 Kubernetes コミュニティはこの需要を明確に理解しており、専用のマルチテナント ワーキング グループを設立しました。チームはこの問題の解決に取り組んでおり、さまざまなモデルに対していくつかの改善を提案してきました。

速度を最適化した小さな VM の方が実現可能です...

Kata Containers は、軽量仮想マシンの標準実装の構築に特化したオープン ソース プロジェクトおよびコミュニティです。使用感や実行効果はコンテナと似ていますが、仮想マシンと同じワークロード分離機能とセキュリティ上の利点を提供できます。

Jessie は、Kata Containers などの仮想マシン コンテナー テクノロジの使用を推奨しています。 Kata Containers は、仮想マシン レベルの分離メカニズムとコンテナーの実行およびアクティベーション メソッドを組み合わせます。このようにして、Kubernetes は各テナント (名前空間ごとに 1 つのテナントを想定) に、ネストされた仮想マシン コンテナー (つまり、基盤となる IaaS によって提供され、仮想マシン内で実行されるコンテナー) で実行される一連の独立した Kubernetes システム サービスを提供できるようになります。

画像は Jessie Frazelle 氏による - Kubernetes におけるハード マルチテナント

これは、Kubernetes のマルチテナント問題に対する優れたソリューションです。 Jessie はさらに進んで、Kubernetes がネストされたコンテナ仮想マシンを使用して Kubernetes 上で実行されるワークロード (Pod) を処理し、それによってリソース使用率を大幅に向上させることを提案しました。

この点に関して、基盤となる IaaS またはクラウド サービス プロバイダーに適したハイパーバイザーを構築するという、より深い最適化を行うことができる方法が少なくとも 1 つあります。 VM コンテナが IaaS によって提供される抽象化の最初のレベルを表す場合、リソースの使用率をさらに最適化できます。具体的には、Kubernetes クラスターを実行するために必要な仮想マシンの数を 1 台 (高可用性の場合は 3 台) に減らし、それを使用して「スーパー ユーザー」に公開される Kubernetes コントロール プレーンをホストできます。

リソース（コスト）最適化されたマルチテナントメカニズム

2 つの名前空間と複数のアプリケーションが実行されている Kubernetes クラスターは次のようになります。

注: 同じ IaaS インフラストラクチャ上で他のクラウド ユーザーのワークロードが実行されています。これらは VM コンテナであるため、通常のクラウド VM と同じレベルの分離が実現され、最小限のリスクで同じハイパーバイザー上で実行できます。

最初はクラウド インフラストラクチャへの展開はゼロなので、スーパー ユーザーにかかるコストもゼロです。

スーパーユーザーはクラウドから Kubernetes クラスターを要求し、クラウド プロバイダーはメインの Kubernetes API とシステム サービスを実行するために単一のコンテナ VM (または高可用性のために 3 つのコンテナ VM) を作成する責任を負います。スーパーユーザーは、システム名前空間にポッドをデプロイするか、新しい名前空間を作成して他のユーザーにアクセス権を割り当てるかを選択できます。

スーパーユーザーは、foo と bar という 2 つの名前空間を作成します。 Kubernetes は、名前空間ごとに、コントロール プレーン (Kubernetes API とシステム サービス) 用にクラウドから 2 つの VM コンテナを要求します。スーパーユーザーは各ユーザーに名前空間へのアクセス権を割り当て、ワークロードのサブセット (ポッド) をデプロイできるようにします。さらに、各ユーザーのコントロール プレーンは、それらのワークロードを実行するための VM コンテナを要求します。

実行プロセス全体を通じて、スーパーユーザーは実際に消費したリソースに対してのみ料金を支払う必要があり、クラウド内でユーザーが利用できるすべての容量はクラウド サービス プロバイダーに属します。

これは実は何も新しいことではありません...

クラウド サービス プロバイダーはすでに上記の目標を達成するために懸命に取り組んでいます。オープンソース コミュニティの動向を追っている友人は、関連する兆候に気づいているはずです。 （より具体的には、これは Amazon が Fargate で実現したいと考えていることですが、公表されていません。）

最初の兆候は、kubelet をエミュレートするように設計されたオープンソース ツールである Virtual Kubelet です。 Kubernetes を他の API に接続し、Kubernetes がクラウド内のコンテナ VM スケジューラからコンテナ VM を要求できるようにします。

同様の兆候は、前述の Kata Containers、Amazon の Firecracker、Google の gvisor など、他の多くの新興仮想マシン コンテナー テクノロジにも見られます。

要約する

適切な改善を Kubernetes ハードテナンシー モデルと組み合わせることで、Kubernetes の可能性を最大限に引き出すことができます。 Kubernetes ワークロードの包括的な分離とポッドごとのコスト消費モデルにより、Kubernetes は最終的にワークロードを実行するための最良の選択肢になります。

パブリック クラウドを使用しない場合、業務システム内にインフラストラクチャ プロバイダーは存在しない (この場合、インフラストラクチャはお客様側で用意する) ため、同じ容量消費モデルを実現することはできませんが、この方法でリソース使用率を向上させ、全体的な容量要件を削減することは可能です。

また、VMware と OpenStack がこのトレンドに注目し、仮想マシン ハイパーバイザーに基づく軽量の仮想マシン コンテナ テクノロジーと理想的な Virtual Kubelet 実装ソリューションを提供してくれることを期待しています。