🚀 Kubernetes: From YAML to Running Pods

Kubernetes may look complicated at first, but the basic process becomes much easier to understand when we break it into five stages:

1️⃣ Define the desired state

We start by writing YAML manifests that describe what we want Kubernetes to create.

• Deployment — Defines the container image, replica count, update strategy, and Pod configuration.
• Service — Gives Pods a stable network address and distributes traffic between them.
• ConfigMap — Stores non-sensitive application configuration.
• Secret — Stores sensitive values such as passwords, tokens, or certificates. Secrets should never be committed to Git in plain text.

2️⃣ Schedule workloads

After we submit the YAML using kubectl apply, the API server validates and stores the desired state.

The scheduler then selects the most appropriate node for each Pod based on:

• CPU and memory requests
• Resource availability
• Node affinity and anti-affinity
• Taints and tolerations
• Labels and scheduling constraints

Requests help Kubernetes choose a suitable node, while limits prevent a container from using more resources than permitted.

3️⃣ Run the application

Once a node is selected, the kubelet on that node works with the container runtime to pull the image and start the containers.

• A Pod is the smallest deployable workload in Kubernetes.
• A ReplicaSet maintains the requested number of Pod replicas.
• A Deployment manages ReplicaSets and supports rolling updates and rollbacks.
• The kubelet continuously reports the Pod’s status to the control plane.

The overall journey is:

Write YAML → kubectl apply → API Server → Scheduler → Kubelet → Running Pods

4️⃣ Expose the application

After the Pods are running, users and other services need a reliable way to reach them.

• Service — Provides stable access to changing Pods.
• Ingress — Routes external HTTP and HTTPS traffic.
• DNS — Enables services to discover one another by name.
• NetworkPolicy — Controls which workloads are allowed to communicate.

This helps us expose applications safely without depending on temporary Pod IP addresses.

5️⃣ Observe and maintain reliability

A running container does not always mean a healthy application. That is why observability and health checks are essential.

• Readiness probe — Determines whether a Pod is ready to receive traffic.
• Liveness probe — Detects an unhealthy application and allows Kubernetes to restart it.
• Logs — Explain what the application is doing.
• Metrics — Show resource usage, traffic, latency, errors, and saturation.
• Events — Help identify scheduling, image-pull, volume, and container-startup problems.

Some useful troubleshooting commands are:


kubectl get pods
kubectl describe pod <name>
kubectl logs <pod>
kubectl get events --sort-by=.metadata.creationTimestamp


A few Kubernetes practices I consistently keep in mind:

✅ Use immutable container-image tags or digests
✅ Configure CPU and memory requests and limits
✅ Add correctly designed readiness and liveness probes
✅ Keep secrets out of source control
✅ Apply least-privilege RBAC and NetworkPolicies
✅ Monitor customer-facing SLIs such as availability, error rate, and latency
✅ Validate every rollout and maintain a tested rollback procedure

Kubernetes is not only about deploying containers. It is about continuously maintaining the desired state and building applications that are scalable, observable, secure, and resilient.

Build with intent. Operate with confidence.

— Zareen Khan