> ## Documentation Index > Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt > Use this file to discover all available pages before exploring further. # Lab Solution Explore Environment optional > Lab demonstrating commands to inspect a Kubernetes cluster and host networking, including nodes, interfaces, IPs, MAC addresses, bridges, routes, and listening ports. 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: | Task | Command | | - | - | | List nodes | `kubectl get nodes` | | Show nodes with IPs | `kubectl get nodes -o wide` | | Show host IP addresses | `ip address` | | Show a specific interface | `ip address show dev ` | | List bridges | `ip -d link show type bridge` | | Show a single link interface state | `ip link show dev ` | | Show routing table | `ip route` | | Find listening ports by process | `ss -ltnp \| grep ` or `netstat -npl \| grep ` | ## How many nodes are part of this cluster? Command: ```bash theme={null} kubectl get nodes ``` Example output: ```bash theme={null} NAME STATUS ROLES AGE VERSION controlplane Ready control-plane 20m v1.26.0 node01 Ready 19m v1.26.0 ``` Answer: There are two nodes: `controlplane` and `node01`. ## What is the internal IP address of the control plane node? Command: ```bash theme={null} kubectl get nodes -o wide ``` Example (relevant columns): ```bash theme={null} NAME STATUS ROLES AGE VERSION INTERNAL-IP controlplane Ready control-plane 20m v1.26.0 192.5.114.3 node01 Ready 19m v1.26.0 192.5.114.6 ``` Answer: The control plane node INTERNAL-IP is: ```text theme={null} 192.5.114.3 ``` ## 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: ```bash theme={null} ip address ``` Example excerpt (control plane host): ```bash theme={null} 3: eth0: mtu 1500 ... link/ether 52:54:00:72:06:00 brd ff:ff:ff:ff:ff:ff inet 192.5.114.3/24 brd 192.5.114.255 scope global eth0 inet 10.244.0.3/24 brd 10.244.0.255 scope global cni0 ``` 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: ```bash theme={null} ip address show dev eth0 ``` ## 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: ```bash theme={null} link/ether 52:54:00:72:06:00 ``` Answer: The MAC address for `eth0` on the control plane node is: ```text theme={null} 52:54:00:72:06:00 ``` (You can also run `ip address show dev ` to view a single interface cleanly.) ## What is the IP address assigned to node01? Command: ```bash theme={null} kubectl get nodes -o wide ``` From the example output: ```text theme={null} node01 INTERNAL-IP: 192.5.114.6 ``` Answer: Node `node01` INTERNAL-IP is: ```text theme={null} 192.5.114.6 ``` ## 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): ```bash theme={null} ip address show dev eth0 ``` Example excerpt: ```bash theme={null} 2: eth0: mtu 1500 ... link/ether 52:54:00:72:06:01 brd ff:ff:ff:ff:ff:ff inet 192.5.114.6/24 brd 192.5.114.255 scope global eth0 inet 10.244.0.6/24 brd 10.244.0.255 scope global cni0 ``` Answer: The MAC address for `eth0` on `node01` is: ```text theme={null} 52:54:00:72:06:01 ``` ## 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: ```bash theme={null} ip -d link show type bridge ``` Example output showing the bridge: ```bash theme={null} 3: cni0: mtu 1500 ... link/ether 0a:58:0a:f4:00:03 brd ff:ff:ff:ff:ff:ff inet 10.244.0.1/24 brd 10.244.0.255 scope global cni0 ``` Answer: The bridge interface used by the container runtime is: ```text theme={null} cni0 ``` ## What is the state of interface cni0? To check the operational state of `cni0`: Command: ```bash theme={null} ip link show dev cni0 ``` Example output: ```bash theme={null} 3: cni0: mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000 link/ether 0a:58:0a:f4:00:01 brd ff:ff:ff:ff:ff:ff ``` Answer: The state of `cni0` is: ```text theme={null} UP ``` ## 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: ```bash theme={null} ip route ``` Example output: ```bash theme={null} default via 172.25.0.1 dev eth1 proto dhcp metric 100 192.5.114.0/24 dev eth0 proto kernel scope link src 192.5.114.3 10.244.0.0/16 dev cni0 proto kernel scope link src 10.244.0.1 ``` Answer: The default gateway is: ```text theme={null} 172.25.0.1 ``` 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: ```bash theme={null} ss -ltnp | grep kube-scheduler # or netstat -npl | grep kube-scheduler ``` Example `ss` output: ```bash theme={null} LISTEN 0 128 127.0.0.1:10259 *:* users:(("kube-scheduler",pid=1234,fd=6)) ``` Answer: kube-scheduler is listening on TCP port: ```text theme={null} 10259 ``` 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](https://wiki.linuxfoundation.org/networking/iproute2); `net-tools` provides `netstat` — [https://sourceforge.net/projects/net-tools/](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 ` to find additional networking-related conditions and events. ## Links and references * Kubernetes Nodes: [https://kubernetes.io/docs/concepts/architecture/nodes/](https://kubernetes.io/docs/concepts/architecture/nodes/) * CNI (Container Network Interface): [https://www.cni.dev/](https://www.cni.dev/) * ip(8) and ss(8) man pages: [https://man7.org/linux/man-pages/man8/ip.8.html](https://man7.org/linux/man-pages/man8/ip.8.html) and [https://man7.org/linux/man-pages/man8/ss.8.html](https://man7.org/linux/man-pages/man8/ss.8.html) * kube-scheduler reference: [https://kubernetes.io/docs/reference/command-line-tools-reference/kube-scheduler/](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-scheduler/) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.