There is a wide variety of tools out there to deploy software to a Kubernetes cluster. In the context of these tools, even a new *Ops term emerged: GitOps . This article will not be another comparison of Kubernetes deployment tools but a comparison of the underlying deployment concepts.
Deployment concepts (push and pull)
In essence there are only two different approaches the tools use: push and pull. Both have their pros and cons. While researching these principles, we stumbled across this article , which already explains nicely most of the aspects.
But in our opinion, it is missing some major problems with the pull approach. We think these problems are worth an article of its own rather than a comment on the above-mentioned article.
The bootstrap problem
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. This seems to be trivial at first glance, it’s just one command. But what about updates? Does your automation start after you manually configured your automation tool?
Some tools base their functionality on Custom Resources to configure the deployment pipelines. How do you update these pipelines?
Some might argue that you could solve these problems after you’ve overcome the initial bootstrap problem. But we will take a look at this in the next section.
The rollout problem
For me, one more drawback is the dynamic nature of Kubernetes clusters. Everyone talks about highly dynamic clusters which scale up and down or move pods to distribute the load. 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?
To be fair, this could also happen to push deployments in the form of disrupted network connections. But we think chances are higher for pull deployments to run into such problems as they are applying changes to the environment they are running in.
To come back to the above-mentioned bootstrap problem: what happens when an operator running inside the cluster tries to update itself?
Some might argue you could circumvent such problems with PodDisruptionBudget or rolling updates, but what happens if your node crashes?
The security concerns for push and pull
Some people think the pull principle is more secure than the push principle because you don’t have credentials saved in your CI/CD system. But you could prevent this problem by combining your CI/CD pipeline with a proper secret management solution.
For the pull approach, your Kubernetes cluster contains an agent which is capable of changing things inside your cluster. Think back some months, when Helm v3 removed Tiller (an agent inside the Kubernetes cluster) because of security considerations. The security concerns that led to the complete removal of Tiller in Helm v3 are also valid for the pull-based deployment approach in general. Tiller was removed because it was difficult for operators to lock it down with RBAC to only let it do what it should be allowed to.
We think neither push nor pull is more secure than the other approach. It depends on how you implement and secure your environment.
Conclusion
What should have been a comparison of Kubernetes deployment concepts might look like a rant against pull-based deployments. But that isn’t our intention. We wanted to make clear that pull cannot exist without some sort of push (for bootstrapping and maintenance). The other point is that the term GitOps is not bound to pull-based deployments, which was our impression when we read the Weave works blog posts. But, for example, Google combines GitOps with a push-based approach. This tweet doesn’t contain push nor pull at all to explain GitOps. And finally, you might encounter a scenario where you have to use pull because you don’t have a setup where your CI infrastructure has network access to your Kubernetes cluster.
We hope this article helps to implement the right GitOps deployment solutions for your environment. It should help you get a better impression of the questions to ask and the decisions to take for the implementation.
Was this post helpful?
More articles
fromChristian Zunker & Daniel Marks
9.8.2021 Your job at codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
More articles in this subject area
Discover exciting further topics and let the codecentric world inspire you.
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Blog authors
Christian Zunker
Do you still have questions? Just send me a message.
Daniel Marks
Do you still have questions? Just send me a message.
Do you still have questions? Just send me a message.