feat(chart): Add support for Gateway API

[Filip7656]

The current Helm chart supports exposing services with Ingress resources. With the Kubernetes Gateway API becoming the recommended successor to Ingress, its good to add support to it.

Gateway API provides a more expressive, extensible, and role-oriented model for traffic management and is already supported by many popular controllers (e.g. Istio, GKE Gateway, Kong, Traefik, Envoy Gateway).

We can run gateway controller alongside ingress as they will have different ip addresses allowing us to validate without interruption.

Proposed enhancement

Add optional support for Gateway API resources, including:

• HTTPRoute (this is the equivalent of ingress resource)
• Migration guide

This support should be opt-in and coexist with the existing Ingress-based configuration.

Suggested helm values.yaml config

httpRoute:
  enabled: true
  hostname: ""
  tls: false
  parentRefs:
    - group: gateway.networking.k8s.io
      kind: Gateway
      name: chainloop-gw
      sectionName: http
  annotations: {}

Example httproute.yaml

{{- if or .Values.controlplane.httpRoute.enabled .Values.httpRoute.enabled }}
{{- $fullName := include "chainloop.controlplane.fullname" . -}}
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: {{ $fullName }}
  namespace: {{ include "common.names.namespace" . | quote }}
  labels: {{- include "chainloop.controlplane.labels" . | nindent 4 }}
{{- if or .Values.controlplane.httpRoute.annotations .Values.httpRoute.annotations }}
  annotations:
    {{- if .Values.controlplane.httpRoute.annotations }}
    {{- include "common.tplvalues.render" ( dict "value" .Values.controlplane.httpRoute.annotations "context" $) | nindent 4 }}
    {{- end }}
    {{- if .Values.httpRoute.annotations }}
    {{- include "common.tplvalues.render" ( dict "value" .Values.httpRoute.annotations "context" $) | nindent 4 }}
    {{- end }}
{{- end }}
spec:
  parentRefs:
{{- if .Values.controlplane.httpRoute.parentRefs }}
    {{- toYaml .Values.controlplane.httpRoute.parentRefs | nindent 4 }}
{{- else if .Values.httpRoute.parentRefs }}
    {{- toYaml .Values.httpRoute.parentRefs | nindent 4 }}
{{- end }}
  hostnames:
    - {{ include "chainloop.httpRoute.get" (dict "key" "hostname" "service" "controlplane" "Values" .Values) }}
  rules:
    - matches:
        - path:
            value: "/"
            type: PathPrefix
      {{- $port := coalesce .Values.controlplane.service.port .Values.controlplane.service.ports.http }}
      backendRefs:
        - name: {{ include "chainloop.controlplane.fullname" . }}
          kind: Service
          namespace: {{ include "common.names.namespace" . | quote }}
          port: {{ $port }}
    - matches:
        - headers:
            - name: content-type
              value: application/grpc
      {{- $portAPI := coalesce .Values.controlplane.serviceAPI.port .Values.controlplane.serviceAPI.ports.http }}
      backendRefs:
        - name:  {{ include "chainloop.controlplane.fullname" . }}-api
          kind: Service
          namespace: {{ include "common.names.namespace" . | quote }}
          port: {{ $portAPI }}
{{- end }}

This implementaion should not affect current ingress as this uses diffrent controller and API.

Tasks

• Create httpRoute files and config in values.yaml
• Test it
• Document and create a migration guide

[migmartri]

awesome, so in practice we'll have only two httproute entries instead of 4 ingresses

[Filip7656]

yes, and we can think about adding some header to the requests with name of the service so we could do one httpproxy and manage traffic by content-type and for example x-chainloop-service header. Then we would be able to have both services under one domain. But this is to be discussed

    - matches:
        - headers:
            - name: content-type
              value: application/grpc
            - name: x-chainloop-service
              value: artifact-cas