According to the referrence, two of the options kube-apiserver takes are --bind-address and --advertise-address It appears to me that they conflict each other.
What is/are the actual difference(s) between the two?
Is --bind-address the address that the kube-apiserver process will listen on?
Is --advertise-address the address that kube-apiserver will advertise as the address that it will be listening on? If so, how does it advertise? Does it do some kind of a broadcast over the network?
According to the reference-kube-apiserver that you are referencing:
--advertise-address ip The IP address on which to advertise the apiserver to members of the cluster. This address must be reachable by the rest of the cluster. If blank, the --bind-address will be used. If --bind-address is unspecified, the host's default interface will be used.
and
--bind-address ip The IP address on which to listen for the --secure-port port. The associated interface(s) must be reachable by the rest of the cluster, and by CLI/web clients. If blank, all interfaces will be used (0.0.0.0 for all IPv4 interfaces and :: for all IPv6 interfaces). (default 0.0.0.0)
Those parameters are configurable, but please keep in mind they should be specified during cluster bootstrapping.
6443, but can be changed with the
--secure-port flag. As described in the documentation - master node should expose secure port for other cluster components to communicate with the Kubernetes API server.default IP is first non-localhost network interface, but can be
changed with the --bind-address flag.
Above mentioned parameters (--secure-port and --bind-address) allow you to configure network interface with secure port for Kubernetes API.
As stated before, if you don't specify any values:
By default it would be default IP is first non-localhost network interface and 6443 port.
Please note that:--advertise-address will be used by kube-apiserver to advertise this address for kubernetes controller which are responsible for preparing endpoints for kubernetes.default.svc (core Service responsible for communication between internal applications and the the API server). This Kubernetes Service VIP is configured for per-node load-balancing by kube-proxy.
More information on kubernetes.default.svc and kubernetes controller can be found here.
All communication paths from the cluster to the master terminate at the apiserver (none of the other master components are designed to expose remote services). In a typical deployment, the apiserver is configured to listen for remote connections on a secure HTTPS port (443) The kubernetes service is configured with a virtual IP address that is redirected (via kube-proxy) to the HTTPS endpoint on the apiserver.
There are two primary communication paths from the master (apiserver) to the cluster. The first is from the apiserver to the kubelet process which runs on each node in the cluster. The second is from the apiserver to any node, pod, or service through the apiserver’s proxy functionality.
Additionally, you can find out more about communication within the cluster by reading master-node-communication and control-plane-node-communication.