Kubernetes ベースのハイブリッド クラウドの長所と短所

ハイブリッド クラウド プラットフォームは現在、Kubernetes ベースのクラウド プラットフォームと非 Kubernetes ベースのクラウド プラットフォームの 2 つのカテゴリに分かれています。したがって、これは、組織がオンプレミスまたはホストされたインフラストラクチャをパブリック クラウドと統合するアーキテクチャを構築するときに行う必要がある基本的な決定です。

[[386877]]

Kubernetesとハイブリッドクラウド

もちろん、オープンソースのコンテナ オーケストレーター Kubernetes は単なるハイブリッド クラウド プラットフォームではありません。これは、オンプレミスのインフラストラクチャやパブリック クラウド、またはその組み合わせでアプリケーションを実行する方法であり、特にコンテナーで実行されるアプリケーションを実行します。ハイブリッド クラウド アーキテクチャのサポートは、Kubernetes プロジェクトの焦点では​​ありません。

それでも、Kubernetes はハイブリッド展開に重要な利点を提供します。アプリケーションが実行されるインフラストラクチャに関係なく、アプリケーションを統一された方法で展開および管理できます。これは、基盤となるインフラストラクチャをアプリケーション環境から抽象化することによって実現されます。組織が Kubernetes 上にアプリケーションをデプロイする場合、パブリック クラウド、ホストされたデータ センター、またはテスト用のラップトップ上のいずれであっても、プロセスは基本的に同じです。

また、Kubernetes は複数の種類のインフラストラクチャにわたるアプリケーション環境を同時に管理できるため、組織のサーバーとアプリケーションの一部がパブリック クラウドで実行され、その他がオンプレミスまたはコロケーション施設で実行される場合でも、一貫した展開と管理のエクスペリエンスを提供します。

Kubernetes ベースのハイブリッド プラットフォーム

これを認識して、過去数年間にいくつかのベンダーが Kubernetes ファーストのハイブリッド クラウド アプローチを採用してきました。最も顕著な例は Google Anthos です。これは、Google Kubernetes Engine を使用して、あらゆるパブリック クラウドまたはプライベート データ センターで実行されているクラスタを管理します。 VMware の Tanzu プラットフォームもその 1 つです。

AWS の EKS Anywhere は、Amazon の Elastic Kubernetes Service を通じてオンプレミスのクラスター (および他のパブリッククラウドで実行されている可能性のあるクラスター) を管理でき、ハイブリッドクラウド プラットフォームとしても使用できます。これは、より幅広いハイブリッドサービスを提供する AWS Outposts という AWS の主なハイブリッドソリューションではありませんが、EKS Anywhere が複数のホスティング環境にわたるコンテナ化されたアプリケーションのデプロイメントをサポートする限り、ハイブリッドクラウドの要件を満たしています。

Kubernetes ベースのハイブリッド プラットフォームには、AWS Outposts、Azure Stack、Azure Arc も含まれており、ハイブリッド クラウド管理の基盤として他のテクノロジを使用します。また、ハイブリッド アーキテクチャを通じて Kubernetes のデプロイメントもサポートしていますが、基盤となるハイブリッド環境の管理レイヤーとして Kubernetes は使用していません。

ハイブリッドクラウドでKubernetesを選択しない理由

あるハイブリッド クラウド アプローチは他のアプローチよりも優れていますか?それはいくつかの変数に依存します。

最も重要なのは、パブリック クラウドの標準ツールではなく Kubernetes を通じてワークロードを管理することを好むかどうかです。 Anthos や Tanzu などのプラットフォームは Kubernetes を使用してすべてをオーケストレーションしますが、Outposts や Azure Stack などのソリューションはネイティブ管理ツール (CloudWatch、CloudTrail、CloudFormation など) を使用してアプリケーションの展開と管理を行います。アプリケーションの展開と管理に Kubernetes アプローチを採用する場合は、Kubernetes ベースのハイブリッド クラウド プラットフォームの方が適している可能性があります。

考慮すべき 2 番目の要素は、アプリケーションがコンテナ化される程度です。 Kubernetes はコンテナだけでなく仮想マシンも管理できます。実際、仮想マシン オーケストレーションは Tanzu と Anthos の主な機能です。しかし、結局のところ、何よりもまずコンテナをオーケストレーションするために設計された Kubernetes 内で VM を管理するのは奇妙に感じるかもしれません。仮想マシンは通常、コンテナほど迅速に起動および停止しません。また、コンテナのように仮想マシンの複数のインスタンスを起動することもまれです。組織のワークロードが主に仮想マシンで構成されている場合は、Kubernetes に依存しないハイブリッド クラウド プラットフォームの方が適している可能性があります。

Kubernetes が今後も長期にわたって存続すると思うかどうかを問うのも価値があります。このプラットフォームは現在非常に人気がありますが (Google と VMware がハイブリッド戦略の基盤としてこれを選択した理由の 1 つです)、登場してからまだ 7 年しか経っていません。 Kubernetes は、長く使用される技術というよりは一時的な流行だと考える人もいます。

結局のところ、5、6年前、Kubernetes がまだ誰も名前を付けられない新しいプロジェクトだった頃、Docker は成長し続けるように見え、ツールを Docker と組み合わせることは安全な賭けのように思われ、今ではそれがどうなったかは誰もが知っています。

したがって、2015 年頃に Mesosphere に全面的に移行したように、Kubernetes ベースのハイブリッド プラットフォームにコミットすると、Mesosphere の人気がなくなったときにすべてを再構築する必要がある可能性があります。

柔軟性は考慮すべき最後の要素です。一般的に、Kubernetes をベースとしたハイブリッド クラウドは、クラウド ベンダーの独自ツールに依存するクラウドよりも柔軟性に優れています。たとえば、Azure Stack を使用している場合、AWS Outposts への移行は基本的に Azure クラウド プラットフォームから AWS クラウド プラットフォームへの移行と同等であるため、AWS Outposts への移行は困難になります。ただし、両方のプラットフォームが Kubernetes 上に構築されているため、Anthos から Tanzu への移行はシームレスではないものの、より簡単になります。

結論は

ハイブリッド クラウド戦略の一部として Kubernetes を選択するのには十分な理由があります。 Kubernetes ツールを必要とせず、Kubernetes が管理できないタイプのワークロードをサポートするプラットフォームを選択する理由もいくつかあります。