Exploring Your Kubernetes Cluster with kubectl

Overview

Every system needs a control panel — and for Kubernetes, that control panel is kubectl. In this article, you will learn what kubectl is, how to check the health of your cluster, and how to inspect the nodes that make up your cluster. By the end, you will feel confident navigating a live Kubernetes environment from the command line.

Prerequisites

Before reading this article, you should be familiar with:

1. What Kubernetes is and why it is used
2. Basic command-line / terminal usage
3. Having a running Kubernetes cluster (local via minikube, or a cloud-based cluster)
4. kubectl installed on your machine

Core Concepts

What is kubectl?

kubectl (pronounced "kube-control" or "kube-c-t-l") is the official command-line tool for interacting with the Kubernetes API. Think of it as a remote control for your cluster. With kubectl you can:

1. Create, update, and delete Kubernetes objects (Pod, Deployment, Service, etc.)
2. Inspect the current state of your cluster
3. View logs and debug running workloads

Almost everything you do with Kubernetes day-to-day goes through kubectl.

Kubernetes Cluster Components

When you check the health of a cluster, you will encounter three critical components:

These three components together form the control plane — the brain of your Kubernetes cluster.

Control Plane Nodes vs. Worker Nodes

A Kubernetes cluster contains two categories of nodes:

1. Control-plane nodes — Run the API server, scheduler, controller-manager, and etcd. They manage the cluster itself. Kubernetes avoids scheduling user workloads here to protect cluster stability.
2. Worker nodes — The machines where your actual application containers run.

Think of control-plane nodes as the management office and worker nodes as the factory floor.

Requests vs. Limits (Resource Management)

Each Pod on a node declares two resource values:

1. Request — The minimum amount of CPU/memory the Pod is guaranteed to receive.
2. Limit — The maximum amount of CPU/memory the Pod is allowed to consume.

If a Pod's limit is higher than its request, the extra resources are provided on a best-effort basis — they are not guaranteed. This allows Kubernetes to efficiently pack workloads onto nodes without over-provisioning.

Kubernetes Version Skew Policy

kubectl and your cluster API server may run slightly different versions — this is normal. Kubernetes follows semantic versioning (MAJOR.MINOR.PATCH, e.g., 1.22.4). The supported version skew is ±3 minor versions between your kubectl and the cluster. Staying within this range ensures compatibility.

Hands-On: Kubernetes Commands

Check kubectl and Cluster Version

This command shows the version of both your local kubectl tool and the remote Kubernetes API server.

Expected output (example):

Check Cluster Component Health

Use this command to get a quick diagnostic of your cluster's core components.

Expected output:

If all three components show Healthy, your cluster is in good shape.

List All Nodes in the Cluster

This command lists every node in your cluster along with its status, role, age, and Kubernetes version.

Expected output:

Nodes with ROLES set to control-plane,master are control-plane nodes. Nodes with <none> are worker nodes. All nodes should show Ready status.

Describe a Specific Node

The describe command gives you a deep view into a single node — including its labels, hardware capacity, running Pods, and resource usage.

Example:

This output is divided into several sections:

1. Labels — metadata tags on the node (OS, architecture, hostname)
2. Conditions — node health checks (memory pressure, disk pressure, readiness)
3. Capacity / Allocatable — total CPU, memory, and Pod slots available
4. System Info — kernel version, container runtime, kubelet version
5. Non-terminated Pods — Pods currently running on this node with their resource requests and limits

List Nodes with Extra Details

For a quick overview of node IPs and OS information alongside the standard output:

Step-by-Step Example

Let's walk through a full cluster health check from scratch.

1. Confirm kubectl can reach your cluster:

1. You should see both Client Version and Server Version printed. If you only see the client version, kubectl cannot reach the cluster — check your kubeconfig.
2. Verify all core components are healthy:

1. All three components (scheduler, controller-manager, etcd-0) should report Healthy.
2. List all nodes and confirm they are Ready:

1. Every node should show Ready. A node showing NotReady needs investigation.
2. Inspect a worker node in detail:

1. Look at the Conditions section — all conditions except Ready should be False (meaning no pressure/issues). The Ready condition should be True.
2. Check what is running on the node:
3. In the output of kubectl describe nodes kube1, scroll to the Non-terminated Pods section. You will see system Pods like kube-dns, kube-proxy, and flannel — these are the cluster's own infrastructure components running in the kube-system namespace.

Summary

1. kubectl is the primary CLI tool for interacting with a Kubernetes cluster via its API.
2. Use kubectl version to confirm connectivity and check version compatibility.
3. Use kubectl get componentstatuses to verify the health of the control plane (scheduler, controller-manager, etcd).
4. Kubernetes nodes are split into control-plane nodes (manage the cluster) and worker nodes (run your workloads).
5. Use kubectl get nodes to list all nodes and their status.
6. Use kubectl describe nodes <name> to get detailed information: hardware specs, conditions, running Pods, and resource usage.
7. Each Pod has a request (guaranteed resources) and a limit (maximum resources). Understanding this helps you plan cluster capacity.