「Kubernetes」とは何か――コンテナ型仮想化の本番利用に向けた課題:先行事例に学ぶKubernetes企業活用の現実(1)
本連載では、サービスの開発、提供のアジリティ向上の一助となることを目的として、企業における「Kubernetes」の活用について解説する。初回は、Kubernetesを使う上で前提となる「Docker」についておさらいし、Kubernetesの概要や起源、現状などを紹介する。
昨今、コンテナオーケストレーションツール「Kubernetes」に注目が集まっています。本連載「先行事例に学ぶKubernetes企業活用の現実」では、サービスの開発、提供のアジリティ向上の一助となることを目的として、企業におけるKubernetesの活用について数回にわたり解説します。
第1回となる本稿では、Kubernetesを使う上で前提となる「Docker」についておさらいし、Kubernetesの概要や起源、現状などを紹介します。第2回では、実際に筆者が関わった事例をベースに、本番環境で活用する際に直面した課題と対応策、「最終的になぜKubernetesを活用するに至ったのか」を解説します。連載の最後には、まとめとして活用のポイントを整理します。
そもそも、Dockerとコンテナ型仮想化のメリットとは何か
Dockerとは、Docker社の提供するオープンソースのコンテナ型仮想化ソフトウェアおよび実行環境です。独立した実行環境(=コンテナおよびその集合)の内部にアプリケーションを構築することで、サービス開発/提供のアジリティを向上させることができます。
サービス開発/提供のアジリティ向上というメリットが得られる理由は、主に下記3つの観点から説明できます。
- 環境の分離
- 高速な動作
- Dockerのエコシステム
環境の分離
Dockerは図1のようにアプリケーションの動作環境を「コンテナ」によって分離します。
Dockerエンジン以下のレイヤーはコンテナ間で共有しつつ、アプリケーションバイナリの動作に必要なライブラリ環境を分離しています。これによって他のアプリケーションの動作環境から影響を受ける可能性を取り除きます。
高速な動作
動作環境を分離するという意味では、ハイパーバイザーを用いたサーバ型仮想化でも同様のことが実現できることにお気付きの方もいるかもしれません。両者の違いは、「どこで動作環境を分離しているか」という点にあります。
サーバ型仮想化では、OS(Linuxカーネルなど)も含めて分離しているため、起動、停止の際にはOSの起動・停止プロセスが含まれます。一方コンテナ型仮想化では、アプリケーションバイナリの実行に必要なライブラリの部分で動作環境が分離されているため、OSの起動・停止プロセスが含まれません。短時間の「独立した動作環境の確保・破棄」「アプリケーションバイナリの起動・停止」が可能になっています。
Dockerのエコシステム
ここまでで述べた1.と2.のアジリティ向上のポイントは、技術的にはDocker以外の他のコンテナ型仮想化ソフトウェア――「chroot」「jail」「Solaris Containers」「LXC(Linux Containers)」などでも実現できます(LXCに至ってはかつてDocker自体で利用されていました)。では、なぜDockerばかりが注目されたのでしょうか。大きな違いはエコシステムにあります。
Dockerの提供するエコシステムには主に「コンテナイメージの配布方法の標準化」「コンテナイメージの構築方法の標準化」の2つのポイントがあります。
- コンテナイメージの配布方法の標準化
Dockerでは、コンテナイメージを配布するための仕組みとしてDocker Hubが提供されています。
Docker Hubにアカウントを作り、コンテナイメージをアップロードすれば、世界中の人に利用してもらえます。また、プライベートレジストリを独自に構築し組織内部に閉じた形でコンテナイメージを共有することも可能です。
- コンテナイメージの構築方法の標準化
Dockerでは、“どうやってコンテナイメージを構築するか”のDSL(Domain Specific Language)も定義されています。一般には「Dockerfile」と呼ばれ、図4のサンプルが示すように、テキストで記述されています。GitHubなどのリポジトリサービスを介してDockerfileを公開することで、コンテナイメージの構築手順をテキストベースで共有できるようになっています。
コンテナ型仮想化の本番活用に向けた課題
Dockerとそのエコシステムを用いることで、アプリケーションの動作環境の構築を簡略化できるとともに、ネットワークを介してあちらこちらに動作環境を展開できるようになりました。この結果、このような仕組みを「本番環境で活用しよう」とするのは自然なことだと思います。
しかし、Docker単独では本番環境で動かすのに困難な問題が幾つか存在します。例えば100台のDockerホスト(Dockerを導入済みのサーバ)があり、この上に本番サービスをデプロイすることを考えてみます。その際、次のような課題が生じます。
- 複数のDockerホストをどう管理するか
- どのDockerホストにコンテナ(アプリケーション)を立ち上げるか
- コンテナのデプロイ方法をどう定義するか
- 複数のコンテナ間の連携をどう実現するか
- コンテナの死活監視をどうするか
- コンテナの保持するデータをどう管理するか
- 外部ネットワークからコンテナへのアクセス経路をどう設定するか
これらの課題に対する解決策としてKubernetesに注目が集まり、その活用が進みつつあるのです。
Kubernetesとは
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年から急速に高まっている理由は、主に次に挙げるようなものと思われます。
- パブリッククラウドによるKubernetesのマネージドサービス提供
- DockerとKubernetesの統合
- 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つの内容について覚えておいてください。
- コンテナ型仮想化によってサービス開発、提供の迅速化が実現できる
- コンテナ型仮想化技術を本番環境で活用するには、コンテナオーケストレーションツールが必要である
- コンテナオーケストレーションツールはKubernetesが現時点でのデファクトスタンダードである
- マネージドサービスやDockerとの統合により、Kubernetes活用のハードルは下がりつつある
次回は、筆者がコンテナをベースとしたサービス開発に取り組む中で検討した事項や、なぜ最終的にKubernetesを活用するに至ったのかを解説します。
筆者紹介
藤原 涼馬
リクルートテクノロジーズ ITソリューション統括部 サイトリライアビリティエンジニアリング部 クラウドグループ所属
ユーザー系SIerでのR&D業務を経て2016年から現職。前職ではシステムの性能分析系技術の研究開発に従事。現在は主に、リクルートグループにおけるコンテナ仮想化をベースとしたシステムの設計・構築・運用に従事。
コンテナ管理ツール「Rancher」のコミュニティー(Rancher JP)のコアメンバーも務める。
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
- 米グーグルのDockerコンテナ管理サービスが一般提供開始
米グーグルがGoogle Cloud Platform上で提供しているDockerコンテナオーケストレーション/管理サービス、Google Container Engineが2015年8月26日、ベータ段階を終了、一般提供が開始された。毎週20億以上のコンテナを立ち上げているグーグルの経験に基づくサービスだとしている。 - Docker管理ツール、Kubernetes、etcd、flannel、cAdvisorの概要とインストール、基本的な使い方
数多く台頭しているDockerの運用管理に関する製品/サービスの特長、使い方を徹底解説する特集。今回は、グーグルが主導で開発しているOSSであるKubernetes、flannel、cAdvisorの概要や主な機能、環境構築方法、使い方について。 - コンテナ運用環境を標準化? CNCFは何をやろうとしているか
Cloud Native Computing Foundationは、クラウドネイティブアプリケーション開発・運用環境に関する技術の「標準化」を推進しているという。臨時エグゼクティブディレクターに、具体的な活動内容を聞いた。