コンテナオーケストレーションにどのような戦略を採用するとしても、まずは「ホスティングスペース」を綿密に計画すべきだ。ホスティングスペースとは、アプリケーションのホストに使用するリソースの全セットを指す。これには、オンプレミスのデータセンターや複数のパブリッククラウドベンダーなどが含まれる可能性がある。アプリケーションごとに、アプリケーションのコンポーネントをホストする場所など、導入作業が必要な範囲を判断する。その結果、Kubernetesの導入における操作の多様性を把握できる。

　以下に挙げる2つの要素を含んだオーケストレーション計画は、マネージドKubernetesの優れた候補になるだろう。

• クラウドベンダーを1社だけ利用する予定であり、ベンダーを変える場合は運用戦略を作り直すための準備ができている
• アプリケーションをクラウドとデータセンターの両方でホストし、両者をまたいだフェイルオーバーやバースティング（処理の補完）をほとんどまたは全く実施しない

　これに対して、マネージドKubernetesが候補にならないのは次のような場合だ。

• 複数のパブリッククラウドベンダーを利用し、異なるベンダーのクラウド間での速やかなアプリケーション移行を計画している
• オンプレミスデータセンターなど全てのホスティングリソースを、アプリケーションのコンポーネントが大規模なリソースプールとして利用できる構造を計画している

2.マルチクラウドの意義を明確にする

　大半の企業は先述の2例のどちらかに落ち着く。その場合、マルチクラウド戦略の定義が次のステップになる。静的なマルチクラウドモデルを採用する場合、アプリケーションのコンポーネントを配置するクラウドは変動しない。動的モデルを採用する場合、アプリケーションのコンポーネントを複数ベンダーのクラウド間で自由に移動できる。静的モデルと動的モデルのどちらを採用するかを選ぶとよいだろう。

　静的モデルを利用する場合、各社のパブリッククラウドに応じたマネージドKubernetesを利用するのが最も適している。だがこれはクラウドベンダーがKubernetesを管理するためのツールを用意している場合に限られる。こうしたツールには、作業を分散し、分散したプロセスを管理できる「Istio」などがある。この場合、クラウドベンダー各社のツールを利用することで、コンテナホスティング機能が向上する可能性が高い。

　動的モデルを利用する場合、クラウドベンダーが提供するマネージドKubernetesのメリットを生かせない可能性が非常に高い。この場合は各クラウドの境界を自由に横断する包括的なオーケストレーション手法が必要だ。従って、クラウドに依存しないツールを備えた独自のKubernetesオーケストレーションシステムの構築を検討すべきだ。

3.オーケストレーション方法の選択

　マネージドKubernetesをクラウド環境でホストする場合、そのクラウドのベンダー以外が提供するネイティブ機能とは連携できないだろう。つまり、マルチクラウドモデルでマネージドKubernetesを採用する場合、それぞれのパブリッククラウドでそれぞれのオーケストレーション作業が必要になる。

　Red Hatの「Red Hat OpenShift」など、Kubernetesディストリビューションを選択する場合、各クラウドにアプリケーションとKubernetesの両方を導入しなければならない。Kubernetesコンポーネントの可用性と管理基盤の連携の確保も必要になる。

　よく使われるマルチクラウドフレームワークの一つがストレージベンダーNetAppの「Stackpoint.io」だ。このフレームワークは、AWS、Microsoft、Googleというパブリッククラウドベンダー大手3社のクラウドサービスを扱える。クラウドだけでなくオンプレミスも対象に含む。Stackpoint.ioを利用することで、企業はマルチクラウド環境を扱えるKubernetes管理基盤を作成し、均一なデプロイを実行できる。

　最後に、利用しているクラウドベンダーがコンテナとKubernetesに対してどのように取り組んでいるか確認することをお勧めする。Googleはこの両方に深く関わってきたものの、2018年11月にGoogle Cloudのトップが交代したことは方向転換を示唆しているかもしれない。MicrosoftはGoogleとほぼ同程度にコンテナとKubernetesに強い関心を示しているようだ。AWSは、同社のコンテナホスティングとオーケストレーションサービスの機能強化に出遅れた。同社のマイクロ仮想マシン（VM）サービス「Firecracker」も、どちらかというと同社がVMを重視していることを示しているのかもしれない。