Skip to main content
This lesson walks through the commands to inspect a Kubernetes cluster and the host network interfaces that carry cluster traffic. Each section shows the command to run, an example trimmed output, and the concise answer you would record for the lab. Quick commands reference:

​
How many nodes are part of this cluster?

Command:
Example output:
Answer: There are two nodes: controlplane and node01.

​
What is the internal IP address of the control plane node?

Command:
Example (relevant columns):
Answer: The control plane node INTERNAL-IP is:

​
What is the network interface configured for cluster connectivity on the control plane node?

To find which host interface carries cluster/pod IPs, list the host IP addresses and identify the interface bound to the node IP and/or the pod network IP allocated by the CNI. Use ip address (or ip link) to inspect interfaces. Command:
Example excerpt (control plane host):
Explanation and answer:
  • The node IP 192.5.114.3 is bound to eth0, so eth0 is the interface used for cluster connectivity on the control plane.
  • To inspect only that interface:

​
What is the MAC address of the control plane interface?

From the ip address output for the interface (eth0) the MAC address appears as link/ether. Example:
Answer: The MAC address for eth0 on the control plane node is:
(You can also run ip address show dev <interface> to view a single interface cleanly.)

​
What is the IP address assigned to node01?

Command:
From the example output:
Answer: Node node01 INTERNAL-IP is:

​
What is the MAC address assigned to node01?

SSH to node01 (or run the following on node01) and inspect its interface (commonly eth0): Command (on node01):
Example excerpt:
Answer: The MAC address for eth0 on node01 is:

​
Which bridge interface is created by the container runtime on the host?

CNI plugins typically create a bridge to attach pod interfaces (commonly named cni0). List bridge-type interfaces: Command:
Example output showing the bridge:
Answer: The bridge interface used by the container runtime is:

​
What is the state of interface cni0?

To check the operational state of cni0: Command:
Example output:
Answer: The state of cni0 is:

​
If you ping Google from the control plane node, what route does it take? (Default gateway)

Find the default route (the gateway used for destinations without more specific routes) with: Command:
Example output:
Answer: The default gateway is:
Traffic to external addresses (e.g., Google) will be routed via 172.25.0.1 using device eth1.

​
What port is the kube-scheduler listening on in the control plane?

You can inspect listening sockets and which process owns them using ss or netstat. Commands:
Example ss output:
Answer: kube-scheduler is listening on TCP port:
In this example it is bound to 127.0.0.1:10259 (localhost). If it were bound to all interfaces you would see 0.0.0.0:10259.
If ss or netstat is not available, install the appropriate package (for example, iproute2 provides ss — https://wiki.linuxfoundation.org/networking/iproute2; net-tools provides netstat — https://sourceforge.net/projects/net-tools/). Alternatively, inspect the scheduler process arguments with ps aux | grep kube-scheduler to check flags like --bind-address or --port.

​
Quick troubleshooting tips

  • If a node is Ready but you can’t reach its IP, verify host firewall rules and cloud provider security groups.
  • If pods are not getting IPs in the expected range, check CNI plugin logs and the bridge (cni0) state.
  • Use kubectl describe node <name> to find additional networking-related conditions and events.

Watch Video