Flux reconciles a Kustomization by pushing objects at the API server, and a GatewayClass is a valid object only once the CRD that defines that kind is registered. Envoy Gateway delivers those CRDs inside its Helm chart [5], so the type definition shows up as a side effect of installing the controller. Skip the ordering and, in the author's account, Flux runs ahead and tries to create a GatewayClass in a cluster that has never heard of GatewayClasses [6]. The three chained Kustomizations plus `wait: true` encode the sequence instead: controllers, wait until healthy, then configs, then apps [7].
That transfers only if your CRDs are packaged the same way. The dependency edge exists because the chart is the delivery mechanism for the schema [5]. Where CRDs are applied as a separate step, the graph has a different shape, and copying someone else's `dependsOn` chain gives you serialization you did not need.
Serialization is the bill. On this layout the controllers Kustomization holds both Longhorn and Envoy Gateway HelmReleases [3], and the apps Kustomization sits downstream of it [4], so a storage controller that never reports healthy is now also the reason Airflow never gets applied [7]. For a single-node homelab rebuilding after a power cut [1] that is the right trade. For a cluster where app teams ship independently of the platform, one health check upstream of everything is a queue.
The secrets failure is the same class of bug with no `dependsOn` available to fix it. The Airflow HelmRelease reads its admin password through `valuesFrom` with `optional: false`, so no secret means no install [13]. Bootstrapping first and creating secrets second gave Flux three retries, an exhausted budget, and a release parked in a failed state [14]. Then remediation reported `missing target release for rollback: cannot remediate failed release`, because a first install that never succeeded leaves nothing to roll back to [15]. Recovery needs `--force` or a suspend/resume, and the stated lesson is to create the secrets before bootstrap, since the cluster exists as soon as MicroK8s is up and Flux does not have to be watching for `kubectl create secret` to work [16]. That last sentence is the kind you only write after it costs you an evening.
Version pinning belongs in the same argument. Every HelmRelease started at `version: "1.x"` [17], and chart 1.22.0 of Airflow carries `appVersion: 3.2.2` [19], which is a useful reminder that a chart range constrains the chart's numbering space and not the application's. The repo now names 1.22.0, 1.12.1 and v1.9.1 [18], which moves upgrade timing out of the reconcile loop and into a commit [17].
Three of the documented stumbles are ordering errors rather than value errors: CRDs before their consumers, secrets before the release that mounts them, and the directory before the kustomization entry that references it, the last of which surfaced as a reconcile hanging on `context deadline exceeded` with no pods appearing [1][20]. Git holds the desired state; the order that state has to arrive in lives in `dependsOn` edges and in a script you run before Flux ever starts watching [4][16].
