Change:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --I am trying to learn how to use kubeadm well and it looks like there may be a problem in the example configuration in . It says , but also uses address 10.100.0.1 for various host things like the kube-apiserver and the etcd server and the scheduler. Also, interestingly, it puts a different address --- 10.100.1.1 --- in the apiserver's cert SANs. I expected to not be confused. Kubernetes version (use ): 1.21.1 Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
seems more like sig/cluster-lifecycle?
/area kubeadm
Sorry, typo, corrected.
But the 'bot does not seem to have noticed the edit.
/remove-sig multicluster
/sig cluster-lifecycle
yeah, FWIW commands are never evaluated on comment edit versus a new comment so that trivial edits do not e.g. restart tests etc. also no need to apologize! just trying to make sure things get the attention of the right folks. in particular seems to stay pretty on top of SCL/kubeadm issues
For the certs sans part, it seems to be intended as the comments above. For podSubnet and node Address overlap, it may be not suggested? Let me check. Here is an example for dual-stack:
The podSubnet part in the dual stack example is suggested by in
he is right, the docs are wrong should be 10.100.0.0/24, but I think that is more an aesthetic issue, and the code will take the right subnet, but for docs is better to be pedantic yeah, that is why I always suggest to use subnets with more clear differentiation, 10.100.0.0/24 and 10.100.1.0/24 are easy to get wrong, however , 10.96.0.0/16 and 10.244.0.0/16 are not

Discussion:
// 	    # certFile: "/etcd/kubernetes/pki/etcd/etcd.crt" // 	    # keyFile: "/etcd/kubernetes/pki/etcd/etcd.key" // 	networking: <del> // 	  serviceSubnet: "10.96.0.0/12" // 	  podSubnet: "10.100.0.1/24" </del> <ins> // 	  serviceSubnet: "10.96.0.0/16" // 	  podSubnet: "10.244.0.0/24" </ins> // 	  dnsDomain: "cluster.local" // 	kubernetesVersion: "v1.12.0" // 	controlPlaneEndpoint: "10.100.0.1:6443"

// 	    # certFile: "/etcd/kubernetes/pki/etcd/etcd.crt" // 	    # keyFile: "/etcd/kubernetes/pki/etcd/etcd.key" // 	networking: <del> // 	  serviceSubnet: "10.96.0.0/12" // 	  podSubnet: "10.100.0.1/24" </del> <ins> // 	  serviceSubnet: "10.96.0.0/16" // 	  podSubnet: "10.244.0.0/24" </ins> // 	  dnsDomain: "cluster.local" <del> // 	kubernetesVersion: "v1.12.0" </del> <ins> // 	kubernetesVersion: "v1.21.0" </ins> // 	controlPlaneEndpoint: "10.100.0.1:6443" // 	apiServer: // 	  extraArgs: