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

Pocket

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つだけ。

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

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

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 と書かれているようにテスト用のクラスタなのでノードの削除をそこまで考慮していない、ということなのではないかな。

Leave a Reply

Your email address will not be published. Required fields are marked *