kubernetes tips and tricks
Essential practices for namespaces, resources, resilience, and observability that separate hobby clusters from real-world deployments.
When we work with any technology across multiple projects, we often realize the mistakes we made during our early learning days. Gradually, we start understanding the technology more deeply, and at some point, we look back and recognize those initial missteps. Sometimes, we even think — “If only someone had told me this earlier, it would’ve been so much easier.”
In the beginning, we rely heavily on trial-and-error problem-solving just to get things working.
Here are some essential checks and tips you should follow while developing Kubernetes applications.
Ignoring Namespaces
Putting all workloads in the default namespace leads to:
Conflicts
Poor isolation
Use separate namespaces for dev, staging, and production. For each separate application, create a new namespace and place all its Kubernetes objects within it.
Manual Deployments
Using kubectl apply -f in production won’t be good for your sleep and peace. - Manual kubectl commands are error-prone and not auditable.
Use declarative YAMLs and apply them via CI/CD or GitOps tools (like ArgoCD or Flux).
Skipping Resource Requests and Limits
Without CPU/memory requests and limits:
Some Pods hog all resources
Others get throttled or evicted
Always define resources.requests and resources.limits for predictable performance.
No Rolling Update Strategy
Default rollout settings can cause downtime.
Tune maxUnavailable and maxSurge for safe rolling updates.
High Availability & Resilience
Running single replicas
Single pods have no redundancy. Always run at least 2-3 replicas for critical services, and use pod disruption budgets to prevent all replicas from going down during maintenance.
Missing pod anti-affinity rules
All replicas on the same node means a single node failure takes down your entire service. Use anti-affinity to spread pods across nodes or availability zones.
Missing Health Probes for your microservice and applicatinon
No livenessProbe or readinessProbe?
Kubernetes won’t know if your service is healthy — leading to:
Traffic going to broken Pods
Stuck containers never restarting
Define both probes properly.
Security
Running Containers as Root
Running containers as root is a huge security risk in production.
Use securityContext.runAsUser and runAsNonRoot to enforce safer defaults.
Using default service accounts
Many teams use the default service account with excessive permissions. Follow least privilege principles and create dedicated service accounts per application.
Observability
Not monitoring cluster capacity
Running out of node capacity causes pod scheduling failures. Monitor node resources and set up cluster autoscaling.
Poor Logging and Monitoring
Only checking logs with kubectl logs isn’t enough in production.
Use Prometheus + Grafana or ELK / Loki for centralized monitoring and alerting.
The key is to treat Kubernetes as a production platform from the start, not as a development toy. Invest in proper configuration, monitoring, and operational practices early to avoid painful incidents later.
