{{/* The Gateway-API alternative to patchmon.ingress.yaml (Gitea #114). Form and reasoning: template-chart/templates/xxx.httproute.yaml and README, "Ingress and Gateway API". Only an HTTPRoute with parentRefs. No Gateway, no gatewayClassName, no Certificate, and no implementation-specific policy object - that subset looks identical on nginx-gateway-fabric, Cilium, Envoy Gateway and Istio, which is the whole reason the cluster's implementation can be swapped without touching this chart. Class and certificate therefore belong to the PLATFORM, on the Gateway and its listeners. ingress.clusterIssuer is meaningless here - this chart renders no Certificate in this mode - and it is not demanded either: its only required() sits inside patchmon.ingress.yaml, behind ingress.enabled. ingress.domain IS STILL REQUIRED, AND NOT BECAUSE OF THIS FILE Checked for this chart rather than copied: ingress.domain is read twice more outside both routing templates. CORS_ORIGIN in patchmon.deployment.yaml carries its own required() and is therefore what makes domain mandatory in EVERY mode of this chart, Gateway mode included - the fallback below is never the only reader. The second read is the explicit "Host" header the probes send (patchmon.server.httpGet in _helpers.tpl), which deliberately uses `| default ""` and demands nothing itself, because the required() above has already fired by the time it runs. The consequence that matters in this mode is the one NOTES.txt already spells out for the Ingress: the 2.x server rejects requests whose Host is neither loopback nor a CORS_ORIGIN host, so a domain the app does not answer on keeps the pod out of Ready forever. Nothing about that changes with a Gateway in front instead of an Ingress - and TRUST_PROXY stays right either way, since a Gateway is a reverse proxy too. WEBSOCKETS: nothing to configure, in either mode. The 2.x server serves the frontend, /api/* and its WebSocket upgrade from one process on one port, and the Gateway API passes an upgrade through on a plain HTTPRoute - there is no annotation involved in Ingress mode either. */}} {{- /* Null-safe like every other block this chart dereferences (#99): an override written without children - "httpRoute:" with the keys below it deleted - is YAML null, and `.Values.httpRoute.enabled` would abort the render with a nil pointer. An empty block means "chart defaults apply", and all three defaults are empty or false, so the whole block collapses to "no HTTPRoute". */ -}} {{- $httpRoute := .Values.httpRoute | default dict -}} {{- if and $httpRoute.enabled .Values.ingress.enabled -}} {{- fail "ingress.enabled and httpRoute.enabled are both true - set exactly one of them. The Ingress and the HTTPRoute would publish the same Service under the same hostname over two different data paths, which is already a conflict at DNS level: one name, two addresses, and which one a client reaches is luck. A migration runs over a SECOND hostname (set httpRoute.hostnames explicitly while the Ingress keeps ingress.domain), never over parallel operation of both." -}} {{- end -}} {{- if $httpRoute.enabled -}} {{- $parentRefs := $httpRoute.parentRefs | default list -}} {{- if not $parentRefs -}} {{- fail "httpRoute.enabled is true but httpRoute.parentRefs is empty - an HTTPRoute without a parent attaches to no Gateway. It is created, it is schema-valid, and it routes NOTHING, with no event and no condition that says so; the only symptom is a hostname that does not answer. Name the cluster's Gateway, e.g. httpRoute.parentRefs: [{name: public, namespace: gateway}]." -}} {{- end -}} {{- /* One source of truth for the hostname: an empty httpRoute.hostnames means [ingress.domain], so the two cannot drift apart. Setting httpRoute.hostnames explicitly is what a migration over a second hostname needs - but mind that it does NOT move CORS_ORIGIN or the probes' Host header, which keep following ingress.domain. For this chart the two therefore have to be set together, or the app rejects the browser's requests from the new name. */ -}} {{- $hostnames := $httpRoute.hostnames | default list -}} {{- if not $hostnames -}} {{- $hostnames = list (required "A Domain/Host must be provided: set ingress.domain (used as the HTTPRoute's single hostname when httpRoute.hostnames is empty) or set httpRoute.hostnames explicitly" .Values.ingress.domain) -}} {{- end -}} apiVersion: gateway.networking.k8s.io/v1 kind: HTTPRoute metadata: name: {{ .Release.Name }}-{{ .Chart.Name }}-httproute spec: parentRefs: {{- toYaml $parentRefs | nindent 4 }} hostnames: {{- toYaml $hostnames | nindent 4 }} rules: # The Ingress counterpart is `path: / , pathType: Prefix` on the one # backend Service - the 2.x server serves the frontend and /api/* from one # process, so a single path covers everything. The port is the Service's # port NUMBER and not its name ("http"): backendRefs takes a PortNumber, # so unlike the Ingress this reference cannot be made by name and the 80 # below has to track patchmon.service.yaml by hand. # ci/run-httproute-match-test.sh is what holds that pair - it fails when a # backendRef names a Service, or a port, the same render does not create. - matches: - path: type: PathPrefix value: / backendRefs: - name: {{ .Release.Name }}-{{ .Chart.Name }}-service port: 80 {{- end }}