Introduction
Modern applications are often packaged in containers. A container bundles an application with the libraries and settings it needs, making the application easier to run consistently. Running one container is straightforward. Running many containers reliably is harder: an operator must decide where they run, restart failed containers, connect applications to one another, and roll out changes safely.
Kubernetes is a container orchestration system that handles those cluster-level responsibilities. You describe the state you want—for example, “run three copies of this web application”—and Kubernetes continually works to make the actual state match that desired state.
A Kubernetes cluster consists of one or more machines called nodes. The control plane manages the cluster, while nodes provide the CPU, memory, networking, and container runtime used by applications. Applications run in Kubernetes objects such as Pods, Deployments, and Services.
In this first lab, you will not deploy an application yet. You will first learn how to orient yourself inside a real cluster:
- Identify the tools, active cluster, Kubernetes version, and node health.
- Find the control-plane and node components that make Kubernetes work.
- Inspect cluster endpoints and detailed node information.
- Explore Pods, Deployments, and Services across namespaces.
The environment is already prepared so that you can focus on Kubernetes concepts instead of installation. It uses Minikube v1.38.1 with a profile named labex-v135, running Kubernetes v1.35.5. Minikube runs a complete Kubernetes cluster inside a Docker container on the LabEx VM. This is a single-node learning environment, but the Kubernetes commands and concepts you practice also apply to larger clusters.
You will work entirely in the terminal. Read the explanations before running each command, then compare the real output with the described evidence. Exact ages, restart counts, and generated names can differ; that is normal in a live system.
Verify the Preconfigured Cluster
In this step, you will learn how the terminal tools connect to Kubernetes, identify the supplied software versions, and confirm that the cluster is ready. Before changing a cluster, an administrator should always know which cluster is active and whether it is healthy.
Environment startup: This lab starts a complete Kubernetes cluster for you. Configuring its control plane, node, and networking components usually takes 2–3 minutes. Please wait patiently for the environment to finish loading before running the commands below.
Understand the Tools
You will use two related command-line tools:
minikubecreates and manages local Kubernetes clusters. A named Minikube environment is called a profile. This lab uses thelabex-v135profile.kubectlis the standard Kubernetes command-line client. It sends requests to the Kubernetes API server to list, create, update, and delete objects.
The cluster is already running. Do not run minikube start: doing so is unnecessary and could make you wait while Minikube rechecks the existing environment.
Enter the Working Directory
Move to the project directory, where later labs will store manifests and other learner-created files:
cd /home/labex/project
The cd command changes the shell's current directory. It normally prints no output when it succeeds.
Check the Minikube Version
Display the installed Minikube version. An option beginning with -- changes command behavior. Here, --short asks for only the version number.
minikube version --short
v1.38.1
This is the cluster-management tool's version, not the Kubernetes version. Minikube and Kubernetes are separate projects and have separate version numbers.
Check the Client and Server Versions
Ask kubectl for version information. This contacts the cluster, so it checks the local client and remote API server:
kubectl version
Client Version: v1.35.5
Kustomize Version: ...
Server Version: v1.35.5
Client Version is the installed kubectl; Server Version is reported by the Kubernetes API server. Seeing the server line proves that kubectl successfully reached a cluster. Kustomize is a bundled manifest-customization feature that is not needed in this lab.
Confirm the Active Context
One computer can store access details for several clusters in a kubeconfig file. A kubeconfig context selects a cluster, user credentials, and default namespace. Checking it prevents accidental work in the wrong cluster.
kubectl config current-context
labex-v135
This matches the prepared Kubernetes v1.35 profile.
List and Select Contexts
Real kubeconfig files often contain more than one context. List them before switching so you do not have to guess a name:
kubectl config get-contexts
The NAME column contains context names, and the CURRENT column marks the active one with *. The cluster, authentication information, and default namespace associated with each context appear in the other columns.
Use use-context when you need to select one of those names. Selecting labex-v135 again is safe even though it is already current, and lets you practise the exact context-switching workflow:
kubectl config use-context labex-v135
Switched to context "labex-v135".
current-context answers “which one is selected?”, get-contexts answers “which choices exist?”, and use-context NAME changes the selection. These commands change only the local client choice; they do not start, stop, or modify a cluster.
Check the Minikube Profile
Ask Minikube for this profile's status. The short option -p means profile and is followed by its name.
minikube status -p labex-v135
labex-v135
type: Control Plane
host: Running
kubelet: Running
apiserver: Running
kubeconfig: Configured
host means the Minikube node container is running. kubelet is the node agent. apiserver is the Kubernetes API endpoint. kubeconfig: Configured means local client configuration points to this cluster. All should be healthy.
List the Nodes
Most kubectl commands follow kubectl <verb> <resource>. Here, get reads objects and nodes is the resource type:
kubectl get nodes
NAME STATUS ROLES AGE VERSION
labex-v135 Ready control-plane ... v1.35.5
NAME identifies the node. STATUS=Ready means it can run workloads. ROLES shows that it hosts the control plane. AGE may be older than this session because the image restores a prepared snapshot. VERSION is the kubelet version.
This lab has one node performing control-plane and workload duties. Production clusters commonly spread these duties across several machines.
Step Checkpoint
You established that kubectl reaches the intended labex-v135 cluster and that its node is Ready on Kubernetes v1.35.5. This is a useful orientation routine whenever you enter an unfamiliar cluster.
Identify Kubernetes Architecture Components
In this step, you will connect the Kubernetes architecture model to real components. Names such as API server, scheduler, and kubelet become easier to remember when you see their running Pods.
Follow a Request Through Kubernetes
Imagine that you ask Kubernetes to run a web application. First, kubectl sends the request to the kube-apiserver, which validates it and stores desired state in etcd.
Next, the kube-scheduler chooses a node for each new Pod. The kube-controller-manager watches the cluster and works to make actual state match desired state.
Finally, the kubelet on the selected node asks the container runtime to start the Pod's containers. Networking components allow Pods and Services to communicate.
This continuous comparison between desired and actual state is reconciliation. If a Deployment requests three Pods but only two exist, a controller creates the missing Pod.
Understand Pods and System Namespaces
A Pod is the smallest deployable Kubernetes unit. It wraps one or more closely related containers and gives them shared networking and storage context.
A namespace provides a logical scope for namespaced objects. kube-system contains cluster infrastructure. The option -n kube-system tells kubectl to search there rather than in the default namespace. Its longer equivalent is --namespace=kube-system; both forms select the same scope.
Minikube runs control-plane components as static Pods. The kubelet creates these directly from node files, allowing the control plane to start before ordinary scheduling is available.
List the Control Plane
Objects can carry labels, key-value metadata used for grouping and selection. Use -l tier=control-plane to select Pods with that label:
kubectl get pods -n kube-system -l tier=control-plane
NAME READY STATUS RESTARTS AGE
etcd-labex-v135 1/1 Running ... ...
kube-apiserver-labex-v135 1/1 Running ... ...
kube-controller-manager-labex-v135 1/1 Running ... ...
kube-scheduler-labex-v135 1/1 Running ... ...
The API server is Kubernetes' front door. etcd stores cluster state. The scheduler chooses Pod placement. The controller manager runs reconciliation controllers.
READY=1/1 means the Pod's one container is ready. Long-running components should be Running. RESTARTS may be nonzero after the saved cluster resumes. AGE describes object age, not time spent in this lab.
Inspect the Labels
Show labels in a final column:
kubectl get pods -n kube-system -l tier=control-plane --show-labels
Look for component=kube-apiserver and tier=control-plane. The first distinguishes a component; the second groups all control-plane Pods. Labels identify objects, and selectors find matching objects.
Inspect Node Networking Components
Use a set-based selector meaning that k8s-app is either kube-proxy or calico-node. Quotes keep the shell from interpreting parentheses.
kubectl get pods -n kube-system -l 'k8s-app in (kube-proxy,calico-node)'
NAME READY STATUS RESTARTS AGE
calico-node-... 1/1 Running ... ...
kube-proxy-... 1/1 Running ... ...
Calico configures Pod networking. kube-proxy maintains node rules that help Services direct traffic to Pods. The kubelet is absent from this list because it is the host agent responsible for operating Pods, so it runs as a host service rather than an ordinary Pod managed by itself.
Step Checkpoint
The API server accepts requests, etcd stores state, the scheduler chooses placement, controllers reconcile state, the kubelet operates the node, and Calico plus kube-proxy support networking.
Inspect Cluster and Node Details
In this step, you will move from a simple health check to detailed inspection. Kubernetes offers concise list views and detailed descriptions; learning when to use each is an essential troubleshooting habit.
Locate the Cluster Endpoints
kubectl cluster-info is a purpose-built orientation command. Unlike kubectl get, it does not list one resource type; it asks the active cluster to report the addresses of important services such as the API server and CoreDNS.
kubectl cluster-info
Kubernetes control plane is running at https://...
CoreDNS is running at https://...
The control-plane URL is the API server endpoint. CoreDNS provides DNS service discovery, allowing workloads to find Services by name instead of tracking changing IPs. Addresses vary, so focus on is running, which shows the API server returned information. It does not prove every workload is healthy.
Expand the Node List
Add -o wide to request more columns:
kubectl get nodes -o wide
NAME STATUS ROLES AGE VERSION INTERNAL-IP ... OS-IMAGE
labex-v135 Ready control-plane ... v1.35.5 192.168.49.2 ... Debian GNU/Linux 12 (bookworm)
INTERNAL-IP is the node's cluster-network address. EXTERNAL-IP=<none> means it has no Kubernetes-managed public address. OS-IMAGE, KERNEL-VERSION, and CONTAINER-RUNTIME describe the node software.
The LabEx backend is Ubuntu 22.04, while Minikube represents the Kubernetes node with a Debian-based Docker container. Seeing Debian here is expected.
Describe the Node
Use describe when a list row is not detailed enough. Its shape is kubectl describe <resource-type> <name>; here the resource type is node and the object name is labex-v135:
kubectl describe node labex-v135
Near the top, inspect identity and scheduling:
Name: labex-v135
Roles: control-plane
Taints: <none>
Unschedulable: false
Taints can repel Pods that do not tolerate them. <none> means this learning node has none. Unschedulable: false means Kubernetes may place workloads on it.
Find the Conditions table:
Type Status ... Reason
NetworkUnavailable False ... CalicoIsUp
MemoryPressure False ... KubeletHasSufficientMemory
DiskPressure False ... KubeletHasNoDiskPressure
PIDPressure False ... KubeletHasSufficientPID
Ready True ... KubeletReady
For pressure and unavailable conditions, False is healthy because the problem is absent. For Ready, True is healthy. Always read the condition name with its value.
Capacity is the node's total reported resources. Allocatable is what Kubernetes can offer Pods after system reservations. System Info reports the runtime and kubelet. Later sections list Pods, allocated requests and limits, and events. Exact values and timestamps can vary.
Step Checkpoint
Use get for a fast table, get -o wide for extra columns, and describe for conditions, capacity, runtime details, and events for one object.
Inspect Resources Across Namespaces
In this step, you will build a beginner's map of common objects: Namespaces organize resources, Pods run containers, Deployments manage Pods, and Services provide stable network access.
Understand the Object Relationships
- A Pod is the smallest deployable unit and contains one or more containers.
- A Deployment declares how many copies of a stateless application should run and manages Pods through a ReplicaSet.
- A Service gives selected Pods a stable virtual IP and DNS name because replaceable Pod IPs can change.
- A Namespace groups namespaced objects and allows the same name in different scopes.
A simplified path is: a Deployment manages Pods, while a Service selects those Pods and gives clients a stable endpoint. Not every object is namespaced; Nodes belong to the whole cluster.
List Pods in Every Namespace
Without a namespace option, kubectl get pods searches only the current namespace. -A means --all-namespaces:
kubectl get pods -A
NAMESPACE is the logical scope. NAME identifies the Pod there. READY is ready containers divided by total containers. STATUS is the lifecycle phase. RESTARTS counts restarts, and AGE is object age.
Long-running infrastructure should be Running. Some ingress admission Pods are Completed with 0/1 readiness because they performed one-time Jobs and exited successfully. Health must be interpreted according to workload purpose.
List Deployments
The plural resource name deployments asks for Deployment objects. Keep -A because system Deployments live outside the current default namespace:
kubectl get deployments -A
NAMESPACE NAME READY UP-TO-DATE AVAILABLE AGE
ingress-nginx ingress-nginx-controller 1/1 1 1 ...
kube-system calico-kube-controllers 1/1 1 1 ...
kube-system coredns 1/1 1 1 ...
kube-system metrics-server 1/1 1 1 ...
READY is ready replicas divided by desired replicas. UP-TO-DATE counts replicas using the current Pod template. AVAILABLE counts replicas available for their purpose. The coredns-... Pod seen earlier is maintained by the coredns Deployment.
List Services
Pods are replaceable, so clients should not depend on a Pod IP. List stable Service endpoints:
kubectl get services -A
NAMESPACE NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
default kubernetes ClusterIP 10.96.0.1 <none> 443/TCP ...
kube-system kube-dns ClusterIP 10.96.0.10 <none> ... ...
ingress-nginx ingress-nginx-controller NodePort ... <none> ... ...
TYPE describes exposure. ClusterIP is reachable inside the cluster; NodePort also opens a node port. CLUSTER-IP is the stable virtual address. EXTERNAL-IP=<none> means no external address is assigned. PORT(S) lists exposed protocols and ports.
The kubernetes Service exposes the API in-cluster. kube-dns gives stable access to CoreDNS. Ingress Services support incoming HTTP and HTTPS.
Build a Combined View
When you do not yet know which common workload type exists, kubectl get all provides a combined orientation view. Adding -A repeats the all-namespaces scope used above:
kubectl get all -A
This groups common resources such as Pods, Services, DaemonSets, Deployments, ReplicaSets, and Jobs. You may see one component at several levels: Deployment, ReplicaSet, and Pod.
Despite its name, get all does not return every resource. ConfigMaps, Secrets, NetworkPolicies, and many others are omitted. Use it for orientation, then request the exact resource type.
Step Checkpoint
Namespaces provide scope, Pods run containers, Deployments maintain desired Pod replicas, and Services provide stable network access to changing Pods.
Summary
You completed your first guided exploration of a Kubernetes cluster. You learned that Kubernetes manages desired state across nodes and that kubectl communicates with the API server using the active kubeconfig context.
You practiced how to distinguish Minikube, Kubernetes, and kubectl versions; confirm context and node readiness; identify control-plane, node, and networking components; use labels and selectors; choose between get, get -o wide, and describe; interpret node conditions and capacity; and relate Namespaces, Pods, Deployments, and Services.
The key beginner habit is to inspect before changing anything: confirm context, check node health, identify the relevant namespace and resource type, and read reported state carefully. Later labs build on this model as you create your own workloads.
