8.06 Cluster Networking

Abstract

Cluster networking covers the basic network requirements for Kubernetes control plane and worker nodes.

Before installing or troubleshooting Kubernetes, verify node interfaces, IPs, hostnames, MAC addresses, routes, and required ports.

In production, incorrect networking or blocked ports can prevent the cluster from forming or cause node/component failures.

Cluster Networking Overview

A Kubernetes cluster has:

control plane nodes
worker nodes
network interfaces
node IP addresses
Kubernetes component ports
firewall / security group rules

Each node must have:

at least one active network interface
a valid IP address
unique hostname
unique MAC address
connectivity to other required nodes
required ports open

Note

Cluster networking problems often look like Kubernetes component failures, but the root cause may be IP, routing, DNS, firewall, or blocked port configuration.

Node Requirements

Every Kubernetes node should have:

Requirement	Why It Matters
Active interface	Node must communicate with cluster
IP address	Components use node IPs
Unique hostname	Kubernetes identifies nodes by name
Unique MAC address	Prevents network conflicts
Correct routes	Nodes must reach each other
Required ports open	Components communicate over specific ports

Warning

If VMs are cloned, verify that hostnames and MAC addresses are unique.

Control Plane Node Ports

Important ports on control plane nodes:

Protocol	Direction	Port	Component	Used By
TCP	Inbound	`6443`	kube-apiserver	kubectl, workers, API clients
TCP	Inbound	`2379-2380`	etcd	kube-apiserver, etcd peers
TCP	Inbound	`10250`	kubelet API	control plane
TCP	Inbound	`10257`	kube-controller-manager	self / control plane
TCP	Inbound	`10259`	kube-scheduler	self / control plane

Tip

Port 6443 is the most important API server port. If this is blocked, kubectl and worker nodes cannot communicate with the API server.

Worker Node Ports

Important ports on worker nodes:

Protocol	Direction	Port	Component	Used By
TCP	Inbound	`10250`	kubelet API	control plane
TCP	Inbound	`30000-32767`	NodePort Services	external clients

Note

NodePort Services expose applications on ports 30000-32767 by default.

Multi-Control Plane Ports

In a multi-control-plane cluster, etcd peer communication is required.

Port	Purpose
`2379`	etcd client communication
`2380`	etcd peer communication

Example:

master-01 etcd ←→ master-02 etcd

Warning

If etcd peer ports are blocked in HA control plane clusters, etcd members may fail to form quorum.

API Server Port

The kube-apiserver listens on:

TCP 6443

Used by:

kubectl
worker nodes
kubelets
controllers
schedulers
external API clients
CI/CD tools

Success

Always verify that API clients can reach the API server on port 6443.

Kubelet Port

The kubelet listens on:

TCP 10250

Used by the control plane to communicate with nodes.

Common operations:

collect node status
inspect Pods
execute logs / exec workflows
manage node-level operations

Note

Kubelet may run on both control plane and worker nodes.

NodePort Range

Default NodePort range:

30000-32767

Used when a Service type is:

type: NodePort

Warning

Open NodePort ranges only where needed. Exposing the full range publicly can increase attack surface.

Required Port Summary

Control PlaneWorker Nodes

Port	Purpose
`6443`	Kubernetes API Server
`2379-2380`	etcd client and peer communication
`10250`	kubelet API
`10257`	kube-controller-manager
`10259`	kube-scheduler

Port	Purpose
`10250`	kubelet API
`30000-32767`	NodePort Services

Network Checks Before Installation

Before installing Kubernetes, verify:

ip link
ip addr
ip route
hostname

Check hostname:

hostname

Check MAC address:

ip link

Check routing:

ip route

Tip

Basic Linux networking commands are useful for both installation validation and production troubleshooting.

Useful Linux Networking Commands

Command	Purpose
`ip link`	Show network interfaces
`ip addr`	Show IP addresses
`ip addr add`	Add IP address to interface
`ip route`	Show routing table
`ip route add`	Add route
`arp`	Show ARP table
`route`	Show legacy routing table
`netstat -plnt`	Show listening TCP ports
`cat /proc/sys/net/ipv4/ip_forward`	Check IP forwarding

Example Commands

View interfaces:

ip link

View IP addresses:

ip addr

Assign IP address:

ip addr add 192.168.1.10/24 dev eth0

View routes:

ip route

Add route:

ip route add 192.168.1.0/24 via 192.168.2.1

View listening ports:

netstat -plnt

Check IP forwarding:

cat /proc/sys/net/ipv4/ip_forward

Firewall and Cloud Security Groups

In production, required ports must be allowed in:

Linux firewall rules
iptables / nftables
cloud security groups
network ACLs
corporate firewalls
host-based security tools

Warning

A Kubernetes component may be healthy locally but unreachable because a firewall or cloud security group blocks the port.

Production Best Practices

Recommended

Use static or reserved node IPs
Ensure every node has a unique hostname
Ensure every node has a unique MAC address
Open only required Kubernetes ports
Restrict API server access to trusted networks
Restrict kubelet access to control plane nodes
Document all firewall and security group rules
Monitor listening ports and network connectivity

Do's

Verify node IPs before cluster bootstrap
Check control plane and worker node port access
Use netstat or ss to validate listening ports
Restrict access to sensitive ports like 6443, 2379, and 10250
Validate connectivity between all nodes
Keep network CIDRs non-overlapping

Don'ts

Don't expose etcd ports publicly
Don't expose kubelet port publicly
Don't open full NodePort range to the internet unless required
Don't clone VMs without changing hostname and MAC address
Don't ignore firewall rules during troubleshooting
Don't use overlapping Pod, Service, and node network CIDRs

Danger

Exposing etcd or kubelet ports publicly can create serious cluster security risks.

Troubleshooting Checklist

When cluster networking fails, check:

Does each node have an IP address?
Can nodes ping each other?
Are hostnames unique?
Are MAC addresses unique?
Is the API server reachable on port 6443?
Is kubelet listening on port 10250?
Are etcd ports open between control plane nodes?
Are firewall or cloud security group rules blocking traffic?
Are routes configured correctly?

Quick Port Validation

Check API server reachability:

curl -k https://<control-plane-ip>:6443/version

Check listening ports:

netstat -plnt

or:

ss -plnt

Check specific port:

nc -vz <node-ip> 6443

Tip

Use nc -vz or telnet to quickly test whether a TCP port is reachable.

Summary

Quote

Kubernetes nodes need valid IPs, routes, hostnames, and MAC addresses
Control plane nodes expose ports like 6443, 2379, 2380, 10257, and 10259
Worker nodes expose kubelet on 10250 and NodePort Services on 30000-32767
Firewall and cloud security group rules must allow required traffic
Always validate basic Linux networking before troubleshooting Kubernetes components