Learning GitOps - FluxCD - Dependencies & Orchestration

#Introduction

In episode 9 you learned all the source types. Now the question shifts: how do we make sure everything deploys in the right order? A production cluster holds dozens of interdependent applications — a database must exist before an application, CRDs before custom resources, an ingress before the services that use it.

This episode covers dependsOn, health checks, ordering strategies, and patterns for complex orchestration scenarios.

#Dependencies with dependsOn

dependsOn is how Flux declares that a Kustomization or HelmRelease may only run after another one finishes and is healthy:

apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: apps
  namespace: flux-system
spec:
  interval: 10m
  dependsOn:
    - name: infrastructure
    - name: databases
  path: ./apps
  prune: true
  sourceRef:
    kind: GitRepository
    name: fleet

Dependencies are not limited to the same namespace — just include namespace alongside name:

apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: team-a-apps
  namespace: team-a
spec:
  interval: 10m
  dependsOn:
    - name: platform
      namespace: flux-system
  path: ./team-a
  prune: true
  sourceRef:
    kind: GitRepository
    name: fleet

#Preventing Circular Dependencies

Flux detects circular dependency chains and rejects them at validation. Practical rules:

• Build the dependency graph as a DAG (directed acyclic graph).
• If A and B need each other, combine them into one Kustomization instead of two that dependsOn each other.
• Use flux trace to see how a Kustomization connects to others:

flux trace kustomization apps

#Health Checks

Without health checks, Flux only knows a resource was applied — not that it's healthy. Flux's built-in health assessment checks common resource types: a Deployment must have ready replicas, a Job must complete, a Pod must be Running.

For more control, declare healthChecks:

apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: apps
  namespace: flux-system
spec:
  interval: 10m
  timeout: 5m
  path: ./apps
  prune: true
  sourceRef:
    kind: GitRepository
    name: fleet
  healthChecks:
    - apiVersion: apps/v1
      kind: Deployment
      name: webapp
      namespace: webapp
    - apiVersion: batch/v1
      kind: Job
      name: migration
      namespace: webapp

• timeout — the maximum limit for one reconciliation cycle, including waiting for health checks. Default 5 minutes.
• A failed health check means the Kustomization's Ready is False, and other Kustomizations that depend on it also wait.

#Readiness Gates

For objects Flux doesn't recognize (e.g. custom resources from an operator), use spec.conditions — similar to Kubernetes readiness gates:

apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: app-operator
  namespace: flux-system
spec:
  interval: 10m
  path: ./infrastructure/app-operator
  prune: true
  sourceRef:
    kind: GitRepository
    name: fleet
  healthChecks:
    - apiVersion: apps/v1
      kind: Deployment
      name: app-operator
      namespace: platform
  commonMetadata:
    annotations:
      app.kubernetes.io/name: app-operator

#Deploy Ordering Strategies

The deploy order is determined by the dependency structure, not a global flag:

Mixed example: five independent applications run in parallel, all waiting for infrastructure:

apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: app-catalog
  namespace: flux-system
spec:
  interval: 10m
  dependsOn:
    - name: infrastructure
  path: ./apps/catalog
  prune: true
  sourceRef:
    kind: GitRepository
    name: fleet
---
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: app-billing
  namespace: flux-system
spec:
  interval: 10m
  dependsOn:
    - name: infrastructure
  path: ./apps/billing
  prune: true
  sourceRef:
    kind: GitRepository
    name: fleet

#Complex Scenarios

A few patterns that come up often in production:

#Database Before Application

flux create kustomization databases \
  --source=fleet \
  --path="./infrastructure/databases" \
  --prune=true
 
flux create kustomization apps \
  --source=fleet \
  --path="./apps" \
  --prune=true \
  --depends-on=databases

#Secrets Before Deployment

Secrets created by an operator (e.g. External Secrets Operator) must exist before pods start. Put the secrets Kustomization first and make sure the deployment waits:

apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: app-backend
  namespace: flux-system
spec:
  interval: 10m
  dependsOn:
    - name: secrets-sync
  path: ./apps/backend
  prune: true
  sourceRef:
    kind: GitRepository
    name: fleet

#CRD Before Custom Resource

This is the most commonly forgotten one. The correct order:

1. The crds Kustomization contains the CRDs and the operator Deployment.
2. The resources Kustomization uses that CRD, with dependsOn to crds.

#Layered Infrastructure

Order from the bottom layer upward: storage → network/ingress → observability → applications. Each layer only depends on the layer below it.

#Closing

Deployment orchestration is now predictable:

• dependsOn builds the dependency graph, including cross-namespace.
• Health checks and readiness gates define what "finished successfully" means.
• Ordering can be sequential, parallel, or mixed based on the dependency structure.
• Database-before-app, secrets-before-pods, and CRD-before-custom-resource patterns maintain stability.

Your deploy flow is solid. In episode 11 we'll manage configuration: variable substitution, per-environment configuration, secret management integration, and best practices for keeping the repository clean. See you!