「Kubernetes」とは何か――コンテナ型仮想化の本番利用に向けた課題：先行事例に学ぶKubernetes企業活用の現実（1）

本連載では、サービスの開発、提供のアジリティ向上の一助となることを目的として、企業における「Kubernetes」の活用について解説する。初回は、Kubernetesを使う上で前提となる「Docker」についておさらいし、Kubernetesの概要や起源、現状などを紹介する。

[藤原涼馬，リクルートテクノロジーズ]

　昨今、コンテナオーケストレーションツール「Kubernetes」に注目が集まっています。本連載「先行事例に学ぶKubernetes企業活用の現実」では、サービスの開発、提供のアジリティ向上の一助となることを目的として、企業におけるKubernetesの活用について数回にわたり解説します。

　第1回となる本稿では、Kubernetesを使う上で前提となる「Docker」についておさらいし、Kubernetesの概要や起源、現状などを紹介します。第2回では、実際に筆者が関わった事例をベースに、本番環境で活用する際に直面した課題と対応策、「最終的になぜKubernetesを活用するに至ったのか」を解説します。連載の最後には、まとめとして活用のポイントを整理します。

そもそも、Dockerとコンテナ型仮想化のメリットとは何か

　Dockerとは、Docker社の提供するオープンソースのコンテナ型仮想化ソフトウェアおよび実行環境です。独立した実行環境（＝コンテナおよびその集合）の内部にアプリケーションを構築することで、サービス開発／提供のアジリティを向上させることができます。

　サービス開発／提供のアジリティ向上というメリットが得られる理由は、主に下記3つの観点から説明できます。

1. 環境の分離
2. 高速な動作
3. Dockerのエコシステム

環境の分離

　Dockerは図1のようにアプリケーションの動作環境を「コンテナ」によって分離します。

図1　Dockerによるアプリケーションの動作環境の分離

　Dockerエンジン以下のレイヤーはコンテナ間で共有しつつ、アプリケーションバイナリの動作に必要なライブラリ環境を分離しています。これによって他のアプリケーションの動作環境から影響を受ける可能性を取り除きます。

高速な動作

　動作環境を分離するという意味では、ハイパーバイザーを用いたサーバ型仮想化でも同様のことが実現できることにお気付きの方もいるかもしれません。両者の違いは、「どこで動作環境を分離しているか」という点にあります。

図2　Dockerによるコンテナ型仮想化（左）とハイパーバイザーを用いたサーバ型仮想化（右）

　サーバ型仮想化では、OS（Linuxカーネルなど）も含めて分離しているため、起動、停止の際にはOSの起動・停止プロセスが含まれます。一方コンテナ型仮想化では、アプリケーションバイナリの実行に必要なライブラリの部分で動作環境が分離されているため、OSの起動・停止プロセスが含まれません。短時間の「独立した動作環境の確保・破棄」「アプリケーションバイナリの起動・停止」が可能になっています。

Dockerのエコシステム

　ここまでで述べた1.と2.のアジリティ向上のポイントは、技術的にはDocker以外の他のコンテナ型仮想化ソフトウェア――「chroot」「jail」「Solaris Containers」「LXC（Linux Containers）」などでも実現できます（LXCに至ってはかつてDocker自体で利用されていました）。では、なぜDockerばかりが注目されたのでしょうか。大きな違いはエコシステムにあります。

　Dockerの提供するエコシステムには主に「コンテナイメージの配布方法の標準化」「コンテナイメージの構築方法の標準化」の2つのポイントがあります。

• コンテナイメージの配布方法の標準化

　Dockerでは、コンテナイメージを配布するための仕組みとしてDocker Hubが提供されています。

図3　Docker Hubの検索ページ

　Docker Hubにアカウントを作り、コンテナイメージをアップロードすれば、世界中の人に利用してもらえます。また、プライベートレジストリを独自に構築し組織内部に閉じた形でコンテナイメージを共有することも可能です。

• コンテナイメージの構築方法の標準化

　Dockerでは、“どうやってコンテナイメージを構築するか”のDSL（Domain Specific Language）も定義されています。一般には「Dockerfile」と呼ばれ、図4のサンプルが示すように、テキストで記述されています。GitHubなどのリポジトリサービスを介してDockerfileを公開することで、コンテナイメージの構築手順をテキストベースで共有できるようになっています。

図4　Dockerfileの例

コンテナ型仮想化の本番活用に向けた課題

　Dockerとそのエコシステムを用いることで、アプリケーションの動作環境の構築を簡略化できるとともに、ネットワークを介してあちらこちらに動作環境を展開できるようになりました。この結果、このような仕組みを「本番環境で活用しよう」とするのは自然なことだと思います。

　しかし、Docker単独では本番環境で動かすのに困難な問題が幾つか存在します。例えば100台のDockerホスト（Dockerを導入済みのサーバ）があり、この上に本番サービスをデプロイすることを考えてみます。その際、次のような課題が生じます。

1. 複数のDockerホストをどう管理するか
2. どのDockerホストにコンテナ（アプリケーション）を立ち上げるか
3. コンテナのデプロイ方法をどう定義するか
4. 複数のコンテナ間の連携をどう実現するか
5. コンテナの死活監視をどうするか
6. コンテナの保持するデータをどう管理するか
7. 外部ネットワークからコンテナへのアクセス経路をどう設定するか

　これらの課題に対する解決策としてKubernetesに注目が集まり、その活用が進みつつあるのです。

Kubernetesとは

　Kubernetesはオープンソースの「コンテナオーケストレーション」ツールです。公式サイトのトップページにおいてもそう明示されていますが、「コンテナオーケストレーション」には明確な定義がまだありません。そこで本連載では、コンテナオーケストレーションを「コンテナ型仮想化を本番環境で活用するために必要な機能を提供すること」と定義します。

図5　Kubernetes公式サイトのトップページ

　実際Kubernetesには、コンテナ型仮想化を本番環境で活用する際の課題に対応するさまざまな機能があります。

　一方でコンテナオーケストレーションツールはKubernetesだけではなく、Docker社が開発した「SwarmKit」や、「Apache Mesos」、Rancher Labsの「Cattle」、既に開発は停止していますがCoreOSの「fleet」などの競合が存在します。では、なぜKubernetesに注目が集まっているのでしょうか。

　それには2つの大きな理由が存在します。1つはKubernetesの起源、もう1つは現時点でKubernetesを取り巻く現状です。

Kubernetesの起源

　Kubernetesの起源をたどる際には、Googleのエンジニアが執筆したサービス管理に関する有名な論文が参考になります。この論文では、「Googleのサービスは、クラスタマネジャー『Borg』上で動作するコンテナを用いて提供されており、Borgと同様の仕組み（＋Borgにおける反省を踏まえた対応策）を備えたオープンソースソフトウェアとしてKubernetesを開発した」旨が記載されています。

　Googleのサービスを支えている基盤と同様の仕組みを備えていることから、「KubernetesはGoogleで既にその有効性を実証済みである」という意味で大きな注目を浴びたといえるでしょう。

Kubernetesを取り巻く現状

　しかし事例があるのみでは、活用はなかなか広まりづらいものです。Kuberenetesを本格的に活用しようという機運が2017年から急速に高まっている理由は、主に次に挙げるようなものと思われます。

1. パブリッククラウドによるKubernetesのマネージドサービス提供
2. DockerとKubernetesの統合
3. CNCF（Cloud Native Computing Foundation）を中心としたベンダー中立な開発体制

・パブリッククラウドによるKubernetesのマネージドサービス提供

　2018年2月時点で、既に世界でのシェアが多いパブリッククラウドサービス（Amazon Web Service（AWS）、Microsoft Azure、Google Cloud Platformなど）が相次いでKubernetesのマネージドサービスをリリースしています（プレビューを含む）。これまでは「Kubernetesは環境の構築・維持の手間が大きい」という問題がありましたが、パブリッククラウドでマネージドサービスが提供されたことで以前と比較すると容易に利用を開始できるようになりました。

・DockerとKubernetesの統合

　Kubernetesについては、概念の理解などの点で非常に学習コストが高いことも問題でした。また、先に述べたように環境構築の手間が大きいことが、知識習得に向けたハードルを上げてしまっていました（ローカルでの学習用に「minikube」などのツールは提供されていましたが）。

　しかし、現在は「Docker for Mac with Kubernetes」「Docker for Windows Desktop with Kubernetes」という形で、DockerとKubernetesの統合が進んでいます。これによってKubernetesについて学習、理解するためのハードルが大幅に下がり、今後一挙に多くのエンジニアが活用できるようになる可能性が出てきています。

・CNCFを中心としたベンダー中立な開発体制

　KubernetesはCNCFによって開発が主導されています。CNCFでは、AWSやMicrosoft、Googleといった大手クラウドベンダーだけではなく、競合となるコンテナオーケストレーションツールの開発元（Docker、Mesosphereなど）も参加しています。特定のベンダーのみに依存せずにオープンな形での議論と開発が進められており、開発元の都合で突然利用できなくなるといったリスクが少なくなっています。

　このような状況から、コンテナオーケストレーションのデファクトスタンダードとしてKubernetesが抜きん出ていることが理解できると思います。

次回は、「なぜKubernetesを活用するに至ったのか」

　今回は、Dockerについておさらいし、Kubernetesの概要や起源、現状などを紹介しました。下記4つの内容について覚えておいてください。

1. コンテナ型仮想化によってサービス開発、提供の迅速化が実現できる
2. コンテナ型仮想化技術を本番環境で活用するには、コンテナオーケストレーションツールが必要である
3. コンテナオーケストレーションツールはKubernetesが現時点でのデファクトスタンダードである
4. マネージドサービスやDockerとの統合により、Kubernetes活用のハードルは下がりつつある

　次回は、筆者がコンテナをベースとしたサービス開発に取り組む中で検討した事項や、なぜ最終的にKubernetesを活用するに至ったのかを解説します。

筆者紹介

藤原 涼馬

リクルートテクノロジーズ ITソリューション統括部 サイトリライアビリティエンジニアリング部　クラウドグループ所属

ユーザー系SIerでのR＆D業務を経て2016年から現職。前職ではシステムの性能分析系技術の研究開発に従事。現在は主に、リクルートグループにおけるコンテナ仮想化をベースとしたシステムの設計・構築・運用に従事。

コンテナ管理ツール「Rancher」のコミュニティー（Rancher JP）のコアメンバーも務める。