Don’t Use Kubernetes Please!

In my 10 years of working in the software industry in various roles I saw people moving from, the following tools have these benefits and these drawbacks, to it is trendy so lets do it.

Kubernetes is one of those things, hosting your applications on Kubernetes has become the standard in deploying applications regardless of whether it actually has any benefits. I am hoping through this article to put some sanity back into the industry and show the drawbacks of using Kubernetes and how it can damage your software cycle, increase costs and make you not agile in anyway possible.

1. Kubernetes is by default more expensive

• Lets consider you are a small to medium size startup your application consists of a couple of backend services a database a caching service and a load balancer. This setup will consist of 2 managed services (Database and Cache), 6 small machines for redundancy for the backend services and 2 load balancers that is if you deploy this to any public cloud normally.
• If you add Kubernetes to this setup you will need to make your machines double the size just the extra side-cars that you need make things functional add 3 machines to be the control plane of Kubernetes, add 3 more machines for etcd cluster, add multiple internal services like ingress controllers and log and metrics collection.
• You already are paying double of what you would have if you just excluded Kubernetes out of this because in a medium to small business there isn’t any feature of Kubernetes you are really using.

2. Kubernetes deployments are more complicated

• The normal setup would cost any CI/CD engineer a couple of days to setup and normally not more than an hour or 2 to debug infrastructure related issues.
• Deploying on Kubernetes usually involves rendering templates, setting CI/CD runners, generating on the fly kubeconfigs for security and so much more that setting up CI/CD would take not less than a month to have something that is production grade ready. To debug an error you could spend days to figure out if something is related to underlying infrastructure, Kubernetes or your application itself. Fun fact I once spent 6 hours to figure out why CoreDNS didn’t want to register new services, that is after spending a day to figure out it is a pure CoreDNS problem, only to find out it was a just a casual bug at the time.

3. Kubernetes is not stable !

• The idea of deploying that many components together with different versions and different maintainers makes it impossible near to have an error free Kubernetes cluster, from network CNI to controllers to custom operators things tends to breakdown most of the https
• It makes perfect sense with all the network encapsulation over the cloud network virtualization over the real network well things tend to get crazy.

4. Version Management is hard.

• To be able to keep track of the versions of all components deployed on your cluster is something that will drain a lot of time. It will take dedicated engineers to maintain 3rd party operators that you are using which configuration versions for them that you need and handle updating the ones that has breaking features.

5. DevOps Engineering cost would sky rocket.

• And it should you are opting in for a setup intended for huge enterprises that have huge budgets and don’t mind having Kubernetes because it is actually benefiting them.

6. Bigger attack surface.

• Kubernetes has its own security vulnerabilities making the attack surface of your application near double that it should be. Do you have the budget to handle security engineers to handle that, or will you overload your only DevOps engineer more with the security work after all he has CKS.
• Kubernetes attacks are being developed daily and managing them is not any easy task to do. Sooner or later you will have to hire a security engineer to secure a technology stack that you don’t need.

I know this has been a long article but I really hoped to shed some light on the crazy trends of technology decisions that has no engineering backing other than following the trend.

If you ever need to asses your need to have Kubernetes as a part of your tech stack or need to have a better ability to manage your current clusters please don’t hesitate to reach out, I have been doing consulting work for a lot of varying sizes companies and I am proud to say I’ve even off-boarded some of them back to the sane world of normally hosting your applications.