はじめに
KubernetesのCalicoを選択した際、インストール時に自動で生成されるippool。
本記事ではippoolの役割とその動きについて、kubeadmでインストールしたクラスターを例に分かりやすく解説しました。
環境情報
- kubectl v1.23
- docker.io/calico/kube-controllers:v3.21.4
ippoolの主な役割
Namespace毎ではないリソースとして存在するIPPoolですが
# kubectl api-resources --namespaced=false NAME SHORTNAMES APIVERSION NAMESPACED KIND ... ippools crd.projectcalico.org/v1 false IPPool ...
以下のようにCalicoインストール時に生成されています。
# kubectl describe ippools Name: default-ipv4-ippool Namespace: Labels: <none> Annotations: projectcalico.org/metadata: {"uid":"...","creationTimestamp":"...Z"} API Version: crd.projectcalico.org/v1 Kind: IPPool Metadata: ... Spec: Allowed Uses: Workload Tunnel Block Size: 26 Cidr: 172.16.0.0/16 Ipip Mode: Always Nat Outgoing: true Node Selector: all() Vxlan Mode: Never Events: <none>
そんな同リソースですが主な役割はPodのIPレンジを規定することにあり、具体的にはCidrに記載のあるレンジにてPodのIPアドレスが割り当てられます。
実機での確認
同クラスターにて起動しているPodのIPを確認すると、確かに同レンジの範囲内で採番されていて
# kubectl get pod -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES mynginx-xx-xx 1/1 Running 0 ... 172.16.156.12 ... <none> <none>
Nodeのルーティングテーブルにも同レンジに対する経路が定義されています。
# ip route ... 172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1
そして同172.17.0.1はコンテナのbridgeのIPとも一致していました。
# docker network inspect [ { "Name": "bridge", ... "Config": [ { "Subnet": "172.17.0.0/16", "Gateway": "172.17.0.1" } ] }, ... ]
終わりに
CalicoにおけるPodのIPレンジは同リソースの値を確認することで把握できます。
kubeadmではインストール時に動的に変更ができますが、それを変更することで同リソースの値も書き換わります。
以上、ご参考になれば幸いです。