(cache) RHEL7.1でKubernetesを実体験（概要編）

はじめに

皆さん、こんにちは。レッドハットの中井です。このコラムでは、Red Hat Enterprise Linux (RHEL)やその関連製品を利用する方々に向けて、レッドハットの最新技術情報をお届けします。単なる機能の説明だけではなく、実際にインストールして試しながら学んでいける ―――― そんな内容を目指していきますので、ぜひ、RHELが動くサーバーを手元に用意して読み進めてください。

今回は、Red Hat Enterprise Linux 7.1で利用可能になった、「Kubernetes」について解説を行います。Kubernetes（「クーバーネティス」と読みます）は、複数のDockerサーバーをまとめて管理するオーケストレーションツールで、Dockerで多数のコンテナーを起動する際に、リソースの空いているサーバーを自動的に見つけて起動するなどが可能になります。

・・・おっと、そう言えば、いまさら「Dockerって何？」という読者の方はいませんよね？　Dockerについては、下記のリンク集から「Docker」のセクションを参照してください。

・RHEL7/CentOS7を満喫するための情報まとめ

RHEL Atomic Hostの登場

ところで、今回、Kubernetesを取り上げるのには理由があります。みなさんご存知のように、RHEL7では標準でDockerが利用できるようになっていますが、レッドハットでは、RHEL7とは別に「Dockerを利用するための専用ディストリビューション」として、RHEL Atomic Hostの開発を進めていました。3月上旬のRHEL7.1のリリースに合わせて、RHEL Atomic Hostもリリースされて、RHELのサブスクリプションを購入したユーザーは、RHEL Atomic Hostも選択できるようになりました。つまり、RHELのサブスクリプションを持っているユーザーは、RHEL、あるいは、RHEL Atomic Hostのどちらかを自由に選んでサーバーにインストールすることが可能です。そして、RHEL Atomic Hostで稼働するDockerをKubernetesから管理することもできます。

実は、RHEL Atomic Hostの正式リリースに先駆けて、RHELの開発拠点となるボストン・ウェストフォードのレッドハットオフィスでは、社内向けの技術トレーニングが実施されていました。各国を代表するRHELの技術者が30名ほど集まって、３日間みっちりとRHEL Atomic Host、Kubernetes、OpenShift v3などの技術解説を聞くという会です。運良く、私もこの会に参加することができて、KubernetesのアーキテクチャーやOpenShift v3との関連などをかなり深く理解することができました。そして、「ウェストフォードで学んだ内容を日本のRHELユーザーにも還元しよう！」ということで、記念すべき第1回のテーマは、Kubernetesになったというわけです。

ちなみに、3月のボストンといえば、積雪の季節です。空港で撮った写真では遠くの方に雪景色が広がっていますが、ボストンの中心部から少しはなれたウェストフォードでは、１メートル以上の雪が歩道に残っていて、日常生活はなかなか大変でした（笑）。

ボストン国際空港の景色

Kubernetesのサーバー構成

まず今回は、Kubernetesの環境で必要となるサーバー構成から紹介します。全体の構成は比較的シンプルで、1台のマスターサーバー（Kubernetes Master）から複数のノード（Minion）を管理する形になります。バックエンドのデータベースとしては、「etcd」と呼ばれる Key-Value Store（KVS）を使用します。その他には、Dockerイメージを提供するDocker Registry（レジストリーサーバー）が必要です。インターネット上のDocker Hubを利用することも可能ですが、プライベートな環境で使用する場合は、専用のレジストリーサーバーを用意しておくのがよいでしょう。

Kubernetesのサーバー構成

なお、本記事の執筆時点では、複数のマスターサーバーで負荷分散する機能は用意されていません。マスターサーバーがSPOFになるのを防止したい場合は、HeartbeatなどでActive-Standbyのクラスター構成にする必要があります。etcdについては、複数ノードによる負荷分散クラスターの構成が可能になっています。

ちなみに、「Minion（ミニオン）」というのは、ちょっとおもしろい名前ですよね。Webで検索すると映画のキャラクターが登場しますが、この黄色い生き物（？）にちなんで名づけたのは間違いないでしょう。ウェストフォードで解説していたエンジニアによると、普通であれば、「Master」に対して「Slave」というところを「Slaveは、本来の意味において、よい言葉ではない」ということで、Minionと呼ぶことにしたそうです。

Kubernetesのネットワーク構成

続いては、ネットワーク構成です。物理ネットワークの構成はとてもシンプルで、すべてのサーバーを共通の「サービスネットワーク」に接続するだけで、Kubernetesを利用することができます。ただし、それぞれのMinionで起動するコンテナーは、専用の「内部ネットワーク」に接続します。内部ネットワークは、トンネリング技術を用いて、オーバーレイ方式で用意する必要があります。下図のように、コンテナーが接続するブリッジ「docker0」が内部ネットワークを経由して相互接続される形になります。

この内部ネットワークは、Kubernetes自体が提供するものではなく、ユーザー側で事前に用意する必要がありますが、Kubernetesと組み合わせるために用意された、Flannelというツールを使うと簡単に構成することができます。その他には、Open vSwitchを使って、VXLANによるオーバーレイネットワークを構成するなども可能です。

Kubernetesのネットワーク構成

Kubernetes を利用するユーザーは、次のような経路で環境へのアクセスを行います。まず、コンテナーの起動・停止などの処理は、MasterサーバーのAPIに対して指示を行います。そして、Minionで起動したコンテナー内のサービスに対しては、Minionで稼働するProxyを経由して、内部ネットワークを通ってアクセスします。実際にコンテナーが起動している場所に関係なく、どのMinionからもアクセスできるようになります。また、Dockerから起動するコンテナーのイメージは、事前に外部のレジストリーサーバーに登録しておきます。