Verwenden von TLS mit einem HTTPS-Eingangsdatencontroller in Azure Kubernetes Service (AKS)

Das TLS-Protokoll (Transport Layer Security) verwendet Zertifikate, um die Sicherheit für Kommunikation, Verschlüsselung, Authentifizierung und Integrität zu gewährleisten. Die Verwendung von TLS mit einem Eingangsdatencontroller in AKS ermöglicht es Ihnen, die Kommunikation zwischen Ihren Anwendungen zu sichern und gleichzeitig die Vorteile eines Eingangsdatencontrollers zu nutzen.

Sie können eigene Zertifikate mitbringen und mit dem Secrets Store CSI-Treiber integrieren. Alternativ können Sie auch cert-manager verwenden, um automatisch Let's Encrypt-Zertifikate zu generieren und zu konfigurieren. Im AKS-Cluster werden zwei Anwendungen 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.

Wichtig

Microsoft verwaltet oder unterstützt cert-manager und damit in Zusammenhang stehende Probleme nicht. Informationen zu Problemen mit cert-manager finden Sie in der Dokumentation unter dem Thema zur Problembehandlung von cert-manager.

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 Eingangsdatencontroller der Kubernetes-Community verwendet.

Voraussetzungen

  • Ferner wird in diesem Artikel davon ausgegangen, dass Sie einen Eingangsdatencontroller und Anwendungen eingerichtet haben. Wenn Sie einen Eingangsdatencontroller oder Beispielanwendungen benötigen, finden Sie weitere Informationen unter Erstellen eines Eingangscontrollers.

  • In diesem Artikel wird der NGINX-Eingangscontroller mithilfe von Helm 3 auf einer unterstützten Version von Kubernetes installiert. Stellen Sie sicher, dass Sie das neueste Release von Helm verwenden und auf die Helm-Repositorys ingress-nginx und jetstack 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 einem integrierten ACR finden Sie unter Authentifizieren mit ACR über AKS.

  • 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 Durchführen einer Installation oder eines Upgrades finden Sie bei Bedarf unter Installieren der Azure CLI.

  • 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.

Verwenden von TLS mit eigenen Zertifikaten mit Secrets Store CSI-Treiber

Um TLS mit Ihren eigenen Zertifikaten mit dem Secrets Store CSI-Treiber zu verwenden, benötigen Sie einen AKS-Cluster mit konfiguriertem Secrets Store CSI-Treiber und eine Azure Key Vault-Instanz.

Weitere Informationen finden Sie unter Einrichten des Secrets Store CSI-Treibers zum Aktivieren des NGINX-Eingangsdatencontrollers mit TLS.

Verwenden von TLS mit Let's Encrypt-Zertifikaten

Um TLS mit Let's Encrypt-Zertifikaten zu verwenden, stellen Sie cert-manager zum automatischen Generieren und Konfigurieren von Let's Encrypt-Zertifikaten bereit.

Importieren der vom Helm-Diagramm verwendeten Images in Ihre ACR-Instanz

  • Verwenden Sie az acr import, um die folgenden Images in Ihre ACR-Instanz zu importieren.

    REGISTRY_NAME=<REGISTRY_NAME>
    CERT_MANAGER_REGISTRY=quay.io
    CERT_MANAGER_TAG=v1.8.0
    CERT_MANAGER_IMAGE_CONTROLLER=jetstack/cert-manager-controller
    CERT_MANAGER_IMAGE_WEBHOOK=jetstack/cert-manager-webhook
    CERT_MANAGER_IMAGE_CAINJECTOR=jetstack/cert-manager-cainjector
    
    az acr import --name $REGISTRY_NAME --source $CERT_MANAGER_REGISTRY/$CERT_MANAGER_IMAGE_CONTROLLER:$CERT_MANAGER_TAG --image $CERT_MANAGER_IMAGE_CONTROLLER:$CERT_MANAGER_TAG
    az acr import --name $REGISTRY_NAME --source $CERT_MANAGER_REGISTRY/$CERT_MANAGER_IMAGE_WEBHOOK:$CERT_MANAGER_TAG --image $CERT_MANAGER_IMAGE_WEBHOOK:$CERT_MANAGER_TAG
    az acr import --name $REGISTRY_NAME --source $CERT_MANAGER_REGISTRY/$CERT_MANAGER_IMAGE_CAINJECTOR:$CERT_MANAGER_TAG --image $CERT_MANAGER_IMAGE_CAINJECTOR:$CERT_MANAGER_TAG
    

Hinweis

Sie können Helm-Diagramme auch in Ihre ACR importieren. Weitere Informationen finden Sie unter Pushen und Pullen von Helm-Diagrammen in eine ACR.

Konfigurationsoptionen für den Eingangsdatencontroller

Sie können Ihren NGINX-Eingangsdatencontroller entweder mithilfe einer statischen öffentlichen IP-Adresse oder einer dynamischen öffentlichen IP-Adresse konfigurieren. Wenn Sie eine benutzerdefinierte Domäne verwenden, müssen Sie Ihrer DNS-Zone einen A-Eintrag hinzufügen. Wenn Sie keine benutzerdefinierte Domäne verwenden, können Sie einen vollqualifizierten Domänennamen (FQDN) für die IP-Adresse des Eingangsdatencontrollers konfigurieren.

Erstellen einer statischen oder dynamischen öffentlichen IP-Adresse

Verwenden einer statischen öffentlichen IP-Adresse

Sie können Ihren Eingangsdatencontroller mit einer statischen öffentlichen IP-Adresse konfigurieren. Die statische öffentliche IP-Adresse wird beibehalten, wenn der Eingangsdatencontroller gelöscht wird. Die IP-Adresse bleibt nicht erhalten, wenn Sie Ihren AKS-Cluster löschen.

Wenn Sie Ihren Eingangsdatencontroller aktualisieren, müssen Sie einen Parameter an den Helm-Release übergeben. So können Sie sicherstellen, dass der Dienst des Eingangsdatencontrollers auf den Lastenausgleich aufmerksam gemacht wird, der ihm zugeordnet wird. Damit die HTTPS-Zertifikate ordnungsgemäß funktionieren, wird eine DNS-Bezeichnung verwendet, um einen vollqualifizierten Domänennamen (FQDN) für die IP-Adresse des Eingangsdatencontrollers zu konfigurieren.

  1. Rufen Sie den Namen der Ressourcengruppe des AKS-Clusters mit dem Befehl az aks show ab.

    az aks show --resource-group myResourceGroup --name myAKSCluster --query nodeResourceGroup -o tsv
    
  2. Erstellen Sie eine öffentliche IP-Adresse mit der statischen Zuteilungsmethode und verwenden Sie den Befehl az network public-ip create. Im folgenden Beispiel wird in der AKS-Clusterressourcengruppe, die Sie im vorherigen Schritt abgerufen haben, eine öffentliche IP-Adresse mit dem Namen myAKSPublicIP erstellt.

    az network public-ip create --resource-group MC_myResourceGroup_myAKSCluster_eastus --name myAKSPublicIP --sku Standard --allocation-method static --query publicIp.ipAddress -o tsv
    

Hinweis

Alternativ können Sie eine IP-Adresse in einer anderen Ressourcengruppe erstellen, die Sie separat von Ihrem AKS-Cluster verwalten können. Wenn Sie eine IP-Adresse in einer anderen Ressourcengruppe erstellen, stellen Sie sicher, dass Folgendes gewährleistet ist:

  • Die vom AKS-Cluster verwendete Clusteridentität verfügt über delegierte Berechtigungen für die andere Ressourcengruppe, z. B. Netzwerkmitwirkender.
  • Fügen Sie den Parameter --set controller.service.annotations."service\.beta\.kubernetes\.io/azure-load-balancer-resource-group"="<RESOURCE_GROUP>" hinzu. Ersetzen Sie <RESOURCE_GROUP> durch den Namen der Ressourcengruppe, in der sich die IP-Adresse befindet.
  1. Fügen Sie den Parameter --set controller.service.annotations."service\.beta\.kubernetes\.io/azure-dns-label-name"="<DNS_LABEL>" hinzu. Die DNS-Bezeichnung kann festgelegt werden, wenn der Eingangsdatencontroller zum ersten Mal bereitgestellt wird, oder sie kann später konfiguriert werden.

  2. Fügen Sie den Parameter --set controller.service.loadBalancerIP="<STATIC_IP>" hinzu. Geben Sie Ihre eigene öffentliche IP-Adresse an, die im vorherigen Schritt erstellt wurde.

    DNS_LABEL="<DNS_LABEL>"
    NAMESPACE="ingress-basic"
    STATIC_IP=<STATIC_IP>
    
    helm upgrade ingress-nginx ingress-nginx/ingress-nginx \
      --namespace $NAMESPACE \
      --set controller.service.annotations."service\.beta\.kubernetes\.io/azure-dns-label-name"=$DNS_LABEL \
      --set controller.service.loadBalancerIP=$STATIC_IP \
      --set controller.service.annotations."service\.beta\.kubernetes\.io/azure-load-balancer-health-probe-request-path"=/healthz
    

Weitere Informationen finden Sie unter Verwenden einer statischen öffentlichen IP-Adresse und einer DNS-Bezeichnung mit dem AKS-Lastenausgleich.

Verwenden einer dynamischen öffentlichen IP-Adresse

Bei der Erstellung wird eine öffentliche Azure-IP-Adresse für Ihren Eingangsdatencontroller angelegt. Die öffentliche IP-Adresse ist für die Lebensdauer Ihres Eingangsdatencontrollers statisch. Die öffentliche IP-Adresse wird nicht beibehalten, wenn der Eingangsdatencontroller gelöscht wird. Wenn Sie einen neuen Eingangsdatencontroller erstellen, wird ihm eine neue öffentliche IP-Adresse zugewiesen. Ihre Ausgabe sollte in etwa dem folgendem Beispiel entsprechen.

  • Verwenden Sie den Befehl kubectl get service, um die öffentliche IP-Adresse für Ihren Eingangsdatencontroller abzurufen.

    # Get the public IP address for your ingress controller
    
    kubectl --namespace ingress-basic get services -o wide -w nginx-ingress-ingress-nginx-controller
    
    # Sample output
    
    NAME                                     TYPE           CLUSTER-IP    EXTERNAL-IP     PORT(S)                      AGE   SELECTOR
    nginx-ingress-ingress-nginx-controller   LoadBalancer   10.0.74.133   EXTERNAL_IP     80:32486/TCP,443:30953/TCP   44s   app.kubernetes.io/component=controller,app.kubernetes.io/instance=nginx-ingress,app.kubernetes.io/name=ingress-nginx
    

Hinzufügen eines A-Eintrags zu Ihrer DNS-Zone

Wenn Sie eine benutzerdefinierte Domäne verwenden, müssen Sie Ihrer DNS-Zone einen A-Eintrag hinzufügen. Wenn Sie keine benutzerdefinierte Domäne verwenden, können Sie die öffentliche IP-Adresse mit einem FQDN konfigurieren.

  • Fügen Sie Ihrer DNS-Zone mithilfe von az network dns record-set a add-record einen A-Datensatz mit der externen IP-Adresse des NGINX-Diensts hinzu.

    az network dns record-set a add-record \
        --resource-group myResourceGroup \
        --zone-name MY_CUSTOM_DOMAIN \
        --record-set-name "*" \
        --ipv4-address MY_EXTERNAL_IP
    

Konfigurieren eines FQDN für Ihren Eingangsdatencontroller

Optional können Sie anstelle einer benutzerdefinierten Domäne einen vollqualifizierten Domänennamen (FQDN) für die IP-Adresse des Eingangsdatencontrollers konfigurieren. Legen Sie dafür eine DNS-Bezeichnung fest. Ihr FQDN sollte dem folgenden Format entsprechen: <CUSTOM DNS LABEL>.<AZURE REGION NAME>.cloudapp.azure.com.

Wichtig

Die DNS-Bezeichnung muss innerhalb ihres Azure-Standorts eindeutig sein.

Sie können Ihren FQDN mit einer der folgenden Methoden konfigurieren:

  • Legen Sie die DNS-Bezeichnung mithilfe der Azure CLI oder Azure PowerShell fest.
  • Legen Sie die DNS-Bezeichnung mithilfe der Helm-Diagrammeinstellungen fest.

Weitere Informationen finden Sie unter Öffentliche IP-Adresse/DNS-Namensbezeichnungen.

Festlegen der DNS-Bezeichnung mithilfe der Azure CLI oder Azure PowerShell

Ersetzen Sie <DNS_LABEL> durch Ihre eindeutige DNS-Bezeichnung.

# Public IP address of your ingress controller
IP="MY_EXTERNAL_IP"

# Name to associate with public IP address
DNSLABEL="<DNS_LABEL>"

# Get the resource-id of the public IP
PUBLICIPID=$(az network public-ip list --query "[?ipAddress!=null]|[?contains(ipAddress, '$IP')].[id]" --output tsv)

# Update public IP address with DNS name
az network public-ip update --ids $PUBLICIPID --dns-name $DNSLABEL

# Display the FQDN
az network public-ip show --ids $PUBLICIPID --query "[dnsSettings.fqdn]" --output tsv

Festlegen der DNS-Bezeichnung mithilfe der Helm-Diagrammeinstellungen

Mithilfe des Parameters --set controller.service.annotations."service\.beta\.kubernetes\.io/azure-dns-label-name" können Sie eine Anmerkungseinstellung an Ihre Helm-Diagrammkonfiguration übergeben. Dieser Parameter kann festgelegt werden, wenn der Eingangsdatencontroller zum ersten Mal bereitgestellt wird. Alternativ kann er später konfiguriert werden.

Im folgenden Beispiel wird gezeigt, wie diese Einstellung aktualisiert wird, nachdem der Controller bereitgestellt wurde. Ersetzen Sie <DNS_LABEL> durch Ihre eindeutige DNS-Bezeichnung.

DNSLABEL="<DNS_LABEL>"
NAMESPACE="ingress-basic"

helm upgrade ingress-nginx ingress-nginx/ingress-nginx \
  --namespace $NAMESPACE \
  --set controller.service.annotations."service\.beta\.kubernetes\.io/azure-dns-label-name"=$DNSLABEL \
  --set controller.service.annotations."service\.beta\.kubernetes\.io/azure-load-balancer-health-probe-request-path"=/healthz

Installieren von cert-manager

Der NGINX-Eingangscontroller unterstützt TLS-Terminierung. Es gibt verschiedene Möglichkeiten zum Abrufen und Konfigurieren von Zertifikaten für HTTPS. Für diesen Artikel wird cert-manager verwendet. Dabei wird die automatische Let‘s Encrypt-Zertifikatsgenerierung und -Verwaltungsfunktionalität mit bereitgestellt.

Verwenden Sie zum Installieren des cert-manager-Controllers die folgenden Befehle.

# Set variable for ACR location to use for pulling images
ACR_URL=<REGISTRY_URL>

# Label the ingress-basic namespace to disable resource validation
kubectl label namespace ingress-basic cert-manager.io/disable-validation=true

# Add the Jetstack Helm repository
helm repo add jetstack https://charts.jetstack.io

# Update your local Helm chart repository cache
helm repo update

# Install the cert-manager Helm chart
helm install cert-manager jetstack/cert-manager \
  --namespace ingress-basic \
  --version=$CERT_MANAGER_TAG \
  --set installCRDs=true \
  --set nodeSelector."kubernetes\.io/os"=linux \
  --set image.repository=$ACR_URL/$CERT_MANAGER_IMAGE_CONTROLLER \
  --set image.tag=$CERT_MANAGER_TAG \
  --set webhook.image.repository=$ACR_URL/$CERT_MANAGER_IMAGE_WEBHOOK \
  --set webhook.image.tag=$CERT_MANAGER_TAG \
  --set cainjector.image.repository=$ACR_URL/$CERT_MANAGER_IMAGE_CAINJECTOR \
  --set cainjector.image.tag=$CERT_MANAGER_TAG

Weitere Informationen zur cert-manager-Konfiguration finden Sie im cert-manager-Projekt.

Erstellen eines CA-Clusterausstellers

Damit Zertifikate ausgestellt werden können, benötigt cert-manager einen der folgenden Zertifikataussteller:

  • Einen Aussteller, der in einem einzelnen Namespace agiert.
  • Eine ClusterIssuer-Ressource, die für alle Namespaces agiert.

Weitere Informationen finden Sie in der cert-manager-Dokumentation zu „Issuers“.

  1. Erstellen Sie einen Clusteraussteller, wie z.B. cluster-issuer.yaml, mithilfe des folgenden Beispielmanifests. Ersetzen Sie MY_EMAIL_ADDRESS durch eine gültige Adresse aus Ihrer Organisation.

    apiVersion: cert-manager.io/v1
    kind: ClusterIssuer
    metadata:
      name: letsencrypt
    spec:
      acme:
        server: https://acme-v02.api.letsencrypt.org/directory
        email: MY_EMAIL_ADDRESS
        privateKeySecretRef:
          name: letsencrypt
        solvers:
        - http01:
            ingress:
              class: nginx
              podTemplate:
                spec:
                  nodeSelector:
                    "kubernetes.io/os": linux
    
  2. Wenden Sie den Zertifikataussteller mithilfe des Befehls kubectl apply an.

    kubectl apply -f cluster-issuer.yaml --namespace ingress-basic
    

Aktualisieren Ihrer Eingangsrouten

Sie müssen Ihre Eingangsrouten aktualisieren, um den Datenverkehr an Ihren FQDN oder Ihre benutzerdefinierte Domäne zu verarbeiten.

Im folgenden Beispiel wird der Datenverkehr als solcher weitergeleitet:

  • Der Datenverkehr an hello-world-ingress.MY_CUSTOM_DOMAIN wird an den Dienst aks-helloworld-one weitergeleitet.
  • Der Datenverkehr an hello-world-ingress.MY_CUSTOM_DOMAIN/hello-world-two wird an den Dienst aks-helloworld-two weitergeleitet.
  • Datenverkehr an hello-world-ingress.MY_CUSTOM_DOMAIN/static wird für statische Ressourcen an den Dienst aks-helloworld-one weitergeleitet.

Hinweis

Wenn Sie einen FQDN für die IP-Adresse des Eingangscontrollers anstelle einer benutzerdefinierten Domäne konfiguriert haben, verwenden Sie den FQDN anstelle von hello-world-ingress.MY_CUSTOM_DOMAIN.

Wenn Ihr FQDN beispielsweise demo-aks-ingress.eastus.cloudapp.azure.com lautet, ersetzen Sie hello-world-ingress.MY_CUSTOM_DOMAIN durch demo-aks-ingress.eastus.cloudapp.azure.com in hello-world-ingress.yaml.

  1. Erstellen oder aktualisieren Sie die hello-world-ingress.yaml-Datei mithilfe der folgenden YAML-Beispieldatei. Aktualisieren Sie spec.tls.hosts und spec.rules.host auf den DNS-Namen, den Sie in einem vorherigen Schritt erstellt haben.

    apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
      name: hello-world-ingress
      annotations:
        nginx.ingress.kubernetes.io/rewrite-target: /$2
        nginx.ingress.kubernetes.io/use-regex: "true"
        cert-manager.io/cluster-issuer: letsencrypt
    spec:
      ingressClassName: nginx
      tls:
      - hosts:
        - hello-world-ingress.MY_CUSTOM_DOMAIN
        secretName: tls-secret
      rules:
      - host: hello-world-ingress.MY_CUSTOM_DOMAIN
        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
      tls:
      - hosts:
        - hello-world-ingress.MY_CUSTOM_DOMAIN
        secretName: tls-secret
      rules:
      - host: hello-world-ingress.MY_CUSTOM_DOMAIN
        http:
          paths:
          - path: /static(/|$)(.*)
            pathType: Prefix
            backend:
              service:
                name: aks-helloworld-one
                port:
                  number: 80
    
  2. Aktualisieren Sie die Eingangsressource mit dem Befehl kubectl apply.

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

Überprüfen Sie, ob ein Zertifikatsobjekt erstellt wurde.

Als Nächstes muss eine Zertifikatressource erstellt werden. Die Zertifikatressource definiert das gewünschte X.509-Zertifikat. Weitere Informationen finden Sie unter cert-manager-Zertifikate.

„Cert-manager“ erstellt automatisch ein Zertifikatsobjekt für Sie, indem „ingress-shim“ verwendet wurde, das seit v0.2.2 automatisch mit „Cert-manager“ bereitgestellt wird. Weitere Informationen finden Sie in der Dokumentation zu „ingress-shim“.

Verwenden Sie den Befehl kubectl get certificate --namespace ingress-basic, um sicherzustellen, dass das Zertifikat erfolgreich erstellt wurde, und überprüfen Sie, ob READY den Wert True hat. Es kann ein paar Minuten dauern, bis Sie die Ausgabe erhalten.

kubectl get certificate --namespace ingress-basic

Die folgende Ausgabe zeigt den Status des Zertifikats an.

NAME         READY   SECRET       AGE
tls-secret   True    tls-secret   11m

Testen der Konfiguration für eingehende Daten

Öffnen Sie einen Webbrowser mit hello-world-ingress.MY_CUSTOM_DOMAIN oder dem FQDN Ihres Kubernetes-Eingangsdatencontrollers. Stellen Sie sicher, dass Folgendes zutrifft:

  • Sie werden zur Verwendung von HTTPS umgeleitet.
  • Das Zertifikat ist vertrauenswürdig.
  • Die Demoanwendung wird im Webbrowser angezeigt.
  • Fügen Sie /hello-world-two am Ende der Domäne hinzu und stellen Sie sicher, dass die zweite Demoanwendung mit dem benutzerdefinierten Titel angezeigt wird.

Bereinigen von Ressourcen

In diesem Artikel wird Helm verwendet, um die Eingangskomponenten, die Zertifikate 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

Durch das Löschen des Beispielnamespaces werden auch alle Ressourcen im Namespace gelöscht.

  • Löschen Sie den gesamten Namespace mit dem kubectl delete-Befehl, indem Sie Ihren Namespacenamen angeben.

    kubectl delete namespace ingress-basic
    

Löschen einzelner Ressourcen

Alternativ können Sie die Ressource einzeln löschen.

  1. Entfernen Sie die Clusterausstellerressourcen.

    kubectl delete -f cluster-issuer.yaml --namespace ingress-basic
    
  2. Listen Sie mit dem Befehl helm list die Helm-Releases auf. Suchen Sie nach Diagrammen mit den Namen nginx und cert-manager, wie in der folgenden Beispielausgabe dargestellt.

    $ helm list --namespace ingress-basic
    
    NAME                    NAMESPACE       REVISION        UPDATED                                 STATUS          CHART                   APP VERSION
    cert-manager            ingress-basic   1               2020-01-15 10:23:36.515514 -0600 CST    deployed        cert-manager-v0.13.0    v0.13.0
    nginx                   ingress-basic   1               2020-01-15 10:09:45.982693 -0600 CST    deployed        nginx-ingress-1.29.1    0.27.0
    
  3. Deinstallieren Sie die Versionen mithilfe des Befehls helm uninstall. Im folgenden Beispiel werden die NGINX-Eingangs- und Zertifikat-Managerbereitstellungen deinstalliert.

    $ helm uninstall cert-manager nginx --namespace ingress-basic
    
    release "cert-manager" uninstalled
    release "nginx" uninstalled
    
  4. 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
    
  5. Entfernen Sie die Eingangsroute, die Datenverkehr an die Beispiel-Apps weitergeleitet hat.

    kubectl delete -f hello-world-ingress.yaml --namespace ingress-basic
    
  6. Löschen Sie den Namespace selbst. Verwenden Sie dazu den kubectl delete-Befehl, und geben Sie den Namespacenamen an.

    kubectl delete namespace ingress-basic
    

Nächste Schritte

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

Sie können außerdem: