Gateway API, TLS and DNS

External traffic is handled by an external load balancer, with the Gateway API routing requests to services inside the cluster based on hostname or path.

DNS

The Kubernetes API and platform services have canonical SUNET-managed hostnames. A customer-owned application hostname is separate: agree its Gateway target with SUNET before creating its DNS record. A custom application hostname does not change the Kubernetes API hostname in your kubeconfig.

We can also provide a DNS management API to automate record creation and updates; particularly useful for large deployments or frequent DNS changes. To use this with a custom domain, delegate the zone to Sunet by updating your domain's NS records to point to our nameservers.

Argo CD DNS alias

The optional Argo CD DNS alias field in the Customer Portal records the hostname you want for the Argo CD web interface. If the requested alias is argocd.example.org, create this CNAME in your authoritative DNS:

argocd.example.org. CNAME argocd.<cluster-slug>.k8s-prod.sunetvdc.se.

Replace <cluster-slug> with the slug shown in the portal. Do not use an A or AAAA record: the target is platform-managed and its addresses can change. A CNAME keeps the alias attached to the canonical service hostname.

Create and retain the CNAME before SUNET activates the alias through the Gateway and cert-manager in a future delivery step. Saving the portal field currently records metadata and requested desired state only; it does not create DNS or activate routing or TLS. Until activation is confirmed, use the canonical Argo CD hostname. The Kubernetes API remains on its canonical SUNET-managed hostname and is not affected by this field.

Routing traffic to a service

Attach an HTTPRoute to the cluster's Gateway to route a hostname to one of your Services:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: my-app
  namespace: my-app
spec:
  parentRefs:
    - name: <cluster-gateway>
      namespace: <gateway-namespace>
  hostnames:
    - app.example.org
  rules:
    - backendRefs:
        - name: my-app
          port: 80

The Gateway and its namespace are part of what Sunet provisions; check kubectl get gateway -A for their names, or ask your delivery contact.

TLS certificates with cert-manager

cert-manager is installed for you. Request a certificate by referencing an issuer, then bind the resulting secret to the Gateway listener (or reference it from your route, depending on how the Gateway is set up):

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: my-app-tls
  namespace: my-app
spec:
  secretName: my-app-tls
  dnsNames:
    - app.example.org
  issuerRef:
    name: <issuer-name>
    kind: ClusterIssuer

cert-manager validates the domain (typically over HTTP-01 through the Gateway) and writes the certificate into the my-app-tls secret, renewing it automatically before expiry. The DNS record for the hostname must already point at the load balancer for validation to succeed. Check kubectl get clusterissuer for the issuer name configured on your cluster.