Skip to main content
In this guide, we analyze the networking configuration of a Kubernetes cluster. We will review the node IP range, pod IP allocation, service IP range, and kube-proxy configuration. The sections below include command outputs and configuration excerpts to explain each concept in detail.

​
1. Determining the Node IP Range

First, verify the IP addresses of the nodes in your cluster (note that these addresses do not pertain to pods or services). Run the following command:
You might see output similar to:
In this example, the control plane has an internal IP of 192.168.10.10. To ensure which network interface uses this IP, run:
Locate the interface (e.g., Ethernet 0) that shows the IP 192.168.10.10. Since the IP belongs to the 192.168.10.x range, the subnet is 192.168.10.0/24.
A /24 subnet mask means the last octet is reserved for host addresses.

​
2. Identifying the Pod IP Range

To understand your pod network setup, check node details with:
Then, examine the network interfaces on your control plane node:
You may notice interfaces related to your networking solution (e.g., Weave). For example, an interface might show an IP address from the range 10.244.0.0/16, indicating the pod CIDR. To verify the pod network range, inspect the logs from one of the Weave pods:
Scroll through the logs to find an entry such as “added entry to weave-addr” which confirms the pod allocation range as 10.244.0.0/16. This means every pod receives an IP address from the 10.244.0.0/16 subnet.

​
3. Determining the Service IP Range

The service IP range for the cluster is defined in the API server configuration. Locate the kube-apiserver manifest file, typically found at /etc/kubernetes/manifests/kube-apiserver.yaml. Look for the flag:
Below is an excerpt from the kube-apiserver manifest:
This configuration confirms that services are assigned IP addresses within the 10.96.0.0/12 range.
Service cluster IP range, API server configuration, Kubernetes networking setup.

​
4. Examining the Kube Proxy Deployment

​
4.1 Number of Kube Proxy Pods

Kube-proxy is typically deployed as one pod per node. To count the number of kube-proxy pods, run:
A sample output might be:
In this example, one kube-proxy pod is running on each node. If your cluster has two nodes, expect to see two kube-proxy pods.

​
4.2 Kube Proxy Proxy Mode

To determine the proxy mode used by kube-proxy, check the logs of one of the kube-proxy pods:
Key log entries such as:
indicate that kube-proxy is operating in IPTables mode.

​
5. Ensuring Kube Proxy Runs on Every Node

Kube-proxy must run on every node to manage the network rules effectively. This is achieved by deploying kube-proxy as a DaemonSet. A DaemonSet automatically ensures that one instance of a pod runs on every node in the cluster. To verify this configuration, execute:
A sample output could be:
This confirms that kube-proxy is deployed as a DaemonSet, ensuring a consistent network setup across all cluster nodes.
Ensure that any changes to the DaemonSet configuration are carefully validated to prevent disruptions to cluster networking.

​
Summary

By reviewing node interfaces, Weave logs, and the API server configuration, you can confirm the cluster’s networking setup and understand the kube-proxy deployment strategy. For further details on Kubernetes networking, check out the Kubernetes Documentation.

Watch Video