コンテナオーケストレーションツールの“事実上の標準”という座をつかんだ「Kubernetes」。その重要性とは? | 東京エレクトロンデバイス

Publickey新野淳一IT羅針盤

コンテナオーケストレーションツールの“事実上の標準”という座をつかんだ「Kubernetes」。その重要性とは?

数多くのソフトウェアが名乗りを上げていたDockerコンテナのオーケストレーションツールの覇権争いですが、「Kubernetes」が事実上の標準の座を獲得することで、その決着を見ました。オーケストレーションツールとはいかなるもので、そして、なぜ重要なのでしょうか?

Dockerに代表されるコンテナ型仮想化では、コンテナエンジンの分野でDockerがほぼ一強である一方、コンテナオーケストレーションの分野では標準の座をめぐり、多くのツールがしのぎを削ってきました。

しかし、その状況にも決着がつきました。Googleが開発し、オープンソース化されたKubernetesが、コンテナオーケストレーションの事実上の標準の座を勝ち取ったのです。

なぜ多くのツールがコンテナオーケストレーションの覇権を争ったのでしょうか。そもそもコンテナオーケストレーションとは何なのでしょうか。

Kubernetes
Kubernetesの公式サイト

ピンチアウトで拡大

Dockerコンテナはまず軽量さが注目された

Dockerに代表されるコンテナ型仮想化が最初に注目されたのは、仮想マシンを扱うよりも軽量かつ迅速に、アプリケーションの実行環境を丸ごと別のマシンへ持ち運ぶことができるという特長のためでした。

多くの開発者がこの機能を利用して、手元のPC上にDockerコンテナ環境を構築し、コンテナごとにテスト環境や本番環境へ移動することを始めました。これにより、開発環境ではちゃんと動いていたのに実行環境では微妙にライブラリやOSのバージョンが違うので動かない、といったことなどが避けられるようになったのです。

多数のコンテナの運用管理を担うのがオーケストレーションツール

Dockerコンテナが本番環境に浸透し始めると、そのコンテナの運用管理をしなくてはならなくなります。

例えばコンテナ化したアプリケーションを何台ものサーバーへ展開するのは手間になり、複数のサーバーへ展開したコンテナがちゃんと稼働しているかどうかを監視することも必要になります。さらに万が一、いずれかのコンテナが落ちたときに別のコンテナを起動するクラスター管理、アプリケーションへの負荷が高まったらサーバーを増やし、負荷が減ればサーバーを減らすスケーラブルな運用対応や複数コンテナへのアクセスの分配など、さまざまな処理が必要となってきます。

こうした多数のコンテナに対する運用管理作業を一般に“コンテナオーケストレーション”と呼びます。そしてKubernetesをはじめとするコンテナオーケストレーションツールは、こうした作業を自動化してくれるのです。正確な表現ではありませんが、コンテナを基盤とした分散環境を実現するOSのような位置づけと言ってもいいでしょう。

コンテナはこれからのアプリケーション基盤の本命

以前、このコラムでDockerコンテナの記事「注目を浴びるDockerコンテナ、従来の仮想化と何が違うのか?」(http://cn.teldevice.co.jp/column/detail/id/102)を書いたとき、私は記事の最後に「Dockerあるいはコンテナ型仮想化は、現在のサーバー仮想化よりも身近かつ便利な存在として広く普及することでしょう。」と書きました。

この予測通り、Dockerコンテナはクラウドアプリケーションの基盤として普及し始めているだけでなく、例えばDevOps、サーバーレス、マイクロサービスアーキテクチャといった、クラウド時代のアプリケーション開発における方法論や仕組みを実現する基盤としても重要な存在と見なされています。

平たく言えば、「これからのアプリケーション基盤としての本命がDockerコンテナ」ということです。

そして、そのDockerコンテナを本番環境で運用管理し、分散アプリケーションとして稼働させるという重要な役割を担うのが、コンテナオーケストレーションツールというわけです。

Kubernetesが事実上の標準に

クラウド時代の分散アプリケーションの基盤となるコンテナ全体をつかさどるソフトウェアというポジションを獲得すべく、さまざまなコンテナオーケストレーションツールが登場してきました。

代表的なものを挙げていくと、Dockerの「Swarm」、CoreOSの「fleet」、Rancher Labsの「Rancher」、Mesosの「Marathon」、そしてGoogleがオープンソース化した Kubernetesなどです。

しかし2017年2月、fleetを開発していたCoreOSは「Kubernetesはオープンソースのコンテナオーケストレーションのデファクトになった」と宣言して、fleetの開発を終了します。9月にはMesosとRancher Labsも相次いでKubernetesのサポートを発表しました。

そしてコンテナオーケストレーションツールの事実上の標準の座をKubernetesが獲得したことを決定づけたのは、Kubernetesの最大の競争相手であるSwarmをリリースしていたDockerが、2017年10月にDockerとKubernetesとの統合採用を発表したことでした。

さらに同年11月には、Amazon Web ServicesもKubernetesのマネージドサービスである「Amazon Elastic Container Service for Kubernetes(Amazon EKS)」(http://www.publickey1.jp/blog/17/amazon_ekskubernetesaws_reinvent_2017.html)を発表。Kubernetes が業界標準になったことを多くの人に印象づける結果となりました。

それ以前からも、Kubernetesの本家であるGoogleはKubernetesのマネージドサービスである「Google Kubernetes Engine」を提供しており、さらにMicrosoft Azureも「Azure Container Service(AKS)」を提供するなど、主要なクラウドサービスにおいてKubernetesマネージドサービスが出揃うといった状況でした。

こうして2017年末を待たずに、コンテナオーケストレーションの業界標準をめぐる戦いは幕を下ろしたのです。

DockerはコンテナオーケストレーションツールとしてKubernetesとの統合を発表した
2017年10月、DockerはコンテナオーケストレーションツールとしてKubernetesとの統合を発表した。

ピンチアウトで拡大

2018年はさらなる普及のフェーズへ

コンテナが普及し、コンテナを運用管理するオーケストレーションツールも事実上の標準が決まったことで、コンテナが本番環境で本格的に利用される状況が整ったと言えます。

Kubernetesだけでなく、さまざまなコンテナの実行環境を各クラウドベンダー、ソフトウェアベンダーが提供しています。2018年度はこうしたサービスや製品が成熟しつつ、さらに広い分野でコンテナオーケストレーションツールが利用され始めるフェーズに入っていくことでしょう。

 

IT羅針盤

※このコラムは不定期連載です。
※会社名および商標名は、それぞれの会社の商標あるいは登録商標です。

新野淳一

新野淳一Junichi Niino

ブログメディア「Publickey」( http://www.publickey1.jp/ )運営者。IT系の雑誌編集者、オンラインメディア発行人を経て独立。新しいオンラインメディアの可能性を追求。