#初めに
「kubernetes the hard way を PC でやってみる」の１３回目、「Pod Network」についてです。（目次）

各ノード上で稼働する Pod は、各ノードの POD CIDR から IP アドレスが割り振られていきます。
それらの間での通信ができるように　CNI (に相当するもの）を構成します。
一般的には kubernetes のネットワークを構成する場合、
flannel や calico などで提供される CNI プラグインを利用しますが
kubernetes the hard way ではその代わりにルーティング設定で代替しています。
そのため、kubernetes the hard way で構築したクラスターでは、CNI が持つ Network Policy については利用できません。

この回は非常にハマりました、一見うまくいっているように見えて疎通はできない、という事象になり
さんざん調べてようやく解決した時に振り返って考えると、いかに自分が NW 構成を理解していないかを痛感しました。
ハマった内容については例によって末尾に記載します。。。　まぁまだ間違っているかもしれませんが…

やることは以下の通りです。　今回はワーカーノードで実施しています

ルーティングの追加

なんとこれだけですね。なのに私は全くうまくいかなかったという。。。

ルーティングの追加

kubernetes the hard way では、 google cloud のコマンドを使ってルーティングを追加しているようですが、
私には全くわかりませんでした。。。

オンプレ ubuntu でルーティングを追加する場合、（いろいろやり方はあるのでしょうが)
netplan を使って追加するという手段があるようです。 NetworkManager 派なので知りませんでした。

さて、肝心の追加内容は以下の通りです。　（図の赤矢印は k8sworker0 について記載しており、
k8sworker1,2 もそれぞれ自分の POD_CIDR 以外は他のノードにルーティングするように設定します。)
※ 細かく追えるように、IP アドレスも記入していますが、要は赤い矢印についてだな、ぐらいの認識で OK です）

##ルーティング設定内容

表のデータ部1行目を例にとって説明すると、
k8sworker0 ( 192.168.199.210 ) が持っている POD_CIDR (10.200.0.0/24) への外部からの通信は、
k8sworker0 の IP にルーティングを行うように、 k8sworker1,2 に登録する、ということです。
逆の見方をすると、　自ノードが持つ POD_CIDR 向けは IPtables が転送してくれるのでルーティングテーブルとして登録しない、とも言えます。
（※ 自ノードの POD_CIDR 向けは POD 作成時に cnio0 向けとして自動的に作成されるようです)

ターゲットNW	ルーティング先	k8sworker0	k8sworker1	k8sworker2	図
10.200.0.0/24	192.168.199.210		〇	〇
10.200.1.0/24	192.168.199.211	〇		〇	①
10.200.2.0/24	192.168.199.212	〇	〇		②

##ルーティング設定方法

netplan でのルーティング設定方法は
/etc/netplan/*.conf を修正して、 netplan apply を実行します。
(以下は k8sworker0 の例で、 routes: 部分を追記しています。
k8sworker0 に不要な部分はコメントアウトしています。
k8sworker1,2 ではコメントアウトする部分が変わってきます)

# cd /etc/netplan/
# ls
00-installer-config.yaml

# vi 00-installer-config.yaml
# This is the network config written by 'subiquity'
network:
  ethernets:
    enp1s0:
      addresses:
      - 192.168.199.210/24
      gateway4: 192.168.199.254
      nameservers:
        addresses:
        - 192.168.199.254
      routes:
          #      - to: 10.200.0.0/24
          #        via: 192.168.199.210
      - to: 10.200.1.0/24
        via: 192.168.199.211
      - to: 10.200.2.0/24
        via: 192.168.199.212
  version: 2

適用します。

# netplan apply

# ip route
default via 192.168.199.254 dev enp1s0 proto static
10.200.1.0/24 via 192.168.199.211 dev enp1s0 proto static
10.200.2.0/24 via 192.168.199.212 dev enp1s0 proto static
192.168.199.0/24 dev enp1s0 proto kernel scope link src 192.168.199.210

10.200.1.0/24, 10.200.2.0/24 が追加されていることがわかります。
作業は以上で終了です。　以下は細かい補足なので興味があればどうぞ。

##インターフェース/ルーティングテーブル関連の補足
ルーティング追加は上記でよいですが、　POD を作成するとどう変わるかを見ておきましょう。

k8sworker0 に上記ルーティング設定をした後のインターフェースの状況は以下のようになっています。

# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 52:54:00:a9:a0:82 brd ff:ff:ff:ff:ff:ff
    inet 192.168.199.210/24 brd 192.168.199.255 scope global enp1s0
       valid_lft forever preferred_lft forever

ループバックを除くと enp1s0 のみです。

ここで、k8sworker0 上で POD ができたときにどうなるかを見てみます。

busybox の Pod を立ててみました。
（手順略...　deployment で replica 3 に指定すれば多分どの worker にも乗るでしょう的な...まぁ手抜きです。）

# kubectl get pods -o wide
NAME                       READY   STATUS    RESTARTS   AGE   IP             NODE         NOMINATED NODE   READINESS GATES
busybox-c44c795b6-kqx5v    1/1     Running   0          14m   10.200.1.141   k8sworker1   <none>           <none>
busybox-c44c795b6-r2qk9    1/1     Running   0          14m   10.200.0.3     k8sworker0   <none>           <none>
busybox-c44c795b6-vsmpb    1/1     Running   0          14m   10.200.2.216   k8sworker2   <none>           <none>

さて、インターフェースですが、以下のように cnio0 と vethXX ができています。
なお、 cnio0 は POD から接続される bridge で、1個だけですが、 vethXX は POD ごとに1個作成されます。
POD削除時には、vethXX は消えますが、POD をすべて消しても cnio0 は残るようです。

# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 52:54:00:a9:a0:82 brd ff:ff:ff:ff:ff:ff
    inet 192.168.199.210/24 brd 192.168.199.255 scope global enp1s0
       valid_lft forever preferred_lft forever
3: cnio0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether ba:a2:c1:d2:ec:ad brd ff:ff:ff:ff:ff:ff
    inet 10.200.0.1/24 brd 10.200.0.255 scope global cnio0
       valid_lft forever preferred_lft forever
8: vethda1293e1@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master cnio0 state UP group default
    link/ether d2:4a:ce:16:16:67 brd ff:ff:ff:ff:ff:ff link-netns cni-9b15f61b-eca0-0ded-9dd3-19ac3306daba

ルーティングテーブル上には、 k8sworker0 の POD_CIDR (10.200.0.0/24) が cnio0 に行くようになっています。
これが図でいう③の部分に該当します。
実際には iptables で NAT されているようなのですが、ここでは割愛します。
余力があれば別途確認しま。。。す。。　かもしれない？

# ip route
default via 192.168.199.254 dev enp1s0 proto static
10.200.0.0/24 dev cnio0 proto kernel scope link src 10.200.0.1
10.200.1.0/24 via 192.168.199.211 dev enp1s0 proto static
10.200.2.0/24 via 192.168.199.212 dev enp1s0 proto static
192.168.199.0/24 dev enp1s0 proto kernel scope link src 192.168.199.210

さらにさらに、作成した POD の中のインターフェースを見てみると
eth0@if8 となっています。この if8 が、　ワーカーノード上の ip addr で表示される番号と対応しています。
また、 8: vethda1293e1@if3 の if3 が 3: cnio0 とつながっている、という感じで追いかけることができます。
（なぜ 8 なの、という話ですが、 POD を作った際に次の番号がどんどんふられていき、
POD を消すとインターフェースもきえるため歯抜けになっていくんですね。
簡単に POD を立てます、とか言いつつ、 4-7 は失敗してやり直したわけだな、と思われてしまうわけですね）

# kubectl exec -it busybox-c44c795b6-r2qk9 ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
3: eth0@if8: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue
    link/ether 4e:46:66:bd:b5:7f brd ff:ff:ff:ff:ff:ff
    inet 10.200.0.3/24 brd 10.200.0.255 scope global eth0
       valid_lft forever preferred_lft forever

ネットワークについても少しはイメージがわきましたね。わいたはずです。わいたことにしてください。

#エラー・並びに調査・対応方法

さて、恒例の ~~黒歴史~~ トラブル内容紹介です。
先に何を間違えたのかを記載しておくと

そもそもマスターでやっていた（論外）
ルーティング設定で自分の POD_CIDR も自分の NIC に転送するよう設定した

1点は、後から考えるとおバカだな、ぐらいの話しではありますが
実際にやっている最中はなかなか気づきません（と言い訳させてください）

2点目です。

ネットワークの設定完了後、疎通できるかどうかを確認すると思います。その途中で NW 疎通ができないことがわかりました。
調査の実施内容は以下の通りです。
結果を見ると、かなり遠回りしている印象ですが、実際の障害の時はそんなものかな、という気もします。
NW 疎通がおかしいなら、自分が実施した NW 設定（ここではルーティング）がおかしい、と
考えることができれば早かったかもしれません。
（ただ、kubernetes the hard way を見ると、3つのルーティング設定が同列に扱われているように見えるので
　オンプレでのルーティング設定もそうなんだろうとの思い込みがありました。。。）

各ノードへのPOD の配置 (deployment の作成)
POD 内から別ノード上のPOD への ping 疎通　（異常の確認）
POD 内から POD のデフォルトゲートウェイへの疎通確認
POD 外から別ノード上の cnio0 （POD_CIDR のGW IP）への疎通確認

疎通ができないことがわかれば、あとはどこまで届いているのかを1つずつ確認していくことになりますが
その際に、上図のような構成が頭にないと分からない、ということになります。

POD の準備

3ノードの上にそれぞれ busybox の POD を立てて、疎通を確認しますが、
簡単に実施するのであれば deployment を作成し、 replica 数を増やせば各ノードに配置されると思います。
作成方法は kubectl apply -f ファイル名 で。
なお、 v1.16 であれば、 kubectl run busybox --image=busybox --restart=Always --replicas=3 -o yaml --dry-run --command -- sleep 3600 で yaml ファイルを生成できます（というか、--dry-run を外せば作成される）が、 v1.18 ではこのコマンドは使えず、 kubectl create deployment をベースとして yaml ファイルを作成する必要があります。
ここは面倒なところですね。

apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    run: busybox
  name: busybox
spec:
  replicas: 3
  selector:
    matchLabels:
      run: busybox
  strategy: {}
  template:
    metadata:
      creationTimestamp: null
      labels:
        run: busybox
    spec:
      containers:
      - command:
        - sleep
        - "3600"
        image: busybox
        name: busybox
        resources: {}
status: {}

Pod が出来たら、 kubectl get pods -o wide で、調べたいノード上の POD を確認します。（IPも出ています）

# kubectl get pods -o wide
NAME                      READY   STATUS    RESTARTS   AGE   IP             NODE         NOMINATED NODE   READINESS GATES
busybox-c44c795b6-5rg4h   1/1     Running   0          10s   10.200.2.218   k8sworker2   <none>           <none>
busybox-c44c795b6-btf4v   1/1     Running   0          10s   10.200.1.143   k8sworker1   <none>           <none>
busybox-c44c795b6-wh2cw   1/1     Running   0          10s   10.200.0.5     k8sworker0   <none>           <none>

Pod 内からの確認

これは定番なので覚えておきましょう。

# kubectl exec -it busybox-c44c795b6-wh2cw /bin/sh
/ #

IP / route を確認します。

/ # ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
3: eth0@if10: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue
    link/ether aa:f3:e9:62:35:2c brd ff:ff:ff:ff:ff:ff
    inet 10.200.0.5/24 brd 10.200.0.255 scope global eth0
       valid_lft forever preferred_lft forever

/ # ip route
default via 10.200.0.1 dev eth0
10.200.0.0/24 dev eth0 scope link  src 10.200.0.5
/ #

自分自身への ping 確認(記載省略)ののち、　デフォルトゲートウェイへの ping を行います。

/ # ping 10.200.0.1
PING 10.200.0.1 (10.200.0.1): 56 data bytes
^C
--- 10.200.0.1 ping statistics ---
5 packets transmitted, 0 packets received, 100% packet loss

飛んでいません。　いろいろと調べてわからない状態が続くと、
「もしかしてコンテナの世界ではデフォルトゲートウェイには ping が飛ばないのが普通なのでは？」などという
妄想がわいてきますがそんなことはありません。
疲れているとおかしなことを考えてしまうものです。そういう時は休みましょう。

デフォルトゲートウェイへの ping が飛ばない状態ですが、
コンテナ内の ip addr や ip route にそんなにおかしいようには思えない。

そのため、一旦コンテナの中には問題ないと仮定して、外からの確認に移ります。

POD 外からの確認

k8sworker0 の OS 上から他のノードの POD にアクセスできるかを確認します。
k8sworker0 から k8sworker1,2 の cni0 (それぞれ 10.200.1.1, 10.200.2.1 ) に ping し、応答があります。

root@k8sworker01:/etc/cni/net.d# ping 10.200.1.1
PING 10.200.1.1 (10.200.1.1) 56(84) bytes of data.
64 bytes from 10.200.1.1: icmp_seq=1 ttl=64 time=0.762 ms
64 bytes from 10.200.1.1: icmp_seq=2 ttl=64 time=0.294 ms
64 bytes from 10.200.1.1: icmp_seq=3 ttl=64 time=0.324 ms
^C
--- 10.200.1.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2047ms
rtt min/avg/max/mdev = 0.294/0.460/0.762/0.213 ms


root@k8sworker01:/etc/cni/net.d# ping 10.200.2.1
PING 10.200.2.1 (10.200.2.1) 56(84) bytes of data.
64 bytes from 10.200.2.1: icmp_seq=1 ttl=64 time=0.516 ms
64 bytes from 10.200.2.1: icmp_seq=2 ttl=64 time=0.408 ms
64 bytes from 10.200.2.1: icmp_seq=3 ttl=64 time=0.252 ms
^C
--- 10.200.2.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2031ms
rtt min/avg/max/mdev = 0.252/0.392/0.516/0.108 ms

ここまでで、　他のノードに関する通信は問題が無いことがわかります。
他のノードへの通信が問題なく、自ノード（のコンテナ）のみに疎通異常がある、ということで
その転送を行っている iptables を疑うわけですが、、、

そもそも iptables がおかしい (kubernetes による iptables のコントロールがおかしい) などということがあるだろうか？

と考え、それよりも自分の設定がおかしいと考えるほうが可能性が高い、と思い、ルーティングテーブルを確認しました。

root@k8sworker01:# ip route show
default via 192.168.199.254 dev enp1s0 proto static
10.200.0.0/24 via 192.168.199.211 dev enp1s0 proto static
10.200.0.0/24 dev cnio0 proto kernel scope link src 10.200.0.1
10.200.1.0/24 via 192.168.199.212 dev enp1s0 proto static
10.200.2.0/24 via 192.168.199.213 dev enp1s0 proto static
192.168.199.0/24 dev enp1s0 proto kernel scope link src 192.168.199.211

10.200.0.0/24 (自ノードの POD_CIDR) へのルートが重複していますね。
ここがおかしいのではないか？となります。

（なお、最初に POD を起動するまでは、 cnio0 に関するルートが無い、下記のような状態なので気づきませんでした
　kubernetes the hard way の Provisioning Pod Network Routes を見ると、　
下記のようなルーティングテーブルもなんとなく正しく思えます。。。

※間違い
# ip route show
default via 192.168.199.254 dev enp1s0 proto static
10.200.0.0/24 via 192.168.199.211 dev enp1s0 proto static
10.200.1.0/24 via 192.168.199.212 dev enp1s0 proto static
10.200.2.0/24 via 192.168.199.213 dev enp1s0 proto static
192.168.199.0/24 dev enp1s0 proto kernel scope link src 192.168.199.211

間違いに気づけば、あとは netplan のルーティング設定を見直して修正し、
問題解消を確認しました。
（設定ファイルで 3台分入れて、自ノード分をコメントアウトしているのは
効率を考えたわけではなく、最初は3つ設定していた、ということなんですね。。。）　

今回はここまでとして、次回は CoreDNS の部分を実施します。

← １２．kubectl
↑ 目次
→ １４．CoreDNS