Kubernetes Deployment Anti – Patterns – Codefresh

Kubectl is not a debugging tool and should not be used as such. Every company that started adopting Kubernetes has eventually run into a problem that prompted the “10-questions-game” with kubectl. If you have a critical problem in your production cluster your first impulse should not be opening a terminal with kubectl. If you are doing this you have already lost the battle, especially if it is 3am, production is down and you are on call.

kubectl get ns kubectl get pods -n sales kubectl describe pod prod-app-1233445 -n sales kubectl get svc – n sales kubectl describe… All your Kubernetes clusters should have proper monitoring/tracing/logging systems in place that can be used for pinpointing issues in a timely manner. If you need to run kubectl to inspect something it means that you have a gap in your observability tools and the thing that you need to inspect should be added to your monitoring tools.

Even if you simply want to inspect a cluster that you are not familiar with you should use a dedicated tool for this purpose. There are many tools for inspecting Kubernetes clusters today. Kubevious for example is a comprehensive Kubernetes dashboard with a built-in rule engine that allows you to search and mark Kubernetes resources according to custom rules. Metrics and tracing are so important that will be discussed in another anti- pattern later in our list. Anti-pattern 7 Misunderstanding Kubernetes network concepts Kubernetes Deployment Antipatterns Gone are the days, where a single load balancer was everything you needed for your application.

Kubernetes introduces its own networking model and it is your duty to learn and understand the major concepts. At the very least you should be familiar with load balancers, clusterIPs, nodeports and ingress (and how they differ). We have seen both ends of the spectrum, where organizations create an overkill setup with a heavy-weight ingress controller (when a simple load balancer would suffice) or creating multiple load balancers (wasting money on the cloud provider) instead of a single ingress setup. Understanding the different service options is one of the most confusing aspects for people starting with Kubernetes networking.

In our previous guide, we documented 10 Docker anti-patterns. This guide has been very popular as it can help you in your first steps with container images. Creating container images for your application, however, is only half the story. You still need a way to deploy these containers in production, and the de facto solution for doing this is by using Kubernetes clusters. We soon realized that we must also create a similar guide for Kubernetes deployments.

This will hopefully give you the whole picture of how to create a container image and how to properly deploy it (or at least warn you of some common pitfalls). Notice that in this guide we talk specifically about application deployments on Kubernetes and not Kubernetes clusters themselves. This means that we assume that the Kubernetes cluster is already there (and it is properly set up) and you simply want to deploy an application on it.

In the future, we will complete the trilogy by also documenting anti-patterns for the creation of the clusters (i.e. talk about the infrastructure level instead of the application level). Unlike other guides that simply complain about how things can go wrong, we always associate each anti-pattern with the respective solution. This way you can actually check your own deployment process and fix any issues without hunting down extra information. Here is the list of bad practices that we will examine today: 1. Using containers with the latest tag in Kubernetes deployments 2.

Baking the configuration inside container images 3. Coupling applications with Kubernetes features/services for no reason 4. Mixing application deployment with infrastructure deployment (e.g. having Terraform deploying apps with the Helm provider) 5. Performing ad-hoc deployments with kubectl edit/patch by hand 6. Using Kubectl as a debugging tool 7. Misunderstanding Kubernetes network concepts 8. Using permanent staging environments instead of dynamic environments 9.

Mixing production and non-production clusters 10. Deploying without memory and CPU limits 11. Misusing health probes 12. Not using Helm (and not understanding what Helm brings to the table) 13. Not having deployment metrics to understand what the application is doing 14. Not having a secret strategy/treating secrets in an ad-hoc manner 15.

This is a short excerpt from the opening of “” by Unknown, quoted for review and introduction purposes. All rights belong to the copyright holders.

Book Information

• Unique ID: a39db3b7e1bbb4f1
• File Extension: .pdf
• File Size: 1,958,146 bytes (1.867 MB)
• Title: –
• Author: Unknown
• Pages: 53
• Language: English (en)

Reading & Word Statistics

• Estimated Reading Time: 36.56 minutes
• Total Words: 7,313
• Total Characters: 46,215
• Average Words per Page: 137.98
• Average Characters per Page: 871.98

Most Frequent Words

kubernetes (131), application (80), deployment (75), cluster (62), anti-pattern (38), antipatterns (36), helm (35), using (33), production (29), also (29), container (27), kubectl (26), environments (26), need (26), even (26), deployments (25), configuration (24), one (24), services (22), infrastructure (22), secrets (21), use (21), time (20), resources (19), metrics (19), environment (19), git (17), inside (16), clusters (16), developers (16), latest (15), applications (15), health (15), solution (15), developer (15), feature (15), staging (14), image (14), see (14), tag (13), images (13), limits (13), understand (13), important (13), features (12), way (12), means (12), running (12), used (12), service (12), containers (11), docker (11), creating (11), know (11), problem (11), pipeline (11), mixing (10), instead (10), dynamic (10), without (10), previous (10), deploy (10), simply (10), single (10), testing (10), load (10), traffic (10), probe (10), get (9), hand (9), probes (9), want (9), secret (9), don’t (9), deployed (9), specific (9), run (9), needs (9), changes (9), virtual (9), company (9), problematic (9), resource (9), templating (9), now (8), ad-hoc (8), deploying (8), set (8), actually (8), app (8), pull (8), external (8), integration (8), code (8), multiple (8), fine (8), liveness (8), non-production (7), memory (7), create (7).

PDF Download