Introduction
kubectl is the command-line tool you will use throughout CKAD-style Kubernetes work. Before you create Pods, Deployments, Services, or configuration objects, you need to know which cluster kubectl is talking to and which namespace your commands target by default.
In this lab, you will inspect the active Kubernetes context, list namespaces, set a practice namespace as the current namespace, and create a small ConfigMap to see how namespaced objects are isolated. The checks focus on the key Kubernetes state you create, not on exact command output formatting.
Confirm kubectl Access
In this step, you will confirm that kubectl can reach the prepared Kubernetes cluster and identify the context your commands are using.
Start in /home/labex/project. The mkdir -p command creates the directory if it is missing and does nothing harmful if it already exists. This course keeps learner work in that directory so later labs can create manifests and helper files in one predictable place.
mkdir -p /home/labex/project
cd /home/labex/project
A Kubernetes context is a saved connection choice in your kubeconfig. It tells kubectl which cluster, user credentials, and default namespace to use. Check the active context before running any object-changing command.
kubectl config current-context
You should see the prepared LabEx Kubernetes profile name:
labex-v135
For a predictable starting point, set the current context namespace to default. You are not creating an object here; you are only telling kubectl which namespace to use when a later namespaced command omits --namespace.
kubectl config set-context --current --namespace=default
The output should confirm that the current context was updated:
Context "labex-v135" modified.
The Kubernetes profile may need a short moment to finish starting after the VM appears. List the cluster nodes first. If this command reports that the API server is not ready yet, wait a few seconds and run the same command again until you see a Ready node.
kubectl get nodes --request-timeout=5s
Expected output will include a ready node and a Kubernetes version:
NAME STATUS ROLES AGE VERSION
labex-v135 Ready control-plane ... v1.35...
Now ask the API server for basic cluster information. This proves that your terminal is not just finding the kubectl binary; it is actually authenticated to a running cluster.
kubectl cluster-info
The output should mention a Kubernetes control plane endpoint:
Kubernetes control plane is running at ...
...
Read Namespaces
In this step, you will inspect Kubernetes namespaces and check which namespace your current context uses by default.
Namespaces are a way to divide namespaced Kubernetes objects into separate scopes inside the same cluster. Many application resources, such as Pods, Deployments, Services, Secrets, and ConfigMaps, live inside exactly one namespace.
List the namespaces that already exist in the cluster:
kubectl get namespaces
You should see system namespaces such as kube-system and the ordinary application namespace default:
NAME STATUS AGE
default Active ...
kube-system Active ...
...
Your context can also store a default namespace. When you run a namespaced command without --namespace, kubectl uses that default namespace. The --minify option shows only the active context, and the jsonpath expression prints only the namespace field.
kubectl config view --minify --output 'jsonpath={..namespace}'; echo
Because you set the context namespace in the previous step, this prints default:
default
You can always override the current namespace for a single command with --namespace. For example, inspect Pods in the Kubernetes system namespace without changing your context:
kubectl get pods --namespace kube-system
The exact Pod names can vary, but the command should return system Pods such as CoreDNS, networking, or storage components:
NAME READY STATUS RESTARTS AGE
... ... ... ... ...
Select a Practice Namespace
In this step, you will create a namespace for this lab and make it the default namespace for later commands.
Create a namespace named ckad-prep-contexts. Namespace names are part of object identity: a ConfigMap named app-settings in one namespace is different from a ConfigMap with the same name in another namespace.
kubectl create namespace ckad-prep-contexts
The creation command should confirm the new namespace:
namespace/ckad-prep-contexts created
Now update only the current context so commands without --namespace target ckad-prep-contexts. The --current option means “modify the context I am using now” instead of naming a context manually.
kubectl config set-context --current --namespace=ckad-prep-contexts
The output confirms that the context was modified:
Context "labex-v135" modified.
Check the namespace stored in the active context again:
kubectl config view --minify --output 'jsonpath={..namespace}'; echo
It should now print:
ckad-prep-contexts
Run a simple Pod listing without --namespace. Because the current namespace is now ckad-prep-contexts, this command looks inside your practice namespace. It is normal for the namespace to be empty.
kubectl get pods
Expected output:
No resources found in ckad-prep-contexts namespace.
Observe Namespace Scoping
In this step, you will create a small ConfigMap and use it to observe how the current namespace affects object lookup.
A ConfigMap stores non-sensitive configuration data for applications. It is lightweight, quick to create, and namespaced, which makes it useful for practicing namespace behavior before you start deploying real applications.
Create a ConfigMap named app-settings without passing --namespace. Because you selected ckad-prep-contexts in the previous step, Kubernetes creates it in that namespace.
kubectl create configmap app-settings --from-literal=mode=prep
The command should report:
configmap/app-settings created
List the ConfigMap without a namespace flag. This uses the current context namespace.
kubectl get configmap app-settings
Expected output:
NAME DATA AGE
app-settings 1 ...
Now ask for the same object with an explicit namespace. This should return the same ConfigMap because ckad-prep-contexts is where you created it.
kubectl get configmap app-settings --namespace ckad-prep-contexts
Finally, check the default namespace. The --ignore-not-found option makes kubectl exit successfully and print nothing when the object does not exist, which is useful for a guided lab because absence is the expected result here.
kubectl get configmap app-settings --namespace default --ignore-not-found
No output means the ConfigMap was not created in default. You have now seen the practical effect of setting the namespace in your current context.
Summary
You confirmed that kubectl can reach the prepared Kubernetes cluster, identified the active context, inspected existing namespaces, changed the current context namespace, and created a ConfigMap to observe namespace scoping. These basics are the foundation for the later CKAD Prep labs, where you will create application objects and need to know exactly where each object is being created and inspected.
