ベンダー固有の構成や機能に注意

マルチクラウド環境でKubernetesサービスを最大限活用するためには

Amazon Web Services（AWS）、Microsoft、Googleの各マネージドKubernetesサービスにはそれぞれメリットがある。だが、このサービスをベンダー固有の他のツールと密接に連携させていると、ワークロードの移植を妨げる恐れがある。

公開 2018年11月09日 05時03分

更新 2019年07月08日 12時57分

著者

Kurt Marko

[TechTarget]

印刷する

マネージドKubernetesサービスは導入のハードルが低い一方で、注意すべき点も存在する

　コンテナの魅力として、ワークロードのオーケストレーション用サービスの「Kubernetes」がある。最も魅力的な側面の一つはクラウドの移植性が確保されることだが、ここには落とし穴がある。Amazon Web Services（AWS）、Microsoft、Googleが、それぞれのクラウドでアウトソーシングサービスとして提供するマネージドKubernetesサービスは、細かい構成やインタフェースがそれぞれ異なっている。マルチクラウド戦略においては、そのことがワークロードの移植の妨げになる恐れがある。

　Kubernetesはコンテナ標準規格を満たすための要素として唯一欠けていた制御パネルの役割を果たし、クラスタの構成とワークロードのデプロイを管理する。その目的は、標準規格に沿ったコントロールプレーンを用意して、コンテナ化したアプリケーションをクラウド間でそのまま移行できるようにすることだ。この考え方は「フェデレーション」と呼ばれる。フェデレーションは、Kubernetesの機能とAPIを介して提供される。

　残念ながら、現実の実装はそれほどシンプルではない。ただし、改善策は幾つかある。

併せて読みたいお薦め記事

コンテナの導入を検討する

コンテナをさらに活用するために

マルチクラウド戦略におけるフェデレーション

　マルチクラウド環境でのフェデレーションには、主に4つのメリットがある。

複数のクラウド間でワークロードを同期できる。
異なるクラスタのワークロードでバックエンドサービスを共有できる。
独立したインフラにワークロードを配置することで冗長性が保たれ、高可用性が実現する。
ワークロードを複数のクラスタ間で簡単に移行できるようにすることで、ベンダーロックインを防ぐ。

　企業がこうしたメリットを生かせるのは、運用している全てのKubernetesの構成が共通する場合に限定される。その場合は、Kubernetersのフェデレーションサポートツール「Kubefed」や、デプロイツールの「Kubernetes Anywhere」などで一元管理が可能になる。ただし多くの企業はKubernetesの習得の難しさを理由に、パブリッククラウドのベンダーが提供するマネージドKubernetesサービスを導入している。こうしたマネージドサービスは必ずしも他のベンダーのサービスとうまく連動するわけではない。特にデータベースやAI（人工知能）など、ベンダー固有の機能と連携させる際は問題になる。

　従って、マネージドKubernetesサービスが、長期的なコンテナやマルチクラウド戦略に与える影響を把握しておくことが重要になる。

Kubernetesサービスの展望

　ライバルのMicrosoftやGoogleに比べて、AWSは完全なマネージドKubernetesサービスをリリースしたのが最も遅かった。AWSの「Amazon Elastic Container Service for Kubernetes」（Amazon EKS）は、2018年6月時点では限られた数のユーザーだけに公開されているプレビュー版の段階にある。とはいえ、AWSの巨大な顧客基盤が、同サービスの最終的な人気を確実なものにするだろう。

　Microsoftは「Azure Kubernetes Service」（AKS）を、Googleは「Google Kubernetes Engine」（GKE）をそれぞれ定着させている。

　AWSはまだAmazon EKSの価格を公表していないため、これら3サービスのコストを比較するのは難しい。AKSとGKEは同様の料金体系を取っており、基盤となるインスタンスのコストを基に、Kubernetesクラスタのノードに対して課金する。コストの見積もりには、Azureの料金計算ツールと、Googleが提供する「Google Cloud Platform Pricing Calculator」がそれぞれ利用できる。

　他にも、以下のような注目すべきマネージドKubernetesサービスがある。

「Alibaba Cloud」の「Container Service for Kubernetes」
「Oracle Cloud」の「Container Engine for Kubernetes」
サードパーティー製Kubernetes管理ツール「StackPointCloud」。AWS、Google、Microsoftに加え、シンプルなクラウド基盤を提供するDigitalOcean、ベアメタル（物理）サーバのクラウドサービスを提供するPacketの計5社の製品と連携できる。
Red Hatのコンテナプラットフォーム「OpenShift」のオンライン版である「OpenShift Online」

マルチクラウド戦略の障害物と改善策

　上記のように、コンテナランタイムとKubernetes管理環境がオープンソース標準に基づいているとしても、各ベンダー固有のサービスとの依存関係により、特定のクラウド実装にロックインされる可能性がある。こうした問題を回避する方法の一つは、クラウドプラットフォームベンダーPlatform9 Systemによるマルチクラウド対応の「Platform9 Managed Kubernetes」や、上述のStackPointCloudなどのクラウドに依存しないKubernetes管理ツールを利用することだ。

　Pivotalのアプリケーションプラットフォーム「Pivotal Cloud Foundry」や、Red HatのOpenShiftのようなPaaS（Platform as a Service）を利用する方法もある。こうしたサービスは、プライベートクラウドとパブリッククラウドのどちらにおいても実行でき、抽象化層として機能するため、開発者や運用担当者のチームは実装の細かい部分について悩まされずに済む。

　Googleは、マルチKubernetes環境を実現するための手引きを、以下のように幾つか挙げている。

Kubernetesサービスを作成し公開することで、Domain Name System（DNS）による複数クラスタ間の通信を可能にする。
複数のクラスタにまたがるマルチクラウドサービスの検出を容易にするため、インフラ管理・構築支援ツールである「Consul」や「Linkerd」など、サードパーティーのシステムを活用することを検討する。
データベースなどの共用サービスには、クラスタ間で遅延の少ないプライベートネットワークを使用する。

　加えて、コンテナで使用される永続ストレージについて、実装の詳細な部分にも注意を払うと同時に、後発のブロックデバイスサービスに関してもアンテナを張り続ける必要がある。

　一般に、マルチクラウド環境におけるKubernetesのフェデレーションの中でも、特にサードパーティーツールを利用しないものは、依然として発展途上にある。実際に機能させるには、ある程度の手動による設定が必要になる。

印刷する