Pull-Based Kubernetes Deployments Moving to GitLab Free Tier

GitLab will include support for pull-based deployment in the platform’s Free tier in an upcoming release, which will provide users increased flexibility, security, scalability, and automation in cloud-native environments. With pull-based deployment, DevOps teams can use the GitLab agent for Kubernetes to automatically identify and enact application changes.

“DevOps teams at all levels benefit from utilizing GitOps strategies such as pull-based deployment in their cloud-native environments. By offering this feature in GitLab’s Free tier, we can introduce more organizations to the power and utility of this secure and scalable functionality,” says Viktor Nagy, product manager of GitLab’s Configure Group.

As an open-core company, GitLab is happy to contribute to the GitOps community and enable the adoption of best practices in the industry.

What is pull-based deployment?

Pull-based and push-based deployment are two main approaches to GitOps, an operational framework that takes DevOps best practices used for application development such as version control, collaboration, compliance, and CI/CD tooling, and applies them to infrastructure automation.

GitOps enables operations teams to move as quickly as their application development counterparts by making use of automation and scalability, without sacrificing security.

While push-based, or agentless, deployment relies on a CI/CD tool to push changes to the infrastructure environment, pull-based deployment uses an agent installed in a cluster to pull changes whenever there is a deviation from the desired configuration. In the pull-based approach, deployment targets are limited to Kubernetes and an agent must be installed in each Kubernetes cluster.

“As long as the GitLab agent for Kubernetes on your infrastructure has the necessary access rights in your cluster, you can configure everything automatically, reducing the DevOps workload and the opportunity to introduce errors,” Nagy says.

Pull-based deployment vs. push-based deployment

Push-based deployment and pull-based deployment each have their pros and cons. Here is a list of the advantages and disadvantages of each GitOps practice:

Push-based deployment pros:

• Ease of use
• Well-known as part of CI/CD
• More flexible, as deployment targets can be on physical servers or virtual containers, not restricted to Kubernetes clusters

Push-based deployment cons:

• Requires organizations to open their firewall to a cluster and grant admin access to external CI/CD
• Requires organizations to adjust their CI/CD pipelines when they introduce new environments

Pull-based deployment pros:

• Secure infrastructure – no need to open your firewall or grant admin access externally
• Changes can be automatically detected and applied without human intervention easier scaling of identical clusters

Pull-based deployment cons:

• Agent needs to be installed in every cluster limited to Kubernetes only

How pull-based deployment impacts the Free-tier experience

Including support for pull-based deployments in GitLab’s Free tier provides a tremendous competitive advantage for smaller organizations, as they can now apply automation in a safe and scalable manner to their cloud-native infrastructure, including virtual containers and clusters. And, for organizations that are trying to get started quickly by minimizing the number of tools in their infrastructure ecosystem, this functionality is included in One DevOps Platform, not as a point solution.

“DevOps teams don’t have to continuously write code for new infrastructure elements – they can write the code once, within a single DevOps platform, and have the agent automatically find it, pull it, and apply it, as well as configuration changes,” Nagy says.

“Also, with the availability of pull-based deployment in this introductory tier, newcomers to GitLab will immediately be able to modernize application development and reduce the security risk associated with configuring such infrastructure.”

This blog post contains information related to upcoming products, features, and functionality. It is important to note that the information presented is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. As with all projects, the items mentioned in this blog post and linked pages are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.