クラウドKubernetesが見かけほどベンダー非依存ではない理由と、その対策

F5

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クラスターをあるクラウドから別のクラウドへ移行しにくくなる可能性があります。さらに、クラウドごとに使用するツールが異なるため、複数のクラウド上にあるクラスターの管理も難しくなります。

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

著者について

F5

F5のその他のブログ記事