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
undjetstack
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.- Weitere Informationen zum Konfigurieren und Verwenden von Helm finden Sie unter Installieren von Anwendungen mit Helm in AKS. Eine Upgradeanleitung finden Sie in der Helm-Installationsdokumentation. Weitere Informationen zum Konfigurieren und Verwenden von Helm finden Sie unter „Installieren von Anwendungen mit Helm in Azure Kubernetes Service (AKS)“.
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.
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
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.
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.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“.
Erstellen Sie einen Clusteraussteller, wie z.B.
cluster-issuer.yaml
, mithilfe des folgenden Beispielmanifests. Ersetzen SieMY_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
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
.
Erstellen oder aktualisieren Sie die
hello-world-ingress.yaml
-Datei mithilfe der folgenden YAML-Beispieldatei. Aktualisieren Siespec.tls.hosts
undspec.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
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.
Entfernen Sie die Clusterausstellerressourcen.
kubectl delete -f cluster-issuer.yaml --namespace ingress-basic
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
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
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
Entfernen Sie die Eingangsroute, die Datenverkehr an die Beispiel-Apps weitergeleitet hat.
kubectl delete -f hello-world-ingress.yaml --namespace ingress-basic
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: