Inquiring pod and service subnets from inside Kubernetes cluster

问题

How can one inquire the Kubernetes pod and service subnets in use (e.g. 10.244.0.0/16 and 10.96.0.0/12 respectively) from inside a Kubernetes cluster in a portable and simple way?

For instance, kubectl get cm -n kube-system kubeadm-config -o yaml reports podSubnet and serviceSubnet. But this is not fully portable because a cluster may have been set up by another means than kubeadm.

kubectl get cm -n kube-system kube-proxy -o yaml reports clusterCIDR (i.e. pod subnet) and kubectl get pod -n kube-system kube-apiserver-master1 -o yaml reports the value passed as command-line option --service-cluster-ip-range to kube-apiserver (i.e. service subnet). master1 stands for the name of any control plane node. But this seems a bit complex.

Is there a better way available e.g. with the Kubernetes 1.17 API?

回答1:

I don't think it would be possible to obtain what you want in a portable and simple way. If you don't specify Cidr's parameters it will assign default one.

As you have many ways to run kubernetes as unmanaged clusters like kubeadm, minikbue, k3s, micork8s or managed like Cloud providers (GKE, Azure, AWS) it's hard to find one way to list all cidrs in all environments. Another obstacle can be versions of Kubernetes or CNI.

In Kubernetes 1.17 Release notes you can find information that

Deprecate the default service IP CIDR. The previous default was 10.0.0.0/24 which will be removed in 6 months/2 releases. Cluster admins must specify their own desired value, by using --service-cluster-ip-range on kube-apiserver.

As example of Kubeadm: $ kubeadm init --pod-network-cidr 10.100.0.0/12 --service-cidr 10.99.0.0/12

There are a few ways to get this pod and service-cidr:

$ kubectl cluster-info dump | grep -E '(service-cluster-ip-range|cluster-cidr)'
                            "--service-cluster-ip-range=10.99.0.0/12",
                            "--cluster-cidr=10.100.0.0/12",



$ kubeadm config view | grep Subnet
  podSubnet: 10.100.0.0/12
  serviceSubnet: 10.99.0.0/12

But if you will check all pods in this cluster, some pods are starting with 192.168.190.X or 192.168.137.X

$ kubectl get pods -A -owide
NAMESPACE     NAME                                       READY   STATUS    RESTARTS   AGE    IP                NODE             NOMINATED NODE   READINESS GATES
default       nginx                                      1/1     Running   0          62m    192.168.190.129   kubeadm-worker   <none>           <none>
kube-system   calico-kube-controllers-77c5fc8d7f-9n6m5   1/1     Running   0          118m   192.168.137.66    kubeadm-master   <none>           <none>
kube-system   calico-node-2kx2v                          1/1     Running   0          117m   10.128.0.4        kubeadm-worker   <none>           <none>
kube-system   calico-node-8xqd9                          1/1     Running   0          118m   10.128.0.3        kubeadm-master   <none>           <none>
kube-system   coredns-66bff467f8-sgmkw                   1/1     Running   0          120m   192.168.137.65    kubeadm-master   <none>           <none>
kube-system   coredns-66bff467f8-t84ht                   1/1     Running   0          120m   192.168.137.67    kubeadm-master   <none>           <none>

If you will describe any CNI pods you can find another CIDRs:

CALICO_IPV4POOL_CIDR:               192.168.0.0/16

For GKE example you will have: node CIDRs

$ kubectl describe node | grep CIDRs
PodCIDRs:                     10.52.1.0/24
PodCIDRs:                     10.52.0.0/24
PodCIDRs:                     10.52.2.0/24

$ gcloud container clusters describe cluster-2 --zone=europe-west2-b | grep Cidr
clusterIpv4Cidr: 10.52.0.0/14
  clusterIpv4Cidr: 10.52.0.0/14
  clusterIpv4CidrBlock: 10.52.0.0/14
  servicesIpv4Cidr: 10.116.0.0/20
  servicesIpv4CidrBlock: 10.116.0.0/20
  podIpv4CidrSize: 24
servicesIpv4Cidr: 10.116.0.0/20

Honestly I don't think there is an easy and portable way to list all podCidrs and serviceCidrs in one simple command.

来源：https://stackoverflow.com/questions/61847788/inquiring-pod-and-service-subnets-from-inside-kubernetes-cluster