Red Hat Enterprise Linux 7.1 Kubernetes入門

Red Hat Enterprise Linux 7.1Kubernetes入門

レッドハット株式会社

中井悦司 / Etsuji NakaiSenior Solution Architect

and Cloud Evangelist

v1.2 2015/04/03

2

Red Hat Enterprise Linux 7.1 Kubernetes入門

はじめに

Red Hat Enterprise Linux 7.1 (RHEL7.1) では、Kubernetesがサポート対象パッケージとして利用可能になりました。

この資料では、RHEL7.1の環境を前提として、Kubernetesのアーキテクチャーを解説しています。具体的な構築・操作方法は参考資料を参照してください。

OpenShift v3についての説明は、資料作成時点のベータ版での情報に基づいていいます。GA版では変更される可能性もあります。

3


自己紹介

中井悦司（なかいえつじ）– Twitter @enakai00

日々の仕事– Senior Solution Architect and

Cloud Evangelist at Red Hat K.K.企業システムでオープンソースの活用を希望されるお客様を全力でご支援させていただきます。

昔とった杵柄– 素粒子論の研究（超弦理論とか）– 予備校講師（物理担当）– インフラエンジニア（Unix/Linux専門）

好評発売中！

4


Contents

Kubernetesのアーキテクチャーコンテナのデプロイ方式定義ファイルの例 OpenShift v3での機能拡張参考資料

Kubernetesのアーキテクチャー

6


Kubernetesの基本サーバー構成

etcd

・・・

バックエンドデータベース（KVS）

Kubernetes MasterKubernetes Node (Minion)

・・・

クラスタ構成で負荷分散可能

Docker Docker Docker

必要に応じて追加可能

Docker Registry

１台のMasterから複数のNode（Minion）を管理するシンプルなアーキテクチャーです。–現在は、Masterを冗長化する機能はありませんので、必要に応じてActive-Standbyクラ

スターを構成します。–バックエンドデータベース（etcd）を外出しにしておけば、IPアドレスのFailoverのみで

構わないはずです。

7


Kubernetesのネットワーク構成

etcd KubernetesMaster

DockerRegistry

Overlayネットワークとして構成

・・・

物理的には、全サーバーを共通のサービスネットワークに接続するだけで利用可能です。

ただし、コンテナ間通信用の内部ネットワークをoverlayネットワークとして用意する必要があります。– Flannel、Open vSwitchなどでoverlayネットワークを構成します。

サービスネットワーク192.168.122.0/24

Minion

docker0

Minion

docker0

内部ネットワーク10.1.0.0/16

8


内部ネットワークの詳細

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


外部からのアクセス経路

etcd KubernetesMaster Minion Docker

RegistryMinion

API操作イメージ登録

・・・

サービスアクセス

外部からのアクセスには次のようなパターンがあります。– Kubernetsの操作は、MasterのAPIを使用します。–コンテナ上のサービスには、MinionのIPアドレスからProxyを経由してアクセスします。– Docker Registryは、Kubernetesとは独立したコンポーネントとして用意します。（コン

テナ上のサービスとして起動することも可能です。）

サービスネットワーク

内部ネットワーク

コンテナのデプロイ方式

11


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


Replication Controller

Replication Controllerは、同一構成のPodが指定の数だけ起動している状態を保持します。Webサーバーが稼働するPodを負荷分散用に複数起動するような使い方が可能です。–それぞれのPodが起動するノードは、スケジューラが自動決定します。Podが異常停止し

た場合は、新たなPodを追加起動します。–起動する数は動的に変更することができますので、オートスケール的な仕組みを作るこ

ともできます。

Podを起動する際は、Pod単体で起動するか、もしくは、Replication Controller経由で起動するかのどちらかを選択します。– Replication Controllerから「起動数=1」で起動した場合は、後から起動数を変更できま

すが、Pod単体で起動した場合はできません。

13


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ｄ

ProxyPrivate IP宛のパケットは

ローカルのProxyが受け取る

Poｄ

Proxy

内部ネットワーク経由でロードバランス

Poｄ

ProxyMinion Minion Minion

14


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

内部ネットワーク経由でロードバランス

定義ファイルの例

16


単一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


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


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

OpenShift v3での機能拡張

20


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登録」の一連の処理が自動化できるようになっています。

参考資料

22


参考資料

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

EMPOWER PEOPLE,

EMPOWER ENTERPRISE,

OPEN INNOVATION.

Red Hat Enterprise Linux 7.1 Kubernetes入門

Technology

Transcript of Red Hat Enterprise Linux 7.1 Kubernetes入門