Kubernetes Building Blocks(1)

Introduction

If you liken Kubernetes to an ocean, those individual drops that make up the ocean are the core building blocks: Namespaces, Pods, ReplicaSets, Deployments, Labels, etc.

Our focus here will be on the first two mentioned.

As a professional working across Data Analytics and Cloud Engineering, I’ve found that the best way to master these concepts isn't just by reading documentation, but by using the Build, See, Destroy methodology. This approach allows you to experiment fearlessly, visualize the cluster's internal logic, and clean up after yourself.

In this post, we are going to move from a blank slate Minikube cluster to an orchestrated environment, exploring both the fast-paced command line and the birds-eye view of the Kubernetes Dashboard.

The Scenario: The Isolated Web Fleet

Imagine you are a DevOps Engineer tasked with deploying a fleet of Nginx web servers for a new project. However, the cluster is shared with other teams, so you can't just dump your resources into the default space.

Tasks

• Carve out a Virtual Sandbox: Create a dedicated Namespace to keep our project isolated.




• Deploy the Fleet: Use both Imperative (quick CLI) and Declarative (YAML/JSON) methods to launch five Nginx pods.




• Inspect & Troubleshoot: Go under the hood to check IP addresses, node placements, and handle the inevitable errors that come with cluster management.




• Visualize the Result: Launch the Minikube Dashboard to confirm 100% health of our fleet.

Namespaces

If multiple users and teams use the same Kubernetes cluster we can partition the cluster into virtual sub-clusters using Namespaces. The names of the resources/objects created inside a Namespace are unique, but not across Namespaces in the cluster.

Step 1: Checking if the Cluster is Ready

Before we can start building with Namespaces and Pods, we need to ensure our local environment is up and running. Using Minikube, we can quickly verify the health of our cluster, run minikube status.

To list all the Namespaces, we can run the following command:

$ kubectl get namespaces

Run $ kubectl get namespaces to Verifying our work is key. You can see the new namespace rahimah is now Active alongside the system-generated ones. It’s now a ready-to-use sandbox where we can deploy our pods without cluttering the rest of the cluster.

Namespaces are great for multi-tenancy. If you are working in a team, giving each developer or project their own namespace prevents naming collisions, meaning you can have a pod named web-server in Namespace A and another web-server in Namespace B without any conflict!

Step 1: Moving to Declarative by Defining Your First Pod

While kubectl run is great for quick tests, real-world Kubernetes relies on Manifests. These YAML files act as the source of truth for your infrastructure, allowing you to version control and share your configurations easily.

The Screenshot: Preparing the Manifest

In this sequence, I’m setting up the workspace and defining the blueprint for our application.

Step 2: Setting the Scene

I created a dedicated directory cluster and a new file rahimah.yaml to keep the project organized.

What the manifest contains:

apiVersion & kind: Tells Kubernetes we are creating a version 1 Pod.

metadata: This is where we name our resource (nginx-pod).

spec: This is the most critical part. It defines the desired state, specifically, that we want one container running the nginx:1.22.1 image on port 80.

KAMS stands for the parts of a manifest.

Tip: YAML is extremely sensitive to indentation! If you're off by even one space, the Kubernetes API will reject your file. I always recommend using a code editor with a YAML linting extension to catch these invisible errors before you hit the terminal, hence I used the vi editor.

The apiVersion field must specify v1 for the Pod object definition. The second required field is kind specifying the Pod object type. The third required field metadata, holds the object's name and optional labels and annotations. The fourth required field spec marks the beginning of the block defining the desired state of the Pod object (also named the PodSpec). Our Pod creates a single container running the nginx:1.22.1 image pulled from a container image registry, in this case from Docker Hub.

The above definition manifest, if stored by a rahimah.yaml file, is loaded into the cluster to run the desired Pod and its associated container image.

Before creating the pod, I'll save the YAML file in a directory, for organization. Then vi into it for verification.

Step 3: Reviewing the Manifest

Before we send our instructions to the Kubernetes API, it’s always a good habit to peek inside the file one last time. This ensures that our indentation is correct and that we are deploying the exact version of the image we intended.

Am inspecting the File with cat command

Notice the consistent feedback from the cluster: pod/nginx-pod created.

Whether you use a complex JSON/YAML file or a simple CLI command, the Kubernetes API processes the request and schedules the workload onto a node.

Step 5: Verifying the Workload

The most satisfying part of any Kubernetes project is seeing that Running status. This is where we confirm that the cluster has successfully pulled the images, allocated resources, and started our containers.

The Screenshot shows Healthy Pod Fleet

In this final view, we run the ultimate "truth" command: kubectl get pods.

I ran the ls command to confirm the file presence in that location,

then I created a pod from the YAML file and get pods to list the pods present in the cluster.

Then vi into the json file that created pod4 to edit it for pod5. Then cat again it to verify the changes were effected.

NOTE: The difference get pods and get pods -o wide

$ kubectl create -f nginx-pod.yaml

$ kubectl create -f nginx-pod.json

Both the YAML and JSON definition files can serve as templates or can be loaded into the cluster respectively as such:

Step 6: Deep Dive

Sometimes, a simple kubectl get pods isn't enough. When you need to know exactly what is happening inside a Pod, like which node it's running on, its IP address, or its lifecycle events, you need to use the describe command.

The Screenshot shows the anatomy of a Running Pod

In this image, I’m running kubectl describe pods and the output is a goldmine of information.

Node Information: You can see this pod is scheduled on the minikube node at IP 192.168.49.2.

Container Details: It confirms we are using the nginx:1.22.1 image and that the container is officially in the Running state.

Conditions: Notice the True values for Initialized, Ready, and PodScheduled. This is the _checklist _Kubernetes uses to ensure the pod is healthy.

IP Address: Each pod gets its own unique internal IP (in this case, 10.244.0.3).

NOTE: If your pod is stuck in Pending or CrashLoopBackOff, always scroll to the very bottom of the describe output. The Events section will tell you the exact reason, whether it’s a failed pull, a lack of memory, or a configuration error.

Step 7: The Apply Warning

As you saw earlier, switching between kubectl run and kubectl apply can trigger a warning message.

Recall the Screenshot Missing Annotation Warning

In this image, I used kubectl apply on a pod that was originally created with a simple run command.

What the Warning Means: Kubernetes is saying: "I don't see the 'last-applied-configuration' note on this pod." You don't actually have to do anything, Kubernetes automatically patches the pod by adding that annotation so it can track future declarative changes.

Hence, once you move to a file-based workflow (using YAML or JSON), stick with kubectl apply. It makes your deployments much more predictable and stable.

Step 8: Using the describe Command for Advanced Inspection

When a simple list isn't enough, we need to look closer. The kubectl describe command is your magnifying glass for everything happening inside a resource.

The Screenshots below show an anatomy of a Running Pod, am inspecting all the pods. The output provides critical data that isn't visible in a standard list:

Placement: You can see exactly which Node (in this case, our minikube VM) is hosting the pod.

Networking: Each pod is assigned its own internal IP address (like 10.244.0.3).

Lifecycle Conditions: Notice the "True" status for Initialized, Ready, and ContainersReady. This is the checklist Kubernetes uses to confirm the pod is healthy and capable of serving traffic.

Events: While not visible in every crop, the bottom of this output logs every action the cluster took, from pulling the image to starting the container.

Tip: If your pod status is Pending, use describe. It will often tell you if the cluster is out of memory or if it can't find a node that fits your requirements.

Always verify cluster health before deployment to minimize downtime.

Step 11: The GUI Perspective (Launching the Minikube Dashboard)

Sometimes a visual overview is exactly what you need to see the *big picture * of your cluster.

In the screenshot below an accessing the Dashboard by running the command minikube dashboard. This automates several complex steps for you;

Enabling the Addon: It ensures the dashboard components are active.

**

Launching the Proxy**: It creates a secure tunnel between your local machine and the cluster.

Opening the UI: It provides a local URL that opens directly in your browser.

The dashboard isn't just for looking, you can use it to edit YAML files, scale your deployments, and view real-time logs without typing a single kubectl command.

The solid green circle shows that 100% of our desired pods are healthy and running.

The Pod List shows all five of our Nginx pods (nginx-pod through nginx-pod5) lined up perfectly.

The Metadata at a Glance: Without typing a single command, we can see the internal IP addresses, the image versions (nginx:1.22.1), and even how long each pod has been alive.

The Sidebar: Notice the menu on the left. This is where you can explore more advanced building blocks like ConfigMaps, Secrets, and Storage Classes as you progress in your journey.

Step 10: Powering Down

Once you’ve finished your lab session, it’s best practice to stop your local cluster to save your machine's battery and CPU.

The screenshot shows the transition from an active environment to a clean stop.

$ minikube stop: This gracefully powers down the Minikube virtual machine.

$ minikube status: Confirming the shutdown. You can see the host, kubelet, and apiserver are all now in a Stopped state.

Your work isn't lost. The next time you run minikube start, your namespaces and manifests will be right where you left them.

Before advancing to more complex application deployment and management methods, become familiar with Pod operations with additional commands such as:

$ kubectl apply -f nginx-pod.yaml

$ kubectl get pods

$ kubectl get pod nginx-pod -o yaml

$ kubectl get pod nginx-pod -o json

$ kubectl describe pod nginx-pod

$ kubectl delete pod nginx-pod

Conclusion

Bridging the Gap Between Code and Infrastructure

Building this fleet of Nginx pods was more than just a technical exercise, it was a demonstration of how a structured "Build, See, Destroy" approach ensures infrastructure reliability. By moving from imperative CLI commands to declarative YAML and JSON manifests, we create a system that is version-controlled, repeatable, and scalable—the core pillars of a modern DevOps culture.

For me, the real power of Kubernetes lies in its self-healing nature and resource isolation. Whether it’s troubleshooting a missing client certificate or using the Dashboard to verify cluster health, the goal remains the same: ensuring high availability and operational excellence for the end user.

As the tech landscape continues to evolve, mastering these foundational building blocks is what allows us to build the resilient, sovereign digital infrastructures of tomorrow.