Kuberenetesを活用すれば、テストや本番など異なる環境で稼働させるコンテナの設定情報を一元管理できる。「一元的に管理し自動的に適用」という仕組みにより、Kuberenetesはネットワーク接続やボリューム管理などの課題も解決している。
コンテナ技術の活用により、開発者や運用管理者の負担が減り、開発環境の構築やアプリケーションを改善するスピードを向上させられます。しかし、コンテナ技術をエンタープライズのサービス提供環境で活用するには課題があります。今回は、大量のコンテナ管理や負荷分散を実現するオーケストレーションツールのデファクトスタンダードである「Kubernetes（クーバネイティス）」がなぜ必要なのか、どのように利用するのかを解説します。
Question 1
コンテナを本番運用するにはDockerだけでは不足で、Kubernetesが必要と聞きます。Kubernetesはどんな機能を持っているのでしょう。
Answer 1
1つ例を挙げましょう。コンテナ内のアプリを動かすためには設定ファイルが必要です。その設定ファイルには、データベース（DB）への接続情報やミドルウエアの設定情報などが含まれています。一方、アプリが動作する環境を1つにまとめたコンテナイメージはポータビリティーを重視するため、通常そういった環境に依存する設定は入れません。しかし、テスト環境、ステージング環境、本番環境といった様々な環境で同一の設定で動かせるわけではありません。では環境依存情報をどのようにコンテナに与えればよいのでしょう。
Dockerではそれを回避するために以下の方法がとられていました（Docker 17.06以前）。
- docker run（コンテナ作成時）時にコマンドオプションで設定ファイルを指定する
- コンテナ実行時に環境変数で設定ファイルを書き換える
どちらもコマンド実行時に指定しなければならないといういささか扱いづらいものでした。Kubernetesではこの設定ファイルをConfigMapリソースという仕組みで一元的に管理できます（Ver1.2以降 2016年3月）。これにより設定ファイルの取り扱いが非常に楽になります（図1）。その使い方は以下の通りです。
- CongfigMapリソースを設定ファイルやYAMLファイルにより作成
- KubernetesのPod（ポッド）を作成するYAMLファイル内で、上記で生成したConfigMapリソース名を指定。
Podは、KubernetesでDockerコンテナを管理するための最小単位です。1つ以上のアプリケーションコンテナのグループと、それらのコンテナの共有リソースを表すグループで、それを単位として管理することで、Dockerコンテナの使いにくさを解消することができます（図2）。
ConfigMapの仕組みにより、YAML形式のテキストファイルで設定情報を一元的に管理し、様々な環境ごとの設定をコンテナ起動時に自動で適用できるようになりました。この「一元的に管理し自動的に適用される」という仕組みは、Kubernetes全般を貫く共通のオペレーションといえます。
