Transcript

• 1. Red Hat Enterprise Linux 7.1 Kubernetes入門 レッドハット株式会社 中井悦司 / Etsuji Nakai Senior Solution Architect and Cloud Evangelist V1.0 2015/03/11
• 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」を作成します。 – 各Minionで稼働するflannelデーモンは、flannel.1に届いたパケットをOTV over UDP(*1) でカプセル化して、宛先Minionのflannelデーモンに転送します。 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 flanneld 10.1.0.0/16への ゲートウェイ minion01 minion02 flanneld 10.1.0.0/16 (*1) http://tools.ietf.org/id/draft-hasmit-otv-04.txt
• 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
• 23. EMPOWER PEOPLE, EMPOWER ENTERPRISE, OPEN INNOVATION.