Kubernetesとマイクロサービスの関係

CTC教育サービスはコラム「Kubernetesとマイクロサービスの関係 」を公開しました。
先日、「Kubernetes Meetup Tokyo #1」に参加して、「Exploring the Philosophy behind Docker/Kubernetes/OpenShift」というタイトルのセッションでお話をさせていただきました(*1)。Dokcer、Kubernetes、OpenShiftは、お互いに深い関係を持つソフトウェアですが、それぞれが生まれた背景、そして、それぞれが目指す世界には違いもあります。このセッションでは、このような世界観の違いを理解するポイントを紹介させていただきました。

　今回は、その中でも特に、「Kubernetesが生まれた背景」について説明したいと思います。

コンテナスケジューラーとしてのKubernetes
　Kubernetesは、Dockerが稼働する複数のサーバーを束ねて管理する、オーケストレーションツールに位置づけられます。Dockerコンテナでアプリケーションをデプロイする際に、コンテナを起動するサーバーを自動的に選び出してくれます。また、スケールアウト型のアプリケーションに対しては、複数のコンテナを起動して、自動的にロードバランスの処理を行うなどの機能もあります。サーバーの台数がそれほど多くなければ、手作業での管理も可能ですが、多数のサーバー上で複数のアプリケーションを混在して利用するとなると、このようなツールが必要になることは容易に想像ができるでしょう。

　現在、Kubernetesは、GoogleとRed Hatのエンジニアが中心となって開発が進められていますが、実は、Googleが社内のアプリケーション基盤として利用していた「Borg」と呼ばれるシステムが元になっています。Google専用に開発されたツールをオープンソースとして、より一般的な形で再実装しているというわけです。2016年の年初には、Googleのエンジニアによる「Borg, Omega, and Kubernetes」というタイトルのエッセイが公開されており、この中で、なぜGoogleではBorgを必要としたのかという理由が説明されています(*2)。

　その理由の1つは、コンテナの管理機能をAPIとして公開することで、アプリケーション開発者に対して、個々のサーバーやOSの存在を意識せずにアプリケーションの管理ができるようにすることです。サーバーリソースの割り当てをコンテナ単位で制御したり、コンテナ単位でアプリケーションの情報を取得することで、アプリケーション監視や問題判別の精度が向上したという説明がなされています。

　これは、「多数のサーバーを１つのコンピューターとして見せる」と考えると分かりやすいでしょう。１台のサーバー上で複数のプロセスへのリソース配分を制御するのは、OSのプロセススケジューラーの役割ですが、この「１つのコンピューター」上で複数のコンテナへのリソース配分を制御するのが、BorgやKubernetesの「コンテナスケジューラー」としての役割となります（図1）。

この続きは以下をご覧ください
http://www.school.ctc-g.co.jp/columns/nakai/nakai90.html