To be fair, this could also happen to push deployments in the form of disrupted network connections. What happens to your pull deployment when the Pod, executing this deployment, has to move because the Kubernetes cluster or the cluster operator thinks so? Everyone talks about highly dynamic clusters which scale up and down or move pods to distribute the load. The rollout problemįor me, one more drawback is the dynamic nature of Kubernetes clusters. But we will take a look at this in the next section. Some might argue that you could solve these problems after you’ve overcome the initial bootstrap problem. Some tools base their functionality on Custom Resources to configure the deployment pipelines.
But what about updates? Does your automation start after you manually configured your automation tool? This seems to be trivial at first glance, it’s just one command.
#WHAT IS KUBERNETES DEPLOYMENT INSTALL#
What most pull-based deployment tools hide with some kubectl example is the problem that you have to somehow install them inside the Kubernetes cluster. We think these problems are worth an article of its own rather than a comment on the above-mentioned article. While researching these principles, we stumbled across this article, which already explains nicely most of the aspects.īut in our opinion, it is missing some major problems with the pull approach. In essence there are only two different approaches the tools use: push and pull. This article will not be another comparison of Kubernetes deployment tools but a comparison of the underlying deployment concepts. In the context of these tools, even a new *Ops term emerged: GitOps. There is a wide variety of tools out there to deploy software to a Kubernetes cluster.