First commit

kong-platform/gatewayclass.yaml

@@ -0,0 +1,14 @@
+# Named "kong-v2", not "kong" — the "kong" GatewayClass already exists on
+# this cluster (backs the unrelated tasks/jira/openrouter Gateway) and its
+# default parametersRef is load-bearing for that Gateway, which has no
+# per-instance override unlike ours. Reusing that name would edit a shared
+# cluster-scoped object something else depends on. No parametersRef here:
+# every domain's own Gateway sets spec.infrastructure.parametersRef itself
+# (see dataplane-template/gateway.yaml), so there's no meaningful default to
+# set at the class level.
+apiVersion: gateway.networking.k8s.io/v1
+kind: GatewayClass
+metadata:
+  name: kong-v2
+spec:
+  controllerName: konghq.com/gateway-operator

kong-platform/kustomization.yaml

@@ -0,0 +1,4 @@
+apiVersion: kustomize.config.k8s.io/v1beta1
+kind: Kustomization
+resources:
+  - gatewayclass.yaml

kong-platform/operator/helmrelease.yaml

@@ -0,0 +1,25 @@
+# Matches the release already installed manually on this cluster
+# (`helm list -n kong`: chart kong-operator-1.3.1, values env.ENABLE_CONTROLLER_KONNECT: true).
+# helm-controller can adopt an existing release under the same
+# releaseName/targetNamespace — this doesn't reinstall from scratch, it
+# starts managing what's already there.
+apiVersion: helm.toolkit.fluxcd.io/v2
+kind: HelmRelease
+metadata:
+  name: kong-operator
+  namespace: flux-system
+spec:
+  interval: 1h
+  releaseName: kong-operator
+  targetNamespace: kong
+  chart:
+    spec:
+      chart: kong-operator
+      version: "1.3.1"
+      sourceRef:
+        kind: HelmRepository
+        name: kong
+        namespace: flux-system
+  values:
+    env:
+      ENABLE_CONTROLLER_KONNECT: true

kong-platform/operator/helmrepository.yaml

@@ -0,0 +1,8 @@
+apiVersion: source.toolkit.fluxcd.io/v1
+kind: HelmRepository
+metadata:
+  name: kong
+  namespace: flux-system
+spec:
+  interval: 1h
+  url: https://charts.konghq.com