Kuberenetesを活用すれば、テストや本番など異なる環境で稼働させるコンテナの設定情報を一元管理できる。「一元的に管理し自動的に適用」という仕組みにより、Kuberenetesはネットワーク接続やボリューム管理などの課題も解決している。

 コンテナ技術の活用により、開発者や運用管理者の負担が減り、開発環境の構築やアプリケーションを改善するスピードを向上させられます。しかし、コンテナ技術をエンタープライズのサービス提供環境で活用するには課題があります。今回は、大量のコンテナ管理や負荷分散を実現するオーケストレーションツールのデファクトスタンダードである「Kubernetes(クーバネイティス)」がなぜ必要なのか、どのように利用するのかを解説します。

Question 1

 コンテナを本番運用するにはDockerだけでは不足で、Kubernetesが必要と聞きます。Kubernetesはどんな機能を持っているのでしょう。

Answer 1

 1つ例を挙げましょう。コンテナ内のアプリを動かすためには設定ファイルが必要です。その設定ファイルには、データベース(DB)への接続情報やミドルウエアの設定情報などが含まれています。一方、アプリが動作する環境を1つにまとめたコンテナイメージはポータビリティーを重視するため、通常そういった環境に依存する設定は入れません。しかし、テスト環境、ステージング環境、本番環境といった様々な環境で同一の設定で動かせるわけではありません。では環境依存情報をどのようにコンテナに与えればよいのでしょう。

 Dockerではそれを回避するために以下の方法がとられていました(Docker 17.06以前)。

  1. docker run(コンテナ作成時)時にコマンドオプションで設定ファイルを指定する
  2. コンテナ実行時に環境変数で設定ファイルを書き換える

 どちらもコマンド実行時に指定しなければならないといういささか扱いづらいものでした。Kubernetesではこの設定ファイルをConfigMapリソースという仕組みで一元的に管理できます(Ver1.2以降 2016年3月)。これにより設定ファイルの取り扱いが非常に楽になります(図1)。その使い方は以下の通りです。

図1●ConfigMapの利用イメージ
[画像のクリックで拡大表示]
  1. CongfigMapリソースを設定ファイルやYAMLファイルにより作成
  2. KubernetesのPod(ポッド)を作成するYAMLファイル内で、上記で生成したConfigMapリソース名を指定。

 Podは、KubernetesでDockerコンテナを管理するための最小単位です。1つ以上のアプリケーションコンテナのグループと、それらのコンテナの共有リソースを表すグループで、それを単位として管理することで、Dockerコンテナの使いにくさを解消することができます(図2)。

図2●Kubernetesクラスター、Node、Podの概要
[画像のクリックで拡大表示]

 ConfigMapの仕組みにより、YAML形式のテキストファイルで設定情報を一元的に管理し、様々な環境ごとの設定をコンテナ起動時に自動で適用できるようになりました。この「一元的に管理し自動的に適用される」という仕組みは、Kubernetes全般を貫く共通のオペレーションといえます。

この先は有料会員の登録が必要です。「日経SYSTEMS」定期購読者もログインしてお読みいただけます。今なら有料会員(月額プラン)が12月末まで無料!

日経 xTECHには有料記事(有料会員向けまたは定期購読者向け)、無料記事(登録会員向け)、フリー記事(誰でも閲覧可能)があります。有料記事でも、登録会員向け配信期間は登録会員への登録が必要な場合があります。有料会員と登録会員に関するFAQはこちら