Domains, ingress & TLS

Before you start

You have a provided pilot cluster, a trusted kubeconfig, kubectl and access to an agreed namespace. Set KUBECONFIG, CP_CONTEXT and CP_NAMESPACE using the access guide before running the commands. The examples use a POSIX shell and a single access file. Grouped blocks stop at missing settings without closing your terminal; they do not provision infrastructure or grant permissions. Connect to your cluster →

First verify your application's internal Service. You also need permission to change the application's DNS records and a public exposure method confirmed by ClusterPilot. Installing your own ingress controller or creating a LoadBalancer Service is not a default step in this managed pilot.

Agree the public entry point

The usual HTTP path is domain → public endpoint → ingress/gateway → Service → Ready Pods. Confirm which parts are provided in your pilot, the DNS target, routing class, permitted ports, certificate issuer/renewal responsibility and any recurring network costs. A ClusterIP Service is internal; an Ingress object needs an existing compatible controller to handle traffic.

• ✓
  Use a test subdomain before moving a live domain; record the old DNS value and cutover/rollback owner.
• ✓
  Agree authentication and allowed public paths; a valid TLS certificate does not authorize application users.
• ✓
  Confirm how certificates and their expiry alerts are handled; do not assume automated issuance.

Configure only the agreed routing layer

If your pilot uses Kubernetes Ingress, this example routes to the first-application Service. Replace the class, domain and TLS Secret name with confirmed values. The referenced Secret must already be provided through the agreed certificate process. For Gateway API or operator-managed routing, use the configuration supplied at handover instead of applying this template.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: cloud-demo
spec:
  ingressClassName: REPLACE_WITH_AGREED_CLASS
  tls:
    - hosts:
        - app.example.com
      secretName: REPLACE_WITH_AGREED_TLS_SECRET
  rules:
    - host: app.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: cloud-demo
                port:
                  number: 80

(
: "${KUBECONFIG:?Set KUBECONFIG from your handover}"
: "${CP_CONTEXT:?Set CP_CONTEXT from your handover}"
: "${CP_NAMESPACE:?Set CP_NAMESPACE from your handover}"
case "$CP_CONTEXT:$CP_NAMESPACE" in
  YOUR_*|*:YOUR_*) printf '%s\n' 'Replace the YOUR_ context and namespace placeholders first.' >&2; exit 1 ;;
esac
kubectl --kubeconfig="$KUBECONFIG" --context="$CP_CONTEXT" --namespace="$CP_NAMESPACE" apply --dry-run=server -f cloud-demo-ingress.yaml
kubectl --kubeconfig="$KUBECONFIG" --context="$CP_CONTEXT" --namespace="$CP_NAMESPACE" diff -f cloud-demo-ingress.yaml
)

Apply only after reviewing the diff and confirming the public exposure. Enabling access can create a billable resource or expose application data even when the manifest is small.

Check each layer independently

(
: "${KUBECONFIG:?Set KUBECONFIG from your handover}"
: "${CP_CONTEXT:?Set CP_CONTEXT from your handover}"
: "${CP_NAMESPACE:?Set CP_NAMESPACE from your handover}"
case "$CP_CONTEXT:$CP_NAMESPACE" in
  YOUR_*|*:YOUR_*) printf '%s\n' 'Replace the YOUR_ context and namespace placeholders first.' >&2; exit 1 ;;
esac
kubectl --kubeconfig="$KUBECONFIG" --context="$CP_CONTEXT" --namespace="$CP_NAMESPACE" get service/cloud-demo ingress/cloud-demo
kubectl --kubeconfig="$KUBECONFIG" --context="$CP_CONTEXT" --namespace="$CP_NAMESPACE" get endpointslices -l kubernetes.io/service-name=cloud-demo
kubectl --kubeconfig="$KUBECONFIG" --context="$CP_CONTEXT" --namespace="$CP_NAMESPACE" describe ingress cloud-demo
)

nslookup app.example.com
curl --head --show-error https://app.example.com/

Diagnose before changing DNS again

A 404 often warrants checking host/path rules; a 502/503 warrants checking the Service target, Ready backends and application response. These are clues, not universal diagnoses. If local port-forward works but the public endpoint does not, preserve the successful internal evidence and escalate the failing routing layer. Do not publish database ports or bypass TLS as a shortcut.