- TechOps Examples
- Posts
- GitOps Push vs. Pull Architecture – Which One to Choose?
GitOps Push vs. Pull Architecture – Which One to Choose?
Govardhana M K
October 30, 2024
TechOps Examples
Hey — It's Govardhana MK 👋
Along with a use case deep dive, we identify the top news, tools, videos, and articles in the TechOps industry.
IN TODAY'S EDITION
🧠 Use Case
GitOps Push vs. Pull Architecture – Which One to Choose?
🚀 Top News
Chinese Hackers Use CloudScout Toolset to Steal Session Cookies from Cloud Services
📽️ Videos
Pulumi in Three Minutes
How To Make AWS Not Frustrating
📚️ Resources
Challenges with IP spoofing in cloud environments
How to See Beautiful Git Project Stats in Your Terminal
Securing Kubernetes Clusters: Avoid These 11 Common Misconfigurations
🛠️ TOOL OF THE DAY
GitHub CLI - Take GitHub to the command line.
Create a shortcut for a gh command.
Check on the status of your pull requests.
View and filter a repository’s open issues.
🧠 USE CASE
GitOps Push vs. Pull Architecture – Which One to Choose?
For someone new to GitOps, it’s a way to manage infrastructure and deployments by using Git as the source of truth, storing configuration files there to automate deployments and continuously sync infrastructure to the desired state.
GitOps Push and Pull Architectures
Let's touch base on what Push and Pull GitOps actually mean.
Push-Based GitOps:
In a push-based model, a CI/CD pipeline (like GitHub actions or Jenkins) initiates deployments, pushing changes directly from Git to the cluster.
This approach provides full control over deployment timing and is easier to integrate with traditional CI/CD pipelines.
Implementation example with GitHub Actions:
GitHub actions configuration (.github/workflows/deploy.yml)
name: Deploy to Kubernetes
on:
push:
branches:
- main
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v2
- name: Set up kubectl
uses: azure/setup-kubectl@v3
with:
version: 'v1.21.2'
- name: Configure kubectl
env:
KUBE_CONFIG_DATA: $
run: |
echo "$KUBE_CONFIG_DATA" | base64 -d > $HOME/.kube/config
- name: Apply Kubernetes manifests
run: |
kubectl apply -f k8s/manifest.yaml
In this example:
The workflow is triggered on every push to the
mainbranch.kubectlis configured to connect to the cluster and applies the manifests, effectively "pushing" the deployment from GitHub Actions to Kubernetes.
Pull-Based GitOps:
In the pull-based model, CD agents (like ArgoCD or Flux) inside the cluster continuously monitor the Git repository for changes and pull them as updates.
This way cluster self-manages, automatically syncing with the Git source.
Implementation example of an Argo CD application manifest:
app.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: techops-app
namespace: argocd
spec:
project: default
source:
repoURL: 'https://github.com/your-org/your-repo.git'
targetRevision: main
path: k8s
destination:
server: 'https://kubernetes.default.svc'
namespace: default
syncPolicy:
automated:
prune: true
selfHeal: true
In this example:
repoURLpoints to the Git repository containing the Kubernetes manifests.syncPolicy.automatedtells Argo CD to automatically sync the cluster with the Git repository.The
selfHealoption ensures any drift from the Git source is corrected, enhancing the reliability of the pull-based model.
A quick comparison snapshot:
Aspect | Push-Based Architecture | Pull-Based Architecture |
|---|---|---|
Control | Deployment triggered externally via CI/CD | Cluster self-manages by pulling updates |
Security | Requires access from CI/CD to cluster | No external access to cluster needed |
Scalability | More suited to smaller setups | Easier to scale across multiple clusters |
Tooling | Integrates with traditional CI/CD tools | Requires GitOps tools like Argo CD, Flux |
Which One to Choose?
Push-Based GitOps:
Ideal for smaller, simpler environments needing control over deployment timing.
Suitable when CI/CD pipeline has direct access to Kubernetes API.
Easier integration with existing CI/CD workflows without a dedicated GitOps tool.
Pull-Based GitOps:
Best for complex, multi-cluster environments focused on security and scalability.
Cluster pulls updates, reducing the need for external CI/CD access.
Well-suited for large-scale setups with frequent state reconciliation needs.
No one solution fits all; choose push-based for simplicity and control, and pull-based for scalability and security.
You may even like:
Learn AI in 5 Minutes a Day
AI Tool Report is one of the fastest-growing and most respected newsletters in the world, with over 550,000 readers from companies like OpenAI, Nvidia, Meta, Microsoft, and more.
Our research team spends hundreds of hours a week summarizing the latest news, and finding you the best opportunities to save time and earn more using AI.