2015/03/26 ver1.1 flannelのトンネルタイプをVXLANに修正。 2015/04/03 ver1.2 flanneldの役割を修正。参考資料を追加。

1. Red Hat Enterprise Linux 7.1
Kubernetes入門
レッドハット株式会社
中井悦司 / Etsuji Nakai
Senior Solution Architect
and Cloud Evangelist
v1.2 2015/04/03

2. 2
Red Hat Enterprise Linux 7.1 Kubernetes入門
はじめに
 Red Hat Enterprise Linux 7.1 (RHEL7.1) では、Kubernetesがサポート対象パッ
ケージとして利用可能になりました。
 この資料では、RHEL7.1の環境を前提として、Kubernetesのアーキテクチャーを
解説しています。具体的な構築・操作方法は参考資料を参照してください。
 OpenShift v3についての説明は、資料作成時点のベータ版での情報に基づいてい
います。GA版では変更される可能性もあります。

3. 3
Red Hat Enterprise Linux 7.1 Kubernetes入門
自己紹介
 中井悦司（なかいえつじ）
– Twitter @enakai00
 日々の仕事
– Senior Solution Architect and
Cloud Evangelist at Red Hat K.K.
企業システムでオープンソースの活用を希望される
お客様を全力でご支援させていただきます。
 昔とった杵柄
– 素粒子論の研究（超弦理論とか）
– 予備校講師（物理担当）
– インフラエンジニア（Unix/Linux専門）
好評発売中！

4. 4
Red Hat Enterprise Linux 7.1 Kubernetes入門
Contents
 Kubernetesのアーキテクチャー
 コンテナのデプロイ方式
 定義ファイルの例
 OpenShift v3での機能拡張
 参考資料

5. Kubernetesのアーキテクチャー

6. 6
Red Hat Enterprise Linux 7.1 Kubernetes入門
Kubernetesの基本サーバー構成
etcd
・・・
バックエンドデータベース（KVS）
Kubernetes Master
Kubernetes Node (Minion)
・・・
クラスタ構成で
負荷分散可能
Docker Docker Docker
必要に応じて
追加可能
Docker Registry
 １台のMasterから複数のNode（Minion）を管理するシンプルなアーキテクチャーです。
– 現在は、Masterを冗長化する機能はありませんので、必要に応じてActive-Standbyクラ
スターを構成します。
– バックエンドデータベース（etcd）を外出しにしておけば、IPアドレスのFailoverのみで
構わないはずです。

7. 7
Red Hat Enterprise Linux 7.1 Kubernetes入門
Kubernetesのネットワーク構成
etcd Kubernetes
Master
Docker
Registry
Overlayネットワーク
として構成
・・・
 物理的には、全サーバーを共通のサービスネットワークに接続するだけで利用可能です。
 ただし、コンテナ間通信用の内部ネットワークをoverlayネットワークとして用意する必要が
あります。
– Flannel、Open vSwitchなどでoverlayネットワークを構成します。
サービスネットワーク
192.168.122.0/24
Minion
docker0
Minion
docker0
内部ネットワーク
10.1.0.0/16

8. 8
Red Hat Enterprise Linux 7.1 Kubernetes入門
内部ネットワークの詳細
 Overlayによる内部ネットワークは、Kubernetesとは独立に事前準備する必要があります。
– 簡易的に実現する場合は、Flannelの利用がおすすめです。
 Flannelは、次のように内部ネットワークを構成します。
– 各MinionのDocker用仮想ブリッジ「docker0」に重複しないサブネットを割り当てます。
（サブネット10.1.x.0/24（x=1,2,3,...）など。）
– 他のMinionと通信するゲートウェイとなる仮想NIC「flannel.1」を作成します。
– 「flannel.1」に届いたパケットは、VXLANでカプセル化して宛先Minionの「flannel.1」
に転送されます(*1)
。
flannel.1
docker0
10.1.1.0/24
10.1.1.0
etn0
10.1.1.1
10.1.0.0/16への
ゲートウェイ
カプセル化して転送 flannel.1
docker0
10.1.2.0/24
10.1.2.0
etn0
10.1.2.1
10.1.0.0/16への
ゲートウェイ
minion01 minion02
10.1.0.0/16
flanneld flanneld
(*1) Flannelデーモン（flanneld）はVXLANの処理に必要な情報をLinuxカーネルに提供します。

9. 9
Red Hat Enterprise Linux 7.1 Kubernetes入門
外部からのアクセス経路
etcd Kubernetes
Master
Minion
Docker
Registry
Minion
API操作 イメージ登録
・・・
サービスアクセス
 外部からのアクセスには次のようなパターンがあります。
– Kubernetsの操作は、MasterのAPIを使用します。
– コンテナ上のサービスには、MinionのIPアドレスからProxyを経由してアクセスします。
– Docker Registryは、Kubernetesとは独立したコンポーネントとして用意します。（コン
テナ上のサービスとして起動することも可能です。）
サービスネットワーク
内部ネットワーク

10. コンテナのデプロイ方式

11. 11
Red Hat Enterprise Linux 7.1 Kubernetes入門
Podの概念について
 Kubernetesは、Podの単位でコンテナを起動します。Podを
起動する際に、その中に含まれるイメージを指定します。
– 単一のコンテナを起動する場合は、1つのイメージだけ
を含むPodを定義します。
– Podが異常停止した場合は、新しいPodを起動します。
コンテナA
仮想NIC
コンテナB
Pod
docker0
 Dockerでコンテナを起動すると、デフォルトではコンテナごとに仮想NICとプライベートIP
が割り当てられますが、オプション指定により「複数のコンテナで仮想NIC（プライベート
IP）を共有する構成」が可能です。
 Kubernetesでは、このような構成でのコンテナ起動をサポートしており、仮想NICを共有す
るコンテナ群をまとめたものを「Pod」と呼びます。localhost経由で通信させたいコンテナ
を1つのPodにまとめることができます。
– 例：PostgreSQLのコンテナとpgadminのコンテナを同じPodで起動する。
– 例：syslogにログ出力するアプリケーションのコンテナとrsyslogdのコンテナを同じPod
で起動する。
仮想ブリッジ

12. 12
Red Hat Enterprise Linux 7.1 Kubernetes入門
Replication Controller
 Replication Controllerは、同一構成のPodが指定の数だけ起動している状態を保持します。
Webサーバーが稼働するPodを負荷分散用に複数起動するような使い方が可能です。
– それぞれのPodが起動するノードは、スケジューラが自動決定します。Podが異常停止し
た場合は、新たなPodを追加起動します。
– 起動する数は動的に変更することができますので、オートスケール的な仕組みを作るこ
ともできます。
 Podを起動する際は、Pod単体で起動するか、もしくは、Replication Controller経由で起動
するかのどちらかを選択します。
– Replication Controllerから「起動数=1」で起動した場合は、後から起動数を変更できま
すが、Pod単体で起動した場合はできません。

13. 13
Red Hat Enterprise Linux 7.1 Kubernetes入門
Serviceの概念について
 Podを起動しただけでは、外部からのアクセスはできません。起動中のPodに対して、
「Service」を定義することでアクセス可能なIPアドレスが用意されます。
– 複数のPodに対して、これらをまとめた1つのServiceを定義します。
– Serviceに対応する「IPアドレス＋ポート番号」にアクセスすると、ラウンドロビンでア
クセスが行われます。
 Serviceを定義する際、ポート番号は明示的に指定します。IPアドレスは、「Private IP」が
自動で1つ割り当てられます。これは、他のPod内のプロセスからアクセス可能なIPアドレス
になります。
– Private IP宛のパケットは、Minion上のProxyデーモンが受け取って、対応するPodに転
送されます。
– 新規にPodを起動すると、既存のServiceのPrivate IPとポート番号は、環境変数として参
照できるようになります。
Poｄ
Proxy
Private IP宛のパケットは
ローカルのProxyが受け取る
Poｄ
Proxy
内部ネットワーク経由で
ロードバランス
Poｄ
Proxy
Minion Minion Minion

14. 14
Red Hat Enterprise Linux 7.1 Kubernetes入門
Minion
外部からServiceへのアクセス方法
サービスアクセス
 外部からServiceにアクセスさせる場合は、Serviceを定義する際に「Public IP（＝アクセス
を許可するMinionのIPアドレス）」を追加で指定します。
– 該当のMinionが受信した該当ポート宛のパケットは、Proxyデーモンに転送されて、
Private IPと同様の処理が行われます。
 Public IPは、Serviceごとに複数指定することができます。
– 複数のPublic IPを指定すると、複数のMinionから該当Serviceにアクセス可能になり、特
定のMinionがSPOFになることを防止できます。
– 接続先のMinionを振り分ける仕組みは、外部で用意する必要があります。DNSロードバ
ランシングなどを利用します。
Poｄ
Proxy
サービス用ポート宛の
パケットをProxyに転送
外部からはMinionの
IPにアクセス
Minion
Poｄ
Proxy
内部ネットワーク経由で
ロードバランス

15. 定義ファイルの例

16. 16
Red Hat Enterprise Linux 7.1 Kubernetes入門
単一Podを起動する例
 次は、単一のPodを起動する定義ファイルの例です。
– Kubernetesで定義するリソースは、(key, value) 形式のラベルを任意の数だけ付与できま
す。これは、他のリソースから参照するためのラベルとなります。
– Kubernetesで定義するリソースは、それぞれに「ネームスペース」を指定します。同じ
ネームスペース内のリソースのみがお互いに参照可能になります。
{
"kind": "Pod",
"id": "apache",
"apiVersion": "v1beta1",
"labels": { "name": "apache" },
"namespace": "default",
"desiredState": {
"manifest": {
"id": "apache",
"restartPolicy": { "always": {} },
"version": "v1beta1",
"volumes": null,
"containers": [
{
"image": "fedora/apache",
"name": "my-fedora-apache",
"ports": [ { "containerPort": 80, "protocol": "TCP" } ]
}
]
}
}
}
Podに含めるコンテナ
ラベル
ネームスペース

17. 17
Red Hat Enterprise Linux 7.1 Kubernetes入門
Replication ControllerからPodを起動する例
 次は、Replication Controllerを使用してPodを起動する定義ファイルの例です。
{
"kind": "ReplicationController",
"id": "apache-controller",
"apiVersion": "v1beta1",
"labels": { "name": "apache-controller" },
"namespace": "default",
"desiredState": {
"replicaSelector": { "name": "apache" },
"replicas": 2,
"podTemplate": {
"desiredState": {
"manifest": {
"id": "apache",
"containers": [
{
"image": "fedora/apache",
"name": "my-fedora-apache",
"ports": [ { "containerPort": 80, "protocol": "TCP" } ]
}
],
"restartPolicy": { "always": {} },
"version": "v1beta1",
"volumes": null
}
},
"labels": { "name": "apache" }
}
}
}
起動するPodの定義
管理対象とする
Podのラベル

18. 18
Red Hat Enterprise Linux 7.1 Kubernetes入門
Serviceを定義する例
 次は、稼動中のPodにアクセスするためのServiceを追加する定義ファイルの例です。
– Podのラベルでアクセス先のPodを指定します。
– Serviceとして受けるポート番号とPod側の転送先ポート番号を指定します。
– 外部からのアクセスが不要な場合（他のPodからのアクセスのみが必要な場合）は、
Public IPを指定する必要はありません。
{
"kind": "Service",
"id": "frontend",
"apiVersion": "v1beta1",
"labels": { "name": "frontend" },
"namespace": "default",
"selector": { "name": "apache" },
"containerPort": 80,
"port": 999,
"publicIPs": [ "192.168.122.10", "192.168.122.11" ]
}
このServiceからアクセス
させるPodのラベル
Public IP

19. OpenShift v3での機能拡張

20. 20
Red Hat Enterprise Linux 7.1 Kubernetes入門
OpenShift v3での機能拡張
 OpenShift v3は、内部的にKubernetesを利用していますが、Kubernetes単体での利用に対
して、次のような機能拡張がなされる予定です。
– Open vSwitchによる内部ネットワークの構成
• Flannelはlatencyが大きくなる傾向があります。OpenShift v3では、Open vSwitch
を利用して、VXLANによるoverlayネットワークを構成します。
– URLによるサービスへのアクセス
• Kubernetesでは、外部からサービスにアクセスする際は、MinionのIPアドレスを明
示的に指定する必要があります。OpenShift v3では、サービスごとに固有のURLを割
り当てて、URLによる透過的なアクセスが可能になります。
– マルチテナントでの利用
• Kubernetesのnamespaceを利用して、マルチテナントで利用するためのインター
フェースが提供されます。
– イメージビルド機能の提供
• Kubernetesでは、使用するイメージは、Registryに事前登録してある前提です。
OpenShift v3では、gitにソースコードをpushすると、「ビルド→テスト→イメージ
化→Registry登録」の一連の処理が自動化できるようになっています。

21. 参考資料

22. 22
Red Hat Enterprise Linux 7.1 Kubernetes入門
参考資料
 OpenShift v3 Internal networking details
– http://www.slideshare.net/enakai/openshift-45465283
 RHEL7.1でKubernetesを実体験（概要編）
– http://jp-redhat.com/openeye_online/column/nakai/902/
 RHEL7.1でKubernetesを実体験（構築編）
– http://jp-redhat.com/openeye_online/column/nakai/991/
 FlannelのVXLANバックエンドの仕組み
– http://enakai00.hatenablog.com/entry/2015/04/02/173739

23. EMPOWER PEOPLE,
EMPOWER ENTERPRISE,
OPEN INNOVATION.