Kubernetes Networking: How Data and Communication Flow Between Control Plane and Worker Nodes
Kubernetes Networking: How Data and Communication Flow Between Control Plane and Worker Nodes
Introduction
One of the most important Kubernetes concepts to understand is how different components communicate with each other.
When we say:
"The Kubernetes master communicates with the worker nodes"
this is only part of the story.
Modern Kubernetes terminology uses Control Plane instead of "Master". The Control Plane manages the cluster, while Worker Nodes run application workloads.
A Kubernetes cluster contains several different types of network communication:
Client → Kubernetes API Server
Worker Node → Control Plane
Control Plane → Worker Node
Pod → Pod
Pod → Service
Pod → External Network
External Client → Service / Ingress / Gateway
Understanding these communication paths is extremely important for:
Kubernetes administration
CNI troubleshooting
Firewall configuration
Cloud networking
Kubernetes security
Service troubleshooting
kubectl execkubectl logskubectl port-forwardNetworkPolicy
Production cluster design
1. Kubernetes Network Architecture
At a high level, a Kubernetes cluster looks like this:
ADMIN / USER
|
|
kubectl
|
v
+-------------------+
| API SERVER |
| Control Plane |
+-------------------+
/ | \
/ | \
v v v
Worker-1 Worker-2 Worker-3
+-------+ +-------+ +-------+
|kubelet| |kubelet| |kubelet|
|runtime| |runtime| |runtime|
|k-proxy| |k-proxy| |k-proxy|
| Pods | | Pods | | Pods |
+-------+ +-------+ +-------+
Pod Network / CNI
<---------------------------->
The Control Plane and Worker Nodes communicate primarily through the Kubernetes API Server.
Kubernetes uses a hub-and-spoke API pattern: API communication from nodes and the Pods running on them terminates at the API Server. The other Control Plane components are not normally exposed as remote services to worker nodes.
2. Control Plane vs Worker Node
Before discussing networking, we need to understand the components involved.
Control Plane
The main Control Plane components include:
| Component | Responsibility |
|---|---|
kube-apiserver | Exposes Kubernetes API |
etcd | Stores Kubernetes cluster state |
kube-scheduler | Selects nodes for unscheduled Pods |
kube-controller-manager | Runs Kubernetes controllers |
cloud-controller-manager | Integrates with cloud providers when used |
The API Server is the primary communication endpoint for Kubernetes clients and nodes.
3. Worker Node Components
A typical Kubernetes Worker Node contains:
| Component | Responsibility |
|---|---|
kubelet | Manages Pods on the node |
| Container Runtime | Runs containers |
kube-proxy | Implements Service networking when used |
| CNI components | Provide Pod networking |
Kubernetes documentation identifies the kubelet, container runtime, and kube-proxy as node components.
A modern Kubernetes cluster may use a networking implementation that provides its own service-proxy functionality, so kube-proxy should not be assumed to be mandatory in every networking implementation.
4. The Most Important Concept: API Server Is the Communication Hub
Consider a cluster with:
Control Plane
10.0.0.10
Worker 1
10.0.1.11
Worker 2
10.0.1.12
The basic management communication looks like:
Worker 1
|
| HTTPS
|
v
API Server
10.0.0.10:6443
^
|
| HTTPS
|
Worker 2
The Worker Nodes do not normally communicate directly with etcd, scheduler, or controller-manager.
Instead:
Worker Node
|
v
kube-apiserver
|
+----> etcd
|
+----> scheduler
|
+----> controller-manager
This architecture provides a central API endpoint through which Kubernetes components interact.
5. Worker Node → Control Plane Communication
This is one of the most important communication paths.
The kubelet on a Worker Node communicates with the Kubernetes API Server.
For example:
Worker Node
+--------------------------+
| |
| kubelet |
| | |
+-----------|--------------+
|
| HTTPS
|
v
+-------------+
| API Server |
+-------------+
The node is configured with credentials and the cluster's CA information so that the kubelet can securely communicate with the API Server. Kubernetes documentation describes this as the normal node-to-control-plane communication model.
6. What Does the Worker Send to the Control Plane?
The Worker Node needs to communicate information about the state of the node and its workloads.
Conceptually:
Worker Node
|
| Node information
| Pod status
| Heartbeats / leases
| API requests
|
v
API Server
The Control Plane uses this information to maintain the desired and observed state of the cluster.
For example:
Pod should exist
|
v
Control Plane
|
v
Worker Node
|
v
kubelet
|
v
Container Runtime
|
v
Container
The important point is that the kubelet is responsible for making sure the Pods assigned to its node are running.
7. Control Plane → Worker Node
Communication also needs to happen in the opposite direction.
However, it is important to understand that Kubernetes does not simply have every Control Plane component directly connecting to every Worker Node.
The primary Control Plane → Node communication paths originate from the API Server.
Kubernetes documents two primary paths:
API Server
|
+----------+----------+
| |
v v
kubelet API proxy
| |
v v
Worker Node/Pod/
Service
The first path is:
API Server → kubelet
The second involves the API Server's proxy functionality for reaching nodes, Pods, or Services.
8. API Server → kubelet
The API Server can communicate with the kubelet's HTTPS endpoint.
This path is important for operations such as:
kubectl logs
kubectl exec
kubectl attach
kubectl port-forward
For example:
User
|
| kubectl logs
v
API Server
|
| HTTPS
v
kubelet
|
v
Pod
Kubernetes specifically documents API Server → kubelet communication for:
fetching Pod logs
attaching to running Pods
kubelet port-forwarding functionality
9. Understanding kubectl logs
Suppose we run:
kubectl logs nginx-pod
A simplified communication flow is:
Your Terminal
|
| kubectl
v
API Server
|
| request to kubelet
v
Worker Node
|
v
kubelet
|
v
Container / Pod
Therefore, if kubectl logs is failing, checking only the Pod itself is not enough.
You should also investigate:
kubectl
|
API Server
|
kubelet
|
container runtime / Pod
10. Understanding kubectl exec
Consider:
kubectl exec -it nginx-pod -- /bin/bash
Conceptually:
Terminal
|
| HTTPS
v
API Server
|
| connection to node
v
kubelet
|
v
Container
|
v
/bin/bash
This is an excellent example of why Kubernetes networking is more than just Pod-to-Pod communication.
There is a separate Control Plane management path.
11. Kubernetes Port 6443
One of the most important Kubernetes ports is:
TCP 6443
This is the commonly used Kubernetes API Server port.
For example:
Worker Node
10.0.1.11
|
| TCP/6443
|
v
Control Plane
10.0.0.10
kube-apiserver
The official Kubernetes port documentation lists TCP 6443 for the Kubernetes API Server.
Note: Kubernetes documentation allows API Server deployments to use different ports;
6443is the common default referenced in the port documentation.
12. Kubelet Port 10250
Another important port is:
TCP 10250
This is commonly used for the kubelet API.
The Kubernetes port documentation lists TCP 10250 for the kubelet API and identifies Control Plane → kubelet communication as one of its uses.
Typical architecture:
Control Plane
|
| TCP 10250
v
Worker Node
|
kubelet
This becomes particularly important when configuring:
cloud security groups
firewalls
security policies
private Kubernetes clusters
on-premises Kubernetes clusters
13. Important Kubernetes Ports
A simplified reference:
| Port | Protocol | Component | Purpose |
|---|---|---|---|
| 6443 | TCP | API Server | Kubernetes API |
| 2379-2380 | TCP | etcd | etcd communication |
| 10250 | TCP | kubelet | Kubelet API |
| 10257 | TCP | controller-manager | Controller Manager |
| 10259 | TCP | scheduler | Scheduler |
| 10256 | TCP | kube-proxy | kube-proxy health/checking |
| 30000-32767 | TCP/UDP | NodePort | Default NodePort range |
These are documented Kubernetes default ports; individual installations can override defaults.
14. Does the Control Plane Send Application Data to Workers?
This is an important distinction.
Kubernetes control-plane communication is not the same thing as application data traffic.
For example:
Control Plane
|
| Kubernetes API / management traffic
|
v
Worker Node
is different from:
Pod A
|
| application traffic
|
v
Pod B
The first is primarily cluster management/control communication.
The second is application data-plane traffic.
15. Kubernetes Data Plane
Suppose we have:
Worker Node 1
Pod A
10.244.1.10
and:
Worker Node 2
Pod B
10.244.2.20
If Pod A sends data to Pod B:
Pod A
10.244.1.10
|
| application traffic
|
v
Pod Network
|
v
Pod B
10.244.2.20
The Kubernetes network model expects Pods to be able to communicate with other Pods, including Pods on different nodes, without requiring application-level proxies or NAT for ordinary Pod-to-Pod communication.
16. Where Does Pod Networking Come From?
Kubernetes itself defines the networking model, but the actual implementation of Pod networking is generally provided by a network plugin/CNI implementation.
For example, a cluster can use different networking implementations.
The CNI/network implementation is responsible for implementing the Pod network.
Conceptually:
Kubernetes
|
|
Pod Networking Model
|
v
+----------------+
| CNI / Network |
| Implementation |
+----------------+
|
+---------+---------+
| |
v v
Worker 1 Worker 2
| |
Pod A Pod B
When creating a cluster with kubeadm, Kubernetes documentation explicitly states that a CNI-based Pod network add-on must be installed so Pods can communicate.
17. Pod-to-Pod Communication
Kubernetes assigns each Pod a unique IP address for its address family.
For example:
Worker 1
+----------------------+
| Pod A |
| 10.244.1.10 |
+----------------------+
|
| Pod network
|
v
Worker 2
+----------------------+
| Pod B |
| 10.244.2.20 |
+----------------------+
The application can communicate using:
10.244.2.20:8080
assuming that address and port are reachable and the relevant network policies allow the traffic.
Kubernetes' network model is designed so Pods can communicate across nodes.
18. Same Pod Communication
Containers inside the same Pod share the Pod's network namespace.
Therefore:
Pod
+-----------------------------+
| |
| Container A |
| Container B |
| Container C |
| |
| Shared network namespace |
| IP: 10.244.1.10 |
+-----------------------------+
The containers can communicate using:
localhost
For example:
Container A
|
| localhost:8080
v
Container B
This works because containers within a Pod share the network namespace and network resources.
19. Pod-to-Service Communication
Pod IP addresses are not generally intended to be the stable endpoint for applications.
Pods can be replaced.
For example:
Pod A
10.244.1.10
may disappear and be replaced by:
Pod A'
10.244.2.15
Therefore Kubernetes provides a Service.
Service
10.96.10.100
|
+--------+--------+
| | |
v v v
Pod A Pod B Pod C
A Service provides a stable IP/hostname for a group of Pods. Kubernetes maintains EndpointSlice information for the Pods backing the Service.
20. kube-proxy and Service Traffic
In clusters using kube-proxy, each node runs kube-proxy.
It watches Service and EndpointSlice information and programs the node's networking so traffic sent to a Service's virtual IP can be redirected to an appropriate endpoint.
Conceptually:
Pod
|
| Service IP
| 10.96.10.100
v
kube-proxy / service proxy
|
+--------+--------+
| | |
v v v
Pod A Pod B Pod C
The exact implementation depends on the service proxy/networking implementation used by the cluster.
21. Kubernetes DNS
Applications should generally avoid hard-coding Pod IP addresses.
Instead, Kubernetes provides DNS-based service discovery.
For example:
frontend
|
| HTTP request
v
backend.default.svc.cluster.local
A Pod can use:
curl http://backend
if backend is a Service in the same namespace.
Kubernetes creates DNS records for Services and Pods, and kubelet configures Pod DNS settings.
22. Complete Communication Example
Let's consider a realistic application:
Internet
|
v
Load Balancer
|
v
Ingress/Gateway
|
v
frontend Service
|
+------+------+
| |
v v
Pod A Pod B
|
| API request
v
backend Service
|
+----+----+
| |
v v
Pod C Pod D
At the same time, Kubernetes management traffic looks like:
API Server
|
+------------+------------+
| | |
v v v
Worker 1 Worker 2 Worker 3
kubelet kubelet kubelet
These are two different communication planes.
23. Control Plane Traffic vs Data Plane Traffic
This distinction is extremely important for Kubernetes administrators.
| Characteristic | Control Plane Traffic | Data Plane Traffic |
|---|---|---|
| Main purpose | Cluster management | Application communication |
| Typical endpoint | API Server | Pod/Service |
| Example | kubelet → API Server | Pod → Pod |
| Example port | 6443 | Application-specific |
| Main components | API Server, kubelet | Pods, CNI, Service proxy |
| Handles | Cluster state and management | Application data |
| Example command | kubectl logs | curl backend:8080 |
| Networking implementation | Kubernetes API/TLS | CNI + networking stack |
| Primary concern | Cluster control | Application connectivity |
This separation makes Kubernetes architecture easier to understand.
24. Does Pod Traffic Go Through the API Server?
Normally, no.
This is one of the most common misunderstandings.
Consider:
Pod A
|
| HTTP
v
Pod B
The application traffic does not normally go through:
API Server
Instead:
Pod A
|
v
CNI / node networking
|
v
Pod B
The API Server manages Kubernetes objects and configuration; it is not the normal data path for application traffic.
Kubernetes explicitly separates Pod networking from the API communication path.
25. Does Pod Traffic Go Through kubelet?
Normally, no.
For example:
Pod A
|
| application request
v
Pod B
does not mean:
Pod A
|
v
kubelet
|
v
API Server
|
v
kubelet
|
v
Pod B
That would be extremely inefficient.
Instead, the networking layer provides the Pod-to-Pod connectivity.
The kubelet is primarily responsible for managing the Pods on its node rather than acting as a general-purpose application network router.
26. Control Plane Communication Example
Imagine:
Control Plane IP:
10.0.0.10
Worker 1:
10.0.1.11
Worker 2:
10.0.1.12
The basic communication can be visualized as:
CONTROL PLANE
+-------------------+
| API SERVER |
| 10.0.0.10 |
| :6443 |
+-------------------+
^ ^
| |
HTTPS | | HTTPS
| |
| |
+--------+--+ +--+---------+
| Worker 1 | | Worker 2 |
|10.0.1.11 | |10.0.1.12 |
| | | |
| kubelet | | kubelet |
| :10250 | | :10250 |
| kube-proxy| | kube-proxy |
| Pods | | Pods |
+-----------+ +------------+
The exact firewall requirements depend on the cluster topology and networking implementation, but the official Kubernetes port documentation lists the common default ports.
27. Complete Network View
A useful mental model is:
USER
|
| kubectl
v
+--------------------+
| API SERVER |
| CONTROL PLANE |
+--------------------+
| |
| |
Management| |Management
| |
v v
+---------+ +---------+
| Worker 1| | Worker 2|
+---------+ +---------+
| |
kubelet kubelet
| |
+---+---+ +---+---+
| Pods | | Pods |
+-------+ +-------+
\ /
\ /
\ /
Pod Network
|
CNI / Network
The important thing is that Kubernetes has multiple communication paths, not one single network.
28. Network Communication Categories
A practical Kubernetes troubleshooting model is to classify traffic into four categories.
Category 1 — Kubernetes API Traffic
kubectl
|
v
API Server
Example:
kubectl get pods
Category 2 — Node ↔ Control Plane
Worker
|
| HTTPS
v
API Server
Example:
kubelet → API Server
Category 3 — Control Plane → Worker
API Server
|
v
kubelet
|
v
Pod
Examples include operations such as:
kubectl logs
kubectl exec
kubectl attach
kubectl port-forward
Kubernetes documents these API Server-to-kubelet uses explicitly.
Category 4 — Application Data Traffic
Pod A
|
| application traffic
v
Service
|
v
Pod B
This is the data plane.
29. Firewall Design
Suppose your cluster is deployed on AWS, Azure, GCP, or on-premises.
You need to think carefully about firewall rules.
A simplified example:
CONTROL PLANE
10.0.0.10
|
| TCP 6443
|
v
WORKER NODES
10.0.1.0/24
Workers need to reach the API Server.
For example:
Worker → API Server:6443
The API Server may also need access to kubelets on:
Worker:10250
depending on the operations and topology involved.
The official Kubernetes ports documentation should be used when building the actual firewall/security-group rules rather than relying on a generic diagram.
30. Why Kubernetes Networking Problems Are Difficult
Suppose:
kubectl get pods
works.
But:
kubectl logs mypod
fails.
This does not automatically mean the Pod network is broken.
You need to isolate the communication path.
kubectl get pods
User
|
v
API Server
|
v
etcd/API state
while:
kubectl logs
User
|
v
API Server
|
v
kubelet
|
v
Pod
Therefore, different commands can exercise different network paths.
31. Troubleshooting Communication
When troubleshooting Kubernetes networking, start with the following.
Check cluster nodes
kubectl get nodes -o wide
Check Pod IP addresses
kubectl get pods -o wide
Example:
NAME READY STATUS IP NODE
frontend 1/1 Running 10.244.1.10 worker-1
backend 1/1 Running 10.244.2.20 worker-2
Check Services
kubectl get svc
Check EndpointSlices
kubectl get endpointslices
Check DNS
From inside a Pod:
cat /etc/resolv.conf
Then:
nslookup backend
or:
getent hosts backend
Kubernetes configures Pod DNS so workloads can resolve Services by DNS name.
Check node networking
On Linux:
ip addr
ip route
ip link
Check listening ports
ss -lntp
For kubelet:
ss -lntp | grep 10250
Test API Server connectivity
From a Worker Node:
curl -k https://<API_SERVER_IP>:6443
Authentication and authorization still apply; this is primarily a network-level connectivity test.
32. NetworkPolicy
Kubernetes also supports NetworkPolicy.
NetworkPolicy can control traffic at the IP/port level between Pods and between Pods and external destinations, provided the cluster's network implementation supports enforcement.
For example:
Frontend Pod
|
| allowed
v
Backend Pod
but:
Frontend Pod
|
X
|
Database Pod
could be blocked by policy.
A conceptual policy might be:
frontend
|
| TCP 8080
v
backend
backend
|
| TCP 5432
v
database
This creates a controlled application communication path.
33. Important Interview Question
Question:
Does the Kubernetes Control Plane handle all application traffic between Pods?
Answer:
No.
The Kubernetes API Server is primarily the control/management API endpoint. Application traffic normally flows through the cluster's Pod networking and Service networking mechanisms rather than through the API Server.
For example:
Pod A
|
| application traffic
v
Pod B
is different from:
kubelet
|
| Kubernetes API
v
API Server
Kubernetes explicitly defines Pod-to-Pod networking separately from Control Plane communication.
34. Another Interview Question
Question:
What is the difference between port 6443 and port 10250?
Answer:
6443 is commonly the Kubernetes API Server port.
Worker → API Server:6443
10250 is commonly the kubelet API port.
API Server → Worker:kubelet 10250
The official Kubernetes documentation lists both ports in its cluster networking reference.
35. Another Interview Question
Question:
What happens when kubectl logs is executed?
A simplified flow is:
kubectl
|
v
API Server
|
v
kubelet
|
v
Pod / container logs
Kubernetes documents API Server-to-kubelet connections for fetching Pod logs.
36. Another Interview Question
Question:
How do Pods communicate across different Worker Nodes?
Suppose:
Worker 1
Pod A
10.244.1.10
and:
Worker 2
Pod B
10.244.2.20
The cluster's Pod network provides connectivity:
Pod A
10.244.1.10
|
v
CNI / Pod Network
|
v
Pod B
10.244.2.20
The exact packet implementation depends on the networking solution deployed in the cluster.
37. Another Interview Question
Question:
Does kube-proxy handle all Kubernetes network traffic?
No.
kube-proxy is primarily associated with implementing Service virtual IP behavior in clusters that use kube-proxy.
Pod-to-Pod networking is provided by the cluster's Pod network implementation.
Kubernetes also allows network implementations to provide their own Service proxy functionality.
38. The Most Important Mental Model
When learning Kubernetes networking, remember this diagram:
CONTROL PLANE
|
|
API SERVER
|
+------------+------------+
| |
| Control traffic |
| |
v v
Worker 1 Worker 2
| |
kubelet kubelet
| |
Pods Pods
\ /
\ /
+---------------------+
CNI
Pod Network
Think of the cluster as having two major worlds:
Control Plane
API Server
|
+---- kubelet
|
+---- cluster state
|
+---- cluster management
Data Plane
Pod
|
+---- Pod
|
+---- Service
|
+---- External application
39. Final Summary
The most important concepts are:
Kubernetes uses the term Control Plane rather than "Master".
The API Server is the central Kubernetes API communication endpoint.
Worker Nodes communicate with the API Server.
The kubelet on each node is a key participant in node management.
API Server → kubelet communication is used for operations such as logs, attach, and port forwarding.
6443/TCPis the commonly documented Kubernetes API Server port.10250/TCPis the commonly documented kubelet API port.Pod-to-Pod traffic is data-plane traffic, not normal API Server traffic.
CNI/network implementations provide the Pod networking required by Kubernetes.
Pods can communicate across Worker Nodes through the Pod network.
Services provide stable networking endpoints for applications.
DNS allows applications to discover Services by name.
kube-proxy commonly implements Service virtual IP behavior, although alternative service-proxy implementations exist.
NetworkPolicy can restrict allowed Pod traffic when supported by the network implementation.
Control-plane traffic and application data-plane traffic should always be considered separately when troubleshooting.
Kubernetes Networking — One-Page Cheat Sheet
USER
|
| kubectl
v
+----------------+
| API SERVER |
| :6443 |
+----------------+
^ |
| |
HTTPS | | HTTPS
| |
+-----+----+ +---+------+
| Worker 1 | | Worker 2|
| | | |
| kubelet | | kubelet |
| :10250 | | :10250 |
| | | |
| Pod A | | Pod B |
+-----+-----+ +----+-----+
\ /
\ /
\ /
\ /
CNI / Pod
Network
|
Pod-to-Pod
Data Traffic
Remember:
API Server
↓
Control / Management Plane
CNI + Pods + Services
↓
Application / Data Plane
That distinction is the foundation for understanding Kubernetes networking.