Freigeben über

Erstellen eines Eingangscontrollers

  • Artikel

Ein Eingangscontroller ist eine Softwarekomponente, die einen Reverseproxy, konfigurierbare Datenverkehrsweiterleitung und TLS-Terminierung für Kubernetes-Dienste bereitstellt. Mithilfe von Ressourcen für eingehende Kubernetes-Daten werden Eingangsregeln und Routen für einzelne Kubernetes-Dienste konfiguriert. Wenn Sie einen Eingangsdatencontroller und Eingangsregeln verwenden, kann eine einzelne IP-Adresse zum Weiterleiten von Datenverkehr an mehrere Dienste in einem Kubernetes-Cluster verwendet werden.

Dieser Artikel beschreibt, wie Sie den NGINX-Eingangscontroller in einem AKS-Cluster (Azure Kubernetes Service) bereitstellen. Es werden zwei Anwendungen im AKS-Cluster ausgeführt, die jeweils über eine einzelne IP-Adresse zugänglich sind.

Wichtig

Das Anwendungsrouting-Add-On wird für den Eingang in AKS empfohlen. Weitere Informationen finden Sie unter Verwalten von nginx-Eingang mit dem Anwendungsrouting-Add-On.

Hinweis

Es gibt zwei Open-Source-Eingangsdatencontroller für Kubernetes, die auf Nginx basieren: Ein Eingangsdatencontroller wird von der Kubernetes-Community verwaltet (kubernetes/ingress-nginx), und einer von NGINX, Inc. (nginxinc/kubernetes-ingress). In diesem Artikel wird der Eingangscontroller der Kubernetes-Community verwendet.

Voraussetzungen

  • In diesem Artikel wird helm 3 verwendet, um den NGINX-Eingangscontroller auf einer unterstützten Version von Kubernetes zu installieren. Stellen Sie sicher, dass Sie das neueste Release von Helm verwenden und auf das Helm-Repository ingress-nginx zugreifen können. Die in diesem Artikel beschriebenen Schritte sind mit früheren Versionen des Helm-Charts, des NGINX-Eingangscontrollers oder von Kubernetes möglicherweise nicht kompatibel.
  • Darüber hinaus wird in diesem Artikel vorausgesetzt, dass Sie über einen vorhandenen AKS-Cluster mit einer integrierten Azure Container Registry-Instanz (ACR) verfügen. Weitere Informationen zum Erstellen eines AKS-Clusters mit integrierter ACR-Instanz finden Sie unter Authentifizieren über Azure Container Registry aus Azure Kubernetes Service.
  • Der Integritätsendpunkt der Kubernetes-API healthz wurde in Kubernetes v1.16 veraltet. Sie können diesen Endpunkt stattdessen durch die Endpunkte livez und readyz ersetzen. Unter Kubernetes-API-Endpunkte für Integrität finden Sie Informationen, um zu bestimmen, welcher Endpunkt für Ihr Szenario verwendet werden soll.
  • Wenn Sie Azure CLI verwenden, müssen Sie für diesen Artikel Version 2.0.64 oder höher der Azure-Befehlszeilenschnittstelle ausführen. Führen Sie az --version aus, um die Version zu finden. Informationen zum Installieren oder Upgrade finden Sie unter [Installieren von Azure CLI][azure-cli-install].
  • Wenn Sie Azure PowerShell verwenden, erfordert dieser Artikel, dass Sie Azure PowerShell-Version 5.9.0 oder höher verwenden. Führen Sie Get-InstalledModule -Name Az aus, um die Version zu ermitteln. Falls Sie eine Installation oder ein Upgrade ausführen müssen, finden Sie unter Installieren von Azure PowerShell weitere Informationen.

Basiskonfiguration

Verwenden Sie Helm, um einen einfachen NGINX-Eingangsdatencontroller zu erstellen, ohne die Standardwerte anzupassen. Die folgende Konfiguration verwendet aus Gründen der Einfachheit die Standardkonfiguration. Sie können Parameter zum Anpassen der Bereitstellung hinzufügen, wie z. B. --set controller.replicaCount=3.

Hinweis

Wenn Sie die Beibehaltung der Clientquell-IP für Anforderungen an Container in Ihrem Cluster aktivieren möchten, fügen Sie dem Helm-Installationsbefehl --set controller.service.externalTrafficPolicy=Local hinzu. Die Clientquell-IP wird in der Anforderungskopfzeile unter X-Forwarded-For gespeichert. Wenn Sie einen Eingangsdatencontroller mit aktivierter Clientquell-IP-Beibehaltung verwenden, funktioniert TLS-Passthrough nicht.

NAMESPACE=ingress-basic

helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm repo update

helm install ingress-nginx ingress-nginx/ingress-nginx \
  --create-namespace \
  --namespace $NAMESPACE \
  --set controller.service.annotations."service\.beta\.kubernetes\.io/azure-load-balancer-health-probe-request-path"=/healthz \
  --set controller.service.externalTrafficPolicy=Local

Hinweis

In diesem Tutorial wird service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path auf /healthz festgelegt. Dies bedeutet Folgendes: Falls der Antwortcode der Anforderungen an /healthz nicht 200 ist, ist der gesamte Eingangsdatencontroller nicht verfügbar. Sie können den Wert in Ihrem eigenen Szenario in einen anderen URI ändern. Sie können diesen Teil oder den Wert nicht löschen, andernfalls ist der Eingangscontroller weiterhin nicht verfügbar. Das in diesem Tutorial verwendete Paket ingress-nginx, das in der offiziellen Kubernetes-Dokumentation bereitgestellt wird, gibt bei der Anforderung von /healthz immer den Antwortcode 200 zurück, da es als Standard-Back-End entworfen wurde, damit Benutzer schnell beginnen können, es sei denn, es wird von Eingangsregeln überschrieben.

Angepasste Konfiguration

Als Alternative zur Basiskonfiguration im obigen Abschnitt zeigen die nächsten Schritte, wie Sie einen benutzerdefinierten Eingangscontroller bereitstellen. Sie haben die Möglichkeit, eine interne statische IP-Adresse oder eine dynamische öffentliche IP-Adresse zu verwenden.

Importieren der vom Helm-Diagramm verwendeten Images in Ihre ACR

Sie müssen die Imageversionen in Ihre eigene Azure Container Registry-Instanz importieren, um deren Versionen zu steuern. Das Helm-Chart des NGINX-Eingangscontrollers basiert auf drei Containerimages. Verwenden Sie az acr import, um diese Images in Ihre ACR zu importieren.

REGISTRY_NAME=<REGISTRY_NAME>
SOURCE_REGISTRY=registry.k8s.io
CONTROLLER_IMAGE=ingress-nginx/controller
CONTROLLER_TAG=v1.8.1
PATCH_IMAGE=ingress-nginx/kube-webhook-certgen
PATCH_TAG=v20230407
DEFAULTBACKEND_IMAGE=defaultbackend-amd64
DEFAULTBACKEND_TAG=1.5

az acr import --name $REGISTRY_NAME --source $SOURCE_REGISTRY/$CONTROLLER_IMAGE:$CONTROLLER_TAG --image $CONTROLLER_IMAGE:$CONTROLLER_TAG
az acr import --name $REGISTRY_NAME --source $SOURCE_REGISTRY/$PATCH_IMAGE:$PATCH_TAG --image $PATCH_IMAGE:$PATCH_TAG
az acr import --name $REGISTRY_NAME --source $SOURCE_REGISTRY/$DEFAULTBACKEND_IMAGE:$DEFAULTBACKEND_TAG --image $DEFAULTBACKEND_IMAGE:$DEFAULTBACKEND_TAG

Hinweis

Zusätzlich zum Importieren von Containerimages in Ihre ACR können Sie auch Helm-Diagramme in Ihre ACR importieren. Weitere Informationen finden Sie unter Pushen und Pullen von Helm-Diagrammen in eine Azure Container Registry-Instanz.

Erstellen eines Eingangscontrollers

Verwenden Sie zum Erstellen des Eingangsdatencontrollers Helm, um ingress-nginx zu installieren. Der Eingangsdatencontroller muss auf einem Linux-Knoten geplant werden. Windows Server-Knoten dürfen nicht auf dem Eingangscontroller ausgeführt werden. Ein Knotenselektor wird mit dem Parameter --set nodeSelector angegeben, um den Kubernetes-Scheduler anzuweisen, den NGINX-Eingangscontroller auf einem Linux-basierten Knoten auszuführen.

Für zusätzliche Redundanz werden zwei Replikate der NGINX-Eingangscontroller mit dem Parameter --set controller.replicaCount bereitgestellt. Um vollständig von der Ausführung von Replikaten des Eingangscontrollers zu profitieren, stellen Sie sicher, dass sich mehr als ein Knoten im AKS-Cluster befindet.

Im folgenden Beispiel wird der Kubernetes-Namespace namens ingress-basic für die Eingangsressourcen erstellt, und es ist beabsichtigt, in diesem Namespace zu arbeiten. Geben Sie ggf. einen Namespace für Ihre eigene Umgebung an. Wenn in Ihrem AKS-Cluster keine rollenbasierte Zugriffssteuerung (RBAC) von Kubernetes aktiviert ist, fügen Sie den Helm-Befehlen --set rbac.create=false hinzu.

Hinweis

Wenn Sie die Beibehaltung der Clientquell-IP für Anforderungen an Container in Ihrem Cluster aktivieren möchten, fügen Sie dem Helm-Installationsbefehl --set controller.service.externalTrafficPolicy=Local hinzu. Die Clientquell-IP wird in der Anforderungskopfzeile unter X-Forwarded-For gespeichert. Wenn Sie einen Eingangsdatencontroller mit aktivierter Clientquell-IP-Beibehaltung verwenden, funktioniert TLS-Passthrough nicht.

# Add the ingress-nginx repository
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm repo update

# Set variable for ACR location to use for pulling images
ACR_LOGIN_SERVER=<REGISTRY_LOGIN_SERVER>

# Use Helm to deploy an NGINX ingress controller
helm install ingress-nginx ingress-nginx/ingress-nginx \
    --version 4.7.1 \
    --namespace ingress-basic \
    --create-namespace \
    --set controller.replicaCount=2 \
    --set controller.nodeSelector."kubernetes\.io/os"=linux \
    --set controller.image.registry=$ACR_LOGIN_SERVER \
    --set controller.image.image=$CONTROLLER_IMAGE \
    --set controller.image.tag=$CONTROLLER_TAG \
    --set controller.image.digest="" \
    --set controller.admissionWebhooks.patch.nodeSelector."kubernetes\.io/os"=linux \
    --set controller.service.annotations."service\.beta\.kubernetes\.io/azure-load-balancer-health-probe-request-path"=/healthz \
    --set controller.service.externalTrafficPolicy=Local \
    --set controller.admissionWebhooks.patch.image.registry=$ACR_LOGIN_SERVER \
    --set controller.admissionWebhooks.patch.image.image=$PATCH_IMAGE \
    --set controller.admissionWebhooks.patch.image.tag=$PATCH_TAG \
    --set controller.admissionWebhooks.patch.image.digest="" \
    --set defaultBackend.nodeSelector."kubernetes\.io/os"=linux \
    --set defaultBackend.image.registry=$ACR_LOGIN_SERVER \
    --set defaultBackend.image.image=$DEFAULTBACKEND_IMAGE \
    --set defaultBackend.image.tag=$DEFAULTBACKEND_TAG \
    --set defaultBackend.image.digest=""

Erstellen eines Eingangsdatencontrollers mit einer internen IP-Adresse

Standardmäßig wird ein NGINX-Eingangscontroller mit Zuweisung einer dynamischen öffentlichen IP-Adresse erstellt. Eine verbreitete Konfigurationsanforderung stellt die Verwendung eines internen privaten Netzwerks und einer IP-Adresse dar. Dieser Ansatz ermöglicht die Beschränkung des Zugriffs auf Ihre Dienste auf interne Benutzer, sodass kein externer Zugriff möglich ist.

Verwenden Sie die Parameter --set controller.service.loadBalancerIP und --set controller.service.annotations."service\.beta\.kubernetes\.io/azure-load-balancer-internal"=true, um Ihrem Eingangsdatencontroller eine interne IP-Adresse zuzuweisen. Geben Sie eine eigene interne IP-Adresse für die Verwendung für den Eingangscontroller an. Stellen Sie sicher, dass diese IP-Adresse nicht bereits in Ihrem virtuellen Netzwerk verwendet wird. Wenn Sie ein vorhandenes virtuelles Netzwerk und Subnetz verwenden, müssen Sie Ihren AKS-Cluster mit den richtigen Berechtigungen zur Verwaltung des virtuellen Netzwerks und Subnetzes konfigurieren. Weitere Informationen finden Sie unter Verwenden von kubenet-Netzwerken mit Ihren eigenen IP-Adressbereichen in Azure Kubernetes Service (AKS) oder Konfigurieren von Azure CNI-Netzwerken in Azure Kubernetes Service (AKS).

# Add the ingress-nginx repository
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm repo update

# Set variable for ACR location to use for pulling images
ACR_LOGIN_SERVER=<REGISTRY_LOGIN_SERVER>

# Use Helm to deploy an NGINX ingress controller
helm install ingress-nginx ingress-nginx/ingress-nginx \
    --version 4.7.1 \
    --namespace ingress-basic \
    --create-namespace \
    --set controller.replicaCount=2 \
    --set controller.nodeSelector."kubernetes\.io/os"=linux \
    --set controller.image.registry=$ACR_LOGIN_SERVER \
    --set controller.image.image=$CONTROLLER_IMAGE \
    --set controller.image.tag=$CONTROLLER_TAG \
    --set controller.image.digest="" \
    --set controller.admissionWebhooks.patch.nodeSelector."kubernetes\.io/os"=linux \
    --set controller.service.loadBalancerIP=10.224.0.42 \
    --set controller.service.annotations."service\.beta\.kubernetes\.io/azure-load-balancer-internal"=true \
    --set controller.service.annotations."service\.beta\.kubernetes\.io/azure-load-balancer-health-probe-request-path"=/healthz \
    --set controller.admissionWebhooks.patch.image.registry=$ACR_LOGIN_SERVER \
    --set controller.admissionWebhooks.patch.image.image=$PATCH_IMAGE \
    --set controller.admissionWebhooks.patch.image.tag=$PATCH_TAG \
    --set controller.admissionWebhooks.patch.image.digest="" \
    --set defaultBackend.nodeSelector."kubernetes\.io/os"=linux \
    --set defaultBackend.image.registry=$ACR_LOGIN_SERVER \
    --set defaultBackend.image.image=$DEFAULTBACKEND_IMAGE \
    --set defaultBackend.image.tag=$DEFAULTBACKEND_TAG \
    --set defaultBackend.image.digest=""

Prüfen Sie den Lastenausgleichsdienst

Überprüfen Sie den Lastenausgleichsdienst, indem Sie kubectl get services verwenden.

kubectl get services --namespace ingress-basic -o wide -w ingress-nginx-controller

Wird der Kubernetes-Lastenausgleichsdienst für den NGINX-Eingangsdatencontroller erstellt, wird eine IP-Adresse unter EXTERNAL-IP zugewiesen, wie in der folgenden Beispielausgabe gezeigt:

NAME                       TYPE           CLUSTER-IP    EXTERNAL-IP     PORT(S)                      AGE   SELECTOR
ingress-nginx-controller   LoadBalancer   10.0.65.205   EXTERNAL-IP     80:30957/TCP,443:32414/TCP   1m   app.kubernetes.io/component=controller,app.kubernetes.io/instance=ingress-nginx,app.kubernetes.io/name=ingress-nginx

Wenn Sie zu diesem Zeitpunkt zu der externen IP-Adresse navigieren, wird die Seite 404 angezeigt. Dies liegt daran, dass Sie die Verbindung mit der externen IP-Adresse noch einrichten müssen, was in den nächsten Abschnitten erfolgt.

Ausführen von Demoanwendungen

Um den Eingangscontroller in Aktion zu sehen, führen Sie zwei Demoanwendungen im AKS-Cluster aus. In diesem Beispiel verwenden Sie kubectl apply, um mehrere Instanzen einer einfachen Hallo Welt-Anwendung auszuführen.

  1. Erstellen Sie eine Datei aks-helloworld-one.yaml, und kopieren Sie den folgenden YAML-Beispielcode:

    apiVersion: apps/v1
kind: Deployment
metadata:
  name: aks-helloworld-one  
spec:
  replicas: 1
  selector:
    matchLabels:
      app: aks-helloworld-one
  template:
    metadata:
      labels:
        app: aks-helloworld-one
    spec:
      containers:
      - name: aks-helloworld-one
        image: mcr.microsoft.com/azuredocs/aks-helloworld:v1
        ports:
        - containerPort: 80
        env:
        - name: TITLE
          value: "Welcome to Azure Kubernetes Service (AKS)"
---
apiVersion: v1
kind: Service
metadata:
  name: aks-helloworld-one  
spec:
  type: ClusterIP
  ports:
  - port: 80
  selector:
    app: aks-helloworld-one

  2. Erstellen Sie eine Datei aks-helloworld-two.yaml, und kopieren Sie den folgenden YAML-Beispielcode:

    apiVersion: apps/v1
kind: Deployment
metadata:
  name: aks-helloworld-two  
spec:
  replicas: 1
  selector:
    matchLabels:
      app: aks-helloworld-two
  template:
    metadata:
      labels:
        app: aks-helloworld-two
    spec:
      containers:
      - name: aks-helloworld-two
        image: mcr.microsoft.com/azuredocs/aks-helloworld:v1
        ports:
        - containerPort: 80
        env:
        - name: TITLE
          value: "AKS Ingress Demo"
---
apiVersion: v1
kind: Service
metadata:
  name: aks-helloworld-two  
spec:
  type: ClusterIP
  ports:
  - port: 80
  selector:
    app: aks-helloworld-two

  3. Führen Sie die beiden Demoanwendungen mit kubectl apply aus:

    kubectl apply -f aks-helloworld-one.yaml --namespace ingress-basic
kubectl apply -f aks-helloworld-two.yaml --namespace ingress-basic

Erstellen einer Eingangsroute

Beide Anwendungen werden jetzt in Ihrem Kubernetes-Cluster ausgeführt. Zum Weiterleiten von Datenverkehr an die einzelnen Anwendungen erstellen Sie eine Kubernetes-Eingangsressource. Die Eingangsressource konfiguriert Regeln, die den Datenverkehr an eine der beiden Anwendungen weiterleiten.

Im folgenden Beispiel wird der Datenverkehr an EXTERNAL_IP/hello-world-one an den Dienst mit dem Namen aks-helloworld-one weitergeleitet. Datenverkehr an EXTERNAL_IP/hello-world-two wird an den Dienst aks-helloworld-two weitergeleitet. Datenverkehr an EXTERNAL_IP/static wird für statische Ressourcen an den Dienst mit dem Namen aks-helloworld-one weitergeleitet.

  1. Erstellen Sie eine Datei mit dem Namen hello-world-ingress.yaml, und fügen Sie den folgenden YAML-Beispielcode ein:

    apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: hello-world-ingress
  annotations:
    nginx.ingress.kubernetes.io/ssl-redirect: "false"
    nginx.ingress.kubernetes.io/use-regex: "true"
    nginx.ingress.kubernetes.io/rewrite-target: /$2
spec:
  ingressClassName: nginx
  rules:
  - http:
      paths:
      - path: /hello-world-one(/|$)(.*)
        pathType: Prefix
        backend:
          service:
            name: aks-helloworld-one
            port:
              number: 80
      - path: /hello-world-two(/|$)(.*)
        pathType: Prefix
        backend:
          service:
            name: aks-helloworld-two
            port:
              number: 80
      - path: /(.*)
        pathType: Prefix
        backend:
          service:
            name: aks-helloworld-one
            port:
              number: 80
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: hello-world-ingress-static
  annotations:
    nginx.ingress.kubernetes.io/ssl-redirect: "false"
    nginx.ingress.kubernetes.io/rewrite-target: /static/$2
spec:
  ingressClassName: nginx
  rules:
  - http:
      paths:
      - path: /static(/|$)(.*)
        pathType: Prefix
        backend:
          service:
            name: aks-helloworld-one
            port: 
              number: 80

  2. Erstellen Sie die Eingangsressource mit dem Befehl kubectl apply.

    kubectl apply -f hello-world-ingress.yaml --namespace ingress-basic

Testen des Eingangscontrollers

Navigieren Sie zu den beiden Anwendungen, um die Routen für den Eingangscontroller zu testen. Öffnen Sie in einem Webbrowser die IP-Adresse Ihres NGINX-Eingangscontrollers, z. B. EXTERNAL_IP. Die erste Demoanwendung wird im Webbrowser angezeigt, wie im folgenden Beispiel gezeigt:

Screenshot der ersten App, die hinter dem Eingangscontroller ausgeführt wird.

Fügen Sie nun den Pfad /hello-world-two der IP-Adresse hinzu, z. B. EXTERNAL_IP/hello-world-two. Die zweite Demoanwendung mit dem benutzerdefinierten Titel wird angezeigt:

Screenshot der zweiten App, die hinter dem Eingangscontroller ausgeführt wird.

Testen einer internen IP-Adresse

  1. Erstellen Sie einen Testpod, und fügen Sie an diesen eine Terminalsitzung an.

    kubectl run -it --rm aks-ingress-test --image=mcr.microsoft.com/dotnet/runtime-deps:6.0 --namespace ingress-basic

  2. Installieren Sie curl mittels apt-get im Pod.

    apt-get update && apt-get install -y curl

  3. Greifen Sie nun mit curl auf die Adresse des Kubernetes-Eingangsdatencontrollers zu, beispielsweise http://10.224.0.42. Geben Sie Ihre eigene interne IP-Adresse an, die Sie beim Bereitstellen des Eingangscontrollers verwendet haben.

    curl -L http://10.224.0.42

    Die Adresse wurde ohne Pfad angegeben, sodass der Eingangsdatencontroller standardmäßig die Route / verwendet. Die erste Demoanwendung wird zurückgegeben, wie in der folgenden verkürzten Beispielausgabe gezeigt:

    <!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
    <link rel="stylesheet" type="text/css" href="/static/default.css">
    <title>Welcome to Azure Kubernetes Service (AKS)</title>
[...]

  4. Fügen Sie den Pfad /hello-world-two der Adresse hinzu, beispielsweise http://10.224.0.42/hello-world-two.

    curl -L -k http://10.224.0.42/hello-world-two

    Die zweite Demoanwendung wird mit dem benutzerdefinierten Titel zurückgegeben, wie in der folgenden verkürzten Beispielausgabe gezeigt:

    <!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
    <link rel="stylesheet" type="text/css" href="/static/default.css">
    <title>AKS Ingress Demo</title>
[...]

Bereinigen von Ressourcen

In diesem Artikel wird Helm verwendet, um die Eingangskomponenten und die Beispiel-Apps zu installieren. Wenn Sie ein Helm-Chart bereitstellen, werden zahlreiche Kubernetes-Ressourcen erstellt. Zu diesen Ressourcen gehören Pods, Bereitstellungen und Dienste. Sie können zur Bereinigung der Ressourcen entweder den gesamten Beispielnamespace oder die einzelnen Ressourcen löschen.

Löschen des Beispielnamespace und aller Ressourcen

Verwenden Sie den kubectl delete-Befehl mit dem Namespacenamen, um den gesamten Beispielnamespace zu löschen. Alle Ressourcen im Namespace werden gelöscht.

kubectl delete namespace ingress-basic

Löschen einzelner Ressourcen

Mehr Kontrolle bietet eine andere Vorgehensweise, bei der Sie einzelne Ressourcen löschen.

  1. Listen Sie mit dem Befehl helm list die Helm-Releases auf.

    helm list --namespace ingress-basic

    Suchen Sie nach Diagrammen mit den Namen ingress-nginx und aks-helloworld, wie in der folgenden Beispielausgabe gezeigt:

    NAME                    NAMESPACE       REVISION        UPDATED                                 STATUS          CHART                   APP VERSION
ingress-nginx           ingress-basic   1               2020-01-06 19:55:46.358275 -0600 CST    deployed        nginx-ingress-1.27.1    0.26.1

  2. Deinstallieren Sie die Versionen mit dem Befehl helm uninstall.

    helm uninstall ingress-nginx --namespace ingress-basic

  3. Entfernen Sie die beiden Beispielanwendungen.

    kubectl delete -f aks-helloworld-one.yaml --namespace ingress-basic
kubectl delete -f aks-helloworld-two.yaml --namespace ingress-basic

  4. Entfernen Sie die Eingangsroute, die Datenverkehr an die Beispiel-Apps weitergeleitet hat.

    kubectl delete -f hello-world-ingress.yaml

  5. Löschen Sie den Namespace mit dem kubectl delete-Befehl und geben Sie Ihren Namespacenamen an.

    kubectl delete namespace ingress-basic

Nächste Schritte

Informationen zum Konfigurieren von TLS mit ihren vorhandenen Eingangskomponenten finden Sie unter Verwenden von TLS mit einem Eingangsdatencontroller.

Informationen zum Konfigurieren Ihres AKS-Clusters für die Verwendung von HTTP-Anwendungsrouting finden Sie unter Aktivieren des HTTP-Anwendungsrouting-Add-Ons.

In diesem Artikel werden einige externe Komponenten in AKS berücksichtigt. Weitere Informationen zu diesen Komponenten finden Sie auf den folgenden Projektseiten:

Kontaktieren Sie uns für Hilfe

Wenn Sie Fragen haben oder Hilfe mit Ihren Azure-Gutschriften benötigen, dann erstellen Sie beim Azure-Support eine Support-Anforderung oder fragen Sie den Azure Community-Support. Sie können auch Produktfeedback an die Azure Feedback Community senden.