Kubernetesにまつわるエトセトラ（主に苦労話）

Kubernetesにまつわるエトセトラ（主に苦労話）
2 0 1 6 年 7 月 2 4 日井上誠一郎 Demystifying Kubernetes
自己紹介: 井上誠一郎 • 元アリエルネットワークCTO (先月まで) • ワークスアプリケーションズエグゼクティブフェロー • 主な著書 • 「P2P教科書」 • 「パーフェクトJava」 • 「パーフェクトJavaScript」 • 「実践JS サーバサイドJavaScript入門」 • 「パーフェクトJava EE」(来月出版)
今日のセッションの目的 •複雑怪奇なKubernetesをひもといていきます •Kubernetesのバージョンは v1.2.6ベースで説明します
複雑さをひもとくための工夫 •Kubernetes固有の概念/用語がたくさんあるので、説明のために簡易化していきます •概念を下から積み上げていきます
Kubernetes理解に必要な知識(私見) Dockerの理解 Dockerのネットワークの理解 flanneldの理解コンテナとpodの関係の理解 podとサービスの関係の理解 Kubernetesのネットワークの理解 (DNSとルーティング) Kubernetesのツールの理解この順序で説明
コンテナに関しての簡易化 • 理屈で言えばコンテナはひとつのOS相当なので、ひとつのコンテナ内で多数のプロセス、たとえばロードバランサ、アプリケーションサーバ、データベースすべてを動かせます • しかし、Kubernetesの思想的には、ひとつのコンテナで動くプロセスの数を最小限にして、代わりに、コンテナ群を管理します • 今回の説明上も、ひとつのコンテナ上で動くのはひとつのプロセス、というモデルを前提にします(Kubernetesの必須要件ではありませんが)
Kubernetesの動作の分解の前に •そもそもKubernetesは何をしてくれるのか? •Kubernetesを使うと何がうれしいのか?
Kubernetesがやってくれること • 複数ホストにコンテナをデプロイ • コンテナ間のネットワーク管理(名前解決含む) • コンテナの死活監視 • コンテナの負荷分散 • コンテナのリソースアロケーション
• 複数ホストにコンテナをデプロイ • どのホストにどのコンテナ(=プロセス)を配備するかを隠蔽 • コンテナ間のネットワーク管理(名前解決含む) • サービスディスカバリ相当の機能 • コンテナの死活監視 • コンテナ(=プロセス)が死んだら、コンテナを自動で新規起動 • コンテナの負荷分散 • 同一機能の複数コンテナ(=プロセス)へのアクセスをバランシングする機能(あまりリッチではない) • コンテナのリソースアロケーション • コンテナごとにCPUリソースやメモリリソースの割り当てを指定できる機能(あまりリッチではない) Kubernetesがやってくれること
Kubernetesがない世界プロセスA プロセスB 依存実行環境開発者プロセスB プロセスB プロセスB プロセスB deploy LB プロセスA LB プロセスA configuration (個々のエンドポイントを設定)
Kubernetesがある世界プロセスA プロセスB 依存実行環境開発者プロセスB プロセスB プロセスB LB プロセスA Kubernetes プロセスB群のサービス名を定義プロセスAにサービス名を与える
用語と概念の整理
• Dockerプロセスが動いているOSをホスト(マシン)と呼びます • ひとつのホストの上で、コンテナが複数稼働します • Kubernetesの世界から見ると、ホストマシンが物理マシンか仮想マシンかはどうでもいい話です。気にしないでください • 同様に、ホストマシンがネットワークのどこにいるか (プライベートネットワーク or グローバルIPを持つ)も Kubernetesの世界からはスコープ外なので、気にしなくて結構ですホストマシンについて
• Kubernetesで最初に混乱するのが、Dockerのネットワークまわりです • flanneldの世界とKubernetesの話が混ざると混乱するので、話を分離します • まずflanneldだけに話を限定します Dockerのネットワークまわりの話とflanneld
• flanneldがないと、あるホストの上で動いているコンテナは、他のホストの上で動いているコンテナのIPアドレスにアクセスできません • 正確に言えば、ある設定をすれば、相手側ホストのIPアドレス経由で、リモートのコンテナにアクセスできます • ただ、基本的には少々面倒な世界です flanneldの役割(1)
• flanneldは各ホスト上で動くデーモンプロセスです。 flanneldがいれば、ホスト群の上のコンテナ群はコンテナ自身のIPアドレスを使って相互にアクセスできます • コンテナたちは一意なIPアドレスを持つようになります • 一見すると、ホスト間のコーディネーションが必要そうですが、仕組みはもっと単純で、flanneldプロセス群が同じデータストア (etcd)でルーティングテーブルを共有しているだけです • なお、この領域には、Docker Swarmなど類似機能の他技術も存在します flanneldの役割(2)
1. (そもそもDockerのネットワーク補助のためなので)Docker自身をインストール 2. 共有データストアとしてetcdが必要なので、どこかに etcdを起動(etcd自体は分散KVSですが、動作確認だけであれば、単体でどこかで起動していれば充分) 3. etcdにflanneldが使うネットワークアドレスを登録 (どのネットワークアドレスを使うかは利用者の自由) 例 $ etcdctl set /coreos.com/network/config '{ "Network": "10.1.0.0/16" }‘ flanneldを動かす手順の概要(1)
4. 各ホストでflanneldデーモンプロセスを起動例同一ホストでetcdが動いている場合は単に $ sudo bin/flanneld 別ホスト(IPアドレスが10.140.0.14)でetcdが動いている場合は $ sudo bin/flanneld -etcd-endpoints 'http://10.140.0.14:4001,http://10.140.0.14:2379' flanneldを動かす手順の概要(2)
5. 個々のflanneldは、どのサブネットを確保したかの情報を /run/flannel/subnet.env に書き出す例 $ cat /run/flannel/subnet.env FLANNEL_NETWORK=10.1.0.0/16 FLANNEL_SUBNET=10.1.19.1/24 FLANNEL_MTU=1432 FLANNEL_IPMASQ=true 6. dockerプロセスに対して、上記のサブネットを使うように指示して起動 $ source /run/flannel/subnet.env $ sudo docker -d --bip=${FLANNEL_SUBNET} --mtu=${FLANNEL_MTU} flanneldを動かす手順の概要(3)
ifconfigでdocker0やflanneldのネットワークアドレスを確認(出力例は抜粋) (下記例の場合、このホスト上のコンテナ群は 10.1.19.0/24 のネットワークを構成) $ ifconfig docker0 Link encap:Ethernet HWaddr 02:42:a5:18:b3:73 inet addr:10.1.19.1 Bcast:0.0.0.0 Mask:255.255.255.0 flannel0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00- 00-00-00-00-00-00-00-00 inet addr:10.1.19.0 P-t-P:10.1.19.0 Mask:255.255.0.0 flanneldの動作確認(1)
ルーティングテーブルの確認: $ netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 0.0.0.0 10.140.0.1 0.0.0.0 UG 0 0 0 ens4 10.1.0.0 0.0.0.0 255.255.0.0 U 0 0 0 flannel0 10.1.19.0 0.0.0.0 255.255.255.0 U 0 0 0 docker0 10.140.0.1 0.0.0.0 255.255.255.255 UH 0 0 0 ens4 他のホスト上のコンテナのIPアドレス(たとえば10.1.79.2)に向けて接続できれば OK flanneldの動作確認(2)
• なかなか面倒... • まず、dockerのデーモンプロセス起動より先に flanneldプロセスの起動が必要 • かつ、flanneldプロセス起動時に、etcdの固定アドレスを外から与える必要がある • 更に、flanneldの書き出した /run/flannel/subnet.env の結果を、dockerのデーモンプロセスの起動時に渡す必要がある OS起動時のflanneldの自動起動(1)
systemdであれば $ sudo vi /lib/systemd/system/docker.service で EnvironmentFile=-/run/flannel/subnet.env を追記(先頭のハイフンの意味は、ファイルが存在しなければ無視する、というオプション) #下記に書き換え ExecStart=/usr/bin/docker daemon -H fd:// $DOCKER_OPTS ExecStart=/usr/bin/docker daemon -H fd:// $DOCKER_OPTS - -bip=${FLANNEL_SUBNET} --mtu=${FLANNEL_MTU} OS起動時のflanneldの自動起動(2)
• Kubernetes理解のための、flanneldの最小理解 • flanneldを使うと、Kubernetes管理下にいる各コンテナは一意なIPアドレスを持ち、相互にリーチャブルになる • flanneldネットワークは、プライベートネットワークなので、Kubernetesの外側からは叩けない • このネットワークは、ホストのIPアドレスのネットワークとは別物 • (後述する)KubernetesのサービスのIPアドレスのネットワークとも別物(ここがわかりづらい) ここまでのまとめ
flanneldをいったん頭から追い出して、 Kubernetesの概念の整理をします
• ノードはKubernetes固有の用語です • 頭が混乱したら、「ホストマシン = ノード」と考えても、大きくは外しません • より正確には、 • ノードは、「マスタノード」と「ワーカーノード」の2種類に分けられますホストマシンとノードについて(1)
• ワーカーノードは、Dockerプロセスが稼働するホストで、その上でKubernetes管理下のコンテナ群が稼働します。こちらは「ワーカーノード = ホスト」の理解で問題ありません • マスタノードのほうは、いくつかのKubernetesのサーバプロセス群のことです • これらのプロセスはコンテナ上で動く必要はありません • 「マスタノード」という用語はややミスリーディングに思います (マスタプロセスのほうが適切) # 古い文書ではワーカーノードがMinionと呼ばれていますホストマシンとノードについて(2)
• podはコンテナをグループ化したKubernetes固有の概念です • あるpodインスタンス内のコンテナは、同一のホスト上で稼働します。かつ、(Dockerネットワーク的な意味で)同じIPアドレスを共有します • 密結合なプロセス群、言い換えると、死ぬ時は一緒に死んでほしいようなプロセス群をpodにまとめます • しかし、今日の説明上は、ひとつのpod内にはひとつのコンテナ、というモデルにします • 既に説明したように、ひとつのコンテナにひとつのプロセスのモデルにしているので、今日の説明では、ひとつのpodはひとつのプロセスと対応します • (pauseという特別なプロセスのコンテナがありますが本質的ではないので説明を割愛します) コンテナとpod
• レプリケーションコントローラ(以下rcと略)は、podを複数インスタンス化するKubernetes固有の概念です • 実運用上、podを単一インスタンスで使ってもKubernetesの旨味が少ないので、必要なレプリカ数を指定したrcを設定するのが普通です • rcは指定したレプリカ数分のpodをインスタンス化します。今回の文脈では、レプリカ数分のプロセス起動になります • プロセスがどのホストで起動するかは実行時に決まります (Kubernetesが空いているホストを見つけます) • rcは指定レプリカ数分のpodを維持します。つまり、仮にどこかの pod(=コンテナ=プロセス)が死ぬと、自動で新しいpodが起動します podとレプリケーションコントローラ(=rc)
• Kubernetes v1.3以降、rcがレプリカセットと Deploymentという新しい概念で置換されていくようです • 今日の説明は rc のまま進めます fyi, rcとレプリカセットとDeployment
• rcの機能により、podは複数インスタンス状態になります • 今回の場合、同じプログラムから複数プロセスが起動すると考えてください • かつこれらのプロセスがどのホストで動くかは実行時に決まるので、個々のプロセスのIPアドレスは実行時に決まります • サービスは、これらの複数インスタンスに対して単一IPアドレスを割り当てるKubernetesの機能です • 結果的に、サービスのIPアドレスに向けたアクセスが、背後の複数 podへ割り振られるのでロードバランサのように振る舞います • 内部的には、各ワーカーノード上で動くkube-proxyというプロセスがiptablesにエントリを追加することで、サービスのIPアドレスを作っています • サービスのIPアドレスはifconfigなどでは見えないアドレスです(後述) podとサービス
• Kubernetesの各サービスのIPアドレスの名前解決にはDNSを使います • SkyDNSというDNS実装が(事実上)Kubernetesに組み込まれています • 実行時に新しいサービスが起動すると、サービス名とIPアドレスのエントリが自動でSkyDNSに登録されます(登録は kube2dnsというプロセスが担当) • 各pod上のプロセスは、サービス名さえわかればサービスにアクセスできます(いわゆるサービスディスカバリ相当の機能になります) • サービス名の命名や、アプリにサービス名をどう与えるかは、アプリケーション開発者の責務です名前解決とSkyDNS
他に知っておくと良い細々したこと:
•Kubernetesの管理用コマンドラインツールです •利用例は後ほど具体例の中で紹介します kubectl
• 分散KVS • Kubernetesのマスタプロセスが使うデータストアです • SkyDNSおよびflanneldもそれぞれetcdをデータストアとして使います。 • 今回の説明においては、etcdとは、どこかにあるただのデータストアと思えば充分です • etcdはコンテナ上にある必要もないですし、マスタノードやワーカーノード上で必ずしも動かす必要はありません • 今日の説明では、(便宜上)マスタノード上でコンテナを使って etcdを起動します etcd
•etcdの管理用コマンドラインツールです •利用例は後ほど具体例の中で紹介します etcdctl
• Kubernetesの各種プロセスをコマンドラインの第一引数で呼び分けられるプログラムです • たとえば hyperkube kubelet と起動すると kubelet プロセスを起動できます • 利用は必須ではないですが、ラクなので今回は hyperkubeを使います hyperkube
• マスタプロセス群は、apiserverやcontroller-managerや schedulerなどがあります • これらは今後Kubernetesのバージョンが上がると色々と変化すると思うので、一群のプロセス群があるということだけ理解すれば充分です • 唯一気にすべきプロセスはapiserverです • kubectlはapiserverのREST APIを叩くプログラムです。apiserverのアドレスを引数で与える必要があります(同一ホストで動いていれば省略可能) • apiserverはデータストアとしてetcdを使うので、apiserver起動の前にetcd起動が必要で、かつapiserverは起動時にetcdのアドレスを知っている必要があります • 他のKubernetesプロセスたちは、起動時に、apiserverプロセスのアドレスを知っている必要があります Kubernetesのマスタプロセス群
• dockerデーモンプロセス: これがないとコンテナが動かせないので当然必要です • kubelet: ワーカーノードをワーカーノードたらしめるプロセスです。pod(=コンテナ)の起動などを担います • kube-proxy: サービスのIPアドレスを管理します(内部的にiptablesを操作) • flanneld: 異なるホスト上のコンテナ同士をネットワーク的につなぎます(説明済み) 各ワーカーノード上で動くプロセス群
Kubernetesを動かしてみます
• 単体ノード上で動かす手順 • http://kubernetes.io/docs/getting-started-guides/docker/ • http://kubernetes.io/docs/getting-started-guides/docker- multinode/deployDNS/ • 複数ノードでの手順 • http://kubernetes.io/docs/getting-started-guides/docker- multinode/master/ • http://kubernetes.io/docs/getting-started-guides/docker- multinode/worker/ 手順は下記を参考
• ふたつのホストを使います • ホストのOSは Ubuntu 16.04 ですが、可能な限りディストリビューション依存のない説明をします • 両方のホストがワーカーノードで、かつ片方のホスト上で(コンテナを使って)マスタプロセス群を動かします • ワーカーノード上のプロセス群(kubeletやkube-proxy) も、コンテナを使って動かします • これらのプロセスは、コンテナで動かすことが必須ではありません。将来、普通にapt-getでインストールできるようになれば、そのほうがシンプルですサンプルの構成
1. 全体の準備 2. マスタノードになるホスト上での作業 3. ワーカーノードになるホスト上での作業 4. 自作アプリのサービス化手順のオーバービュー
kubectlコマンドをインストールします基本的には、kubectlコマンドはどのマシンにインストールしても構いません(マスタプロセスのIPアドレスにリーチャブルな場所であれば)。 $ export K8S_VERSION=1.2.6 $ curl http://storage.googleapis.com/kubernetes- release/release/v${K8S_VERSION}/bin/linux/amd64/kubectl > kubectl $ sudo mv kubectl /usr/local/bin/ $ sudo chmod +x /usr/local/bin/kubectl マスタプロセスと異なるホストにインストールした場合、kubectlのコマンドラインオプションの-sでマスタプロセスのホストのIPアドレスとポート(10.140.0.14:8080)を指定する必要があります(あるいは kubeconfig ファイルで設定) $ kubectl -s 10.140.0.14:8080 cluster-info 全体の準備
• 前述したように、マスタノードという用語はややミスリーディングです • いくつかのマスタプロセスを起動するノードを、単にマスタノードと呼びます • 今回の場合、このホストはワーカーノードにもなりますマスタノードになるホスト
Docker自身のインストール $ sudo apt-get update; sudo apt-get -y upgrade; sudo apt-get -y install docker.io 仮にホストでetcdが動いていると邪魔するので、プロセスがいないことを確認仮に動いていたら、止めておく $ sudo systemctl stop etcd $ sudo systemctl disable etcd マスタノードになるホスト上での作業(1)
環境変数設定(利便性のため) $ export MASTER_IP=10.140.0.14 # ホストのIPアドレス。ifconfigで確認 $ export K8S_VERSION=1.2.6 $ export ETCD_VERSION=2.2.5 $ export FLANNEL_VERSION=0.5.5 $ export FLANNEL_IFACE=ens4 # ifconfigで確認 $ export FLANNEL_IPMASQ=true マスタノードになるホスト上での作業(2)
• flanneldを動かします。その前にflanneldが依存する etcdを動かします • これらはコンテナで動かす必要はないですが、ラクをするために両方ともコンテナで動かします • ややトリッキーですが、flanneldとetcd専用のDocker デーモンプロセスを起動します • 手順の中の可変項目は、flanneldが使うネットワークアドレスの部分("10.1.0.0/16")です。これは好きに決められますマスタノードになるホスト上での作業(3)
専用Dockerデーモンプロセスの起動 $ sudo sh -c 'docker daemon -H unix:///var/run/docker-bootstrap.sock -p /var/run/docker-bootstrap.pid --iptables=false -- ip-masq=false --bridge=none -- graph=/var/lib/docker-bootstrap 2> /var/log/docker- bootstrap.log 1> /dev/null &' マスタノードになるホスト上での作業(4)
etcdプロセスの起動(コンテナ内) $ sudo docker -H unix:///var/run/docker-bootstrap.sock run -d --net=host ¥ gcr.io/google_containers/etcd-amd64:${ETCD_VERSION} ¥ /usr/local/bin/etcd ¥ --listen-client- urls=http://127.0.0.1:4001,http://${MASTER_IP}:4001 ¥ --advertise-client-urls=http://${MASTER_IP}:4001 ¥ --data-dir=/var/etcd/data マスタノードになるホスト上での作業(5)
etcdへの初期データ投入 $ sudo docker -H unix:///var/run/docker- bootstrap.sock run ¥ --net=host ¥ gcr.io/google_containers/etcd- amd64:${ETCD_VERSION} ¥ etcdctl set /coreos.com/network/config '{ "Network": "10.1.0.0/16" }' マスタノードになるホスト上での作業(6)
通常Dockerデーモンを一時停止 $ sudo systemctl stop docker flanneldプロセスの起動(コンテナ内) $ sudo docker -H unix:///var/run/docker-bootstrap.sock run -d ¥ --net=host --privileged ¥ -v /dev/net:/dev/net ¥ quay.io/coreos/flannel:${FLANNEL_VERSION} ¥ /opt/bin/flanneld ¥ --ip-masq=${FLANNEL_IPMASQ} ¥ --iface=${FLANNEL_IFACE} マスタノードになるホスト上での作業(7)
flanneldのサブネットのネットワークアドレスを(通常の)Dockerデーモンプロセスに伝えます $ sudo docker -H unix:///var/run/docker-bootstrap.sock exec flanneldコンテナの出力ハッシュ値(=コンテナID) cat /run/flannel/subnet.env 入力例 $ sudo docker -H unix:///var/run/docker-bootstrap.sock exec 195ea9f70770ac20a3f04e02c240fb24a74e1d08ef749f162beab5ee8c905734 cat /run/flannel/subnet.env 出力例 FLANNEL_NETWORK=10.1.0.0/16 FLANNEL_SUBNET=10.1.19.1/24 FLANNEL_MTU=1432 FLANNEL_IPMASQ=true マスタノードになるホスト上での作業(8)
$ sudo vi /lib/systemd/system/docker.service で ExecStart=/usr/bin/docker daemon -H fd:// $DOCKER_OPTS --bip=10.1.19.1/24 --mtu=1432 と書き換えマスタノードになるホスト上での作業(9)
Dockerデーモンプロセスを再起動します $ sudo /sbin/ifconfig docker0 down $ sudo brctl delbr docker0 $ sudo systemctl daemon-reload $ sudo systemctl restart docker マスタノードになるホスト上での作業(10)
Docker再起動前の確認(抜粋) $ ifconfig docker0 Link encap:Ethernet HWaddr 02:42:25:65:c5:f3 inet addr:10.1.20.1 Bcast:0.0.0.0 Mask:255.255.255.0 Docker再起動後の確認(抜粋) $ ifconfig docker0 Link encap:Ethernet HWaddr 02:42:a5:18:b3:73 inet addr:10.1.19.1 Bcast:0.0.0.0 Mask:255.255.255.0 flannel0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00- 00-00-00-00-00-00-00 inet addr:10.1.19.0 P-t-P:10.1.19.0 Mask:255.255.0.0 マスタノードになるホスト上での作業(11)
Docker再起動後のルーティングテーブルの確認 $ netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 0.0.0.0 10.140.0.1 0.0.0.0 UG 0 0 0 ens4 10.1.0.0 0.0.0.0 255.255.0.0 U 0 0 0 flannel0 10.1.19.0 0.0.0.0 255.255.255.0 U 0 0 0 docker0 10.140.0.1 0.0.0.0 255.255.255.255 UH 0 0 0 ens4 マスタノードになるホスト上での作業(12)
マスタプロセス群およびワーカーノードに必要なプロセス群(kubeletと kube-proxyなど)をhyperkubeで起動します $ sudo docker run ¥ --volume=/:/rootfs:ro --volume=/sys:/sys:ro ¥ --volume=/var/lib/docker/:/var/lib/docker:rw ¥ --volume=/var/lib/kubelet/:/var/lib/kubelet:rw ¥ --volume=/var/run:/var/run:rw ¥ --net=host --privileged=true --pid=host -d ¥ gcr.io/google_containers/hyperkube-amd64:v${K8S_VERSION} ¥ /hyperkube kubelet --allow-privileged=true ¥ --api-servers=http://localhost:8080 ¥ --v=2 --address=0.0.0.0 --enable-server ¥ --hostname-override=127.0.0.1 ¥ --config=/etc/kubernetes/manifests-multi --containerized ¥ --cluster-dns=10.0.0.10 --cluster-domain=cluster.local マスタノードになるホスト上での作業(13)
Kubernetesのマスタプロセスの動作確認 $ kubectl cluster-info Kubernetes master is running at http://localhost:8080 マスタノードになるホスト上での作業(14)
SkyDNSをpodとして動かします。 $ curl http://kubernetes.io/docs/getting-started- guides/docker-multinode/skydns.yaml.in > skydns.yaml.in $ export DNS_REPLICAS=1 $ export DNS_DOMAIN=cluster.local # 自分で決めてよいドメイン名 $ export DNS_SERVER_IP=10.0.0.10 # 自分で決めてよいDNSサーバのIPアドレス(KubernetesのサービスとしてIPアドレス) $ sed -e "s/{{ pillar¥['dns_replicas'¥] }}/${DNS_REPLICAS}/g;s/{{ pill ar¥['dns_domain'¥] }}/${DNS_DOMAIN}/g;s/{{ pillar¥['dns_serve r'¥] }}/${DNS_SERVER_IP}/g" skydns.yaml.in > ./skydns.yaml マスタノードになるホスト上での作業(15)
rcおよびサービスの作成(skydns.yamlの中身はrcとサービス) $ kubectl create -f ./skydns.yaml マスタノードになるホスト上での作業(15)
$ kubectl cluster-info Kubernetes master is running at http://localhost:8080 KubeDNS is running at http://localhost:8080/api/v1/proxy/namespaces/kube- system/services/kube-dns 確認(このfailureの原因は不明) $ curl http://localhost:8080/api/v1/proxy/namespaces/kube-system/services/kube-dns { "kind": "Status", "apiVersion": "v1", "metadata": {}, "status": "Failure", "message": "no endpoints available for service ¥"kube-dns¥"", "reason": "ServiceUnavailable", "code": 503 } SkyDNSの動作確認(1)
$ kubectl get --all-namespaces svc NAMESPACE NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE default kubernetes 10.0.0.1 <none> 443/TCP 2m kube-system kube-dns 10.0.0.10 <none> 53/UDP,53/TCP 1m $ kubectl get --all-namespaces ep NAMESPACE NAME ENDPOINTS AGE default kubernetes 10.140.0.14:6443 2m kube-system kube-dns 10.1.19.2:53,10.1.19.2:53 1m SkyDNSの動作確認(2)
$ dig @10.0.0.10 cluster.local. (抜粋) ;; ANSWER SECTION: cluster.local. 30 IN A 10.1.19.2 cluster.local. 30 IN A 127.0.0.1 cluster.local. 30 IN A 10.0.0.10 cluster.local. 30 IN A 10.0.0.1 $ dig @10.1.19.2 cluster.local. も動くが、このIPアドレスは状況によって変わりうるので依存してはいけない SkyDNSの動作確認(3)
• 最初のホスト上でflanneldを設定しました • このホスト上でマスタプロセス群を起動しました(apiserverなど) • このホストをワーカーノードにしました (kubeletとkube-proxyの起動) • SkyDNSをKubernetesのサービスとして起動しました(10.0.0.10のIPアドレスでアクセス可能) ここまでのまとめ
Docker自身のインストール $ sudo apt-get update; sudo apt-get -y upgrade; sudo apt-get -y install docker.io 環境変数設定(利便性のため) $ export MASTER_IP=10.140.0.14 # マスタノードのホストのIPアドレス $ export K8S_VERSION=1.2.6 $ export FLANNEL_VERSION=0.5.5 $ export FLANNEL_IFACE=ens4 # ifconfigで確認 $ export FLANNEL_IPMASQ=true ワーカーノードになるホスト上での作業(1)
• マスタノードと同じく、flanneldをコンテナで起動します • etcdはマスタノード上のetcdを参照します • flanneldの起動はマスタノードと同じ手順です専用Dockerデーモンプロセスの起動 $ sudo sh -c 'docker daemon -H unix:///var/run/docker- bootstrap.sock -p /var/run/docker-bootstrap.pid -- iptables=false --ip-masq=false --bridge=none -- graph=/var/lib/docker-bootstrap 2> /var/log/docker- bootstrap.log 1> /dev/null &' 通常Dockerデーモンを一時停止 $ sudo systemctl stop docker ワーカーノードになるホスト上での作業(2)
flanneldプロセスの起動(コンテナ内) $ sudo docker -H unix:///var/run/docker- bootstrap.sock run -d ¥ --net=host --privileged -v /dev/net:/dev/net ¥ quay.io/coreos/flannel:${FLANNEL_VERSION} ¥ /opt/bin/flanneld ¥ --ip-masq=${FLANNEL_IPMASQ} ¥ --etcd-endpoints=http://${MASTER_IP}:4001 ¥ --iface=${FLANNEL_IFACE} ワーカーノードになるホスト上での作業(3)
flanneldのサブネットのネットワークアドレスを(通常の)Dockerデーモンプロセスに伝えます $ sudo docker -H unix:///var/run/docker-bootstrap.sock exec flanneldコンテナの出力ハッシュ値(=コンテナID) cat /run/flannel/subnet.env 出力例 FLANNEL_NETWORK=10.1.0.0/16 FLANNEL_SUBNET=10.1.79.1/24 FLANNEL_MTU=1432 FLANNEL_IPMASQ=true $ sudo vi /lib/systemd/system/docker.service で ExecStart=/usr/bin/docker daemon -H fd:// $DOCKER_OPTS --bip=10.1.79.1/24 -- mtu=1432 と書き換えワーカーノードになるホスト上での作業(4)
Dockerデーモンプロセスを再起動します $ sudo /sbin/ifconfig docker0 down $ sudo brctl delbr docker0 $ sudo systemctl daemon-reload $ sudo systemctl restart docker ワーカーノードになるホスト上での作業(5)
確認はifconfigおよびnetstat -rnで実施再起動後のルーティングテーブルの確認 $ netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 0.0.0.0 10.140.0.1 0.0.0.0 UG 0 0 0 ens4 10.1.0.0 0.0.0.0 255.255.0.0 U 0 0 0 flannel0 10.1.79.0 0.0.0.0 255.255.255.0 U 0 0 0 docker0 10.140.0.1 0.0.0.0 255.255.255.255 UH 0 0 0 ens4 ワーカーノードになるホスト上での作業(6)
ワーカーノードに必要なプロセス(kubelet)をhyperkubeで起動します $ sudo docker run ¥ --volume=/:/rootfs:ro --volume=/sys:/sys:ro ¥ --volume=/dev:/dev ¥ --volume=/var/lib/docker/:/var/lib/docker:rw ¥ --volume=/var/lib/kubelet/:/var/lib/kubelet:rw ¥ --volume=/var/run:/var/run:rw ¥ --net=host --privileged=true --pid=host -d ¥ gcr.io/google_containers/hyperkube-amd64:v${K8S_VERSION} ¥ /hyperkube kubelet ¥ --allow-privileged=true --api-servers=http://${MASTER_IP}:8080 ¥ --v=2 --address=0.0.0.0 --enable-server --containerized ¥ --cluster-dns=10.0.0.10 --cluster-domain=cluster.local ワーカーノードになるホスト上での作業(7)
ワーカーノードに必要なプロセス(kube-proxy)を hyperkubeで起動します $ sudo docker run -d --net=host --privileged ¥ gcr.io/google_containers/hyperkube- amd64:v${K8S_VERSION} ¥ /hyperkube proxy ¥ --master=http://${MASTER_IP}:8080 --v=2 ワーカーノードになるホスト上での作業(8)
•ふたつ目のホスト上でflanneldを設定しました •このホストをワーカーノードにしました(kubeletとkube-proxyの起動) ここまでのまとめ
$ kubectl -s 10.140.0.14:8080 cluster-info Kubernetes master is running at 10.140.0.14:8080 KubeDNS is running at 10.140.0.14:8080/api/v1/proxy/namespaces/kube- system/services/kube-dns サービスの確認 $ kubectl -s 10.140.0.14:8080 get --all-namespaces svc NAMESPACE NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE default kubernetes 10.0.0.1 <none> 443/TCP 47m kube-system kube-dns 10.0.0.10 <none> 53/UDP,53/TCP 45m Kubernetesの基本的な動作確認(1)
ノードの確認 $ kubectl get nodes NAME STATUS AGE 127.0.0.1 Ready 52m ubuntu16k5 Ready 16m Kubernetesの基本的な動作確認(2)
自作Node.jsアプリをKubernetes上のサービスとして動かしてみる
server.js => var http = require('http'); var handleRequest = function(request, response) { response.writeHead(200); response.end("Hello World"); } var www = http.createServer(handleRequest); www.listen(8888); サンプルアプリケーションのDockerイメージを準備(1)
Dockerfile => FROM node:latest EXPOSE 8888 COPY server.js . CMD node server.js $ sudo docker build -t mynode:latest . $ sudo docker images # 確認サンプルアプリケーションのDockerイメージを準備(2)
このDockerイメージを複数ホストから取得できるためにレジストリに登録する必要があります (自前でdockerレジストリを立てるのがベストですが、今回はDockerHubで代用します) $ docker login $ docker tag mynode:latest guest/mynode # guest の部分はDockerHubのログインID $ docker push guest/mynode Dockerイメージをレジストリに登録
mynode.yaml => apiVersion: v1 kind: ReplicationController metadata: name: my-node spec: replicas: 2 template: metadata: labels: app: sample spec: containers: - name: mynode image: guest/mynode ports: - containerPort: 8888 rc用の設定ファイル ReplicationController(rc)の設定ファイルこのrcの識別名(開発者の命名) レプリケーション数の指定 Dockerイメージの指定(on DockerHub) ラベル(keyとvalue両方とも開発者の命名)
mynode-svc.yaml => apiVersion: v1 kind: Service metadata: name: frontend labels: app: sample spec: ports: - port: 8888 selector: app: sample サービス用の設定ファイル(selectorで mynode.yamlを参照する関係) サービス(svc)の設定ファイルこのサービスの識別名(開発者の命名) ラベル(開発者の命名) rc(やpod)のラベルでセレクト
起動は $ kubectl create -f mynode.yaml $ kubectl create -f mynode-svc.yaml 削除する時は $ kubectl delete -f mynode-svc.yaml $ kubectl delete -f mynode.yaml 設定ファイルによる起動および削除
まずrcを起動(=暗黙にpodを起動)してみます $ kubectl create -f mynode.yaml rcを起動(=暗黙にpodを起動)
podの確認 $ kubectl get --all-namespaces po NAMESPACE NAME READY STATUS RESTARTS AGE default k8s-master-127.0.0.1 4/4 Running 0 50m default k8s-proxy-127.0.0.1 1/1 Running 0 50m default my-node-ejvv9 1/1 Running 0 10s default my-node-lm62r 1/1 Running 0 10s kube-system kube-dns-v10-suqsw 4/4 Running 0 48m rcの確認 $ kubectl get --all-namespaces rc NAMESPACE NAME DESIRED CURRENT AGE default my-node 2 2 36s kube-system kube-dns-v10 1 1 49m podとrcの確認
サービス(svc)はまだ存在していません $ kubectl get --all-namespaces svc NAMESPACE NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE default kubernetes 10.0.0.1 <none> 443/TCP 51m kube-system kube-dns 10.0.0.10 <none> 53/UDP,53/TCP 49m エンドポイント(ep)もまだ存在しません $ kubectl get --all-namespaces ep NAMESPACE NAME ENDPOINTS AGE default kubernetes 10.140.0.14:6443 51m kube-system kube-dns 10.1.19.2:53,10.1.19.2:53 49m サービスとエンドポイントの確認
サービスを起動してみます $ kubectl create -f mynode-svc.yaml サービス(svc)の起動
サービス確認 $ kubectl get --all-namespaces svc NAMESPACE NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE default frontend 10.0.0.206 <none> 8888/TCP 21s default kubernetes 10.0.0.1 <none> 443/TCP 53m kube-system kube-dns 10.0.0.10 <none> 53/UDP,53/TCP 51m エンドポイント確認 $ kubectl get --all-namespaces ep NAMESPACE NAME ENDPOINTS AGE default frontend 10.1.19.3:8888,10.1.79.2:8888 58s default kubernetes 10.140.0.14:6443 53m kube-system kube-dns 10.1.19.2:53,10.1.19.2:53 52m サービスとエンドポイントの確認
サービスのIPアドレスにアクセス $ curl http://10.0.0.206:8888 Hello World アプリの動作確認
Podの確認 $ kubectl describe po my-node-ejvv9 Name: my-node-ejvv9 Namespace: default Node: ubuntu16k5/10.140.0.15 Start Time: Wed, 20 Jul 2016 09:23:11 +0000 Labels: app=sample Status: Running IP: 10.1.79.2 Controllers: ReplicationController/my-node Containers: mynode: Container ID: docker://daf3fb9f2217ef40226aab040bd64d6f6f0d5bdcd0318e5628e9af07adcb650 4 Image: guest/mynode 以下略 podの詳細
レプリケーションの確認 $ kubectl describe rc my-node Name: my-node Namespace: default Image(s): guest/mynode Selector: app=sample Labels: app=sample Replicas: 2 current / 2 desired Pods Status: 2 Running / 0 Waiting / 0 Succeeded / 0 Failed No volumes. Events: FirstSeen LastSeen Count From SubobjectPath Type Reason Message --------- -------- ----- ---- ----------- -- -------- ------ ------- 5m 5m 1 {replication-controller } Normal SuccessfulCreate Created pod: my-node-ejvv9 5m 5m 1 {replication-controller } Normal SuccessfulCreate Created pod: my-node-lm62r レプリケーション(rc)の確認
サービスの確認 $ kubectl describe svc frontend Name: frontend Namespace: default Labels: app=sample Selector: app=sample Type: ClusterIP IP: 10.0.0.206 Port: <unset> 8888/TCP Endpoints: 10.1.19.3:8888,10.1.79.2:8888 Session Affinity: None No events. サービスの詳細
エンドポイントの確認(:コンテナのIPアドレスの確認) $ kubectl describe ep frontend Name: frontend Namespace: default Labels: app=sample Subsets: Addresses: 10.1.19.3,10.1.79.2 NotReadyAddresses: <none> Ports: Name Port Protocol ---- ---- -------- <unset> 8888 TCP No events. エンドポイントの確認
$ kubectl scale --replicas=5 rc/my-node replicationcontroller "my-node" scaled rcのスケールアウト検証
$ kubectl get --all-namespaces rc NAMESPACE NAME DESIRED CURRENT AGE default my-node 5 5 7m kube-system kube-dns-v10 1 1 55m rcのスケールアウト検証の確認(1)
$ kubectl get --all-namespaces po NAMESPACE NAME READY STATUS RESTARTS AGE default k8s-master-127.0.0.1 4/4 Running 0 57m default k8s-proxy-127.0.0.1 1/1 Running 0 57m default my-node-3blsf 1/1 Running 0 39s default my-node-a2015 1/1 Running 0 39s default my-node-ejvv9 1/1 Running 0 7m default my-node-lm62r 1/1 Running 0 7m default my-node-u5gxt 1/1 Running 0 39s kube-system kube-dns-v10-suqsw 4/4 Running 0 56m rcのスケールアウト検証の確認(2)
$ kubectl get --all-namespaces ep NAMESPACE NAME ENDPOINTS AGE default frontend 10.1.19.3:8888,10.1.19.4:8888,10.1.79.2:8888 + 2 more... 5m default kubernetes 10.140.0.14:6443 58m kube-system kube-dns 10.1.19.2:53,10.1.19.2:53 56m rcのスケールアウト検証の確認(3)
$ kubectl describe ep frontend Name: frontend Namespace: default Labels: app=sample Subsets: Addresses: 10.1.19.3,10.1.19.4,10.1.79.2,10.1.79.3,10.1.79.4 NotReadyAddresses: <none> Ports: Name Port Protocol ---- ---- -------- <unset> 8888 TCP No events. 片方のホストに2つ(10.1.19.3,10.1.19.4)、もうひとつのホストに3つ (10.1.79.2,10.1.79.3,10.1.79.4)のpodがある RCのスケールアウト検証の確認(4)
podが増えようと、サービスとしての見え方は不変 $ kubectl get --all-namespaces svc NAMESPACE NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE default frontend 10.0.0.206 <none> 8888/TCP 5m default kubernetes 10.0.0.1 <none> 443/TCP 58m kube-system kube-dns 10.0.0.10 <none> 53/UDP,53/TCP 56m rcのスケールアウト検証の確認(5)
$ kubectl describe po my-node-3blsf Name: my-node-3blsf Namespace: default Node: ubuntu16k5/10.140.0.15 Start Time: Wed, 20 Jul 2016 09:29:54 +0000 (略) 個々のpodの物理位置の確認(Nodeの行)
$ kubectl exec -it my-node-3blsf sh => 別ホスト上のpodへもログイン可能なので、Dockerレベルのコンテナへのログイン(docker exec -it)より便利です特定podへログイン
$ kubectl logs my-node-3blsf tailfも可能 $ kubectl logs -f my-node-3blsf 特定podのログの確認
$ sudo docker ps |grep mynode 9b8ecdb7a42f guest/mynode "/bin/sh -c 'node ser" 15 minutes ago Up 15 minutes k8s_mynode.6062cb3_my-node-a2015_default_841729f4-4e5c-11e6- 930a-42010a8c000e_a8947e68 50e8cd85abec guest/mynode "/bin/sh -c 'node ser" 21 minutes ago Up 21 minutes k8s_mynode.6062cb3_my-node-lm62r_default_94564430-4e5b-11e6- 930a-42010a8c000e_bcf722c3 fyi, Dockerレベルでコンテナの詳細を確認 $ sudo docker inspect 9b8ecdb7a42f (略) fyi, Dockerレベルで確認
• たとえばDockerレベルでコンテナを落としたり、ホストOSからDockerコンテナ上のプロセスをkill • たとえば特定のマシン(VMインスタンス)を落とすテスト => レプリケーションの数が維持される特定のpodを落とすテスト
• 自作アプリをサービスとして起動しました • rcにより、pod(=コンテナ=プロセス)を複数インスタンス化しました • podのインスタンス数がどうあれ、サービスにはサービスのIPアドレスで常にアクセス可能です • 個々のpodの障害調査をしたければ、シェルで直接ログインしたりログの監視が可能ですここまでのまとめ
Kubernetesのネットワーク
各pod内からはサービス名つまり curl http://frontend:8888 でお互いが見えます => DNSが返すIPアドレスは、サービスのIPアドレス (DockerコンテナのIPアドレスでもないし、ホストのIPアドレスでもない) 名前解決(DNS)
$ dig @10.0.0.10 frontend.default.svc.cluster.local. (略) ;; ANSWER SECTION: frontend.default.svc.cluster.local. 30 IN A 10.0.0.206 => DNSのFQDNは frontend.default.svc.cluster.local. フォーマット: サービス名.ネームスペース名.svc.cluster.local. ホストからの名前解決
• ここまでの話: • DNSでサービス名からサービスのIPアドレスがひけるようになりました • ここからの話: • このサービスのIPアドレスから、サービスにひもづくpodにたどりつく必要があります • rcのメカニズムにより、サービスにひもづくpodは複数ありうるので、どこかのpodにたどりつく必要があります • 正確に言うと、pod内のコンテナにたどりつく必要がありますネットワーク詳解
• サービスのIPアドレスはifconfigの世界には存在しないアドレスです • iptablesで、サービスのIPアドレスからpod(=コンテナ)のアドレスへ宛先アドレスを書き換えます • rcのメカニズムで複数のpodがある場合、iptablesのロードバランス機能で振り分けます • iptablesにサービスのIPアドレスを追加するのはkube-proxy の役割です • pod(=コンテナ)のアドレス宛のパケットをホストのIPアドレス宛に変えるのはflanneldの役割です • (このルーティングテーブルはetcdに入っています) ネットワークの動作概要
10.0.0.206宛のパケットはiptablesでランダムに5つのどれかに行きます(rcのレプリカ数が5の場合): $ sudo iptables-save | grep 10.0.0.206 -A KUBE-SERVICES -d 10.0.0.206/32 -p tcp -m comment --comment "default/frontend: cluster IP" -m tcp - -dport 8888 -j KUBE-SVC-GYQQTB6TY565JPRW $ sudo iptables-save |grep KUBE-SVC-GYQQTB6TY565JPRW :KUBE-SVC-GYQQTB6TY565JPRW - [0:0] -A KUBE-SERVICES -d 10.0.0.206/32 -p tcp -m comment --comment "default/frontend: cluster IP" -m tcp - -dport 8888 -j KUBE-SVC-GYQQTB6TY565JPRW -A KUBE-SVC-GYQQTB6TY565JPRW -m comment --comment "default/frontend:" -m statistic --mode random -- probability 0.20000000019 -j KUBE-SEP-IABZAQPI4OCAAEYI -A KUBE-SVC-GYQQTB6TY565JPRW -m comment --comment "default/frontend:" -m statistic --mode random -- probability 0.25000000000 -j KUBE-SEP-KOOQP76EBZUHPEOS -A KUBE-SVC-GYQQTB6TY565JPRW -m comment --comment "default/frontend:" -m statistic --mode random -- probability 0.33332999982 -j KUBE-SEP-R2LUGYH3W6MZDZRV -A KUBE-SVC-GYQQTB6TY565JPRW -m comment --comment "default/frontend:" -m statistic --mode random -- probability 0.50000000000 -j KUBE-SEP-RHTBT7WLGW2VONI3 -A KUBE-SVC-GYQQTB6TY565JPRW -m comment --comment "default/frontend:" -j KUBE-SEP-DSHEFNPOTRMM5FWS iptablesを確認(1)
$ sudo iptables-save |grep KUBE-SEP-DSHEFNPOTRMM5FWS :KUBE-SEP-DSHEFNPOTRMM5FWS - [0:0] -A KUBE-SEP-DSHEFNPOTRMM5FWS -s 10.1.79.4/32 -m comment --comment "default/frontend:" -j KUBE-MARK-MASQ -A KUBE-SEP-DSHEFNPOTRMM5FWS -p tcp -m comment --comment "default/frontend:" -m tcp -j DNAT --to-destination 10.1.79.4:8888 -A KUBE-SVC-GYQQTB6TY565JPRW -m comment --comment "default/frontend:" -j KUBE-SEP-DSHEFNPOTRMM5FWS => ある確率で 10.0.0.206:8888宛のパケットは 10.1.79.4:8888 宛のパケットへ変換される iptablesを確認(2)
$ netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 0.0.0.0 10.140.0.1 0.0.0.0 UG 0 0 0 ens4 10.1.0.0 0.0.0.0 255.255.0.0 U 0 0 0 flannel0 10.1.19.0 0.0.0.0 255.255.255.0 U 0 0 0 docker0 10.140.0.1 0.0.0.0 255.255.255.255 UH 0 0 0 ens4 => 10.1.79.4:8888 宛のパケットはflanneldへ行くホストのルーティングテーブルを確認
$ etcdctl ls --recursive /coreos.com/network/subnets /coreos.com/network/subnets/10.1.19.0-24 /coreos.com/network/subnets/10.1.79.0-24 $ etcdctl get /coreos.com/network/subnets/10.1.79.0-24 {"PublicIP":"10.140.0.15"} => "10.140.0.15"は、10.1.79.0/24のpod(コンテナ)が動いているホストのIPアドレス flanneldのルーティングテーブルを確認
•iptablesでサービスのIPアドレス宛のパケットがpodのIPアドレス宛になる •pod宛のパケットはflanneldの力で、そのpodが動いているホスト宛のパケットになるここまでのまとめ
10.0.0.206をホストの外から叩けるようにするには、NodePort(or LoadBalancer)でポートを外に見せる mynode-svc.yaml => apiVersion: v1 kind: Service metadata: name: frontend labels: app: sample spec: type: NodePort ports: - port: 8888 selector: app: sample ホストの外にポートを公開するには動作は異なりますが、感覚的には Dockerでポートエクスポートする感じ
• Kubernetesは初見でかなり複雑怪奇に見えますが、きちんと分解すればなんとか理解できる(はず) • ちょっとした考察 • おかしなことが起きた時、プロセスは潔く死んだほうが Kubernetesに優しそうです • iptablesを使っている限り、負荷分散が(ラウンドロビンより) リッチになる見込みがない部分は賛否両論あるかもしれません (LBとしては、ある種の割り切り) まとめ
• メインのプログラミング言語: Java、JavaScript、Swift(一部) • 使っているミドルウェアの言語: Scala(Spark、Kafka)、 Go(Kubernetes) • OS(Linux)、JVM、アルゴリズム、ミドルウェア、ネットワーク、ブラウザそれぞれの専門家は歓迎します • 本物の機械学習ができるデータがあります(会社組織というアーキテクチャが分析対象) • 大規模開発(東京、大阪、上海、シンガポール、チェンナイ) なので、日本なんてどうでもいいと思うタフさ(鈍感さ)と抽象化して大枠をとらえる力があると良いと思います最後にJTFのスポンサーなので人材募集 (株式会社ワークスアプリケーションズ)

Check these out next

Kubernetesにまつわるエトセトラ（主に苦労話）

Recommended

More Related Content

Slideshows for you(20)

Viewers also liked(20)

Similar to Kubernetesにまつわるエトセトラ（主に苦労話）(20)

More from Works Applications(10)

Recently uploaded(20)

Kubernetesにまつわるエトセトラ（主に苦労話）