10 Anti-Patterns for Kubernetes Deployments

Common practices in Kubernetes deployments that have better solutions

Photo by Jon Tyson on Unsplash

As container adoption and usage continues to rise, Kubernetes (K8s) has become the leading platform for container orchestration. It’s an open-source project with tens of thousands of contributors from over 315 companies with the intention of remaining extensible and cloud-agnostic, and it’s the foundation of every major cloud provider.

When you have containers running in production, you want your production environment to be as stable and resilient as possible to avert disaster (think every online Black Friday shopping experience). When a container goes down, another one needs to spin up to take its place, no matter what time of day — or into the wee hours of the night — it is. Kubernetes provides a framework for running distributed systems resiliently, from scaling to failover to load balancing and more. And there are many tools that integrate with Kubernetes to help meet your needs.

Best practices evolve with time, so it’s always good to continuously research and experiment for better ways for Kubernetes development. As it is still a young technology, we are always looking to improve our understanding and use of it.

In this article, we’ll be examining ten common practices in Kubernetes deployments that have better solutions at a high level. I will not go into depth on the best practices since custom implementation might vary among users.

1. Putting the configuration file inside/alongside the Docker image
2. Not using Helm or other kinds of templating
3. Deploying things in a specific order. (Applications shouldn’t crash because a dependency isn’t ready.)
4. Deploying pods without set memory and/or CPU limits
5. Pulling the latest tag in containers in production
6. Deploying new updates/fixes by killing pods so they pull the new Docker images during the restart process
7. Mixing both production and non-production workloads in the same cluster.
8. Not using blue/green or canaries for mission-critical deployments. (The default rolling update of Kubernetes is not always enough.)