gitops-knowledge

What this skill does

# Flux CD Knowledge Base

You are an expert on Flux CD, the GitOps toolkit for Kubernetes. Use this knowledge base
to answer questions accurately, generate correct YAML manifests, and explain Flux concepts.

**Rules:**
- Always use the exact apiVersion/kind combinations from the CRD table below. Never invent API versions.
- Before generating YAML for any CRD, read its OpenAPI schema from `assets/schemas/` to verify field names, types, and enum values.
- When a question requires detail beyond this file, load the relevant reference file from `references/`.
- Prefer Flux Operator (FluxInstance) for cluster setup. Do not reference `flux bootstrap` or legacy `gotk-*` files.

## What is Flux

Flux is a set of Kubernetes controllers that implement GitOps — the practice of using Git
(or OCI registries) as the source of truth for declarative infrastructure and applications.
Flux continuously reconciles the desired state stored in sources with the actual state of
the cluster.

**Flux Operator** manages the Flux installation declaratively through a `FluxInstance` custom
resource. It handles installation, configuration, upgrades, and lifecycle of all Flux controllers.
Only one FluxInstance named `flux` can exist per cluster.

**How resources relate:**

```
Sources (Git, OCI, Helm, Bucket)
  │
  ▼ produce artifacts
Artifacts (tarballs, Helm charts, OCI layers)
  │
  ▼ consumed by
Appliers (Kustomization, HelmRelease)
  │
  ▼ create/update
Managed Resources (Deployments, Services, ConfigMaps, ...)
  │
  ▼ status reported to
Notifications (Provider + Alert → Slack, Teams, GitHub, ...)
```

**ResourceSet orchestration flow:**

```
ResourceSetInputProvider (GitHub PRs, OCI tags, ...)
  │
  ▼ exports inputs
ResourceSet (template + input matrix)
  │
  ▼ generates per-input
Namespaces, Sources, Kustomizations, HelmReleases, RBAC, ...
```

**Two delivery models:**
- **Git-based:** Flux watches Git repositories and applies changes on commit.
- **Gitless (OCI-based):** Git → CI pushes OCI artifacts → Flux pulls from registry. OCI artifacts
  are immutable, signed, and don't require Git credentials on clusters.

## Controllers and CRDs

| Kind | apiVersion | Controller | Purpose |
|------|-----------|------------|---------|
| FluxInstance | fluxcd.controlplane.io/v1 | flux-operator | Manages Flux installation lifecycle |
| FluxReport | fluxcd.controlplane.io/v1 | flux-operator | Read-only observed state of Flux |
| ResourceSet | fluxcd.controlplane.io/v1 | flux-operator | Template resources from input matrix |
| ResourceSetInputProvider | fluxcd.controlplane.io/v1 | flux-operator | Fetch inputs from external services |
| GitRepository | source.toolkit.fluxcd.io/v1 | source-controller | Fetch from Git repositories |
| OCIRepository | source.toolkit.fluxcd.io/v1 | source-controller | Fetch OCI artifacts from registries |
| HelmRepository | source.toolkit.fluxcd.io/v1 | source-controller | Index Helm chart repositories |
| HelmChart | source.toolkit.fluxcd.io/v1 | source-controller | Fetch and package Helm charts |
| Bucket | source.toolkit.fluxcd.io/v1 | source-controller | Fetch from S3-compatible storage |
| ExternalArtifact | source.toolkit.fluxcd.io/v1 | (external) | Generic artifact storage for 3rd-party controllers |
| ArtifactGenerator | source.extensions.fluxcd.io/v1beta1 | source-controller | Compose/decompose artifacts from multiple sources |
| Kustomization | kustomize.toolkit.fluxcd.io/v1 | kustomize-controller | Build and apply Kustomize overlays or plain YAML |
| HelmRelease | helm.toolkit.fluxcd.io/v2 | helm-controller | Install and manage Helm releases |
| Provider | notification.toolkit.fluxcd.io/v1beta3 | notification-controller | External notification provider config |
| Alert | notification.toolkit.fluxcd.io/v1beta3 | notification-controller | Route events to notification providers |
| Receiver | notification.toolkit.fluxcd.io/v1 | notification-controller | Webhook receiver for incoming events |
| ImageRepository | image.toolkit.fluxcd.io/v1 | image-reflector-controller | Scan container image registries |
| ImagePolicy | image.toolkit.fluxcd.io/v1 | image-reflector-controller | Select image by version policy |
| ImageUpdateAutomation | image.toolkit.fluxcd.io/v1 | image-automation-controller | Update YAML in Git with new image tags |

## How Flux Works

### Reconciliation Loop

Flux controllers run a continuous reconciliation loop:

1. **Sources poll for changes** — source-controller checks Git repos, OCI registries, Helm repos,
   or S3 buckets at configured intervals and produces versioned artifacts.
2. **Appliers consume artifacts** — kustomize-controller and helm-controller detect new artifact
   revisions, build manifests (Kustomize overlays or Helm templates), and apply them to the cluster
   using server-side apply.
3. **Drift detection and self-healing** — Flux compares the desired state from the source with the
   live state in the cluster. When drift is detected, Flux corrects it automatically (if enabled).
4. **Notifications report status** — notification-controller sends events to external systems
   (Slack, Teams, GitHub commit status, etc.) based on Alert rules.

### Dependency Ordering

Use `dependsOn` to control reconciliation order. For example, install CRDs before CRs,
or infrastructure before applications:

```yaml
spec:
  dependsOn:
    - name: infra-controllers  # wait for this Kustomization to be Ready
```

ResourceSets support richer dependencies with `readyExpr` (CEL expressions) and can depend on any type of resource:

```yaml
spec:
  dependsOn:
    - apiVersion: fluxcd.controlplane.io/v1
      kind: ResourceSet
      name: policies
      ready: true
      readyExpr: "status.conditions.filter(e, e.type == 'Ready').all(e, e.status == 'True')"
```

### Reactivity with Watch Labels

By default, Flux controllers poll sources at the configured interval. To react immediately
when a dependency changes, add the watch label to the upstream resource:

```yaml
metadata:
  labels:
    reconcile.fluxcd.io/watch: Enabled
```

When a ConfigMap or Secret with this label changes, any Kustomization or HelmRelease that
references it via `postBuild.substituteFrom` or `valuesFrom` will reconcile immediately.

## Decision Trees

### Which Source Type?

- **Git repo with Kustomize overlays or plain YAML** → `GitRepository`
- **OCI artifact (container image with manifests)** → `OCIRepository`
- **Helm chart from OCI registry** → `OCIRepository` with `layerSelector` for Helm media type
- **Helm chart from HTTPS Helm repo** → `HelmRepository` (default type)
- **S3/GCS/MinIO bucket** → `Bucket`
- **Monorepo that needs splitting** → `ArtifactGenerator` (creates `ExternalArtifact` per path)
- **Helm chart + env-specific values from Git** → `ArtifactGenerator` (composes chart with values overlay)

### Kustomization vs HelmRelease?

- **Plain YAML or Kustomize overlays** → `Kustomization`
- **Helm chart** → `HelmRelease`
- Both can deploy to remote clusters via `kubeConfig` and support `dependsOn`.

### ResourceSet vs Kustomization?

- **One set of manifests, one deployment** → `Kustomization`
- **Same template deployed for N inputs (tenants, components, environments)** → `ResourceSet`
- ResourceSets generate resources from an input matrix; Kustomizations apply a fixed set of manifests.

### How to Set Up GitOps from Scratch

1. Install Flux Operator (Helm chart or Terraform)
2. Create a `FluxInstance` named `flux` in the `flux-system` namespace
3. Configure `.spec.sync` to point to your Git repo or OCI registry
4. Organize manifests in the source repo using Kustomize base+overlay pattern
5. Create `Kustomization` resources to apply manifests from the source
6. Add `Provider` + `Alert` for notifications

## Canonical YAML Patterns

### 1. GitOps Pipeline (GitRepository + Kustomization)

```yaml
apiVersion: source.toolkit.fluxcd.io/v1
kind: GitRepository
metadata:
  name: my-app
  namespace: flux-system
spec:
  interval: 5m
  url: https://github.com/org/my-app