HTTP-Anfragen brauchen Routing? Anfragen an Anwendungs-Services weiterleiten

Deine Website und Bestellanwendung benötigen einen gemeinsamen öffentlichen Einstiegspunkt. Der URL-Pfad soll bestimmen, welche Anwendung eine Anfrage erhält. Ein Kubernetes-Service verbindet Clients mit Pods, wählt aber keine Anwendung anhand eines HTTP-Pfads aus. Ein Gateway kann diese Entscheidung treffen.

In diesem Lab erreicht http:/// die vorhandene Webanwendung und http:///orders eine separate Bestellanwendung. Beide verwenden interne ClusterIP-Services hinter dem Gateway.

Ressource	Aufgabe
GatewayClass	Bestimmt die Controller-Implementierung, die Gateways verwaltet; hier approuting-istio
Gateway	Definiert den Einstiegspunkt und den HTTP-Listener auf Port 80
HTTPRoute	Prüft Anfragepfade und wählt den Ziel-Service
Service	Wählt die bereiten Anwendungs-Pods aus

Die Anfrage folgt dem Weg öffentliches Gateway → HTTPRoute-Regel → Service-Backend → Anwendungs-Pod. Dieses Kubernetes-Gateway gehört zum AKS Application Routing. Du erstellst keinen separaten Azure-API-Management-Dienst.

Verwende aks-ctlab-weu in UK West, den Namespace ct-apps, das bereite Deployment ct-web und ct-web-internal aus den vorherigen Trips. Starte den Cluster bei Bedarf. Du benötigst Berechtigungen zum Aktualisieren der AKS-Ressource und deinen Kubernetes-Administrationszugriff.

Dieses Lab verwendet die Gateway API. Der Support für Managed NGINX Ingress endet im November 2026; deshalb nutzt diese neue Übung den unterstützten Nachfolger. Deine NGINX-Anwendungscontainer sind Webserver und von dieser Einstellung des Ingress-Controllers unabhängig.

Gateway-API-Routing aktivieren

Verwende für diese Add-on-Einstellung Azure Cloud Shell → Bash: Die dokumentierte Aktivierung erfolgt über die Azure CLI. Anschließend wenden wir die Anwendungs- und Routing-Manifeste im Portal an. Das Update ändert deinen vorhandenen Cluster und erstellt ihn nicht neu.

Die Azure CLI muss Version 2.86.0 oder neuer haben. Prüfe die Version mit dem folgenden Befehl, bevor du az aks update ausführst. Ist sie älter, verwende eine aktualisierte Azure-CLI-Umgebung. Ersetze diesen Schritt nicht durch die ältere NGINX-Application-Routing-Option.

az account set --subscription "CloudTrips TEST"
az version --query '"azure-cli"' -o tsv

az aks update \
  --resource-group rg-cloudtrips-aks-test-weu \
  --name aks-ctlab-weu \
  --enable-gateway-api \
  --enable-app-routing-istio

az aks get-credentials \
  --resource-group rg-cloudtrips-aks-test-weu \
  --name aks-ctlab-weu \
  --overwrite-existing
kubelogin convert-kubeconfig -l azurecli
kubectl get gatewayclass approuting-istio

Warte, bis das Update abgeschlossen ist. Der letzte Befehl sollte approuting-istio mit ACCEPTED: True anzeigen. Falls du später eine neue Cloud-Shell-Sitzung öffnest, wiederhole vor kubectl die Befehle az account set, az aks get-credentials und kubelogin.

Diese Schritte setzen voraus, dass das separate Istio-Service-Mesh-Add-on im Lab-Cluster nicht aktiviert ist. Beide Implementierungen können nicht gleichzeitig aktiviert sein. Entferne für diese Übung kein bestehendes Mesh aus einem gemeinsam genutzten Cluster.

Die Routing-Komponenten benötigen Node-Kapazität. Das Gateway erstellt öffentliche Load-Balancer-Netzwerkressourcen, für die Kosten anfallen können. Der Beispielendpunkt verwendet HTTP ohne Authentifizierung; beschränke ihn auf die Demonstrationsseiten.

Zweite Anwendung mit Service hinzufügen

Öffne im Portal aks-ctlab-weu → Kubernetes resources → Services and ingresses → Create → Apply a YAML. Füge das vollständige folgende Manifest ein und wähle Add oder Apply:

apiVersion: v1
kind: ConfigMap
metadata:
  name: ct-orders-page
  namespace: ct-apps
data:
  index.html: |
    <html><body><h1>CloudTrips Orders</h1><p>Response from the orders application.</p></body></html>
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: ct-orders
  namespace: ct-apps
spec:
  replicas: 2
  selector:
    matchLabels:
      app: ct-orders
  template:
    metadata:
      labels:
        app: ct-orders
    spec:
      nodeSelector:
        kubernetes.io/os: linux
      containers:
        - name: nginx
          image: nginx:stable-alpine
          ports:
            - containerPort: 80
          resources:
            requests:
              cpu: 100m
              memory: 64Mi
            limits:
              cpu: 250m
              memory: 128Mi
          readinessProbe:
            httpGet:
              path: /
              port: 80
            initialDelaySeconds: 2
            periodSeconds: 5
          volumeMounts:
            - name: page
              mountPath: /usr/share/nginx/html
              readOnly: true
      volumes:
        - name: page
          configMap:
            name: ct-orders-page
---
apiVersion: v1
kind: Service
metadata:
  name: ct-orders
  namespace: ct-apps
spec:
  type: ClusterIP
  selector:
    app: ct-orders
  ports:
    - name: http
      port: 80
      targetPort: 80

Eine ConfigMap ist ein Kubernetes-Objekt, das nicht vertrauliche Konfiguration oder Text getrennt vom Anwendungs-Image speichert. Pods können den Inhalt als Umgebungsvariablen oder Dateien verwenden. Hier speichert ct-orders-page die Datei index.html. Das Deployment bindet sie als /usr/share/nginx/html/index.html in jeden NGINX-Container ein. So stellen wir unsere eigene Seite bereit, ohne ein neues NGINX-Image zu bauen. Die ConfigMap speichert nur den Inhalt; NGINX betreibt den Webserver und liefert die Seite aus.

Beide Orders-Pods zeigen deshalb CloudTrips Orders statt der NGINX-Standardseite der ursprünglichen Anwendung. Dies ist Beispielinhalt, kein Backend zur Bestellverarbeitung.

Filtere unter Workloads → Deployments nach ct-apps und warte, bis ct-orders zwei bereite Replikate hat. Prüfe unter Services and ingresses, ob ct-orders und ct-web-internal als ClusterIP-Services auf Port 80 vorhanden sind.

Gateway und Route erstellen

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

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: ct-http
  namespace: ct-apps
spec:
  gatewayClassName: approuting-istio
  listeners:
    - name: http
      protocol: HTTP
      port: 80
      allowedRoutes:
        namespaces:
          from: Same
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: ct-app-routes
  namespace: ct-apps
spec:
  parentRefs:
    - name: ct-http
      sectionName: http
  rules:
    - matches:
        - path:
            type: Exact
            value: /orders
      filters:
        - type: URLRewrite
          urlRewrite:
            path:
              type: ReplaceFullPath
              replaceFullPath: /
      backendRefs:
        - name: ct-orders
          port: 80
    - matches:
        - path:
            type: PathPrefix
            value: /
      backendRefs:
        - name: ct-web-internal
          port: 80

Das Gateway nimmt HTTP auf Port 80 an und erlaubt Routen aus seinem eigenen Namespace. Die HTTPRoute verbindet sich mit seinem Listener http. Es ist keine Hostname-Einschränkung konfiguriert. Du kannst daher über die öffentliche IP testen, ohne Domain oder DNS-Konfiguration.

Der exakte Pfad /orders wählt ct-orders aus. Das Gateway schreibt diesen Pfad vor dem Weiterleiten in / um, weil der Beispielserver seine Seite unter / bereitstellt. In der Browseradresse bleibt /orders stehen: Dies ist eine interne Umschreibung, keine Weiterleitung des Browsers.

Die Präfixregel / sendet andere Pfade an ct-web-internal. Der exakte Treffer /orders hat Vorrang vor dem allgemeineren Präfixtreffer. Verwende für dieses Beispiel /orders ohne abschließenden Schrägstrich; /orders/ stimmt nicht mit der exakten Regel überein.

Routing-Status prüfen

Suche im Portal unter Kubernetes resources → Custom resources nach den Ressourcen Gateway und HTTPRoute in ct-apps und prüfe deren Status/YAML. Gateway-Ressourcen erscheinen möglicherweise nicht in der älteren Liste Ingresses.

Für eine ausdrückliche Statusprüfung führe in deiner verbundenen Cloud Shell → Bash Folgendes aus:

kubectl wait --for=condition=Programmed gateway/ct-http \
  -n ct-apps --timeout=300s
kubectl get gateway ct-http -n ct-apps
kubectl describe httproute ct-app-routes -n ct-apps

Erwarte Programmed=True beim Gateway sowie Accepted=True und ResolvedRefs=True im Parent-Status der Route. ResolvedRefs bestätigt, dass referenzierte Ressourcen wie Services aufgelöst werden können. Es beweist nicht, dass deren Anwendungs-Pods gesund sind.

Das Gateway erhält eine eigene öffentliche Adresse. Der erzeugte LoadBalancer-Service unter Services and ingresses heißt normalerweise ct-http-approuting-istio. Warte, falls seine externe IP noch aussteht. Verwende die Gateway-Adresse für diesen Trip. Die frühere Adresse von ct-web-public umgeht diese Routing-Regeln.

Beide Pfade testen

Kopiere die Adresse aus dem Gateway-Status oder dem erzeugten Service. Öffne diese beiden URLs im Browser und ersetze den Platzhalter durch die tatsächliche IP:

http://<gateway-ip>/
http://<gateway-ip>/orders

Anfrage	Erwartete Antwort
/	Welcome to nginx! von der vorhandenen Webanwendung
/orders	CloudTrips Orders von der zweiten Anwendung

Verwende HTTP, nicht HTTPS; dieser Listener hat keine TLS-Konfiguration. Alternativ kannst du aus Cloud Shell testen:

GATEWAY_IP=$(kubectl get gateway ct-http -n ct-apps \
  -o jsonpath='{.status.addresses[0].value}')
curl -i --max-time 30 "http://$GATEWAY_IP/"
curl -i --max-time 30 "http://$GATEWAY_IP/orders"

Beide Antworten sollten den HTTP-Status 200, aber unterschiedliche Seiteninhalte haben. Das zeigt, dass ein gemeinsamer Einstiegspunkt Anfragen anhand ihrer Pfade an zwei Anwendungs-Services weiterleitet.

Falls das Gateway bereit ist, du aber einen Fehler erhältst, prüfe die Bedingungen der Route und die Bereitschaft der Pods beider Deployments. Ein Aufruf von /orders/ statt /orders folgt der allgemeinen Webroute und kann einen NGINX-404-Fehler liefern, weil dieser Dateipfad nicht existiert.

Routing-Lab behalten oder entfernen

Falls ct-web-public aus dem Services-Trip noch existiert, lösche diesen Service im Portal, sobald du den direkten Zugriff nicht mehr benötigst. Behalte ct-web-internal: Die HTTPRoute verwendet ihn.

Um dieses Routing-Lab zu entfernen, lösche unter Custom resources zuerst ct-app-routes und anschließend ct-http in ct-apps. Das Löschen des Gateways stößt die Bereinigung seiner erzeugten Proxy- und Service-Ressourcen an. Prüfe vor dem Deaktivieren des Add-ons, ob sie verschwunden sind. Entferne den gemeinsam verwendeten Azure Load Balancer des Clusters nicht manuell.

Lösche das Deployment ct-orders unter Workloads, seinen Service ct-orders unter Services and ingresses und ct-orders-page unter Configuration → Config maps. Behalte das ursprüngliche Web-Deployment und seinen internen Service für weitere Übungen.

Wenn kein anderes Gateway dieses Add-on verwendet, deaktiviere seine Routing-Implementierung in Cloud Shell:

az aks update \
  --resource-group rg-cloudtrips-aks-test-weu \
  --name aks-ctlab-weu \
  --disable-app-routing-istio

Die verwalteten Gateway-API-Ressourcendefinitionen können installiert bleiben. Der AKS-Cluster existiert weiterhin und verursacht Kosten. Stoppe ihn zwischen Sitzungen oder lösche seine Lab-Ressourcengruppe, wenn du AKS nicht mehr benötigst.