Skip to main content

GitOps Model

Purpose: For platform engineers and developers, explains the platform team / app team collaboration model with separated repos and FluxCD watches.

Concept Summary​

The openCenter GitOps model splits responsibilities between two teams through separate Git repositories. The platform team owns cluster infrastructure and FluxCD configuration. The application team owns application manifests. FluxCD bridges the two — it watches both repositories and reconciles their contents into the cluster.

How It Works​

Platform Team Responsibilities​

The platform team manages the customer GitOps repository. Their scope includes:

  • FluxCD bootstrap — gotk-components.yaml and gotk-sync.yaml in flux-system/
  • GitRepository sources — CRDs that tell FluxCD where to pull from (both openCenter-gitops-base and application repos)
  • Kustomization resources — CRDs that tell FluxCD what path to reconcile and into which namespace
  • Platform services — Overlays for cert-manager, Kyverno, Harbor, observability stack, etc.
  • SOPS secrets — Encrypted credentials for platform services

The platform team creates a GitRepository and Kustomization for each application repo:

# services/sources/customer-app.yaml (managed by platform team)
apiVersion: source.toolkit.fluxcd.io/v1
kind: GitRepository
metadata:
  name: customer-app
  namespace: flux-system
spec:
  url: ssh://git@github.com/customer-org/customer-app.git
  ref:
    branch: main
  interval: 5m
  secretRef:
    name: customer-app-deploy-key
---
# services/fluxcd/customer-app.yaml (managed by platform team)
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: customer-app
  namespace: flux-system
spec:
  sourceRef:
    kind: GitRepository
    name: customer-app
  path: ./
  interval: 10m
  prune: true
  targetNamespace: customer-app
  wait: true
  timeout: 5m

Application Team Responsibilities​

The application team manages their own repository. Their scope includes:

  • Kubernetes manifests — Deployments, Services, ConfigMaps, and Secrets for their applications
  • Gateway API resources — HTTPRoute definitions for ingress routing
  • Kustomize structure — A root kustomization.yaml that composes all application resources
  • Application-level NetworkPolicies — Isolation rules for their workloads

The application team does not need access to the platform team's repository. They push to their own repo; FluxCD detects the change and reconciles.

Trade-Offs and Alternatives​

ApproachProsCons
Separated repos (current)Clear ownership, independent release cycles, least-privilege accessTwo repos to coordinate; platform team must create GitRepository/Kustomization for each app
Monorepo (all in one)Single source of truth, simpler FluxCD configBlast radius — one bad commit affects everything; access control is coarser
App team self-service (app team creates own FluxCD CRDs)Full autonomy for app teamsRequires cluster-level RBAC for app teams; harder to enforce standards

Common Misconceptions​

  • "The app team needs cluster-admin." They do not. The app team pushes manifests to Git. FluxCD (running as a platform service with appropriate RBAC) applies them. The app team never runs kubectl apply directly.
  • "Changes require platform team approval." Only the initial onboarding (creating the GitRepository + Kustomization) requires platform team action. After that, the app team deploys independently by pushing to their branch.
  • "FluxCD polls constantly." The default interval: 5m means FluxCD checks the Git source every 5 minutes. For faster feedback, configure a webhook notification from the Git provider to FluxCD's receiver endpoint.

Further Reading​