Die App braucht Netzwerkzugriff? Interne und externe Kubernetes-Services konfigurieren

Deine Anwendung hat drei laufende Pods, aber ihre IP-Adressen können sich ändern, wenn Kubernetes sie ersetzt. Ein Service bietet Clients eine stabile Adresse und leitet Verbindungen an passende, bereite Pods weiter. Clients verwenden den Service, statt einzelne Pod-Adressen zu verfolgen.

Verwende aks-ctlab-weu in UK West, den Namespace ct-apps und das Deployment ct-web aus dem Replikate-Trip. Starte den Cluster bei Bedarf und prüfe, ob seine drei Pods bereit sind. Behalte deinen Kubernetes-Administrationszugriff aus dem Cluster-Trip.

Wir erstellen zwei Services, die dieselben Pods auswählen:

Service	Typ	Wer verwendet ihn?
ct-web-internal	ClusterIP	Anwendungen innerhalb des Clusters über eine clusterinterne IP oder einen DNS-Namen
ct-web-public	LoadBalancer	Clients außerhalb des Clusters über eine öffentliche Azure-IP

Verwende für alle Schritte das Azure-Portal. Ein kleiner Test-Pod führt den internen HTTP-Aufruf aus und schreibt das Ergebnis in seine Logs. Der öffentliche Service stellt nur unsere NGINX-Beispielseite über HTTP bereit; für Load-Balancer-Netzwerkressourcen und öffentliche IPs können zusätzliche Kosten anfallen.

Internen Service erstellen

Öffne Kubernetes services → aks-ctlab-weu → Kubernetes resources → Services and ingresses → Create → Apply a YAML.

Füge folgendes Manifest ein und wähle Add oder Apply, je nach Anzeige im Portal:

apiVersion: v1
kind: Service
metadata:
  name: ct-web-internal
  namespace: ct-apps
spec:
  type: ClusterIP
  selector:
    app: ct-web
  ports:
    - name: http
      protocol: TCP
      port: 80
      targetPort: 80

Feld	Aufgabe
namespace: ct-apps	Erstellt den Service im selben Namespace wie die Anwendung
selector: app: ct-web	Findet Pods mit dem passenden Label in diesem Namespace
port: 80	Port, über den Clients den Service erreichen
targetPort: 80	Port, auf dem NGINX in den ausgewählten Pods lauscht

Ein Service wählt Pod-Labels aus, nicht den Namen des Deployments. Beide verwenden in diesem Lab ct-web, aber der Selektor muss mit den Labels in der Pod-Vorlage des Deployments übereinstimmen.

Aktualisiere Services and ingresses, filtere nach ct-apps und öffne ct-web-internal. Prüfe Type: ClusterIP, eine zugewiesene Cluster IP und TCP-Port 80. Eine öffentliche externe IP ist hier nicht vorgesehen. Die ClusterIP bleibt während der Lebensdauer dieses Services stabil, auch wenn Pods ersetzt werden.

Zugriff innerhalb des Clusters testen

Die interne Adresse ist kein Internet-Endpunkt. Der Aufruf ihrer ClusterIP auf deinem Laptop oder direkt aus einer normalen Cloud Shell ist deshalb kein geeigneter Test. Führe einen Client innerhalb des Clusters aus.

Öffne erneut Create → Apply a YAML und wende dieses Manifest an:

apiVersion: v1
kind: Pod
metadata:
  name: ct-service-check
  namespace: ct-apps
spec:
  restartPolicy: Never
  containers:
    - name: check
      image: busybox:1.37
      command:
        - sh
        - -c
        - wget -S -O - -T 15 http://ct-web-internal.ct-apps.svc.cluster.local
      resources:
        requests:
          cpu: 10m
          memory: 16Mi
        limits:
          cpu: 100m
          memory: 32Mi

Dieser temporäre Pod ruft mit wget den DNS-Namen des Services auf. ct-web-internal ist der Service-Name, ct-apps sein Namespace und svc.cluster.local das standardmäßige Cluster-DNS-Suffix. Eine Anwendung im selben Namespace kann einfach http://ct-web-internal verwenden.

Öffne Kubernetes resources → Workloads → Pods, filtere nach ct-apps und wähle ct-service-check → Logs. Wähle bei Bedarf den Container check aus. Erwarte HTTP/1.1 200 OK und HTML mit Welcome to nginx!.

Der Pod sollte mit Completed enden, weil er einen einzelnen Aufruf ausführt und sich anschließend beendet. Das ist für diesen Test erfolgreich, obwohl er kein dauerhaft laufender Anwendungs-Pod ist. Um den Test zu wiederholen, lösche nur ct-service-check und wende sein Manifest erneut an.

Falls die Live-Logs im Portal leer bleiben, öffne Cloud Shell → Bash und führe den gesamten folgenden Block aus. Er verbindet kubectl über deine Azure-CLI-Anmeldung erneut mit dem Lab-Cluster und ruft anschließend die Logs des Test-Containers ab, auch nachdem dieser beendet wurde:

az account set --subscription "CloudTrips TEST"

az aks get-credentials \
  --resource-group rg-cloudtrips-aks-test-weu \
  --name aks-ctlab-weu \
  --overwrite-existing

kubelogin convert-kubeconfig -l azurecli

kubectl logs ct-service-check -n ct-apps -c check

Erwarte HTTP/1.1 200 OK und Welcome to nginx! in der Ausgabe. Der Containerzustand Terminated ist nach diesem einmaligen Test normal, wenn der Grund Completed und der Exit-Code 0 ist. Ein anderer Exit-Code weist auf einen fehlgeschlagenen Test hin. Meldet die Azure CLI eine abgelaufene Anmeldung, starte Cloud Shell neu und wiederhole den Block. Das vorherige Verbinden hilft auch beim kubectl-Fehler „You must be logged in to the server“, wenn Verbindungskonfiguration oder Authentifizierung aktualisiert werden müssen.

Externen Service erstellen

Kehre zu Services and ingresses → Create → Apply a YAML zurück und wende dieses Manifest an:

apiVersion: v1
kind: Service
metadata:
  name: ct-web-public
  namespace: ct-apps
spec:
  type: LoadBalancer
  selector:
    app: ct-web
  ports:
    - name: http
      protocol: TCP
      port: 80
      targetPort: 80

Dadurch entsteht ein zweiter Zugriffsweg zu denselben drei Pods. Es werden weder ein weiteres Deployment noch zusätzliche Replikate erstellt. AKS konfiguriert Azure-Load-Balancer-Ressourcen und eine öffentliche Frontend-Adresse für diesen Service. Du musst keinen Load Balancer manuell erstellen oder selbst Port 80 auf jedem Node öffnen.

Aktualisiere die Service-Liste mit ausgewähltem Namespace ct-apps. ct-web-public sollte Type: LoadBalancer anzeigen. Seine externe IP kann zunächst Pending sein. Warte einige Minuten und aktualisiere die Ansicht, bis eine Adresse erscheint.

Kopiere die externe/öffentliche IP, nicht die ClusterIP. Öffne sie im Browser in diesem Format und ersetze den Platzhalter durch die tatsächliche IP:

http://<external-ip>/

Verwende http://, denn dieses Lab konfiguriert weder ein TLS-Zertifikat noch einen HTTPS-Listener. Die Seite Welcome to nginx! sollte erscheinen. Falls der Browser auf HTTPS wechselt, gib die HTTP-Adresse ausdrücklich ein.

Beide Adressen erreichen jetzt die Anwendung: der interne DNS-Name aus einem Pod und die öffentliche IP aus deinem Browser. Kubernetes aktualisiert die Backend-Endpunkte des Services, sobald passende Pods bereit werden oder verschwinden. Verbindungen können unterschiedliche Replikate erreichen. Identische NGINX-Seiten sehen aber gleich aus; wiederholtes Aktualisieren beweist nicht, dass jeder Pod angesprochen wurde.

Falls ein Aufruf fehlschlägt, prüfe, ob die drei ct-web-Pods bereit sind und der Service-Selektor im Namespace ct-apps genau app: ct-web lautet. Prüfe Details und Events des Services auf Bereitstellungsfehler. Ohne passende, bereite Pods hat ein Service kein gesundes Anwendungsziel.

Öffentlichen Endpunkt aufräumen

Wähle nach dem Test unter Services and ingresses den Service ct-web-public und anschließend Delete. Dadurch wird der öffentliche Service entfernt und die Bereinigung seiner Azure-Netzwerkkonfiguration angestoßen. Lösche den gemeinsam verwendeten Load Balancer des Clusters oder andere Ressourcen in der MC_-Node-Ressourcengruppe nicht manuell.

Lösche ct-service-check unter Workloads → Pods. Behalte ct-web-internal und das Deployment für weitere Übungen oder lösche auch den internen Service, wenn du ihn nicht mehr brauchst. Das Löschen eines Services lässt die Anwendungs-Pods weiterlaufen; das Löschen des Namespace ct-apps entfernt alle darin enthaltenen Ressourcen.

Für die Worker-VMs des Clusters fallen weiterhin Kosten an. Verwende zwischen Sitzungen Overview → Stop. Für verbleibende Netzwerkressourcen und Datenträger können weiterhin Kosten entstehen. Wenn du AKS nicht mehr benötigst, lösche die Ressourcengruppe des Clusters.