Here are the answers to the five questions:
1. Workstation responsibilities and tools
The workstation is the admin/operator machine used to control the cluster; it is not part of the cluster itself. Its main jobs are deploying and managing workloads, applying configuration changes, troubleshooting, and monitoring cluster state. Common tools include kubectl, kubeadm, Helm, and kubeconfig files for cluster access.
2. Four core control plane components running as Pods on the master
kube-apiserver kube-controller-manager kube-scheduler etcd
These run as static Pods/managed Pods on the control plane when using kubeadm.
3. Master initialization command and required node tools
The master is initialized with:
sudo kubeadm init
On both master and worker nodes, you need:
- a container runtime, such as containerd or Docker
kubelet kubeadm
kubectl is normally installed on the control plane node and/or workstation. It is not required on worker nodes for the cluster to function.
4. Adding a worker node vs. adding a master node
A worker node is added with a simple join command:
kubeadm join <api-server-ip>:6443 --token <token> --discovery-token-ca-cert-hash sha256:<hash>
After joining, the worker runs kubelet and kube-proxy.
Adding an extra master/control plane node is more involved. You first upload the control-plane certificates:
kubeadm init phase upload-certs --upload-certs
Then create a control-plane join command. The new master joins using something like:
kubeadm join <api-server-ip>:6443 \
--token <token> \
--discovery-token-ca-cert-hash sha256:<hash> \
--control-plane \
--certificate-key <certificate-key>
The new master also runs the control plane components and, with stacked etcd, joins the etcd cluster as a member. That is the key difference: a worker only gets kubelet/kube-proxy, while a new master gets full control-plane components and etcd membership.
5. kube-proxy function and placement
kube-proxy implements Kubernetes Service networking. It watches the API server for Services and EndpointSlices, then programs iptables or IPVS rules on the node so traffic to a Service IP is routed to the correct backend Pods. It runs on every node in the cluster, including master/control-plane nodes, typically as a DaemonSet.