GitOps-Driven Cluster Bootstrapping: FluxCD vs ArgoCD

Introduction

By mid-2021, GitOps had evolved from an application deployment pattern to a comprehensive approach for managing entire Kubernetes clusters. Tools like FluxCD and ArgoCD expanded beyond application sync to support cluster bootstrapping, enabling teams to manage cluster initialization, add-ons, and configurations declaratively from Git repositories.

This mattered because it represented a shift from imperative cluster setup (running commands, applying manifests manually) to declarative cluster management (defining desired state in Git, letting controllers reconcile). GitOps bootstrapping enabled teams to version control cluster configurations, automate cluster creation, and maintain consistency across environments.

Historical note: FluxCD v2 (GitOps Toolkit) and ArgoCD had both matured significantly by 2021, with cluster bootstrapping patterns emerging as a natural extension of their application deployment capabilities.

GitOps Bootstrapping Concepts

Bootstrap Pattern

The bootstrap pattern involves using a minimal cluster (or external system) to deploy GitOps controllers, which then manage the rest of the cluster (or additional clusters):

1. Bootstrap Cluster: Create a minimal cluster (or use existing infrastructure).
2. Install GitOps Controller: Deploy FluxCD or ArgoCD to the bootstrap cluster.
3. Point to Git Repository: Configure controller to watch Git repository for cluster definitions.
4. Automated Provisioning: Controller provisions clusters, installs add-ons, and manages configurations.

Day-0 to Day-2 Operations

GitOps bootstrapping extends across the entire cluster lifecycle:

• Day-0: Initial cluster creation and basic configuration.
• Day-1: Installing essential add-ons (CNI, DNS, monitoring, ingress).
• Day-2: Ongoing configuration management, updates, and policy enforcement.

FluxCD Cluster Bootstrap

FluxCD v2 Architecture

FluxCD v2 (GitOps Toolkit) introduced a modular architecture:

• Source Controller: Manages Git and Helm repositories.
• Kustomize Controller: Applies Kustomize overlays.
• Helm Controller: Manages Helm releases.
• Notification Controller: Handles alerts and notifications.

Bootstrap Workflow

# Install FluxCD CLI
curl -s https://fluxcd.io/install.sh | sudo bash

# Bootstrap FluxCD
flux bootstrap github \
  --owner=my-org \
  --repository=cluster-config \
  --branch=main \
  --path=clusters/production

# FluxCD installs itself and watches the repository

Cluster Definition in Git

# clusters/production/cluster.yaml
apiVersion: kustomize.toolkit.fluxcd.io/v1beta2
kind: Kustomization
metadata:
  name: cluster-bootstrap
  namespace: flux-system
spec:
  interval: 10m0s
  path: ./bootstrap
  prune: true
  sourceRef:
    kind: GitRepository
    name: flux-system
---
# bootstrap/kustomization.yaml
resources:
  - namespace.yaml
  - cni.yaml
  - coredns.yaml
  - monitoring.yaml

ArgoCD Cluster Bootstrap

App of Apps Pattern

ArgoCD uses the App of Apps pattern for cluster bootstrapping:

# root-app.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: cluster-bootstrap
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/my-org/cluster-config
    targetRevision: main
    path: clusters/production
  destination:
    server: https://kubernetes.default.svc
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

Cluster Components as ArgoCD Apps

# clusters/production/apps.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: cni
spec:
  source:
    repoURL: https://github.com/projectcalico/calico
    targetRevision: v3.20.0
    path: k8s-manifests
  destination:
    server: https://kubernetes.default.svc
---
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: coredns
spec:
  source:
    repoURL: https://github.com/coredns/deployment
    targetRevision: master
    path: kubernetes
  destination:
    server: https://kubernetes.default.svc

Comparison: FluxCD vs ArgoCD for Bootstrapping

Day-0 to Day-2 Operations

Day-0: Cluster Creation

GitOps can trigger cluster creation using Cluster API or infrastructure tools:

# FluxCD Kustomization for Cluster API
apiVersion: kustomize.toolkit.fluxcd.io/v1beta2
kind: Kustomization
metadata:
  name: cluster-creation
spec:
  interval: 5m0s
  path: ./cluster-api
  sourceRef:
    kind: GitRepository
    name: cluster-definitions

Day-1: Essential Add-Ons

Install CNI, DNS, and monitoring immediately after cluster creation:

# ArgoCD Application for CNI
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: calico-cni
spec:
  syncPolicy:
    automated:
      prune: true
  source:
    repoURL: https://github.com/projectcalico/calico
    path: k8s-manifests
  destination:
    server: https://kubernetes.default.svc

Day-2: Ongoing Management

Manage configurations, policies, and updates declaratively:

# FluxCD Kustomization for policies
apiVersion: kustomize.toolkit.fluxcd.io/v1beta2
kind: Kustomization
metadata:
  name: cluster-policies
spec:
  interval: 10m0s
  path: ./policies
  sourceRef:
    kind: GitRepository
    name: cluster-config

Multi-Cluster Management

FluxCD Multi-Cluster

FluxCD can manage multiple clusters from a single Git repository:

# clusters/
#   production/
#     flux-system/
#       gotk-components.yaml
#     bootstrap/
#       kustomization.yaml
#   staging/
#     flux-system/
#       gotk-components.yaml
#     bootstrap/
#       kustomization.yaml

Each cluster runs its own FluxCD instance, watching different paths in the same repository.

ArgoCD Multi-Cluster

ArgoCD supports multi-cluster management:

# Register remote cluster
argocd cluster add production-cluster-context

# Create Application pointing to remote cluster
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: production-apps
spec:
  destination:
    server: https://production-cluster:6443
    namespace: default

Practical Considerations

Bootstrap Cluster Requirements

• Minimal Resources: Bootstrap cluster needs minimal resources to run GitOps controllers.
• Network Access: Bootstrap cluster needs access to Git repositories and container registries.
• High Availability: Bootstrap cluster should be HA; if it fails, cluster management stops.

Git Repository Structure

Organize Git repositories for clarity:

cluster-config/
├── clusters/
│   ├── production/
│   │   ├── flux-system/      # FluxCD configuration
│   │   ├── bootstrap/        # Day-0/Day-1 resources
│   │   └── apps/             # Day-2 applications
│   └── staging/
│       ├── flux-system/
│       ├── bootstrap/
│       └── apps/
└── base/                     # Shared base configurations

Secret Management

GitOps requires secure secret management:

• Sealed Secrets: Encrypt secrets in Git (FluxCD supports natively).
• External Secrets Operator: Sync secrets from external systems (AWS Secrets Manager, Vault).
• SOPS: Encrypt secrets with age or PGP (FluxCD supports natively).

Getting Started

FluxCD Bootstrap

# Install FluxCD CLI
curl -s https://fluxcd.io/install.sh | sudo bash

# Bootstrap FluxCD
flux bootstrap github \
  --owner=my-org \
  --repository=cluster-config \
  --branch=main \
  --path=clusters/production \
  --personal

ArgoCD Bootstrap

# Install ArgoCD
kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

# Access ArgoCD UI
kubectl port-forward svc/argocd-server -n argocd 8080:443

# Login (default admin password)
argocd admin initial-password -n argocd

Caveats & Lessons Learned

• Bootstrap Dependency: GitOps bootstrapping requires a bootstrap cluster or manual initial setup.
• Secret Management: Secrets must be managed securely; don’t commit plaintext secrets to Git.
• Repository Access: Git repositories must be accessible from clusters; plan for private repositories.
• Reconciliation Loops: GitOps controllers continuously reconcile; ensure Git repository is source of truth.

Common Failure Modes

• “Git repository inaccessible”: Clusters need network access to Git repositories; verify connectivity.
• “Secret sync failures”: Secret management tools may fail; monitor secret sync status.
• “Reconciliation conflicts”: Manual changes to clusters can conflict with GitOps; enforce Git as source of truth.

Conclusion

GitOps-driven cluster bootstrapping in 2021 represented a paradigm shift in how teams managed Kubernetes clusters. By extending GitOps principles from applications to infrastructure, FluxCD and ArgoCD enabled declarative cluster management from day zero through day two operations.

While both tools offered similar capabilities, their approaches differed: FluxCD’s CLI-first, automation-focused model appealed to teams wanting programmatic control, while ArgoCD’s rich UI and App of Apps pattern suited teams preferring visual management. Both demonstrated that GitOps wasn’t just for applications—it was for everything.

For teams managing multiple clusters or seeking consistency across environments, GitOps bootstrapping provided a unified approach that reduced operational complexity and enabled infrastructure automation at scale. It would become the foundation for platform engineering and internal developer platforms in subsequent years.