On a fresh cluster, a Flux Kustomization that deploys an app fails because the operator supplying its CRDs is not installed yet. How do dependsOn and healthChecks on the Kustomization resource fix the ordering?

## Why the ordering problem exists at all Kubernetes has no general ordering primitive. Apply a CustomResource before its CustomResourceDefinition exists and the API server rejects it as an unknown kind. Apply a workload before the operator that mutates it is running and it starts unconfigured. A single `kubectl apply -f` of a directory hits this constantly, and Flux inherits it: within one `Kustomization`, kustomize-controller applies in a sensible built-in order (namespaces and CRDs before things that use them) and retries the reconciliation on failure, but it cannot know that your app needs *this* operator's controller Pod to be running first. The Flux answer is to make ordering a property of the resources you already have, rather than an annotation buried in manifests. ## dependsOn: order between Kustomizations ```yaml apiVersion: kustomize.toolkit.fluxcd.io/v1 kind: Kustomization metadata: name: apps namespace: flux-system spec: interval: 10m path: ./apps/production prune: true sourceRef: kind: GitRepository name: fleet dependsOn: - name: infra-controllers ``` `dependsOn` is a list of references to other Kustomization objects (name, and namespace if it differs). Before reconciling, kustomize-controller checks each dependency's `Ready` condition. If any is not ready, it does not apply — it requeues and reports that it is waiting on the dependency, so the reason is visible in `flux get kustomizations` rather than hidden in a crash loop. This is what makes the common three-tier layout work: `infra-controllers` (cert-manager, ingress controller, CRDs) → `infra-configs` (ClusterIssuers, the custom resources those CRDs define) → `apps`. Each layer names the one below. `HelmRelease` has the same field, so a chart can wait for another release. Two properties worth stating in an interview. First, a dependency is a gate, not a trigger: the dependent still reconciles on its own interval, it just refuses to proceed while blocked. Second, the graph must be acyclic — a cycle leaves both objects waiting forever, and the fix is to look at the reported reason rather than at logs. ## healthChecks: making "Ready" mean something Here is the subtlety that separates people who have run Flux from people who have read about it. By default, a Kustomization becomes Ready when the apply succeeded. Applied is not running. The operator's Deployment exists but has zero available replicas; its webhook is not serving yet; the CRD is registered but the controller that reconciles those custom resources is still pulling its image. The dependent Kustomization sees Ready, applies the app, and the app fails — the same failure you were trying to avoid, one step later. `healthChecks` changes the definition of Ready for that Kustomization: ```yaml spec: interval: 10m path: ./infrastructure/controllers prune: true wait: false timeout: 5m healthChecks: - apiVersion: apps/v1 kind: Deployment name: cert-manager-webhook namespace: cert-manager sourceRef: kind: GitRepository name: fleet ``` Each entry names an object by apiVersion, kind, name and namespace. The Kustomization is not Ready until those objects are assessed healthy — for a Deployment, that means its rollout has completed. `timeout` bounds the wait; exceeding it fails the reconciliation with a health-check failure rather than hanging. `wait: true` is the broad-brush version: require readiness of *everything* the Kustomization applied. It is convenient and it is honest about the whole layer, but it is slower, it makes one perpetually-unready object block the layer, and it needs a realistic `timeout`. Named `healthChecks` is the surgical version — you list the handful of objects the next layer genuinely depends on. Note that the two are not mutually exclusive in intent: `wait: true` supersedes the need for an explicit list, so pick one deliberately. ## What this buys you operationally - **A fresh cluster converges unattended.** Bootstrap a brand-new cluster and the layers come up in order without anyone running things by hand. That is the real test — a GitOps setup that only works because the cluster already has the operators installed is not reproducible. - **Failures point at a cause.** "apps: dependency 'infra-controllers' is not ready" is a diagnosis. A CrashLoopBackOff on the app is a symptom. - **Retries are free.** Because reconciliation is level-triggered and interval-driven, a dependency that becomes ready five minutes later just unblocks the next tick. There is nothing to re-run. ## Limits to acknowledge dependsOn orders *Kustomizations*, not individual objects, so the granularity of your ordering is the granularity of your layer split — over-splitting to express fine ordering produces a brittle dependency graph. Health assessment covers the object kinds Flux knows how to assess plus custom resources that report standard readiness conditions; an operator whose CR never reports a condition cannot be waited on meaningfully. And long chains multiply worst-case convergence time on a cold cluster, since each layer's timeout can be spent in sequence.