Push vs Pull Deployment
Push vs Pull Deployment

Push Approach

In the push approach, an external system (mostly CD pipelines) are triggering deployments to the cluster, after a git repository was committed to or a previous CI pipeline was executed successfully. In this approach, the pipeline system has access to the cluster.

Pros:

Security is determined by the git repository and the build pipeline.

Deploying Helm Charts can be done easier and with the support of helm plugins.

Secret management is easier because secrets can be applied to pipelines and also stored encrypted in git, as preferred by the user.

Not bound to the specific tool, because all kind of tools can be used.

Container version updates can be injected by build pipeline.

Cons:

Cluster credentials are inside the build system

Updating the containers of deployments is still easier with a pull-based process

Strongly coupled to the CD system, because pipelines have to be created that are maybe in the language of Gitlab Runners, and then later on the team decides to migrate to Azure DevOps or Jenkins and a lot of the build pipelines have to be migrated.

Tools:

⁠

Jenkins⁠

⁠

The One DevOps Platform | GitLab⁠

⁠

Pull approach

The pull approach is based on the fact, that all changes are applied from inside the cluster. There is an operator inside the cluster, that regularly scans the associated git repositories and docker registries and if a change occurs, the cluster state will be updated from inside. This process is generally noted as very secure, due to the fact, that no external client has credentials with admin access to the cluster.

Pros:

No external client has the right to publish to the cluster, all updates are coming from inside.

Some tools allow also syncing helm chart updates and can sync them to the cluster.

Docker registries can be scanned for new versions and if a new image is pushed, the git repo and the deployment are updated with the new version.

Pull-based tools can be distributed in different namespaces, with different git repositories and access rights and through this, a multi-tenant model can be applied. Team A can use namespace A, Team B can use namespace B and Infrastructure Team can have a global one.

The tools are regularly very lightweight.

Combined with a tool like Bitnami Sealed Secrets operator, secrets can be placed encrypted inside the git repository and are extracted inside the cluster.

No coupling on the CD pipelines, because deployments are done cluster internally.

Cons:

Managing secrets of Helm Chart deployments is harder than normal because secret values have to be first created as for example sealed secrets, then be decrypted by an internal operator and then made available to the pull tool. After this has happened, a helm release can be executed with the values in the secrets that are already deployed. The easiest way would be to create a secret of all helm values used for deployment, decrypt it and then commit it to git.

Through the pull approach, you are bound to the tools executing the pull. This shrinks the possibility to customize the process of applying deployments to the cluster. For example, the usage of Kustomize is harder, because it has to be executed before the result templates are pushed to git. I don’t say that separate tools can’t be used, but it is harder to implement them to the deployment flow.

Tools:

⁠

Flux - the GitOps family of projects⁠

⁠

Argo CD - Declarative GitOps CD for Kubernetes⁠

⁠

Want to print your doc?
This is not the way.

Try clicking the ⋯ next to your doc name or using a keyboard shortcut (

CtrlP

) instead.

Push vs Pull DeploymentPush vs Pull Deployment

Push Approach

Pros:

Cons:

Tools:

Pull approach

Pros:

Cons:

Tools:

Push vs Pull Deployment
Push vs Pull Deployment