feat: evaluate Flux Operator advanced CRDs (ResourceSet, FluxReport, MCP Server)

[patrick-hermann-sva]

Summary

The Flux Operator has grown beyond just the FluxInstance CRD. We currently only use FluxInstance and the Flux Status Page (via apps/flux-web). Several newer features could significantly improve our GitOps workflow and should be evaluated for adoption.

Current Usage

Component	Status	Location
FluxInstance CRD	Actively used	Bootstrap (README), tests/vcluster/xplane/flux.yaml
Flux Status Page (web UI)	Deployed	apps/flux-web/ (serverOnly: true)
FluxReport CRD	Not used	—
ResourceSet CRD	Not used	—
ResourceSetInputProvider CRD	Not used	—
Flux Operator CLI	Not used	—
Flux Operator MCP Server	Not used	—

Features to Evaluate

1. ResourceSet CRD

Manages groups of Kubernetes and Flux resources based on input matrices. This could replace our current pattern of manually creating per-cluster Kustomization CRs.

Potential use case — multi-cluster app deployment:

apiVersion: fluxcd.controlplane.io/v1
kind: ResourceSet
metadata:
  name: app-deployments
  namespace: flux-system
spec:
  inputMatrix:
    - cluster: [cluster-a, cluster-b, cluster-c]
      app: [vault, cert-manager, prometheus]
  resources:
    - apiVersion: kustomize.toolkit.fluxcd.io/v1
      kind: Kustomization
      metadata:
        name: "${app}-${cluster}"
      spec:
        path: "./infra/${app}"
        postBuild:
          substitute:
            CLUSTER_NAME: "${cluster}"

Evaluate:

• Can ResourceSet replace per-cluster Kustomization manifests in the fleet repo (stuttgart-things/stuttgart-things)?
• How does it interact with our variable substitution pattern (postBuild.substitute)?
• Can it template the GitRepository tag reference per environment?

2. ResourceSetInputProvider CRD

Fetches input values from external services (GitHub, GitLab, Azure DevOps, Container Registries). Could automate version tracking.

Potential use cases:

• GitHub releases: Auto-detect latest chart versions from OCI registries and feed into ResourceSet
• Container registry tags: Watch for new app versions and update ResourceSet inputs
• Branch-based environments: Create Flux resources per branch automatically

Evaluate:

• Can InputProvider watch ghcr.io/stuttgart-things/* for new chart versions?
• Can it replace Renovate for version bumps (or complement it)?
• Integration with our OCI HelmRepository and OCIRepository patterns

3. FluxReport CRD

Reflects the state of a Flux installation. Could provide observability without needing flux get all.

Potential use cases:

• Feed into Prometheus/Grafana dashboards (we already deploy Prometheus in infra/prometheus)
• Feed into Uptime Kuma monitors (we already deploy it in apps/uptime-kuma)
• Display in Headlamp UI (we already deploy it in apps/headlamp)
• Display in Backstage (planned in feat: add Backstage-compatible docs/ directory with TechDocs #42)

Evaluate:

• Does FluxReport auto-generate when FluxInstance is deployed, or does it need separate configuration?
• What metrics/status fields does it expose?
• Can we scrape it with Prometheus?

4. Flux Operator CLI (flux-operator)

Command-line interface for interacting with the Flux Operator, built with Cobra.

Potential use cases:

• Integrate into Taskfile.yaml for local developer workflows
• Use in CI/CD pipeline (feat: add CI/CD release pipeline with GitHub Actions #44) for validation and status checks
• Complement the Dagger kubernetes-deployment module (blueprints repo)

Evaluate:

• What commands does it offer beyond flux CLI?
• Can it manage ResourceSets and InputProviders?
• How does it compare to flux CLI for our workflows?

5. Flux Operator MCP Server

Connects AI assistants to Kubernetes clusters running the operator. Built with mcp-go.

Potential use cases:

• Connect Claude Code / Claude Desktop to live cluster state for debugging
• Query Flux resource status, reconciliation errors, and drift from within an AI assistant
• Automate troubleshooting workflows (e.g., "why is app X not reconciling?")

Evaluate:

• What tools/resources does the MCP server expose?
• Can it be deployed alongside our existing apps/flux-web?
• Security considerations for AI assistant cluster access
• Integration with Claude Code MCP configuration

Investigation Tasks

• ResourceSet: Deploy a proof-of-concept ResourceSet in a test cluster that templates Kustomizations for 2-3 apps across 2 environments
• ResourceSetInputProvider: Test GitHub/OCI registry input provider with one of our ghcr.io/stuttgart-things charts
• FluxReport: Check if it's auto-generated; if so, test Prometheus scraping; if not, create one and evaluate output
• Flux Operator CLI: Install and compare capabilities vs flux CLI for our use cases
• MCP Server: Deploy and test with Claude Code; document tools/resources it exposes
• Document findings in the Backstage docs (feat: add Backstage-compatible docs/ directory with TechDocs #42) under a new docs/advanced/ section

References

• Flux Operator docs
• ResourceSet API
• ResourceSetInputProvider API
• Flux Operator CLI
• Flux Operator MCP Server
• Related issues: feat: add Backstage-compatible docs/ directory with TechDocs #42 (Backstage docs), feat: add CI/CD release pipeline with GitHub Actions #44 (CI/CD pipeline)