Hands-on Practical: Cluster Inspection

Kubernetes architecture consists of a control plane and worker nodes. You will use the kubectl command-line tool to connect to your local cluster and inspect these components directly. This exercise solidifies your understanding by allowing you to see the system's architecture reflected in its running state.

Before you begin, ensure that your local Kubernetes cluster, set up with Minikube or Kind, is running. Your kubectl command-line tool should also be configured to communicate with it.

Verifying Your Connection

First, let's confirm that kubectl is pointed at the correct cluster. The context determines which cluster your commands are sent to. You can check the current context with this command:

kubectl config current-context

The output should match the name of your local cluster, for example, minikube or kind-kind. If you manage multiple clusters, kubectl config get-contexts will list all available options.

With the context confirmed, run kubectl cluster-info to get a high-level summary of the cluster's endpoints.

kubectl cluster-info

You should see output similar to this:

Kubernetes control plane is running at https://127.0.0.1:50937
CoreDNS is running at https://127.0.0.1:50937/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.

This output verifies two important things: kubectl can successfully communicate with the Kubernetes API server (the control plane), and the cluster's internal DNS service (CoreDNS) is active. The API server endpoint is the entry point for all cluster management operations.

Inspecting Cluster Nodes

A Kubernetes cluster is composed of one or more nodes. In our local setup, we likely have a single node that serves as both a control plane and a worker. Let's list the nodes in the cluster.

kubectl get nodes

You can also use the shorter alias no: kubectl get no. The output provides a concise table:

NAME                 STATUS   ROLES           AGE   VERSION
minikube             Ready    control-plane   12m   v1.28.3

Here's a breakdown of the columns:

• NAME: The unique identifier for the node.
• STATUS: Indicates if the node is healthy and ready to accept Pods. Ready is the desired state.
• ROLES: Shows the role of the node. In larger clusters, you would see worker roles, but in many local setups, the single node is designated as the control-plane.
• AGE: How long the node has been running.
• VERSION: The Kubernetes version running on the node.

Exploring the kube-system Namespace

Kubernetes uses namespaces to organize objects within a cluster. Think of them as virtual clusters within your physical cluster. The components that make up Kubernetes itself run in a special namespace called kube-system.

To see the control plane and other system-level components running as Pods, execute the following command:

kubectl get pods -n kube-system

The -n flag specifies the namespace. The output reveals the running heart of your cluster:

NAME                               READY   STATUS    RESTARTS   AGE
coredns-5dd5756b68-7v7j9           1/1     Running   0          15m
etcd-minikube                      1/1     Running   0          15m
kube-apiserver-minikube            1/1     Running   0          15m
kube-controller-manager-minikube   1/1     Running   0          15m
kube-proxy-n2g2c                   1/1     Running   0          15m
kube-scheduler-minikube            1/1     Running   0          15m
storage-provisioner                1/1     Running   0          15m

This list directly corresponds to the architecture we discussed earlier.

• etcd-minikube: The cluster's backing store.
• kube-apiserver-minikube: The API server that kubectl communicates with.
• kube-controller-manager-minikube: Runs the controller loops.
• kube-scheduler-minikube: Assigns Pods to nodes.
• kube-proxy-...: A network proxy running on each node.
• coredns-...: Provides service discovery and DNS for the cluster.

Where is the Kubelet? You might notice that the Kubelet is missing from this list. That's because the Kubelet is not a Pod. It's a system agent that runs directly on the host operating system of each node, often as a systemd service. Its job is to communicate with the container runtime and the API server to manage the Pods scheduled for its node.

A diagram of the primary components running as Pods within the kube-system namespace.

Getting Detailed Information with describe

The get command gives you a summary, but for a deeper look into any Kubernetes object, you use the describe command. Let's inspect our node to see more detailed information. Replace minikube with your actual node name from the kubectl get nodes command.

kubectl describe node minikube

The output is verbose but extremely useful for diagnostics. It includes:

• Labels and Annotations: Key-value metadata used to organize and select objects.
• System Info: Details about the node's operating system, kernel version, and container runtime.
• Conditions: The health status of the node, such as Ready, MemoryPressure, or DiskPressure. The Ready condition is the most significant indicator of a healthy, functioning node.
• Capacity and Allocatable: Information about the node's total resources (CPU, memory, storage) and the amount available for Pods.
• Pods: A list of all Pods currently running on the node.
• Events: A chronological log of events related to the node, such as its registration with the cluster. This is often the first place to look when troubleshooting issues.

By running these commands, you have successfully interacted with your Kubernetes cluster's API, listed its primary resources, and mapped the running components back to the architecture discussed in this chapter. You have confirmed that your cluster is operational and ready for you to deploy applications, which is exactly what we will do in the next chapter.