kindにkindnetdというCNIプラグインが同梱されていた

kindを使っているときに、ふとkindで使われるCNIプラグインって何だろうと思って見てみたところ、kindnetdというものが動いていたので調べた。

NAME READY STATUS RESTARTS AGE

kindnet-5gfch 1/1 Running 0 140m

kindnet-fmp2r 1/1 Running 0 140m

kindnet-httpn 1/1 Running 0 140m

kindnet-nsqc6 1/1 Running 0 140m

名前から察するに、kind専用のように見える。DaemonSetを調べて、使われているイメージを見る。

$ k -n kube-system get ds kindnet -o yaml | grep "image:"

        image: kindest/kindnetd:0.5.3

kindest/kindnetd だった。コードはどこかというと、kubernetes-sigs/kindリポジトリの中にある（ link ）。ということで、これを読めばkindnetdが何をしているのか、分かるはず。コードの量も少なそうだ。

.

├── Dockerfile

├── VERSION

├── build.sh

├── cmd

│   └── kindnetd

│   ├── cni.go

│   ├── main.go

│   ├── masq.go

│   └── routes.go

├── go.mod

├── go.sum

└── push-cross.sh



2 directories, 10 files

cmd/kindnetd/main.goを見ると、kindnetdについての説明がコメントで書かれている。

// kindnetd is a simple networking daemon to complete kind's CNI implementation

// kindnetd will ensure routes to the other node's PodCIDR via their InternalIP

// kindnetd will ensure pod to pod communication will not be masquerade

// kindnetd will also write a templated cni config supplied with PodCIDR

//

// input envs:

// - HOST_IP: should be populated by downward API

// - POD_IP: should be populated by downward API

// - CNI_CONFIG_TEMPLATE: the cni .conflist template, run with {{ .PodCIDR }}

つまり、kindnetdはkindのCNI実装をコンプリートするためのシンプルなネットワーク用デーモンということらしい。やることはシンプルで、以下の3つだけ。

他ノードのインターナルIPアドレスを経由する、PodCIDRへのルーティングを設定する
マスカレードなしでPod間通信を行えるようにする
CNIコンフィグを書き込む

workerに入ってルーティングをみてみると、以下の通りであった。172.17.0.0/16がノードネットワークで、10.244.0.0/24や10.244.1.0/24はノード毎のPodCIDR。このクラスタはworker nodeが３台なので、２台へのルーティング設定が存在しているということになる。

default via 172.17.0.1 dev eth0

10.244.0.0/24 via 172.17.0.5 dev eth0

10.244.1.0/24 via 172.17.0.2 dev eth0

10.244.2.2 dev veth5fc1b103 scope host

10.244.2.4 dev veth00c929dc scope host

10.244.3.0/24 via 172.17.0.4 dev eth0

172.17.0.0/16 dev eth0 proto kernel scope link src 172.17.0.3

ルーティングの同期を行うsyncRoute関数がルーティングの追加は行うが削除は行わない点が少し面白い。kindの説明に local clusters for testing Kubernetes と書かれているようにテスト用のクラスタなのでノードの削除をそこまで考慮していない、ということなのではないかな。