Skip to main content
In this lesson you’ll inspect cluster networking by checking node interfaces, CNI logs, the kube-apiserver configuration, and kube-system workloads. These steps help answer common Kubernetes networking questions such as node subnets, Pod IP allocation, Service ClusterIP ranges, and how kube-proxy is deployed and configured.
Before you begin, you need kubectl access to the cluster and shell access on a control-plane node (or appropriate permissions to view pod logs and static manifests). Use kubectl from a machine with cluster credentials.

​
Question 1 — What network range are the nodes in the cluster part of?

Inspect the nodes to get their internal IPs, then verify the node’s interface addresses on a control-plane or any node. Run:
Example output:
On the control plane, check interfaces:
Example (truncated) output:
Explanation:
  • The node’s primary interface for cluster traffic is eth0 with inet 192.168.10.10/24.
  • Therefore the nodes are on the 192.168.10.0/24 subnet (a /24 provides host addresses in the last octet).
Answer: 192.168.10.0/24

​
Question 2 — What is the range of IP addresses configured for Pods on this cluster?

This cluster uses Weave Net as the CNI. Pod IP allocation configuration is typically visible in the Weave Net pod logs (look for ipalloc-range or IPALLOC_RANGE). List the weave pods:
Example output:
Inspect the Weave Net pod logs:
Excerpt:
Explanation:
  • Weave Net is allocating Pod IPs from 10.244.0.0/16, as indicated by ipalloc-range and the weave bridge address (10.244.0.1/16).
Answer: 10.244.0.0/16

​
Question 3 — What IP range is configured for Services within the cluster?

The Service ClusterIP range is configured via the kube-apiserver flag --service-cluster-ip-range. Inspect the static manifest typically located at /etc/kubernetes/manifests/kube-apiserver.yaml on a control-plane node or view the contents using kubectl if the manifest is exported elsewhere. Example manifest snippet:
Answer: 10.96.0.0/12
Do not modify kube-apiserver static manifests unless you understand the impact. Changes to --service-cluster-ip-range require careful planning and could disrupt cluster services.

​
Question 4 — How many kube-proxy pods are deployed in this cluster?

List kube-system pods:
Example output:
Explanation:
  • There are two kube-proxy pods (one per node in this 2-node cluster).
Answer: 2

​
Question 5 — What type of proxy is kube-proxy configured to use?

Inspect kube-proxy logs to see which proxier implementation it selected (e.g., iptables, ipvs, or userspace). Example:
Excerpt:
Answer: iptables For more on proxier implementations see the kube-proxy documentation: https://kubernetes.io/docs/reference/command-line-tools-reference/kube-proxy/

​
Question 6 — How does the cluster ensure kube-proxy runs on all nodes?

Kubernetes commonly deploys node-local agents (like kube-proxy and many CNIs) as a DaemonSet so a copy runs on each eligible node. Verify DaemonSets:
Or view all resources:
Example relevant output:
Explanation:
  • daemonset.apps/kube-proxy with desired=2 ensures kube-proxy runs on each node matching the DaemonSet’s nodeSelector/tolerations.
  • DaemonSets guarantee one (or more) pods per eligible node and are the usual mechanism for per-node agents.
Answer: kube-proxy is deployed as a DaemonSet, ensuring one pod per node.

​
Summary

Watch Video