Freigeben über

Erstellen eines unverwalteten Ingress-Controllers

Zusammenfassung

Ein Ingress-Controller ist eine Softwarekomponente, die einen Reverse-Proxy, konfigurierbare Datenverkehrsweiterleitung und TLS-Terminierung für Kubernetes-Dienste bereitstellt. Verwenden Sie Kubernetes-Eingangsressourcen, um die Eingangsregeln und Routen für einzelne Kubernetes-Dienste zu konfigurieren. Wenn Sie einen Eingangscontroller und Eingangsregeln verwenden, können Sie eine einzelne IP-Adresse verwenden, um den Datenverkehr an mehrere Dienste in einem Kubernetes-Cluster weiterzuleiten.

Dieser Artikel beschreibt, wie Sie den NGINX-Eingangscontroller in einem AKS-Cluster (Azure Kubernetes Service) bereitstellen. Anschließend führen Sie zwei Anwendungen im AKS-Cluster aus, und auf jede Anwendung kann über die einzelne IP-Adresse zugegriffen werden.

Wichtig

Verwenden Sie für den Ingress in AKS das Anwendungsrouting-Add-On. Weitere Informationen finden Sie unter Managed nginx-Ingress mit dem Anwendungs-Routing-Add-on.

Hinweis

Zwei Open Source-Eingangscontroller für Kubernetes basieren auf NGINX: eine wird von der Kubernetes-Community (kubernetes/ingress-nginx) verwaltet, und eine wird von NGINX, Inc. (nginxinc/kubernetes-ingress) verwaltet. In diesem Artikel wird der Kubernetes-Community-Eingangscontroller verwendet.

Bevor Sie beginnen

  • 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 möglicherweise nicht mit früheren Versionen des Helmdiagramms, des NGINX-Eingangscontrollers oder kubernetes 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 einem integrierten ACR finden Sie unter Authentifizieren mit azure Container Registry von Azure Kubernetes Service.
  • Der Kubernetes-API-Integritätsendpunkt healthz wurde in Kubernetes v1.16 als veraltet markiert. Sie können diesen Endpunkt stattdessen durch die Endpunkte livez und readyz ersetzen. Unter Kubernetes-API-Endpunkte für Gesundheitsstatus erfahren Sie, 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 ermitteln. 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.

Grundlegende Konfiguration des Eingangscontrollers

Verwenden Sie Helm, um einen einfachen NGINX-Eingangscontroller 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

Um die Client-Quell-IP-Erhaltung für Anforderungen an Container in Ihrem Cluster zu aktivieren, fügen Sie --set controller.service.externalTrafficPolicy=Local dem Helm-Installationsbefehl hinzu. Die Clientquell-IP wird in der Anforderungskopfzeile unter X-Forwarded-For gespeichert. Wenn Sie einen Eingangscontroller mit aktivierter Clientquell-IP-Erhaltung verwenden, funktioniert TLS-Pass-Through 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

Legen Sie in diesem Lernprogramm service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path auf /healthz fest. Diese Einstellung bedeutet, dass der gesamte Ingress-Controller stoppt, wenn der Antwortcode für Anfragen an /healthz nicht 200 ist. Sie können den Wert in einen anderen URI ändern, um Ihr Szenario anzupassen. Sie können diesen Teil nicht löschen oder den Wert nicht zurücksetzen, sonst stoppt der Ingress-Controller. Das ingress-nginx Paket, das in diesem Lernprogramm verwendet wird und von dem offiziellen Kubernetes bereitgestellt wird, gibt bei Anfragen an /healthz immer einen 200 Antwortcode zurück. Es ist als Standard-Back-End konzipiert, sodass Benutzer schnell loslegen können, es sei denn, eine Eingangsregel überschreibt es.

Angepasste Konfiguration des Eingangscontrollers

Als Alternative zur im vorherigen Abschnitt dargestellten Basiskonfiguration wird im nächsten Schritt gezeigt, wie ein angepasster Eingangscontroller bereitgestellt wird. Sie können eine interne statische IP-Adresse oder eine dynamische öffentliche IP-Adresse verwenden.

Importieren Sie die vom Helm-Chart verwendeten Images in Ihr ACR

Um Imageversionen zu steuern, importieren Sie sie in Ihre eigene Azure-Containerregistrierung. Das Helm-Chart des NGINX Ingress-Controllers basiert auf drei Container-Images. 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 Helm, um ingress-nginx zu installieren und den Ingress-Controller zu erstellen. Der Ingress-Controller muss einem Linux-Knoten zugewiesen werden. Windows Server-Knoten sollten den Ingress-Controller nicht ausführen. Geben Sie eine Knotenauswahl mithilfe des --set nodeSelector Parameters an, um den Kubernetes-Scheduler anweisen, den NGINX-Eingangscontroller auf einem Linux-basierten Knoten auszuführen.

Stellen Sie für zusätzliche Redundanz zwei Replikate der NGINX-Eingangscontroller mithilfe des --set controller.replicaCount Parameters bereit. Um optimal von der Ausführung von Replikaten des Ingress-Controllers zu profitieren, sollten Sie sicherstellen, dass mehr als ein Knoten in Ihrem AKS-Cluster vorhanden ist.

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 Ihr AKS-Cluster keine rollenbasierte Zugriffskontrolle (Role-Based Access Control, RBAC) von Kubernetes aktiviert hat, fügen Sie --set rbac.create=false zu den Helm-Befehlen hinzu.

Hinweis

Um die Client-Quell-IP-Erhaltung für Anforderungen an Container in Ihrem Cluster zu aktivieren, fügen Sie --set controller.service.externalTrafficPolicy=Local dem Helm-Installationsbefehl hinzu. Die Clientquell-IP wird in der Anforderungskopfzeile unter X-Forwarded-For gespeichert. Wenn Sie einen Eingangscontroller mit aktivierter Clientquell-IP-Erhaltung verwenden, funktioniert TLS-Pass-Through 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 Sie einen Ingress-Controller unter Verwendung einer internen IP-Adresse

Standardmäßig verwendet ein NGINX-Eingangscontroller eine dynamische öffentliche IP-Adresse. Möglicherweise möchten Sie jedoch eine interne, private Netzwerk- und IP-Adresse verwenden. Dieser Ansatz beschränkt den Zugriff auf Ihre Dienste auf interne Benutzer, ohne externen Zugriff.

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 Ihre eigene interne IP-Adresse 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 konfigurieren, um das virtuelle Netzwerk und das Subnetz zu verwalten. 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=""

Überprüfen des Ingress-Load-Balancer-Dienstes

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

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

Wenn Sie den Kubernetes-Lastenausgleichsdienst für den NGINX-Eingangscontroller erstellen, weist er eine IP-Adresse unter EXTERNAL-IP zu, 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. Diese Antwort wird angezeigt, da Sie die Verbindung mit der externen IP einrichten müssen, die in den nächsten Abschnitten erfolgt.

Ausführen von Demoanwendungen für Eingangstests

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

  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 von Eingangsroutingregeln

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 Eingangscontrollerroutings

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 Demo-App, die hinter dem nicht verwalteten Eingangscontroller in AKS 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 Demo-App, die hinter dem nicht verwalteten Eingangscontroller in AKS ausgeführt wird.

Testen einer internen IP-Adresse

  1. Erstellen Sie einen Test-Pod und fügen Sie eine Terminal-Sitzung daran an.

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

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

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

  3. Greifen Sie auf die Adresse Ihres Kubernetes-Ingress-Controllers mithilfe von curl, z. B. http://10.224.0.42, zu. Geben Sie Ihre eigene interne IP-Adresse an, die Sie beim Bereitstellen des Eingangscontrollers verwendet haben.

    curl -L http://10.224.0.42

    Sie haben keinen Pfad mit der Adresse bereitgestellt, sodass der Eingangscontroller 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-Diagramm bereitstellen, erstellen Sie viele Kubernetes-Ressourcen. Zu diesen Ressourcen gehören Pods, Bereitstellungen und Dienste. Um diese Ressourcen zu bereinigen, können Sie entweder den gesamten Beispielnamespace löschen oder die einzelnen Ressourcen löschen.

Löschen des Beispielnamespace und aller Ressourcen

Um den gesamten Beispielnamespace zu löschen, verwenden Sie den kubectl delete-Befehl und geben Sie Ihren Namespacenamen an. Mit diesem Befehl werden alle Ressourcen im Namespace gelöscht.

kubectl delete namespace ingress-basic

Löschen einzelner Ressourcen

Alternativ können Sie die einzelnen Ressourcen löschen, die für einen differenzierteren Ansatz erstellt wurden.

  1. Listen Sie die Helm-Releases mithilfe des helm list Befehls 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 mithilfe des helm uninstall Befehls.

    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 mithilfe des kubectl delete Befehls, und geben Sie ihren Namespacenamen an.

    kubectl delete namespace ingress-basic

Nächste Schritte

Informationen zum Konfigurieren von TLS mit Ihren vorhandenen Ingress-Komponenten finden Sie unter Verwenden von TLS mit einem Ingress-Controller.

Informationen zum Konfigurieren Ihres AKS-Clusters zur Verwendung des Anwendungsroutings finden Sie unter Anwendungsrouting-Add-On.

Dieser Artikel enthält einige externe Komponenten für AKS. Weitere Informationen zu diesen Komponenten finden Sie auf den folgenden Projektseiten:

  • Last updated on