Skip to main content

Platform Choice

The chart supports Gateway API, Kubernetes Ingress, and OpenShift Routes for the user-facing app/API path. Enable one depending on your platform.

Kubernetes — Gateway API with Envoy Gateway

Gateway API is the preferred option for the kOps v2 rehearsal profile and for self-hosted clusters that already run Envoy Gateway.

Prerequisites

Install Gateway API CRDs, cert-manager with Gateway support, and Envoy Gateway:
Create or reuse a GatewayClass named eg. On AWS kOps, the kOps v2 reference configures Envoy’s data-plane Service as an internet-facing NLB.

Values

Set the corresponding application URLs:

Verify


Kubernetes — Ingress

The frontend and backend each get their own Ingress and their own hostname. The frontend makes API calls to the backend hostname directly — there is no /api path proxying.

Prerequisites

Install ingress-nginx before deploying the chart:
Wait for the LoadBalancer IP or hostname:
Create DNS A records for both hostnames pointing at this address.

Separate-host values

Ingress is configured under the top-level ingress block:
Set the corresponding URLs in the frontend and backend Secrets:

Shared-host values

Shared-host mode routes the frontend at / and the backend at ingress.apiPrefix:
Add the annotation under the top-level ingress block:

TLS — Pre-existing certificates


OpenShift — Frontend and API Routes

OpenShift uses Routes instead of Ingress. The chart creates Routes for the frontend and backend API. Connect stays internal through CONNECT_SERVICE_URL unless your deployment needs a public Connect endpoint.

Values

The Routes use edge TLS termination — TLS is terminated at the OpenShift router, plain HTTP to the pods.

Generated Route resources

Set the corresponding URLs in the frontend and backend Secrets:

Observability (Grafana)

Expose the Grafana UI from the otel-lgtm component when otelLgtm.enabled: true:

Internal Service Addresses

When configuring Secrets, use these ClusterIP hostnames (release name cobi-dashboard, namespace cobi):