DevOps3 min read
Do you actually need Kubernetes? A decision guide
Kubernetes is excellent at problems most teams do not have yet. The cost of adopting it early is paid in engineering hours you needed elsewhere.
As an application developer on Kubernetes you mainly work with Deployments (desired replicas of your container), Services (stable internal networking), Ingress (external routing), ConfigMaps and Secrets (configuration), probes (health), and resource requests and limits (scheduling). Understanding those covers the vast majority of day-to-day work.
| Object | What it does |
|---|---|
| Pod | One or more containers scheduled together; rarely created directly |
| Deployment | Maintains N replicas and performs rolling updates |
| Service | Stable DNS name and load balancing across pods |
| Ingress | Routes external HTTP traffic to services |
| ConfigMap | Non-secret configuration as env vars or files |
| Secret | Sensitive configuration; base64-encoded, encrypt at rest |
| HorizontalPodAutoscaler | Scales replicas from metrics |
| Job / CronJob | Run-to-completion and scheduled tasks |
| PersistentVolumeClaim | Durable storage for stateful workloads |
| PodDisruptionBudget | Limits voluntary disruption during maintenance |
apiVersion: apps/v1
kind: Deployment
metadata: { name: web }
spec:
replicas: 3
selector: { matchLabels: { app: web } }
template:
metadata: { labels: { app: web } }
spec:
containers:
- name: web
image: registry.example.com/web@sha256:abc123
ports: [{ containerPort: 3000 }]
envFrom:
- configMapRef: { name: web-config }
- secretRef: { name: web-secrets }
resources:
requests: { cpu: 100m, memory: 256Mi }
limits: { memory: 512Mi }
readinessProbe:
httpGet: { path: /readyz, port: 3000 }
periodSeconds: 5
livenessProbe:
httpGet: { path: /healthz, port: 3000 }
periodSeconds: 15Readiness answers 'can this pod serve traffic right now'; liveness answers 'is this pod broken beyond recovery'.
Requests are what the scheduler reserves — they decide which node your pod lands on. Limits are the hard ceiling: exceeding a CPU limit throttles the container, and exceeding a memory limit kills it (OOMKilled).
kubectl get pods -l app=web # what is running
kubectl describe pod web-7d9f... # events: scheduling, probe failures, OOM
kubectl logs -f deploy/web --tail=100 # logs
kubectl logs web-7d9f... --previous # logs from the crashed instance
kubectl rollout status deploy/web # is the deploy done
kubectl rollout undo deploy/web # roll back
kubectl port-forward svc/web 3000:80 # reach it locally
kubectl top pods # actual CPU/memory usagekubectl describe is the one to learn first. Its events section explains almost every 'why is my pod not running' question — image pull failures, insufficient resources, failing probes, missing secrets.
For a couple of services, yes — it is clearer than a templating layer. Once you have many services and environments, Helm or Kustomize removes duplication that would otherwise drift.
They are base64-encoded, not encrypted, by default. Enable encryption at rest, restrict RBAC, and for anything sensitive use an external secret manager synced into the cluster.
The container keeps exiting and Kubernetes is backing off between restarts. Check kubectl logs --previous for the actual error; the state itself only tells you it keeps dying.
A rolling update plus correct readiness probes, a pod disruption budget, and graceful SIGTERM handling with a preStop delay so connections drain before the pod stops.
ROVQIX Engineering
Engineering team, ROVQIX
The ROVQIX engineering team builds and maintains web platforms, APIs and infrastructure for clients across SaaS, ecommerce and enterprise. These notes come out of real production work — deploys, incidents, migrations and audits.
ROVQIXdesigns and builds production web platforms — Next.js front ends, Node.js APIs and the infrastructure behind them. Tell us what you're building and we'll scope it with you.
Kubernetes is excellent at problems most teams do not have yet. The cost of adopting it early is paid in engineering hours you needed elsewhere.
A 1.2GB Node image that runs as root and ignores SIGTERM is the default outcome. Every part of that is avoidable.
Zero downtime is not a deployment tool setting. It is a property of an application that can run two versions at once.
No spam. Just the occasional case study and craft breakdown.