Implement GitOps continuous delivery for Kubernetes using ArgoCD or Flux. Use for automated deployments with Git as single source of truth, pull-based delivery, drift detection, multi-cluster management, and progressive rollouts.
npx skills add https://github.com/ancoleman/ai-design-components --skill implementing-gitops
Implement GitOps continuous delivery for Kubernetes using declarative, pull-based deployment models where Git serves as the single source of truth for infrastructure and application configuration.
Use GitOps workflows for:
Trigger keywords: "deploy to Kubernetes", "ArgoCD setup", "Flux bootstrap", "GitOps pipeline", "environment promotion", "multi-cluster deployment", "automated reconciliation"
All system configuration stored in Git repositories. No manual kubectl apply or cluster modifications. Declarative manifests (YAML) for all Kubernetes resources, environment-specific overlays, infrastructure configuration, and application deployments.
Operators running inside clusters pull changes from Git and apply them automatically. Benefits include no cluster credentials in CI/CD pipelines, support for air-gapped environments, self-healing through continuous reconciliation, and simplified CI/CD.
GitOps operators continuously compare actual cluster state with desired state in Git and reconcile differences through a continuous loop: watch Git, compare live state, apply differences, report status, repeat.
Use declarative Kubernetes manifests (not imperative scripts) to define desired state.
| Decision Factor | Choose ArgoCD | Choose Flux |
|----------------|---------------|-------------|
| Team Preference | Visual management with web UI | CLI/API-first workflows |
| Learning Curve | Easier onboarding with UI | Steeper but more flexible |
| Architecture | Monolithic, stateful controller | Modular, stateless controllers |
| Multi-Tenancy | Built-in RBAC and projects | Kubernetes-native RBAC |
| Resource Usage | Higher (includes UI components) | Lower (minimal controllers) |
| Best For | Transitioning to GitOps | Platform engineering |
Hybrid Approach: Some teams use Flux for infrastructure and ArgoCD for applications.
For ArgoCD implementation patterns, see references/argocd-patterns.md
For Flux implementation patterns, see references/flux-patterns.md
For Kustomize overlay patterns, see references/kustomize-overlays.md
kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
Basic Application:
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: myapp
namespace: argocd
spec:
project: default
source:
repoURL: https://github.com/org/repo.git
targetRevision: HEAD
path: k8s/overlays/prod
destination:
server: https://kubernetes.default.svc
namespace: myapp
syncPolicy:
automated:
prune: true
selfHeal: true
flux bootstrap github \
--owner=myorg \
--repository=fleet-infra \
--branch=main \
--path=clusters/production
Basic Kustomization:
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
name: myapp
namespace: flux-system
spec:
interval: 10m
path: "./k8s/prod"
prune: true
sourceRef:
kind: GitRepository
name: myapp
For complete examples, see examples/argocd/ and examples/flux/
Branch-Based Strategy: dev branch → staging branch → main branch (prod)
Kustomize-Based Strategy: k8s/base/ → k8s/overlays/{dev,staging,prod}/
Promotion Process:
For multi-environment ApplicationSet patterns, see references/argocd-patterns.md
ArgoCD: Register external clusters with argocd CLI, use ApplicationSets to generate Applications per cluster, manage from single ArgoCD instance.
Flux: Bootstrap Flux per cluster, use same Git repo with cluster-specific paths, configure remote clusters via kubeConfig secrets.
For detailed multi-cluster patterns, see references/multi-cluster.md
Canary Deployments: Gradually shift traffic to new version, monitor metrics during rollout, automated rollback on failures.
Blue-Green Deployments: Deploy new version alongside old, switch traffic atomically, instant rollback if issues detected.
ArgoCD: Use Argo Rollouts for progressive delivery
Flux: Integrate Flagger for automated canary analysis
For progressive delivery strategies and Argo Rollouts examples, see references/progressive-delivery.md
GitOps requires storing configuration in Git, but secrets must be protected.
| Tool | Approach | Security | Complexity |
|------|----------|----------|------------|
| Sealed Secrets | Encrypt secrets for Git | Medium | Low |
| SOPS | Encrypt files with KMS | High | Medium |
| External Secrets | Reference external vaults | High | Medium |
| HashiCorp Vault | Central secret management | Very High | High |
For secret management integration patterns, see references/secret-management.md
GitOps operators continuously monitor for drift between Git (desired state) and cluster (actual state).
ArgoCD Automatic Self-Healing:
syncPolicy:
automated:
prune: true # Remove resources not in Git
selfHeal: true # Revert manual changes
Flux Automatic Reconciliation:
spec:
interval: 10m # Check every 10 minutes
prune: true # Remove resources not in Git
force: true # Force apply on conflicts
Manual Operations:
# ArgoCD
argocd app get myapp # View sync status
argocd app diff myapp # Show differences
argocd app sync myapp # Manually trigger sync
# Flux
flux get kustomizations # View sync status
flux reconcile kustomization myapp # Force immediate sync
For drift detection strategies and troubleshooting, see references/drift-remediation.md
Execute operations before/after syncs using hooks.
PreSync Hook (Database Migration):
apiVersion: batch/v1
kind: Job
metadata:
annotations:
argocd.argoproj.io/hook: PreSync
argocd.argoproj.io/hook-delete-policy: HookSucceeded
PostSync Hook (Smoke Test):
apiVersion: batch/v1
kind: Job
metadata:
annotations:
argocd.argoproj.io/hook: PostSync
For complete sync hook examples, see examples/argocd/sync-hooks.yaml
ArgoCD Metrics: Exposed at /metrics endpoint (argocd_app_sync_total, argocd_app_info)
Flux Metrics: From controllers (gotk_reconcile_condition, gotk_reconcile_duration_seconds)
Sync Stuck/OutOfSync:
Self-Heal Not Working:
Secrets Not Decrypting:
argocd app create <name> # Create application
argocd app get <name> # View status
argocd app sync <name> # Trigger sync
argocd app diff <name> # Show drift
argocd app list # List all applications
flux create source git <name> # Create Git source
flux create kustomization <name> # Create kustomization
flux get all # View all resources
flux reconcile <kind> <name> # Force reconciliation
flux logs # View controller logs
kustomize build k8s/overlays/prod # Preview generated YAML
kubectl apply -k k8s/overlays/prod # Apply directly
kubectl diff -k k8s/overlays/prod # Show differences
Use the provided installation scripts for quick setup:
# Install ArgoCD
./scripts/install-argocd.sh
# Bootstrap Flux
export GITHUB_TOKEN=<token>
export GITHUB_OWNER=<org>
export GITHUB_REPO=fleet-infra
./scripts/install-flux.sh
# Check for drift
./scripts/check-drift.sh
# Promote environment
./scripts/promote-env.sh dev staging
Complete working examples provided in examples/ directory:
ArgoCD Examples:
Flux Examples:
Kustomize Examples:
Rollout Examples:
GitOps provides automated, declarative continuous delivery for Kubernetes with Git as the single source of truth. Choose ArgoCD for UI-driven workflows or Flux for CLI/API-first approaches. Implement automated reconciliation, drift detection, and progressive delivery for reliable deployments at scale. Integrate secret management, multi-cluster orchestration, and disaster recovery for production-grade GitOps workflows.
Assess Kubernetes workloads and cluster configuration for AKS Automatic compatibility. Identifies incompatibilities, generates fixes, and guides migration from AKS Standard to AKS Automatic. WHEN: migrate to AKS Automatic, check AKS Automatic readiness, validate manifests for Automatic, assess cluster for Automatic compatibility, fix deployment for Automatic compatibility, identify AKS Automatic migration blockers, is my cluster ready for AKS Automatic.
Discovers available Azure OpenAI model capacity across regions and projects. Analyzes quota limits, compares availability, and recommends optimal deployment locations based on capacity requirements. USE FOR: find capacity, check quota, where can I deploy, capacity discovery, best region for capacity, multi-project capacity search, quota analysis, model availability, region comparison, check TPM availability. DO NOT USE FOR: actual deployment (hand off to preset or customize after discovery), quota increase requests (direct user to Azure Portal), listing existing deployments.
Interactive guided deployment flow for Azure OpenAI models with full customization control. Step-by-step selection of model version, SKU (GlobalStandard/Standard/ProvisionedManaged), capacity, RAI policy (content filter), and advanced options (dynamic quota, priority processing, spillover). USE FOR: custom deployment, customize model deployment, choose version, select SKU, set capacity, configure content filter, RAI policy, deployment options, detailed deployment, advanced deployment, PTU deployment, provisioned throughput. DO NOT USE FOR: quick deployment to optimal region (use preset).
Unified Azure OpenAI model deployment skill with intelligent intent-based routing. Handles quick preset deployments, fully customized deployments (version/SKU/capacity/RAI policy), and capacity discovery across regions and projects. USE FOR: deploy model, deploy gpt, create deployment, model deployment, deploy openai model, set up model, provision model, find capacity, check model availability, where can I deploy, best region for model, capacity analysis. DO NOT USE FOR: listing existing deployments (use foundry_models_deployments_list MCP tool), deleting deployments, agent creation (use agent/create), project creation (use project/create).
Intelligently deploys Azure OpenAI models to optimal regions by analyzing capacity across all available regions. Automatically checks current region first and shows alternatives if needed. USE FOR: quick deployment, optimal region, best region, automatic region selection, fast setup, multi-region capacity check, high availability deployment, deploy to best location. DO NOT USE FOR: custom SKU selection (use customize), specific version selection (use customize), custom capacity configuration (use customize), PTU deployments (use customize).
This skill should be used when working with LaminDB, an open-source data framework for biology that makes data queryable, traceable, reproducible, and FAIR. Use when managing biological datasets (scRNA-seq, spatial, flow cytometry, etc.), tracking computational workflows, curating and validating data with biological ontologies, building data lakehouses, or ensuring data lineage and reproducibility in biological research. Covers data management, annotation, ontologies (genes, cell types, diseases, tissues), schema validation, integrations with workflow managers (Nextflow, Snakemake) and MLOps platforms (W&B, MLflow), and deployment strategies.
Latch platform for bioinformatics workflows. Build pipelines with Latch SDK, @workflow/@task decorators, deploy serverless workflows, LatchFile/LatchDir, Nextflow/Snakemake integration.
Run Python code in the cloud with serverless containers, GPUs, and autoscaling. Use when deploying ML models, running batch processing jobs, scheduling compute-intensive tasks, or serving APIs that require GPU acceleration or dynamic scaling.
Take ancoleman/implementing-gitops from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
The agent identifies a skill by the name field in its header. Two skills with the
same name cannot sit side by side — one of them will be ignored.