Cloud & DevOpsBy Abdul Rahman01 Jul 20263 min read
Kubernetes for Developers: The Essentials You Actually Need
You don't need to be a cluster administrator to work effectively with Kubernetes. The core objects, a production-ready Deployment, health checks, configuration and when Kubernetes is overkill.
Kubernetes has become the standard platform for running containers at scale, and it appears in a large share of backend and DevOps job descriptions. The good news for application developers: you only need a handful of concepts to be productive.
Ingress routes traffic to a Service, which load-balances across healthy Pods managed by a Deployment.
The Objects That Matter
- Pod — one or more containers that run together. Pods are disposable; Kubernetes replaces them freely.
- Deployment — declares how many replicas of a Pod should run and manages rolling updates and rollbacks.
- Service — a stable network address that load-balances across the Pods of a Deployment.
- Ingress (or the newer Gateway API) — routes external HTTP(S) traffic to Services.
- ConfigMap and Secret — configuration and sensitive values injected into containers.
A Production-Ready Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
name: api
spec:
replicas: 3
selector:
matchLabels: { app: api }
template:
metadata:
labels: { app: api }
spec:
containers:
- name: api
image: registry.example.com/api:1.4.2
ports: [{ containerPort: 3000 }]
envFrom: [{ secretRef: { name: api-secrets } }]
resources:
requests: { cpu: "100m", memory: "256Mi" }
limits: { memory: "512Mi" }
readinessProbe:
httpGet: { path: /health/ready, port: 3000 }
livenessProbe:
httpGet: { path: /health/live, port: 3000 }
Four details separate this from a tutorial example:
- Pinned image tag — never
latestin production. - Resource requests and limits — so the scheduler can place Pods and one service can't starve others.
- Readiness probe — traffic only goes to Pods that are ready.
- Liveness probe — stuck containers are restarted automatically.
Design Your App for Kubernetes
Kubernetes works best with applications that follow a few rules (largely the Twelve-Factor principles):
- Stateless processes — keep sessions and files in databases or object storage, not in the container.
- Configuration from environment variables.
- Logs to stdout/stderr, collected by the platform.
- Graceful shutdown — handle
SIGTERM, finish in-flight requests, then exit. - Fast startup, so scaling and rolling updates are quick.
Scaling
The Horizontal Pod Autoscaler adds or removes replicas based on CPU, memory or custom metrics. It only works well when resource requests are set accurately and the app is stateless.
When Kubernetes Is Overkill
Kubernetes brings real operational overhead. For a single application or a small team, managed platforms — serverless containers (AWS App Runner, Google Cloud Run), a PaaS, or a simple VM with Docker Compose — are often faster and cheaper. Kubernetes pays off when you run many services, need fine-grained control, or have a platform team to operate it.
Key Takeaways
- Learn Pods, Deployments, Services, Ingress, ConfigMaps and Secrets first.
- Pin image tags, set resource requests, and add readiness and liveness probes.
- Build stateless apps that log to stdout and shut down gracefully.
- Choose simpler platforms when Kubernetes' overhead isn't justified.
