Stéphane Tailland
11d27c2655
postBuild.substituteFrom can only read a ConfigMap in its own namespace. dataplane-template-defaults existed only in flux-system, so every gateway Kustomization had to live in flux-system to reach it — a namespace the feature teams have no access to. Their own gateway configuration ended up outside their reach as a side effect of a substitution rule, not as a governance decision. Add a namespace-less copy of the ConfigMap under kong-platform/domain-defaults, plus one Kustomization per domain in flux/domain-defaults.yaml differing only by targetNamespace. One source file, one edit when a default changes, six copies that follow. Platform-owned deliberately: these are the defaults a team inherits, not ones it sets, so they stay in flux-system while everything a team does own moves out of it. This is the precondition, not the move itself. The flux-system copy stays until the gateway Kustomizations relocate, and they cannot be patched into a new namespace — that is a delete and recreate, with a window where the gateway is unreconciled. It also retires a workaround: platform-llm inlined OTEL_TRACES_ENDPOINT because its Kustomization had to sit in the llm namespace, holding real credentials it must not put in flux-system, and so could not read this ConfigMap. With the ConfigMap in llm, that inlining can go. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
k8s-platform
Platform-team owned, cluster-scoped only. Rare changes, cautious sync (not aggressive auto-sync).
Per-domain gateway infrastructure (Gateway, GatewayConfiguration,
KonnectAPIAuthConfiguration) does NOT live here — see the dedicated
dataplane-<domain> repos, to avoid write contention across domains.
flux/
The Flux Operator (flux-system namespace) that everything else in this
GitOps setup depends on. Installed 2026-08-19 on the local cluster.
The operator itself is installed manually via Helm — bootstrap problem, Flux can't deploy the thing that deploys it:
helm install flux-operator oci://ghcr.io/controlplaneio-fluxcd/charts/flux-operator \
--namespace flux-system --create-namespace
flux/fluxinstance.yaml configures the actual Flux controllers
(source-controller, kustomize-controller, helm-controller,
notification-controller) — tracked in git, applied via
kubectl apply -k flux/.
flux/gitrepository.yaml is what lets Flux clone this (k8s-platform)
repo so other repos' Kustomizations can reference paths inside it (e.g.
dataplane-template/). url is a PLACEHOLDER — this repo has no git
remote yet. Once it does, apply it manually once
(kubectl apply -f flux/gitrepository.yaml) — same bootstrap-chicken-egg
reasoning as the operator install above.
kong-platform/
Cluster-wide Kong foundations:
gatewayclass.yaml—GatewayClasskong-v2(deliberately not namedkong, to avoid touching the pre-existingkongGatewayClass that backs the unrelatedtasks/jira/openrouterGateway on this cluster).operator/—HelmRepository+HelmReleasefor the Kong Gateway Operator itself, matching the release already installed manually on this cluster (helm list -n kong: chartkong-operator-1.3.1,env.ENABLE_CONTROLLER_KONNECT: true).helm-controllercan adopt an existing release under the samereleaseName/targetNamespacerather than reinstalling.
dataplane-template/
The shared KonnectAPIAuthConfiguration + GatewayConfiguration + Gateway
Secrettemplate (one copy,${VAR}-parameterized) that every domain's FluxKustomizationbuilds viapostBuild.substitute— seedataplane-catalog/README.mdfor the full mechanism and the values/secret side of it.
Applying today (no git remote yet)
Nothing here reconciles from git automatically yet — flux/gitrepository.yaml
has no real URL. Apply directly:
kubectl apply -k flux/ # fluxinstance.yaml + gitrepository.yaml (the
# latter will just sit inert, PLACEHOLDER url)
kubectl apply -f kong-platform/gatewayclass.yaml
dataplane-template/ is never applied on its own — it only makes sense
built + substituted by a domain's flux-kustomization.yaml, which itself
can't reconcile yet (needs the real GitRepository, see above).