Stéphane Tailland
a392e09ae5
Every Kong entity names its control plane through
controlPlaneRef.konnectNamespacedRef (this operator version exposes no
konnectID ref type), and the only mirror CR available was the one the
Gateway operator auto-creates with a random suffix. That suffix was
looked up by hand and pasted into CONTROL_PLANE_REF_NAME in 11 places
across 11 repos, where it went stale silently whenever the Gateway was
recreated. Replacing the Konnect org did exactly that: all 11 refs named
CRs that no longer existed and every service, route and plugin binding
sat Programmed=False.
Declare a mirror CR named ${NAME}-cp instead, so the refs are derived
from NAME and never need touching again. source: Mirror adopts an
existing control plane rather than owning it — deleting the CR leaves
the control plane in Konnect intact (verified: count unchanged across a
delete), so it coexists with the operator's own mirror of the same id.
The id itself comes from Vault via External Secrets, so a new Konnect
org now needs no edit in any repo.
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).