Code change:
After you initialize your control-plane, the kubelet runs normally. {{< /note >}} <ins> #### Network setup kubeadm similarly to other Kubernetes components tries to find a usable IP on the network interface associated with the default gateway on a host. Such an IP is then used for the advertising and/or listening performed by a component. To find out what this IP is on a Linux host you can use: ```shell ip route show # Look for a line starting with "default via" ``` Kubernetes components do not accept custom network interface as an option, therefore a custom IP address must be passed as a flag to all components instances that need such a custom configuration. To configure the API server advertise address for control plane nodes created with both `init` and `join`, the flag `--apiserver-advertise-address` can be used. Preferably, this option can be set in the [kubeadm API](/docs/reference/config-api/kubeadm-config.v1beta3) as `InitConfiguration.localAPIEndpoint` and `JoinConfiguration.controlPlane.localAPIEndpoint`. For kubelets on all nodes, the `--node-ip` option can be passed in `.nodeRegistration.kubeletExtraArgs` inside a kubeadm configuration file (`InitConfiguration` or `JoinConfiguration`). For dual-stack see [Dual-stack support with kubeadm](/docs/setup/production-environment/tools/kubeadm/dual-stack-support). {{< note >}} IP addresses become part of certificates SAN fields. Changing these IP addresses would require signing new certificates and restarting the affected components, so that the change in certificate files is reflected. See [Manual certificate renewal](/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/#manual-certificate-renewal) for more details on this topic. {{</ note >}} {{< warning >}} The Kubernetes project recommends against this approach (configuring all component instances with custom IP addresses). Instead, the Kubernetes maintainers recommend to setup the host network, so that the default gateway IP is the one that Kubernetes components auto-detect and use. On Linux nodes, you can use commands such as `ip route` to configure networking; your operating system might also provide higher level network management tools. If your node's default gateway is a public IP address, you should configure packet filtering or other security measures that protect the nodes and your cluster. {{< /warning >}} {{< note >}} If the host does not have a default gateway, it is recommended to setup one. Otherwise, without passing a custom IP address to a Kubernetes component, the component will exit with an error. If two or more default gateways are present on the host, a Kubernetes component will try to use the first one it encounters that has a suitable global unicast IP address. While making this choice, the exact ordering of gateways might vary between different operating systems and kernel versions. {{< /note >}} </ins> ### Preparing the required container images This step is optional and only applies in case you wish `kubeadm init` and `kubeadm join`

Related discussion:
text: I have a catastrophic problem with my production control-plane just because I naive believe in the instruction of the output of . My control-plane was gone and I couldn't recover from the failure because could not restart. After some tests, I found that need to be so that it tell the to use the correct internal IP that allow both new control plane and the current plane to talk to each other. Specifically, those IPs should allow etcd to communicate throw both servers. Without the default IP interface was used, but the firewall that I set on the default IP did not allow etcd to connect through. At this point, I would like to make a change to the document in a way that it emphasize the importance of in the command.
/language en /sig docs /kind feature
Page reported in issue: /sig cluster-lifecycle
/retitle Highlight the significance of in kubeadm join for HA cluster setup
all k8s components work like that. not only kubeadm. if you want custom IP from a different interface you need to pass it to the advertise address flag, but also as --node-ip to the kubelet. overall this setup with private IPs is not recommended and is difficult to manage. instead you should make the setup so that the public IP is the default route. then firewall the cluster properly. PRs for the above "create cluster" page with a note fix are welcome. the note can talk about "init" and "join", public IPs and firewall. /help /sig network
/triage accepted
actually, let me try to send the note. /remove-help
/assign