Part-81: Kubernetes — PODs (Imperative Way) Demo

#kubernetes #cloud #devops #learning

Kubernetes — PODs with Imperative Way

Step-01: PODs Introduction

What is a Pod? (short intro)

A Pod is the smallest deployable object in Kubernetes. It wraps one (usually) container instance of your application and provides a shared networking and storage context for that container. When you want to run a container on Kubernetes, you create a Pod that holds it.

What is a Multi-Container Pod? (short intro)

A Multi-Container Pod contains two or more containers that must run together and share the same network namespace and storage. These are used for tightly-coupled helper patterns (sidecars) like log collectors, data pullers/pushers, or content generators that the main container consumes.

Step-02: PODs Demo (Imperative)

Step-02-01: Get Worker Nodes Status

Verify your kubeconfig is set and that worker nodes are Ready.

# Configure kubeconfig for kubectl (replace placeholders)
gcloud container clusters get-credentials <CLUSTER-NAME> --region <REGION> --project <PROJECT-NAME>

# Example
gcloud container clusters get-credentials standard-public-cluster-1 --region us-central1 --project gcp-zero-to-hero-468909

# Get Worker Node Status
kubectl get nodes

# Get Worker Node Status with wide option
kubectl get nodes -o wide

Step-02-02: Create a Pod

Create a Pod imperatively using kubectl run.

# Template
kubectl run <desired-pod-name> --image <Container-Image> 

# Replace Pod Name & Container Image
kubectl run my-first-pod --image ghcr.io/stacksimplify/kubenginx:1.0.0

Step-02-03: List Pods

# List Pods
kubectl get pods

# Alias: po
kubectl get po

Step-02-04: List Pods with wide option

This shows which node each Pod is running on (and other extra info).

# List Pods with Wide Option
kubectl get pods -o wide

Step-02-05: What happened in the background when the Pod was created?

When you ran kubectl run:

Kubernetes created a Pod object in the cluster.

The node agent (kubelet) scheduled the Pod to a worker node (or the scheduler did).
The node pulled the Docker image from the registry (Docker Hub, GitHub Packages, etc.).
Kubernetes created the container inside the Pod and started it.

These are the key lifecycle actions that lead to a running container inside a Pod.

Step-02-06: Describe Pod (troubleshooting)

kubectl describe is essential for debugging. Look at Events for errors, image pulls, scheduling info, readiness/liveness failures, etc.

# Get list of pod names
kubectl get pods

# Describe the Pod (replace with your pod name)
kubectl describe pod <Pod-Name>
kubectl describe pod my-first-pod

Observation:

Review the Events section closely — it usually tells you why something failed (image pull errors, crashloops, scheduling issues, etc.).

Step-02-07: Access the Application

Right now the Pod is only reachable inside the cluster (on the node / cluster network).
To access the app externally, create a Service (NodePort or LoadBalancer).
Services are a key Kubernetes concept — they provide stable networking (VIP) and load-balancing in front of Pods.

Step-02-08: Delete Pod

Clean up when you’re done.

# Get list of pods
kubectl get pods

# Delete Pod
kubectl delete pod <Pod-Name>
kubectl delete pod my-first-pod

Wrap-up / Tips

This is the imperative approach — you used kubectl commands to create and manage Pods directly.
For production or repeatable setups, prefer the declarative approach (YAML + kubectl apply -f) so you can version-control manifests.
Use kubectl describe and kubectl logs frequently when debugging.

🌟 Thanks for reading! If this post added value, a like ❤️, follow, or share would encourage me to keep creating more content.

— Latchu | Senior DevOps & Cloud Engineer

☁️ AWS | GCP | ☸️ Kubernetes | 🔐 Security | ⚡ Automation
📌 Sharing hands-on guides, best practices & real-world cloud solutions