はじめに
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ではインストール時に動的に変更ができますが、それを変更することで同リソースの値も書き換わります。
以上、ご参考になれば幸いです。