コンテナのオーケストレーションといえば、Googleが開発したオープンソースのツールKubernetesが今や事実上のデフォルトスタンダードになってしまったようだ。だから今日Dockerが、コペンハーゲンで行われたDockerCon EuropeでKubernetesのネイティブサポートを発表したことには、誰も驚かないだろう。
同社独自のオーケストレーションツールDocker Swarmを完全に放棄したわけではないが、今回初めてKubernetesのネイティブサポートを提供したということは、今やそのユーザー数がとても多いから、コンテナ企業である以上、サポートせざるをえないのだ。ただしDockerの場合は、ユーザーがランタイムにオーケストレーションエンジンを選択できる。DockerのプロダクトマネージャーBanjot Chananaによると、毎回SwarmかKubernetesかどちらかを選べるが、コードを替える必要はない。
これまでも、DockerでKubernetesを使うことはできたが、それは必ずしも容易ではなかった。今回発表されたKubernetesのサポートにより、Docker Enterprise EditionとDocker Developer Editionのどちらのユーザーにとっても、それがずっと単純になったはずだ。
Chananaによると、Dockerのアーキテクチャのおかげで、KubernetesとDocker Swarmの併用はそれほど難しくなく、違和感もない。Dockerは顧客に、プログラムのコンテナを作るための標準的な方法を提供している。それはDevOpsモデルでは通常、デベロッパーの担当になる。
一方オペレーションの方は、コンテナのライフサイクルの間にそのデプロイとセキュリティと管理を担当し、そのためにコンテナオーケストレーションツールを使用する。最近の2年間でAWS, Oracle, Microsoft, VMwareとPivotalなどのビッグネームがこぞってKubernetesを採用し、彼らはオープンソースのKubernetesプロジェクトの拠点であるCloud Native Computing Foundationにも参加した。それによりデフォルトスタンダードとしてのKubernetesの地位が、いよいよ確定した。
これだけの企業がKubernetesバスに乗り込んでしまったからには、Dockerも顧客の要望に従わざるをえない。Dockerはこれまで、自社のオーケストレーションツールを使いながらKubernetesをサポートすることもできていたが、でも今後は、大多数のコンテナワークロードでKubernetesが選ばれることが、確実になってきた。
なお、今週のThe Informationの記事によると、GoogleはKubernetesを開発していた2014年に、Dockerをコラボレーションに誘（さそ）っている。でも当時DockerはSwarmを選び、そしてGoogleはCloud Native Computing Foundationへと向かった。今日の発表は、まさに円が閉じたようであり、これからはDockerも、（コードはホストしないけれど）Kubernetesをサポートしていくことになる。
