Domains, Ingress & TLS

Bevor Sie starten

Sie haben einen bereitgestellten Pilotcluster, eine vertrauenswürdige kubeconfig, kubectl und Zugriff auf einen vereinbarten Namespace. Setzen Sie KUBECONFIG, CP_CONTEXT und CP_NAMESPACE über die Zugangsanleitung, bevor Sie Befehle ausführen. Die Beispiele verwenden eine POSIX-Shell und eine einzelne Zugangsdatei. Gruppierte Blöcke stoppen bei fehlenden Einstellungen, ohne Ihr Terminal zu schließen; sie stellen keine Infrastruktur bereit und vergeben keine Rechte. Mit dem Cluster verbinden →

Prüfen Sie zuerst den internen Service Ihrer Anwendung. Sie benötigen außerdem Änderungsrechte für die DNS-Einträge Ihrer Anwendung und einen von ClusterPilot bestätigten öffentlichen Zugangsweg. Ein eigener Ingress-Controller oder ein LoadBalancer-Service ist kein Standardschritt dieses Managed-Piloten.

Öffentlichen Zugangsweg vereinbaren

Der übliche HTTP-Weg lautet Domain → öffentlicher Endpunkt → Ingress/Gateway → Service → Ready-Pods. Bestätigen Sie Pilotumfang, DNS-Ziel, Routing-Klasse, zulässige Ports, Zertifikatsausstellung und -erneuerung sowie laufende Netzwerkkosten. Ein ClusterIP-Service ist intern; ein Ingress-Objekt benötigt einen vorhandenen kompatiblen Controller für den Verkehr.

• ✓
  Vor einer bestehenden Domain eine Test-Subdomain nutzen; alten DNS-Wert sowie Verantwortlichen für Wechsel und Rückweg erfassen.
• ✓
  Authentifizierung und öffentliche Pfade vereinbaren; ein gültiges TLS-Zertifikat berechtigt noch keine Anwendungsnutzer.
• ✓
  Verwaltung von Zertifikaten und Ablaufalarmen klären; automatische Ausstellung nicht voraussetzen.

Nur vereinbarte Routing-Schicht konfigurieren

Verwendet Ihr Pilot Kubernetes Ingress, führt dieses Beispiel zum Service der ersten Anwendung. Ersetzen Sie Klasse, Domain und TLS-Secret durch bestätigte Werte. Das referenzierte Secret muss bereits über den vereinbarten Zertifikatsprozess vorliegen. Bei Gateway API oder betreiberseitigem Routing nutzen Sie die Übergabekonfiguration anstelle dieser Vorlage.

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
)

Wenden Sie die Änderung erst nach Diff-Prüfung und Bestätigung des öffentlichen Zugangs an. Auch ein kleines Manifest kann kostenpflichtige Ressourcen anlegen oder Anwendungsdaten öffentlich zugänglich machen.

Jede Schicht einzeln prüfen

(
: "${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/

Vor weiteren DNS-Änderungen diagnostizieren

Bei 404 lohnt die Prüfung von Host- und Pfadregeln; bei 502/503 die Prüfung von Service-Ziel, Ready-Backends und Anwendungsantwort. Dies sind Hinweise, keine allgemeingültigen Diagnosen. Funktioniert Port-Forward, der öffentliche Endpunkt aber nicht, sichern Sie den erfolgreichen internen Befund und melden Sie die fehlerhafte Routing-Schicht. Veröffentlichen Sie keine Datenbankports und umgehen Sie TLS nicht als Abkürzung.