Cloud Kubernetes が見た目ほどベンダーに依存しないわけではない理由と、その対処法

Kubernetes はオープンソース プラットフォームです。 つまり、これはベンダーに依存しないプラットフォームであり、ある Kubernetes 実装から別の Kubernetes 実装に簡単に移行できると考えるかもしれません。

しかしそれは間違いです。 現実には、多くの Kubernetes ソリューション、特に特定のパブリック クラウドに関連付けられているソリューションは、想像するほどベンダーに依存しません。

幸いなことに、これは、ロックインを回避したい場合に、Kubernetes ホスティング ソリューションとしてパブリック クラウドを利用できないことを意味するものではありません。 可能ですが、クラウドベースの Kubernetes の利点を享受しながらも、特定のクラウド プロバイダーの Kubernetes サービスに縛られないように Kubernetes 戦略を設計する必要があります。

クラウドベースのKubernetesオプション

現在、主要なパブリック クラウドはすべて、SaaS アーキテクチャを介してホストされた Kubernetes サービスを提供しています。 Amazon には Elastic Kubernetes Service があります。 Azure は Azure Kubernetes Service を提供します。 Google は Google Kubernetes Engine を提供しています。 IBM には IBM Cloud Kubernetes Service があります。

これらのサービスは、クラウドベースのインフラストラクチャと、Kubernetes の展開と管理を自動化するソフトウェアを結合しているため、Kubernetes を迅速に導入して実行したいと考えている組織にとって魅力的なソリューションです。

クラウド Kubernetes のロックインリスク

これらのクラウド Kubernetes サービスは、特定のサービスに依存しないように見えるため、その魅力も高まります。 表面的には、ある Kubernetes SaaS プラットフォームから別のプラットフォームに移行するのは簡単そうに思えるかもしれません。 これらのプラットフォームはすべて、標準のオープンソース Kubernetes に基づいています。 これらは同じ Kubernetes ツール (kubectl など) へのアクセスを提供し、一般的に同じタイプのストレージとネットワーク構成をサポートします。 この観点から見ると、彼らはベンダーにまったく依存していないように見えます。

しかし、詳しく調べてみると、Kubernetes をホスト型サービスとして提供するパブリック クラウドは、見た目ほど柔軟で汎用的ではないことがわかります。 これらは、それらをホストするパブリック クラウドで実行されている他のサービスとさまざまな方法で統合され、依存しています。 Kubernetes クラスターを管理するために使用するクラウドごとに IAM ポリシーを作成する必要があります。 認証には、Azure Kubernetes Service の場合は Azure Active Directory など、ベンダー固有のサービスを使用することになる場合があります。 また、多くの場合、Kubernetes サービスでは厳密には必須ではないものの、アドオンや代替ツールの使用を推奨しています。 たとえば、Google Kubernetes Engine では kubectl の代わりに gke-deploy を使用するように求められますが、Elastic Kubernetes Service は Amazon 独自のツールである eksctl で使用するように設計されています。

したがって、Kubernetes をホストするためにどのクラウドを使用しても、基盤となる Kubernetes コードは同じである可能性があり、実際に試してみれば技術的には汎用ツールに固執することもできますが、最終的に使用することになるツールと構成は、ベンダーに依存しない可能性が高くなります。 これらは、使用する Kubernetes サービスに固有のものです。

たとえば、Azure Kubernetes Service から Google Kubernetes Engine に移行する場合、これは大きな障壁となります。 Kubernetes ワークロードをリフト アンド シフトできるとしても、それらをサポートするツール チェーンと構成ファイルでは同じことはできません。

クラウドKubernetesロックインを回避する

Kubernetes クラスターを展開する際にパブリック クラウドの利便性とスケーラビリティを活用したいが、ロックインは避けたい場合は、2 つの基本的なソリューションがあります。

1 つは、クラウドベースの仮想マシンを使用して独自のクラスターを手動でセットアップし、自分で管理することです。 このアプローチでは、クラウド プロバイダーの SaaS Kubernetes サービスに付属する自動化と統合は得られませんが、インフラストラクチャは得られます。 特殊なツールを使用していないため、すべてを再構築せずにクラスターをあるクラウド ホストから別のクラウド ホストに移行するのが簡単になります。 もちろん、ここでの欠点は、クラスターのセットアップと管理にかなりの手作業が必要になることです。

もう 1 つのアプローチ (より自動化され、スケーラブルなアプローチ) は、クラスターがどのクラウドに存在しているかに関係なく、Volterra のVoltStack®サービスなどのソリューションを使用してクラスターを管理することです。 この戦略では、基本的に各ベンダーのプラットフォームのクラウド固有のツールを、あらゆるパブリック クラウドで機能する集中型のコマンド アンド コントロール センターに置き換え、異なるパブリック クラウド間でクラスターを簡単に移行または複製できるようになります。 特定のパブリック クラウドにロックインされることなく、Google Kubernetes Engine や Azure Kubernetes Engine などのサービスと同じ管理性が得られます。

結論

Kubernetes はどこでどのように実行しても Kubernetes であると誤解しないでください。 さまざまなクラウドベースの Kubernetes サービス間には大きな違いがあり、Kubernetes クラスターをあるクラウドから別のクラウドに移植することが妨げられる可能性があります (各クラウドには異なるツール セットがあるため、異なるクラウド上のクラスターの管理が困難になることは言うまでもありません)。

幸いなことに、解決策があります。Volterra のVoltStackサービスのようなクラウドに依存しない Kubernetes 管理ソリューションを使用してすべてのクラスターを管理することで、特定のクラウド プロバイダへの依存から解放され、クラウドベースの Kubernetes の使いやすさを活用できるようになります。