BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース Kubernetesの将来 - VMか、コンテナか、ハイパーバイザか?

Kubernetesの将来 - VMか、コンテナか、ハイパーバイザか?

原文(投稿日:2019/05/25)へのリンク

Kubernetesの将来については、対立する2つのビジョンがある。Pivotalの主任技術者であるPaul Czarkowski氏は、VMがコンテナに取って代わると予測しているが、Red Hatの副社長であるJoe Fernandes氏は、VMの利用はKubernetesにとっての進化であり、コンテナを置き換えるものではない、という考えだ。さらに、Red Hatのプリンシパル・マーケティングマネージャであるChris Short氏は、Kubernetesはハイパーバイザ(hypervisor)をまさに駆逐しようとしている、と説明する。

コンテナは、ソフトウェアの構築方法やデプロイ方法は改善したものの、仮想マシンのように安全で隔離されたサンドボックスは実現できていない、とCzarkowski氏は言う。それどころか、コンテナは共有カーネルモデルに基づいて構築されているため、基本的なプロセス分離しか提供していないのだ。Kubernetesのコンポーネントの大部分はテナントを意識していないので、ネームスペースないしPodセキュリティポリシのレベルで分離を行うソフトテナンシモデルに留まっており、APIは共有コンポーネントに含まれる。

このような状況から、"ひとつの大きな共有"クラスタではなく、"多数のクラスタ"という新たなパターンが生まれました。GoogleのGKEサービスの顧客には、数十のKubernetesを所有して、複数のチームにデプロイする状況が珍しくありません。たいていの場合、開発者が、それぞれ独自のクラスタを用意します。このような振る舞いが、"Kubesprawl"の衝撃的な数に結び付いているのです。

Kzesprawl問題を解決する手段として、Czarkowski氏は、Kata ContainersのようなマイクロVMの使用に言及した。マイクロVMとは、"コンテナのような感触と動作を持ち、VMと同水準のワークロード分離とセキュリティ上のメリットを提供するような、軽量VMの標準実装を開発する、オープンソースプロジェクトとコミュニティ"である。"複数のKubernetesコントロールプレーンを用意する代わりに、この提案書では、Kata Containerと、AWS、Azure、GCP、vSphereといったシステムのVM上で動作するネストVMコンテナとを使用して、各テナントに独立した環境(Kubernetes APIを含む)を提供するのです"と、Kubersprawl氏は説明する。Czarkowski氏はこのデプロイメントを、次のような図で表現している。

出典: "The future of Kubernetes is Virtual Machines" by Paul Czarkowski

上の図では、foobarという、2つのKubernetesネームスペースがデプロイされている。それぞれのネームスペースには独自のAPI、システムサービス、Podがある。将来的にこのような、ネストしたVMによるマルチテナントクラスタが可能になれば、Kubesprawlは低減し、基盤となるインフラストラクチャを使用して、同じVM内でコンテナ以外のワークロードをホストすることが可能になる。

さらにShort氏は、"まもなく実現しそうな興味深いアイデアのひとつは、ハイパーバイザとしてKubernetesを使用することだ"とも述べている。KubeVirtKata Containersのようなツールを使って、コンテナ化できないレガシワークロードの移行を支援する方法だ。KubeVirtは仮想マシン管理用のアドオンで、Kubernetes上で仮想化ソリューションを提供する。また、KubeVirtは、簡単にコンテナ化できないレガシーアプリケーションで、自己修復や自動ロールアウト(およびロールバック)、水平スケーリングなど、Kubernetesの組み込み機能を使用可能にするものだ。Short氏は言う。

つまりこれは、仮想マシンをほとんど変更することなくコンテナ化できる、ということです。すでに計画されている開発の一部では、ハイパーバイザとしてのKubernetesが、データセンタとクラウドの状況を変え始めることでしょう。

結果的にCzarkowski氏とShort氏は、自身の意見でお互いを補完している。Czarkowski氏はKubernetesが将来的に、AWSのFirecrackerやGoogleのgVisorのような新興技術を搭載したVMになる、と考えている。一方のShort氏は、VMの将来はKubeVirtのようなツールを備えたKubernetesであり、Kubernetesと同じように、企業がレガシアプリケーションを移行する対象である、という考えだ。

Fernandes氏にとって将来的に重要なのは、コンテナがVMに取って代わることではなく、従来のVMベースのワークロードやマイクロVMといったさまざまなワークロードのオーケストレーションに、Kubernetesをいかに使用するか、という点なのだ。Kubernetesは企業のワークロードを近代化し、コンテナ、VM、さらにはベアメタル・インフラストラクチャさえも対象に含めた、ハイブリッドオペレーションを実現する。パフォーマンス上の目的からハードウェアアクセラレーションを活用する必要がある場合には、ワークロードをベアメタルインフラストラクチャ上で引き続き運用することになるだろう。あるいは、Short氏が述べているように、VM、マイクロVM、あるいはKubeVirtやKata Containersのようなツールを組み合わせて、既存のワークロードのリフト・アンド・シフトを望む企業もそうだ。

VMはコンテナに代わるものではない、とFemandes氏が考える理由はそこにある。そうではなく、VMの利用は、Kubernetesスタック内で進化を続けるのだ。2019年のトレンドはKubernetesと、より広い意味での仮想化が交差する点にあり、KubernetesはコンテナとVMによるハイブリッドなワークロードを実行できるようになるだろう。

Fernandes氏は、Kubernetesの重要な3つの傾向を挙げて、Short氏とCzarkowski氏の見解の補足を目的とした自身の記事を締め括っている。

  1. 信頼できないワークロードに対して、より厳密なマルチテナント分離を提供するために、マイクロVMをオーケストレーションするKubernetes。
  2. コンテナベースのワークロードと合わせて、従来のVMベースのワークロードを(KubeVirtによって)オーケストレーションおよびマネジメントするKubernetes。
  3. VMベース環境上のKubernetesに代わるものとして、ベアメタルサーバ上への展開が増加するKubernetesクラスタ。

Kubernetesの未来について、あなたはどう思うだろうか?

この記事に星をつける

おすすめ度
スタイル

BT