Cloud Native Developers JP Kubernetes Network Deep Dive! @hhiroshell 1

Cloud Native Developers JP お品書き • Kubernetesクラスター・ネットワークの全体像 • Pod Network • Service Network • クラスター外への公開 2

Cloud Native Developers JP Kubernetesクラスター・ネットワークの 全体像 3

Cloud Native Developers JP Kubernetesクラスター・ネットワークの全体像 名前 何をやってくれるのか 関連する Kubernetes Objects Pod Network クラスター内のPodに一意のクラスター内IP を割り当て、そのIPをもってクラスターの構 成要素が互いに通信できるようにする Pods Service Network 複数のPodに対するルーティングの制御と ロードバランシング Services, Endpoints クラスター外への公開 クラスター外からの通信を受け付けて、 Serviceオブジェクトに引き渡す ServicesのNodePortタイプ, ServicesのLoadBalancerタイプ, Ingress 4 • Kubernetesクラスター・ネットワークは3つに分けて考えると全体 像が捉え易い • 3つの機能の重ね合わせで全体の機能が実現される（詳しくは後述）

Cloud Native Developers JP Pod Network • Kubernetesのインフラとなるマシン群が、コンテナの実行環境に対 して提供するネットワークのこと • Kubernetesはこのようなネットワークの上にインストールされる （ので、Pod NetworkはKubernetesの機能には含まれない） • クラスター内のコンテナにIPを割り当てた場合に、そのIPをもって クラスターの構成要素からコンテナに到達できるようにする 5 Pod Pod Container 127.17.0.5 127.17.0.5 127.17.0.4 Container アクセスの起点が別のContainerだった場合の例

Cloud Native Developers JP Service Network • 複数のPodに対するルーティングとロードバランシングを実現する ネットワーク機構のこと • Kubernetesオブジェクト的にはServicesオブジェクトを利用 6 Pod Pod 10.102.34.153 Pod 127.17.0.6 127.17.0.5 Service: 10.102.34.153 127.17.0.4 Service 127.17.0.5 127.17.0.6 ※コンテナは省略

Cloud Native Developers JP クラスター外への公開 • クラスター外からの通信を受け付けられるようにして、Podとして 実現されたアプリケーションを外部に公開する • クラスター外からの通信は、Service Networkに引き渡されてPodに 到達する 7 クラスター 外の何か Pod 10.102.34.153 Pod 127.17.0.6 127.17.0.5 Service: 10.102.34.153 Service 127.17.0.5 127.17.0.6 LB 例えばロードバランサー ※コンテナは省略

Cloud Native Developers JP Pod Network 8

Cloud Native Developers JP Pod Network（再掲） • Kubernetesのインフラとなるマシン群が、コンテナの実行環境に対 して提供するネットワークのこと • Kubernetesはこのようなネットワークの上にインストールされる （ので、Pod NetworkはKubernetesの機能には含まれない） • クラスター内のコンテナにIPを割り当てた場合に、そのIPをもって クラスターの構成要素からコンテナに到達できるようにする 9 Pod Pod Container 127.17.0.5 127.17.0.5 127.17.0.4 Container アクセスの起点が別のContainerだった場合の例

Cloud Native Developers JP Pod Networkについてもう少し • Pod Networkが具体的に満たさなければならない要件 – 全てのコンテナがNATなしで他のコンテナに通信可能 – 全てのノードがNATなしで全てのコンテナに通信可能 – コンテナが自身のIPを参照するとき、他のコンテナから見たときと同じ結果 となる • アプリから見たときに、コンテナを使わない環境（複数のマシン上 にアプリ、DB等をインストール）のときと、ネットワーク的に同じ 条件を作っている。 ✓移行性に優れる ✓Dockerのネットワークに比較してシンプルで管理しやすい 10

Cloud Native Developers JP 11 Pod Networkの構成 Node Pod Container eth0: 10.100.0.2 docker0: 1.0.1.1 veth0: 1.0.1.2 Node Pod Container eth0: 10.100.0.3 docker0: 1.0.2.1 veth0: 1.0.2.2

Cloud Native Developers JP 12 Pod Networkの構成 Node Pod Container eth0: 10.100.0.2 docker0: 1.0.1.1 veth0: 1.0.1.2 Node Pod Container eth0: 10.100.0.3 docker0: 1.0.2.1 veth0: 1.0.2.2 Pod内のコンテナ群はひとつの仮想 NICを共有（1 Pod : 1 IP） コンテナ同士で同じPortは使えない cbr0仮想ブリッジが Podと物理NICを橋渡し Node間の通信を正しく配送する仕組み(Overlay Network)を用意する必要あり

Cloud Native Developers JP 13 Pod Networkを作るには Node Pod Container eth0: 10.100.0.2 docker0: 1.0.1.1 veth0: 1.0.1.2 Node Pod Container eth0: 10.100.0.3 docker0: 1.0.2.1 veth0: 1.0.2.2 この辺の構成は Kubernetesのプロセスが やってくれる Overlay NetworkをKubenetesとは別に用意する必要あり

Cloud Native Developers JP 14 Pod Networkが満たすべき要件 ① Node Pod Container eth0: 10.100.0.2 docker0: 1.0.1.1 veth0: 1.0.1.2 Node Pod Container eth0: 10.100.0.3 docker0: 1.0.2.1 veth0: 1.0.2.2 ① NATなしでコンテナ同士が通信可能 1.0.2.2

Cloud Native Developers JP 15 Pod Networkが満たすべき要件 ② Node Pod Container eth0: 10.100.0.2 docker0: 1.0.1.1 veth0: 1.0.1.2 Node Pod Container eth0: 10.100.0.3 docker0: 1.0.2.1 veth0: 1.0.2.2 Node内の プロセス ② NATなしでNodeからコンテナに通信可能 1.0.2.2

Cloud Native Developers JP 16 Pod Networkが満たすべき要件 ③ Node Pod Container eth0: 10.100.0.2 docker0: 1.0.1.1 veth0: 1.0.1.2 Node Pod Container eth0: 10.100.0.3 docker0: 1.0.2.1 veth0: 1.0.2.2 ③ 自身のIPを参照するとき、他のコンテナから見たときと同じ結果となる 1.0.2.2 1.0.2.2

Cloud Native Developers JP Overlay Networkの実現方式（代表的なもの） • Flannel – CoreOSによって開発。Kubernetesとの組み合わせの実績が豊富 – 物理ネットワーク上に仮想的なトンネルを構成してNode間通信を実現 • Google Compute EngineのAdvanced Routing – GCE固有の方式 – GCEのネットワークインフラに、PodのIPに対応したルーティングルールを構 成することでNode間通信を実現 • その他多数の実装あり。詳細は公式ドキュメントを参照 – https://kubernetes.io/docs/concepts/cluster-administration/networking/ 17

Cloud Native Developers JP Service Network 18

Cloud Native Developers JP Service Network • 複数のPodに対するルーティングとロードバランシングを実現する ネットワーク機構のこと • Kubernetesオブジェクト的にはServicesオブジェクトを利用 19 Pod Pod 10.102.34.153 Pod 127.17.0.6 127.17.0.5 Service: 10.102.34.153 127.17.0.4 Service 127.17.0.5 127.17.0.6

Cloud Native Developers JP 復習）Label/Label Selector • Kubernetes Objectをタグのよう な属性を設定して、グループ分け する仕組み • Label: – Kubernetes Objectにアタッチする key/valueペアのセット • Label Selector: – Labelの設定値の条件を指定する情報。 条件に該当するものをグループとして 識別する partition = customerA Label Selector "tier" : “web", "partition" : "customerA" "tier" : “app", "partition" : "customerA" "tier" : “web", "partition" : "customerB" Label 20

Cloud Native Developers JP 復習）Label/Label Selectorを使ったルーティング • Serviceがルーティング対象のPodを識別するために利用される サービス partition = customerA クラスター内外か らのリクエスト 21

Cloud Native Developers JP Kubernetesを少し触っていると思うこと • Serviceオブジェクトを使って通信のルーティングとロードバランス が実現されている • でもクラスター内にロードバランサやスイッチの実態があるわけで はない。そんなコンテナが動いている様子もない • Serviceオブジェクトの実態は何なのか ？ 22

Cloud Native Developers JP 23 Serviceを経由する通信の実際の動き Node Pod Container eth0: 10.100.0.2 docker0: 1.0.1.1 veth0: 1.0.1.2 Node Pod Container eth0: 10.100.0.3 docker0: 1.0.2.1 veth0: 1.0.2.2 10.3.241.152 サービス宛のパケットを 送出 iptables iptables

Cloud Native Developers JP 24 Serviceを経由する通信の実際の動き Node Pod Container eth0: 10.100.0.2 docker0: 1.0.1.1 veth0: 1.0.1.2 Node Pod Container eth0: 10.100.0.3 docker0: 1.0.2.1 veth0: 1.0.2.2 10.3.241.152 iptablesにより宛先をPod に書き換え iptables iptables

Cloud Native Developers JP 25 Serviceを経由する通信の実際の動き Node Pod Container eth0: 10.100.0.2 docker0: 1.0.1.1 veth0: 1.0.1.2 Node Pod Container eth0: 10.100.0.3 docker0: 1.0.2.1 veth0: 1.0.2.2 1.0.2.2 iptablesにより宛先をPod に書き換え iptables iptables

Cloud Native Developers JP 26 Serviceを経由する通信の実際の動き Node Pod Container eth0: 10.100.0.2 docker0: 1.0.1.1 veth0: 1.0.1.2 Node Pod Container eth0: 10.100.0.3 docker0: 1.0.2.1 veth0: 1.0.2.2 1.0.2.2 ここから先はPod Networkが 仕事をしてくれる iptables iptables

Cloud Native Developers JP iptablesとkube-proxy（Proxy-mode: iptablesの場合） • Serviceオブジェクトの実態は、iptablesとkube-proxy – Serviceオブジェクトが作成されると、Label/LabelSelectorなどの内容に従っ て、kube-proxyがNode上のiptablesを更新する – Serviceオブジェクト宛のパケットは、iptablesの内容に従って宛先をPodのIP に変更して送信される 27 Node Pod eth0: 10.100.0.2 docker0: 1.0.1.1 veth0: 1.0.1.2 iptables kube-proxy apiserver >_ kubectl サービス作成 kube-proxyが検知 iptablesを更新

Cloud Native Developers JP iptablesの中身を見てみます • （次ページへ） 28

Cloud Native Developers JP 29 core@master ~ $ sudo iptables -t nat -nL KUBE-SERVICES Chain KUBE-SERVICES (2 references) target prot opt source destination KUBE-SVC-ERIFXISQEP7F7OF4 tcp -- 0.0.0.0/0 10.100.0.10 tcp dpt:53 KUBE-SVC-FXLGR4ACHNVPGVKC tcp -- 0.0.0.0/0 10.100.165.46 tcp dpt:80 KUBE-SVC-NPX46M4PTMTKRN6Y tcp -- 0.0.0.0/0 10.100.0.1 tcp dpt:443 KUBE-SVC-TCOU7JCQXEZGVUNU udp -- 0.0.0.0/0 10.100.0.10 udp dpt:53 KUBE-NODEPORTS all -- 0.0.0.0/0 0.0.0.0/0 ADDRTYPE match dst-type core@master ~ $ sudo iptables -t nat -nL KUBE-SVC-FXLGR4ACHNVPGVKC Chain KUBE-SVC-FXLGR4ACHNVPGVKC (1 references) target prot opt source destination KUBE-SEP-3O2637RFZBCDAJGA all -- 0.0.0.0/0 0.0.0.0/0 statistic mode random probability 0.50 KUBE-SEP-YV4GLKIWPGUCNDUG all -- 0.0.0.0/0 0.0.0.0/0

Cloud Native Developers JP 30 core@master ~ $ sudo iptables -t nat -nL KUBE-SEP-3O2637RFZBCDAJGA Chain KUBE-SEP-3O2637RFZBCDAJGA (1 references) target prot opt source destination KUBE-MARK-MASQ all -- 10.244.70.3 0.0.0.0/0 DNAT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp to:10.244.70.3:80 core@master ~ $ sudo iptables -t nat -nL KUBE-SEP-YV4GLKIWPGUCNDUG Chain KUBE-SEP-YV4GLKIWPGUCNDUG (1 references) target prot opt source destination KUBE-MARK-MASQ all -- 10.244.70.4 0.0.0.0/0 DNAT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp to:10.244.70.4:80

Cloud Native Developers JP Proxy-mode • Serviceを実現する仕組みは3種類ある – Proxy-mode: userspace • v1.1までのデフォルト • kube-proxyがルーティングに割り込む。userspace/kernelspaceのスイッチが発生するの で、パフォーマンスと信頼性においてiptablesに比べて不利 – Proxy-mode: iptables • v1.2+のデフォルト • iptablesを更新しておいて、あとのルーティングはカーネル任せ • ルーティング先のPodが上がっているかどうかは気にしない（できない）のでreadiness probesをちゃんと利用する必要あり – Proxy-mode: ipvs • 1.10時点でbeta。IPVSカーネルモジュールを利用する方式らしい 31

Cloud Native Developers JP Kubernetesオブジェクトの世界でもう少し詳しく • 通常Serviceを作成するとEndpointsも作られる • Endpointsルーティング先の実態が存在する場合に、それに対するア クセスポイントを表すもの – Label/Label Selectorによって、ルーティング先のPodが決まる場合、それが Endpointsとして反映される 32 Pod Pod 127.17.0.6 127.17.0.5 Service 10.102.34.153 Endpoint 127.17.0.5 127.17.0.6 Pod

Cloud Native Developers JP DNS • クラスター内のDNSとして機能するKubernetesのアドオン • kube-dns, core-dnsがよく使われる • DNSによる名前解決を使うことで、クラスター内で通信を行う際に ドメイン名を利用することができる 33

Cloud Native Developers JP ドメイン名の命名規則 • [Service名].[Namespace名].svc.cluster.local – .svc.cluster.local は省略可 – 同じネームスペース内からなら、[ネームスペース名]以降を全て省略可 • _[Port名]._[Protocol名].[Service名].[Namespace名].svc.cluster.local – ServiceのPortに”mane”を設定して作成した場合に、そのPort毎に作成される 34

Cloud Native Developers JP Headless Service • clusterIP: Noneを指定して作成するServiceオブジェクト • Label/LabelSelectorで紐づくPodに対して、直接ドメイン名を割り 当てることができる（ServiceのIPに対してではない） • Kubernetesのルーティング機能の影響を避けたい場合に使う – ステートフルなPodを使っていて、必ず特定のPodにアクセスするようにした い – 独自のディスカバリの仕組みを利用したい 35

Cloud Native Developers JP Headless Serviceの使い方の例 - MySQLの冗長構成 • Service(Headless) – 書き込みは必ずMasterにルー ティング • Service(ClusterIP) – Read Replicaにアクセスを分 散。スケールアウトしても自 動でルーティング対象に 36 MySQL Master Read Replica Read Replica ストレージ サービス Kubernetesクラスター R Service (ClusterIP) Service (Headless) アプリ W

Cloud Native Developers JP クラスター外への公開 37

Cloud Native Developers JP クラスター外への公開 • クラスター外からの通信を受け付けられるようにして、Podとして 実現されたアプリケーションを外部に公開する • クラスター外からの通信は、Service Networkに引き渡されてPodに 到達する 38 クラスター 外の何か Pod 10.102.34.153 Pod 127.17.0.6 127.17.0.5 Service: 10.102.34.153 Service 127.17.0.5 127.17.0.6 外部からのアクセスを 受け入れるポイント

Cloud Native Developers JP 39 クラスター外から入る通信の実際の動き Node Pod Container eth0: 10.100.0.2 docker0: 1.0.1.1 veth0: 1.0.1.2 Node Pod Container eth0: 10.100.0.3 docker0: 1.0.2.1 veth0: 1.0.2.2 iptables iptables 30000 30000 各Nodeの30000番ポートが開 放されている状態

Cloud Native Developers JP 40 クラスター外から入る通信の実際の動き Node Pod Container eth0: 10.100.0.2 docker0: 1.0.1.1 veth0: 1.0.1.2 Node Pod Container eth0: 10.100.0.3 docker0: 1.0.2.1 veth0: 1.0.2.2 iptables iptables 10.100.0.2:30000 30000 30000 外部からの通信が入ってくる

Cloud Native Developers JP 41 クラスター外から入る通信の実際の動き Node Pod Container eth0: 10.100.0.2 docker0: 1.0.1.1 veth0: 1.0.1.2 Node Pod Container eth0: 10.100.0.3 docker0: 1.0.2.1 veth0: 1.0.2.2 iptables 10.100.0.2:30000 iptables 30000 30000 iptablesにより宛先をPodに書 き換え

Cloud Native Developers JP 42 クラスター外から入る通信の実際の動き Node Pod Container eth0: 10.100.0.2 docker0: 1.0.1.1 veth0: 1.0.1.2 Node Pod Container eth0: 10.100.0.3 docker0: 1.0.2.1 veth0: 1.0.2.2 iptables iptables 1.0.2.2 30000 30000 iptablesにより宛先をPodに書 き換え

Cloud Native Developers JP 43 Serviceを経由する通信の実際の動き Node Pod Container eth0: 10.100.0.2 docker0: 1.0.1.1 veth0: 1.0.1.2 Node Pod Container eth0: 10.100.0.3 docker0: 1.0.2.1 veth0: 1.0.2.2 1.0.2.2 iptables iptables 30000 30000 ここから先はPod Networkが 仕事をしてくれる

Cloud Native Developers JP クラスター外からアクセス受け入れる方法 • クラスター外からのアクセスをNodeが受け入れるようにするには、 用途に応じて何通りかの方法がある – ServiceのNodePortタイプ – ServiceのLoadBarancerタイプ – Ingress (beta)

Cloud Native Developers JP ServiceのNodePortタイプ • 対象のPodにルーティングされる口を、各Node上に構成する • ポート番号は、各ノードで共通 クラスター外から のリクエスト 172.17.8.104 172.17.8.103 172.17.8.102 172.17.8.104:30159 172.17.8.102:30159 172.17.8.103:30159

Cloud Native Developers JP ServiceのLoadBalancerタイプ • クラウド・プロバイダが提供するLBサービスを自動構成 • クラスター内にはNodePortまたはClusterIPと同等のServiceを構成 • Serviceオブジェクト以上のことをLBに設定することはできない – つまりL3-4相当 クラスター外から のリクエスト LB

Cloud Native Developers JP Ingress (beta) • ロードバランシング、SSL/TLS終端等の機能を提供（L7相当） • Ingressオブジェクトは構成情報を定義するだけのリソース。実際の動作 を担う実態は、Ingress Controllerがプロビジョニングしてくれる – NGINXを利用した「NGiNX Ingress Controller」、GCPのLBを利用するGCE 「LoadBalancer Controller」がある Pod Pod Pod (nginx) Ingress Ingress Controller Ingressを作成 クラスター 外の何か LBの実態を作成、クラスター内への入り口を用意 Service

Cloud Native Developers JP まとめ 48

Cloud Native Developers JP Kubernetesクラスター・ネットワークの全体像 名前 何をやってくれるのか 関連する Kubernetes Objects Pod Network クラスター内のPodに一意のクラスター内IP を割り当て、そのIPをもってクラスターの構 成要素が互いに通信できるようにする Pods Service Network 複数のPodに対するルーティングの制御と ロードバランシング Services, Endpoints クラスター外への公開 クラスター外からの通信を受け付けて、 Serviceオブジェクトに引き渡す ServicesのNodePortタイプ, ServicesのLoadBalancerタイプ, Ingress 49 • Kubernetesクラスター・ネットワークは3つに分けて考えると全体 像が捉え易い • 3つの機能の重ね合わせで全体の機能が実現される（詳しくは後述）

Cloud Native Developers JP Fin. 50