DS
если поднять кластер kubeadm init ... с ключем --pod-network-cidr 10.244.0.0/16, то
kubectl describe no controller-1
показывает в выводе есть такие строки
PodCIDR: 10.244.0.0/24тут ок. далее
PodCIDRs: 10.244.0.0/24
если поднять кластер kubeadm init ... БЕЗ ключа --pod-network-cidr и потом отредактировать
vi /etc/kubernetes/manifests/kube-controller-manager.yaml
дождаться когда pod перестартует
kube-controller-manager-controller-1, то
kubectl describe no controller-1
НЕ показывает в выводе PodCIDR и PodCIDRs строки.
Надо ещё где-то подправить? Тапками можете кидать, я только учусь
Например cni kube-router записывает podCidr в cni конфиг:
{
"cniVersion": "0.3.0",
"name": "mynet",
"plugins": [
{
"bridge": "kube-bridge",
"ipam": {
"subnet": "10.244.12.0/24",
"type": "host-local"
},
"isDefaultGateway": true,
"name": "kubernetes",
"type": "bridge"
},
{
"capabilities": {
"portMappings": true,
"snat": true
},
"conditionsV4": [
"!",
"-d",
"10.96.0.0/12"
],
"type": "portmap"
}
]
}
И создает бридж с этой подсетью:
4: kube-bridge: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 2e:b8:fd:7b:df:61 brd ff:ff:ff:ff:ff:ff
inet 10.244.12.1/24 scope global kube-bridge
valid_lft forever preferred_lft forever
inet6 fe80::2cb8:fdff:fe7b:df61/64 scope link
valid_lft forever preferred_lft forever
Я не тестил, что будет если сменить podCidr. Но как минимум, на ходу оно скорее всего не будет менять подсеть бриджа, так как это приведет скорее к тому, что сетка для всех pod'ов, работающих на этой ноде, перестанет работать.
Все эти нюансы тебе надо учитывать естественно. Если ты думаешь, сменил podCidr и оно магически поехало, то это не так, совершенно точно.