Skip to main content
In this lesson we cover the essential networking requirements and checks for Kubernetes master (control plane) and worker nodes. This includes interface and address requirements, hostname and MAC address considerations, and the ports that must be reachable between components to ensure healthy cluster operation. Cluster networking fundamentals
  • Each node (master or worker) must have at least one functional network interface (for example eth0).
  • That interface must be assigned an IP address reachable from other nodes that need to communicate with it.
  • Each node must have a unique hostname.
  • Each node must have a unique MAC address — especially important when virtual machines are created from cloned images or templates.
A diagram titled "IP and FQDN" showing three nodes — master-01 (192.168.1.10) and two workers (192.168.1.11 and 192.168.1.12) — each with a MAC address and an eth0 interface. All three connect to a central network cloud labeled 192.168.1.0.
If you create VMs from templates or snapshots, always assign a unique hostname and regenerate or reassign MAC addresses before joining them to a cluster. Duplicate hostnames or MACs can cause network and cluster membership problems.
Ports required for control plane and node communication Below is a concise reference table for the core Kubernetes ports you must allow between control-plane nodes, kubelets, and external clients. Open these ports on firewalls, host-based firewalls, cloud security groups, and network ACLs as appropriate for your environment.
A screenshot of documentation showing a "Control plane" and "Worker node(s)" table listing protocols, directions, port ranges and purposes for Kubernetes components. A blue link to the kubernetes.io networking ports page appears at the bottom.
If you run multiple control-plane nodes, ensure etcd peer port 2380 is open between every etcd member. Blocking this port prevents etcd quorum and can break the control plane.
Network reachability and firewall considerations When troubleshooting, check:
  • Host-based firewalls (iptables, nftables, firewalld, ufw).
  • Cloud provider security rules (for example AWS Security Groups, GCP firewall rules, Azure NSGs).
  • Any network ACLs or external firewalls that sit between nodes.
Useful commands to inspect node and cluster networking Run these commands from the control plane or any machine with kubeconfig for cluster-level checks, or directly on each node for host-level checks. Cluster / node summary
Inspect interfaces, IP addresses, and MAC addresses on a node
Check hostnames
Check which ports are listening and associated processes
Inspect firewall rules
Troubleshooting checklist
  • Verify node IPs and hostnames: ensure they are unique and resolvable (DNS or /etc/hosts).
  • Confirm MAC addresses for VMs: cloned VMs must have unique MACs.
  • Ensure required ports are open and reachable from the appropriate sources:
    • From workers to control plane: TCP 6443
    • Between control-plane nodes: TCP 2380 (etcd peer), TCP 2379 (etcd client as needed)
    • From control plane to kubelets: TCP 10250
  • Check cloud provider firewall or security groups in addition to host-based firewalls.
  • Use ss, telnet/nc (netcat), or curl (for HTTP endpoints) to test TCP reachability.
Next steps / practice
  • Run the commands above to map your cluster: list nodes, view interfaces, capture MAC addresses, and confirm listening ports.
  • From a worker node, verify you can reach TCP 6443 on your control plane IP(s).
  • If using multiple control-plane nodes, validate etcd peer connectivity on TCP 2380.
  • Move on to advanced network troubleshooting (CNI plugin checks, service IP routing, and overlay network diagnostics) once these host-level validations are complete.
Links and references Keep this guide as a quick checklist when setting up or troubleshooting cluster networking — it covers the most common causes of connectivity problems and the relevant commands to diagnose them.

Watch Video