Een controller voor inkomend verkeer maken met een statisch openbaar IP-adres in Azure Kubernetes Service (AKS)

Een controller voor inkomend verkeer is een stukje software dat omgekeerde proxy’s, configureerbare verkeersroutering en TLS-beëindiging voor Kubernetes-services biedt. Kubernetes-resources voor inkomend verkeer worden gebruikt om de regels en routes voor uitgaand verkeer worden geconfigureerd voor individuele Kubernetes-services. Met behulp van een controller en regels voor inkomend verkeer kan er één enkel IP-adres worden gebruikt voor het routeren van verkeer naar meerdere services in een Kubernetes-cluster.

In dit artikel wordt beschreven hoe u de NGINX-controller voor een Azure Kubernetes Service (AKS) implementeert. De controller voor ingress is geconfigureerd met een statisch openbaar IP-adres. Het certificaatbeheerproject wordt gebruikt voor het automatisch genereren en configureren van Let's Encrypt-certificaten. Ten slotte worden er twee toepassingen uitgevoerd in het AKS-cluster, die allemaal toegankelijk zijn via één IP-adres.

U kunt ook het volgende doen:

Voordat u begint

In dit artikel wordt ervan uitgenomen dat u een bestaand AKS-cluster hebt. Als u een AKS-cluster nodig hebt, bekijkt u de AKS-quickstart met behulp van de Azure CLI of met behulp van de Azure Portal.

In dit artikel wordt Helm 3 gebruikt om de NGINX-controller voor ingress te installeren op een ondersteunde versie van Kubernetes. Zorg ervoor dat u de nieuwste versie van Helm gebruikt en toegang hebt tot de opslagplaatsen ingress-nginx en jetstack Helm. De stappen die in dit artikel worden beschreven, zijn mogelijk niet compatibel met eerdere versies van de Helm-grafiek, NGINX-controller voor ingress of Kubernetes.

Zie Toepassingen installeren met Helm in Azure Kubernetes Service (AKS) voormeer informatie over het configureren en gebruiken van Helm. Zie de helm-installatie docs voor upgrade-instructies.

Voor dit artikel moet u ook Azure CLI versie 2.0.64 of hoger uitvoeren. Voer az --version uit om de versie te bekijken. Zie Azure CLI installeren als u de CLI wilt installeren of een upgrade wilt uitvoeren.

Bovendien wordt in dit artikel ervan uitgenomen dat u een bestaand AKS-cluster met een geïntegreerde ACR hebt. Zie Verifiëren met ACR voor meer informatie over het maken van een AKS-cluster met een geïntegreerde ACR Azure Container Registry van Azure Kubernetes Service.

De afbeeldingen importeren die door de Helm-grafiek worden gebruikt in uw ACR

In dit artikel wordt gebruikgemaakt van de Helm-grafiek voor de NGINX-ingress controller,die afhankelijk is van drie containerafbeeldingen. Gebruik az acr import om deze afbeeldingen te importeren in uw ACR.

REGISTRY_NAME=<REGISTRY_NAME>
CONTROLLER_REGISTRY=k8s.gcr.io
CONTROLLER_IMAGE=ingress-nginx/controller
CONTROLLER_TAG=v1.0.4
PATCH_REGISTRY=docker.io
PATCH_IMAGE=jettech/kube-webhook-certgen
PATCH_TAG=v1.5.2
DEFAULTBACKEND_REGISTRY=k8s.gcr.io
DEFAULTBACKEND_IMAGE=defaultbackend-amd64
DEFAULTBACKEND_TAG=1.5
CERT_MANAGER_REGISTRY=quay.io
CERT_MANAGER_TAG=v1.5.4
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 $CONTROLLER_REGISTRY/$CONTROLLER_IMAGE:$CONTROLLER_TAG --image $CONTROLLER_IMAGE:$CONTROLLER_TAG
az acr import --name $REGISTRY_NAME --source $PATCH_REGISTRY/$PATCH_IMAGE:$PATCH_TAG --image $PATCH_IMAGE:$PATCH_TAG
az acr import --name $REGISTRY_NAME --source $DEFAULTBACKEND_REGISTRY/$DEFAULTBACKEND_IMAGE:$DEFAULTBACKEND_TAG --image $DEFAULTBACKEND_IMAGE:$DEFAULTBACKEND_TAG
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

Notitie

Naast het importeren van containerafbeeldingen in uw ACR, kunt u ook Helm-grafieken in uw ACR importeren. Zie Push and pull Helm charts to an Azure container registry (Helm-grafieken pushen en pullen naar een Azure-containerregister) voor meer informatie.

Een controller voor ingress maken

Standaard wordt een NGINX-controller voor ingress gemaakt met een nieuwe toewijzing van een openbaar IP-adres. Dit openbare IP-adres is alleen statisch voor de levensduur van de controller voor ingress en gaat verloren als de controller wordt verwijderd en opnieuw wordt gemaakt. Een veelvoorkomende configuratievereiste is om de NGINX-controller voor binnenkomende gegevens een bestaand statisch openbaar IP-adres te geven. Het statische openbare IP-adres blijft bestaan als de controller voor ingress wordt verwijderd. Op deze manier kunt u bestaande DNS-records en netwerkconfiguraties gedurende de levenscyclus van uw toepassingen op een consistente manier gebruiken.

Als u een statisch openbaar IP-adres wilt maken, moet u eerst de naam van de resourcegroep van het AKS-cluster op halen met de opdracht az aks show:

az aks show --resource-group myResourceGroup --name myAKSCluster --query nodeResourceGroup -o tsv

Maak vervolgens een openbaar IP-adres met de statische toewijzingsmethode met behulp van de opdracht az network public-ip create. In het volgende voorbeeld wordt een openbaar IP-adres met de naam myAKSPublicIP gemaakt in de AKS-clusterresourcegroep die u in de vorige stap hebt verkregen:

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

Notitie

Met de bovenstaande opdrachten maakt u een IP-adres dat wordt verwijderd als u uw AKS-cluster verwijdert. U kunt ook een IP-adres maken in een andere resourcegroep die afzonderlijk van uw AKS-cluster kan worden beheerd. Als u een IP-adres in een andere resourcegroep maakt, moet u ervoor zorgen dat de clusteridentiteit die wordt gebruikt door het AKS-cluster machtigingen heeft gedelegeerd aan de andere resourcegroep, zoals Inzender voor netwerken. Zie Use a static public IP address and DNS label with the AKS load balancer (Een statisch openbaar IP-adres en DNS-label gebruiken met de AKS-load balancer) voor meer load balancer.

Implementeer nu de nginx-ingress-grafiek met Helm. Voor toegevoegde redundantie worden er twee replica's van de NGINX-ingangscontrollers geïmplementeerd met de parameter --set controller.replicaCount. Zorg ervoor dat uw AKS-cluster meer dan één knooppunt heeft om volledig te profiteren van het uitvoeren van replica's van de controller voor ingress.

IP- en DNS-label

U moet twee extra parameters doorgeven aan de Helm-release, zodat de controller voor toegangsbeheer wordt bewust gemaakt van zowel het statische IP-adres van de load balancer dat moet worden toegewezen aan de controllerservice voor toegangsbeheer en van het DNS-naamlabel dat wordt toegepast op de resource van het openbare IP-adres. De HTTPS-certificaten werken alleen goed als er een DNS-naamlabel wordt gebruikt om een FQDN te configureren voor het IP-adres van de ingress-controller.

  1. Voeg de --set controller.service.loadBalancerIP parameter toe. Geef uw eigen openbare IP-adres op dat in de vorige stap is gemaakt.
  2. Voeg de --set controller.service.annotations."service\.beta\.kubernetes\.io/azure-dns-label-name" parameter toe. Geef een DNS-naamlabel op dat moet worden toegepast op het openbare IP-adres dat in de vorige stap is gemaakt. Met dit label maakt u een DNS-naam van het formulier <LABEL>.<AZURE REGION NAME>.cloudapp.azure.com

De ingangscontroller moet ook worden gepland op een Linux-knooppunt. Windows Server-knooppunten mogen de ingangscontroller niet uitvoeren. Er wordt een knooppuntselector opgegeven met behulp van de parameter --set nodeSelector om de Kubernetes-planner te laten weten dat de NGINX-ingangscontroller moet worden uitgevoerd op een Linux-knooppunt.

Tip

In het volgende voorbeeld wordt een Kubernetes-naamruimte gemaakt voor de ingress-resources met de naam ingress-basic en is bedoeld om te werken binnen die naamruimte. Geef waar nodig een naamruimte op voor uw eigen omgeving. Als uw AKS-cluster niet Kubernetes RBAC is ingeschakeld, voegt u toe --set rbac.create=false aan de Helm-opdrachten.

Tip

Als u behoud van ip-adressen van clientbron wilt inschakelen voor aanvragen naar containers in uw cluster, voegt u toe --set controller.service.externalTrafficPolicy=Local aan de Helm-installatieopdracht. Het ip-adres van de clientbron wordt opgeslagen in de aanvraagheader onder X-Forwarded-For. Wanneer u een toegangscontroller gebruikt waarop behoud van ip-adressen van clientbron is ingeschakeld, werkt TLS-pass-through niet.

Werk het volgende script bij met het IP-adres van de controller voor ingress en een unieke naam die u wilt gebruiken voor het FQDN-voorvoegsel.

Belangrijk

U moet en bijwerken <STATIC_IP> door <DNS_LABEL> uw eigen IP-adres en unieke naam bij het uitvoeren van de opdracht. De DNS_LABEL moet uniek zijn binnen de Azure-regio.

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

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

# Use Helm to deploy an NGINX ingress controller
helm install nginx-ingress ingress-nginx/ingress-nginx \
    --namespace ingress-basic --create-namespace \
    --set controller.replicaCount=2 \
    --set controller.nodeSelector."kubernetes\.io/os"=linux \
    --set controller.image.registry=$ACR_URL \
    --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.admissionWebhooks.patch.image.registry=$ACR_URL \
    --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_URL \
    --set defaultBackend.image.image=$DEFAULTBACKEND_IMAGE \
    --set defaultBackend.image.tag=$DEFAULTBACKEND_TAG \
    --set defaultBackend.image.digest="" \
    --set controller.service.loadBalancerIP=$STATIC_IP \
    --set controller.service.annotations."service\.beta\.kubernetes\.io/azure-dns-label-name"=$DNS_LABEL

Wanneer de Kubernetes load balancer-service wordt gemaakt voor de NGINX-controller voor ingress, wordt uw statische IP-adres toegewezen, zoals wordt weergegeven in de volgende voorbeelduitvoer:

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

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

Er zijn nog geen regels voor binnengangen gemaakt, dus wordt de standaardpagina 404 van de NGINX-ingress-controller weergegeven als u naar het openbare IP-adres bladert. In de volgende stappen worden regels voor ingress geconfigureerd.

U kunt controleren of het DNS-naamlabel is toegepast door als volgt een query uit te voeren op de FQDN op het openbare IP-adres:

az network public-ip list --resource-group MC_myResourceGroup_myAKSCluster_eastus --query "[?name=='myAKSPublicIP'].[dnsSettings.fqdn]" -o tsv

De toegangscontroller is nu toegankelijk via het IP-adres of de FQDN.

Certificaatbeheer installeren

De NGINX-ingangscontroller ondersteunt TLS-beëindiging. Er zijn verschillende manieren om certificaten voor HTTPS op te halen en te configureren. In dit artikel wordt gedemonstreerd hoe u certificaatbeheer gebruikt.Dit biedt automatische functionaliteit voor het genereren en beheren van Certificaten versleutelen.

Notitie

In dit artikel wordt de staging omgeving voor Let's Encrypt gebruikt. Gebruik in productie-implementaties letsencrypt-prod en https://acme-v02.api.letsencrypt.org/directory in de resourcedefinities en bij het installeren van de Helm-grafiek.

Als u de certificaatbeheercontroller wilt installeren in een Kubernetes RBAC-cluster, gebruikt u de volgende helm install opdracht:

# Label the cert-manager 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 

Zie het certificaatbeheerproject voor meer informatie over de configuratie van certificaatbeheer.

Een CA-clustervergever maken

Voordat certificaten kunnen worden uitgegeven, is voor certificaatbeheer een issuer- of ClusterIssuer-resource vereist. Deze Kubernetes-resources zijn identiek qua functionaliteit, maar werken in één naamruimte en werken Issuer ClusterIssuer in alle naamruimten. Zie de documentatie voor certificaatbeheerder voor meer informatie.

Maak een clustervergever, zoals cluster-issuer.yaml , met behulp van het volgende voorbeeldmanifest. Werk het e-mailadres bij met een geldig adres van uw organisatie:

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-staging
spec:
  acme:
    server: https://acme-staging-v02.api.letsencrypt.org/directory
    email: user@contoso.com
    privateKeySecretRef:
      name: letsencrypt-staging
    solvers:
    - http01:
        ingress:
          class: nginx
          podTemplate:
            spec:
              nodeSelector:
                "kubernetes.io/os": linux

Gebruik de opdracht om de vergever te kubectl apply maken.

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

De uitvoer moet er ongeveer als het volgende voorbeeld uit zien:

clusterissuer.cert-manager.io/letsencrypt-staging created

Demotoepassingen uitvoeren

Er zijn een controller voor ingress en een oplossing voor certificaatbeheer geconfigureerd. We gaan nu twee demotoepassingen uitvoeren in uw AKS-cluster. In dit voorbeeld wordt Helm gebruikt om twee exemplaren van een eenvoudige 'Hallo wereld'-toepassing te implementeren.

Als u de controller voor ingress in actie wilt zien, moet u twee demotoepassingen uitvoeren in uw AKS-cluster. In dit voorbeeld gebruikt u om twee exemplaren van een eenvoudige kubectl apply Hallo wereld-toepassing te implementeren.

Maak het bestand aks-helloworld.yaml en kopieer het in het volgende voorbeeld van YAML:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: aks-helloworld
spec:
  replicas: 1
  selector:
    matchLabels:
      app: aks-helloworld
  template:
    metadata:
      labels:
        app: aks-helloworld
    spec:
      containers:
      - name: aks-helloworld
        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
spec:
  type: ClusterIP
  ports:
  - port: 80
  selector:
    app: aks-helloworld

Maak een ingress-demo.yaml-bestand en kopieer het in het volgende voorbeeld van YAML:

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

Voer de twee demotoepassingen uit met kubectl apply behulp van :

kubectl apply -f aks-helloworld.yaml --namespace ingress-basic
kubectl apply -f ingress-demo.yaml --namespace ingress-basic

Een route voor ingress maken

Beide toepassingen worden nu uitgevoerd op uw Kubernetes-cluster, maar ze zijn geconfigureerd met een service van het type ClusterIP . Daarom zijn de toepassingen niet toegankelijk via internet. Als u deze openbaar beschikbaar wilt maken, maakt u een Kubernetes-ingress-resource. De resource voor het binnenverkeer configureert de regels die verkeer naar een van de twee toepassingen doors groeperen.

In het volgende voorbeeld wordt verkeer naar het adres https://demo-aks-ingress.eastus.cloudapp.azure.com/ doorgeleid naar de service met de naam aks-helloworld . Verkeer naar het adres https://demo-aks-ingress.eastus.cloudapp.azure.com/hello-world-two wordt doorgeleid naar de ingress-demo service. Werk de hosts en host bij naar de DNS-naam die u in een vorige stap hebt gemaakt.

Maak een bestand met de hello-world-ingress.yaml naam en kopieer het in het volgende yaml-voorbeeld.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: hello-world-ingress
  annotations:
    kubernetes.io/ingress.class: nginx
    cert-manager.io/cluster-issuer: letsencrypt-staging
    nginx.ingress.kubernetes.io/rewrite-target: /$1
    nginx.ingress.kubernetes.io/use-regex: "true"
spec:
  tls:
  - hosts:
    - demo-aks-ingress.eastus.cloudapp.azure.com
    secretName: tls-secret
  rules:
  - host: demo-aks-ingress.eastus.cloudapp.azure.com
    http:
      paths:
      - path: /hello-world-one(/|$)(.*)
        pathType: Prefix
        backend:
          service:
            name: aks-helloworld
            port:
              number: 80
      - path: /hello-world-two(/|$)(.*)
        pathType: Prefix
        backend:
          service:
            name: ingress-demo
            port:
              number: 80
      - path: /(.*)
        pathType: Prefix
        backend:
          service:
            name: aks-helloworld
            port:
              number: 80

Maak de ingress-resource met behulp van de kubectl apply opdracht .

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

De uitvoer moet er ongeveer als het volgende voorbeeld uit zien:

ingress.extensions/hello-world-ingress created

Certificaatobject verifiëren

Vervolgens moet er een certificaatresource worden gemaakt. De certificaatresource definieert het gewenste X.509-certificaat. Zie certificaten voor certificaatbeheer voor meer informatie.

Certificaatbeheer heeft waarschijnlijk automatisch een certificaatobject voor u gemaakt met behulp van ingress-shim, dat automatisch wordt geïmplementeerd met certificaatbeheer sinds v0.2.2. Zie de documentatie voor ingress-shim voor meer informatie.

Gebruik de opdracht om te controleren of het certificaat is kubectl describe certificate tls-secret --namespace ingress-basic gemaakt.

Als het certificaat is uitgegeven, ziet u uitvoer die er ongeveer als volgt uit ziet:

Type    Reason          Age   From          Message
----    ------          ----  ----          -------
  Normal  CreateOrder     11m   cert-manager  Created new ACME order, attempting validation...
  Normal  DomainVerified  10m   cert-manager  Domain "demo-aks-ingress.eastus.cloudapp.azure.com" verified with "http-01" validation
  Normal  IssueCert       10m   cert-manager  Issuing certificate...
  Normal  CertObtained    10m   cert-manager  Obtained certificate from ACME server
  Normal  CertIssued      10m   cert-manager  Certificate issued successfully

De configuratie van het ingress testen

Open een webbrowser naar de FQDN van uw Kubernetes-controller voor ingress, zoals https://demo-aks-ingress.eastus.cloudapp.azure.com .

Omdat in deze voorbeelden wordt letsencrypt-staging gebruikt, wordt het uitgegeven TLS/SSL-certificaat niet vertrouwd door de browser. Accepteer de waarschuwingsprompt om door te gaan naar uw toepassing. De certificaatgegevens geven aan dat dit valse TUSSENliggende X1-certificaat voor LE is uitgegeven door Let's Encrypt. Dit valse certificaat geeft aan cert-manager dat de aanvraag correct is verwerkt en een certificaat van de provider heeft ontvangen:

Let's Encrypt staging certificate (Faseringscertificaat versleutelen)

Wanneer u Let's Encrypt wijzigt in gebruik in plaats van , wordt een vertrouwd certificaat gebruikt dat is uitgegeven door prod staging Let's Encrypt, zoals wordt weergegeven in het volgende voorbeeld:

Let's Encrypt certificate

De demotoepassing wordt weergegeven in de webbrowser:

Voorbeeld van toepassing

Voeg nu het pad /hello-world-two toe aan de FQDN, zoals https://demo-aks-ingress.eastus.cloudapp.azure.com/hello-world-two . De tweede demotoepassing met de aangepaste titel wordt weergegeven:

Toepassingsvoorbeeld twee

Resources opschonen

In dit artikel is Helm gebruikt om de toegangsgegevens, certificaten en voorbeeld-apps te installeren. Wanneer u een Helm-grafiek implementeert, wordt er een aantal Kubernetes-resources gemaakt. Deze resources omvatten pods, implementaties en services. Als u deze resources wilt ops schonen, kunt u de volledige voorbeeldnaamruimte of de afzonderlijke resources verwijderen.

De voorbeeldnaamruimte en alle resources verwijderen

Als u de volledige voorbeeldnaamruimte wilt verwijderen, gebruikt u de kubectl delete opdracht en geeft u de naam van uw naamruimte op. Alle resources in de naamruimte worden verwijderd.

kubectl delete namespace ingress-basic

Resources afzonderlijk verwijderen

Een meer gedetailleerde benadering is ook het verwijderen van de afzonderlijke resources die zijn gemaakt. Verwijder eerst de certificaatbronnen:

kubectl delete -f certificates.yaml
kubectl delete -f cluster-issuer.yaml

Vermeld nu de Helm-releases met de helm list opdracht . Zoek naar grafieken met de naam nginx-ingress en cert-manager, zoals wordt weergegeven in de volgende voorbeelduitvoer:

$ helm list --all-namespaces

NAME                    NAMESPACE       REVISION        UPDATED                        STATUS          CHART                   APP VERSION
nginx-ingress           ingress-basic   1               2020-01-11 14:51:03.454165006  deployed        nginx-ingress-1.28.2    0.26.2
cert-manager            ingress-basic   1               2020-01-06 21:19:03.866212286  deployed        cert-manager-v0.13.0    v0.13.0

Verwijder de releases met de helm uninstall opdracht . In het volgende voorbeeld worden de implementaties van NGINX-ingress en certificaatbeheer verwijderd.

$ helm uninstall nginx-ingress cert-manager -n ingress-basic

release "nginx-ingress" deleted
release "cert-manager" deleted

Verwijder vervolgens de twee voorbeeldtoepassingen:

kubectl delete -f aks-helloworld.yaml --namespace ingress-basic
kubectl delete -f ingress-demo.yaml --namespace ingress-basic

Verwijder de naamruimte zelf. Gebruik de kubectl delete opdracht en geef de naam van uw naamruimte op:

kubectl delete namespace ingress-basic

Verwijder ten slotte het statische openbare IP-adres dat is gemaakt voor de controller voor ingress. Geef de MC_ van de clusterresourcegroep op die u in de eerste stap van dit artikel hebt verkregen, zoals MC_myResourceGroup_myAKSCluster_eastus:

az network public-ip delete --resource-group MC_myResourceGroup_myAKSCluster_eastus --name myAKSPublicIP

Volgende stappen

Dit artikel bevat enkele externe onderdelen voor AKS. Zie de volgende projectpagina's voor meer informatie over deze onderdelen:

U kunt ook het volgende doen: