Will Kubernetes Collapse Under the Weight of Its Complexity?
This blog post starts under a false premise. Kubernetes is not for app developers, it is the substrate on which applications, databases, and other workloads run. Just like you wouldn&#x27;t want an application developer SSHing into machines in production (assuming you have ops people), you don&#x27;t want them to use kubernetes, except kubernetes has done one better -- it&#x27;s abstracted so well (especially with the introduction and widespread use of Custom Resource Definitions AKA CRDs) that you <i>can</i> let them write resource definitions, which are declarative representations of the resources they will need for their application, and run those.<p>Coming from someone who gave a talk at Kubecon I&#x27;m very surprised to read something like this. Maybe I&#x27;m the one with the misunderstanding, but I&#x27;m going to try and refute the things this article said&#x2F;is implying.<p>1. Kubernetes is complex<p>This is kind of right, but it&#x27;s also kind of not -- Kubernetes is <i>essentially</i> complex, given that it encourages write-once solutions to all the problems it faces. Here are the pieces that make a basic Kubernetes &quot;cluster&quot;:<p>- apiserver =&gt; you send commands to this to change&#x2F;query cluster state<p>- controller-manager =&gt; works to make your ensure that the cluster is in the state you want it to be (making workloads replicate&#x2F;restart&#x2F;etc)<p>- scheduler =&gt; figures out where to put workloads<p>- kubelet =&gt; runs containers -- one on each node that can do work<p>- kube-proxy =&gt; maintains the routing infrastructure necessary to enable containers on any node to hit a container on another one.<p>All of those pieces are needed -- the only concession I would make is that they could all be in the same daemon (one executable), but that&#x27;s actually worse at scale, and harder to debug -- all of these services can produce a lot of logs.<p>2. Application developers can&#x27;t use kubernetes as it is<p>Application developers can use kubernetes as it is. Learning to write a kubernetes resource definition is not any harder than figuring out the conventions and configuration you have to write for Heroku, or AWS ElasticBeanstalk, or AWS ECS. In fact, I would argue that it&#x27;s simpler.<p>We&#x27;ve touched on another problem here -- the competitor for kubernetes is not SSH, it&#x27;s not heroku -- it&#x27;s tools like CloudFormation&#x2F;ECS. I don&#x27;t know if you&#x27;ve CloudFormation, but it&#x27;s kind of a clusterfuck, hard to set up quite right, and the dynamic yaml approach they&#x27;ve taken is enough rope for one clever developer to hang you and your whole team with.<p>Bold prediction, but I think AWS is going to abandon CloudFormation and ECS in favor of Kubernetes resources once it stabilizes.<p>OK, let&#x27;s say you disagreed with everything I&#x27;ve said up until this point -- at the very least, you can deploy tools like the following to your kubernetes cluster:<p><a href="https:&#x2F;&#x2F;gitkube.sh" rel="nofollow">https:&#x2F;&#x2F;gitkube.sh</a> =&gt; heroku workflow<p><a href="https:&#x2F;&#x2F;helm.sh" rel="nofollow">https:&#x2F;&#x2F;helm.sh</a> =&gt; cloud-formation&#x2F;elastic-beanstalk workflow (with kubernetes primitives)<p>And presto, you have a completely different interface to your cluster, WITHOUT changing anything fundamental underneath.<p>3. Developers who only focus on the application-level are the goal<p>Why would you even want this? Not only is it basically impossible to hide the underlying infrastructure so well that the application developer doesn&#x27;t have to know about it, it&#x27;s arguably not even a good idea.<p>Take session management -- if you want to handle it in the context of more than one frontend running at a time, you generally outsource that state to a cache like redis. An application developer who grew up in this imaginary world where app developers never touch infrastructure is not who I want solving this issue, assuming there isn&#x27;t a qualified ops person. If you needed to optimize even further, app-local caches could be deployed, but this requires knowledge of &quot;sticky sessions&quot; -- this very much is a deployment&#x2F;infrastructure specific question, again, that app-only developer is just about useless here.<p>I&#x27;m no hiring manager but the desire to stay an &quot;application&quot; developer who only worries about that part of the stack when the &quot;application&quot; as a whole is so much more would be a red flag for me. Even if you were delivering a desktop application, the developer who worries about underlying OS-specific enhancements (for example knowing how to optimize the app for MacOS) is the one I want, the one I want to pay the big bucks for.<p>4. It&#x27;s hard to deploy the usual app+backing store+caching+worker pool structure<p>The author touches on this a little bit with the &quot;maybe operators and helm charts solve this&quot;, and that&#x27;s exactly what the operator pattern (Custom Resource Definitions, AKA CRDs, plus custom controllers) were meant to solve -- now you can actually give declarative specifications of what you want your Redis&#x2F;Postgres&#x2F;Celery&#x2F;whatever cluster to look like, and `kubectl apply`, and the platform handles it. There&#x27;s arguably no difference here between how you&#x27;d use this and a tool like heroku.<p>Also, for the record you can trivially extend `kubectl`:
<a href="https:&#x2F;&#x2F;kubernetes.io&#x2F;docs&#x2F;tasks&#x2F;extend-kubectl&#x2F;kubectl-plugins&#x2F;" rel="nofollow">https:&#x2F;&#x2F;kubernetes.io&#x2F;docs&#x2F;tasks&#x2F;extend-kubectl&#x2F;kubectl-plug...</a>