Używanie protokołu TLS z kontrolerem ruchu przychodzącego w usłudze Azure Kubernetes Service (AKS)

Protokół TLS (Transport Layer Security) używa certyfikatów w celu zapewnienia zabezpieczeń komunikacji, szyfrowania, uwierzytelniania i integralności. Korzystanie z protokołu TLS z kontrolerem ruchu przychodzącego w usłudze AKS umożliwia zabezpieczanie komunikacji między aplikacjami i korzystanie z zalet kontrolera ruchu przychodzącego.

Możesz przynieść własne certyfikaty i zintegrować je ze sterownikiem CSI magazynu wpisów tajnych. Alternatywnie możesz użyć narzędzia cert-manager, który automatycznie generuje i konfiguruje certyfikaty Let's Encrypt . Dwie aplikacje działają w klastrze usługi AKS, z których każda jest dostępna za pośrednictwem jednego adresu IP.

Ważne

Dodatek routingu aplikacji jest zalecany w przypadku ruchu przychodzącego w usłudze AKS. Aby uzyskać więcej informacji, zobacz Managed nginx Ingress with the application routing add-on (Zarządzanie ruchem przychodzącym nginx przy użyciu dodatku routingu aplikacji).

Ważne

Firma Microsoft nie zarządza ani nie obsługuje menedżera certyfikatów ani żadnych problemów wynikających z jego użycia. Aby uzyskać informacje na temat problemów z programem cert-manager, zobacz dokumentację rozwiązywania problemów z programem cert-manager.

Istnieją dwa kontrolery ruchu przychodzącego typu open source dla platformy Kubernetes oparte na Nginx: jeden jest obsługiwany przez społeczność kubernetes (kubernetes/ingress-nginx), a jeden jest obsługiwany przez NGINX, Inc. (nginxinc/kubernetes-ingress). W tym artykule użyto kontrolera ruchu przychodzącego społeczności Platformy Kubernetes.

Zanim rozpoczniesz

  • W tym artykule założono, że masz skonfigurowany kontroler ruchu przychodzącego i aplikacje. Jeśli potrzebujesz kontrolera ruchu przychodzącego lub przykładowych aplikacji, zobacz Tworzenie kontrolera ruchu przychodzącego.

  • W tym artykule użyto programu Helm 3 do zainstalowania kontrolera ruchu przychodzącego NGINX w obsługiwanej wersji platformy Kubernetes. Upewnij się, że używasz najnowszej wersji programu Helm i masz dostęp do ingress-nginx repozytoriów programu Helm i jetstack . Kroki opisane w tym artykule mogą nie być zgodne z poprzednimi wersjami wykresu Helm, kontrolera ruchu przychodzącego NGINX lub Kubernetes.

  • W tym artykule założono, że masz istniejący klaster usługi AKS ze zintegrowanym usługą Azure Container Registry (ACR). Aby uzyskać więcej informacji na temat tworzenia klastra usługi AKS przy użyciu zintegrowanego rejestru ACR, zobacz Uwierzytelnianie za pomocą usługi ACR z usługi AKS.

  • Jeśli używasz interfejsu wiersza polecenia platformy Azure, ten artykuł wymaga interfejsu wiersza polecenia platformy Azure w wersji 2.0.64 lub nowszej. Uruchom polecenie az --version, aby dowiedzieć się, jaka wersja jest używana. Jeśli konieczna będzie instalacja lub uaktualnienie, zobacz Instalowanie interfejsu wiersza polecenia platformy Azure.

  • Jeśli używasz programu Azure PowerShell, w tym artykule jest wymagany program Azure PowerShell w wersji 5.9.0 lub nowszej. Uruchom polecenie Get-InstalledModule -Name Az, aby dowiedzieć się, jaka wersja jest używana. Jeśli konieczna będzie instalacja lub uaktualnienie, zobacz Instalowanie programu Azure PowerShell.

Używanie protokołu TLS z własnymi certyfikatami za pomocą sterownika CSI magazynu wpisów tajnych

Aby używać protokołu TLS z własnymi certyfikatami ze sterownikiem CSI magazynu wpisów tajnych, potrzebny jest klaster usługi AKS ze skonfigurowanym sterownikiem CSI magazynu wpisów tajnych i wystąpieniem usługi Azure Key Vault.

Aby uzyskać więcej informacji, zobacz Konfigurowanie sterownika CSI magazynu wpisów tajnych w celu włączenia kontrolera ruchu przychodzącego NGINX za pomocą protokołu TLS.

Używanie protokołu TLS z certyfikatami Let's Encrypt

Aby użyć protokołu TLS z certyfikatami Let's Encrypt, wdrożysz menedżera certyfikatów, który automatycznie generuje i konfiguruje certyfikaty Let's Encrypt.

Zaimportuj obrazy menedżera certyfikatów używane przez pakiet Helm do usługi ACR

  • Użyj polecenia az acr import , aby zaimportować następujące obrazy do usługi ACR.

    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
    

Uwaga

Możesz również zaimportować wykresy programu Helm do usługi ACR. Aby uzyskać więcej informacji, zobacz Wypychanie i ściąganie wykresów helm do usługi ACR.

Opcje konfiguracji kontrolera ruchu przychodzącego

Kontroler ruchu przychodzącego NGINX można skonfigurować przy użyciu statycznego publicznego adresu IP lub dynamicznego publicznego adresu IP. Jeśli używasz domeny niestandardowej, musisz dodać rekord A do strefy DNS. Jeśli nie używasz domeny niestandardowej, możesz skonfigurować w pełni kwalifikowaną nazwę domeny (FQDN) dla adresu IP kontrolera ruchu przychodzącego.

Tworzenie statycznego lub dynamicznego publicznego adresu IP

Używanie statycznego publicznego adresu IP

Kontroler ruchu przychodzącego można skonfigurować przy użyciu statycznego publicznego adresu IP. Statyczny publiczny adres IP pozostaje w przypadku usunięcia kontrolera ruchu przychodzącego. Adres IP nie pozostanie, jeśli usuniesz klaster usługi AKS.

Podczas uaktualniania kontrolera ruchu przychodzącego należy przekazać parametr do wydania programu Helm, aby upewnić się, że usługa kontrolera ruchu przychodzącego jest świadoma modułu równoważenia obciążenia, który zostanie mu przydzielony. Aby certyfikaty HTTPS działały poprawnie, należy użyć etykiety DNS do skonfigurowania nazwy FQDN dla adresu IP kontrolera ruchu przychodzącego.

  1. Pobierz nazwę grupy zasobów klastra usługi AKS za az aks show pomocą polecenia .

    az aks show --resource-group myResourceGroup --name myAKSCluster --query nodeResourceGroup -o tsv
    
  2. Utwórz publiczny adres IP przy użyciu metody alokacji statycznej przy użyciu az network public-ip create polecenia . Poniższy przykład tworzy publiczny adres IP o nazwie myAKSPublicIP w grupie zasobów klastra usługi AKS uzyskanej w poprzednim kroku.

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

Uwaga

Alternatywnie możesz utworzyć adres IP w innej grupie zasobów, którą można zarządzać oddzielnie od klastra usługi AKS. Jeśli tworzysz adres IP w innej grupie zasobów, upewnij się, że spełnione są następujące warunki:

  • Tożsamość klastra używana przez klaster usługi AKS ma delegowane uprawnienia do grupy zasobów, na przykład Współautor sieci.
  • --set controller.service.annotations."service\.beta\.kubernetes\.io/azure-load-balancer-resource-group"="<RESOURCE_GROUP>" Dodaj parametr . Zastąp <RESOURCE_GROUP> ciąg nazwą grupy zasobów, w której znajduje się adres IP.
  1. --set controller.service.annotations."service\.beta\.kubernetes\.io/azure-dns-label-name"="<DNS_LABEL>" Dodaj parametr . Etykietę DNS można ustawić po pierwszym wdrożeniu kontrolera ruchu przychodzącego lub można go skonfigurować później.

  2. --set controller.service.loadBalancerIP="<STATIC_IP>" Dodaj parametr . Określ własny publiczny adres IP utworzony w poprzednim kroku.

    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
    

Aby uzyskać więcej informacji, zobacz Używanie statycznego publicznego adresu IP i etykiety DNS z modułem równoważenia obciążenia usługi AKS.

Używanie dynamicznego publicznego adresu IP

Publiczny adres IP platformy Azure jest tworzony dla kontrolera ruchu przychodzącego podczas tworzenia. Publiczny adres IP jest statyczny dla cyklu życia kontrolera ruchu przychodzącego. Publiczny adres IP nie pozostanie, jeśli usuniesz kontroler ruchu przychodzącego. Jeśli utworzysz nowy kontroler ruchu przychodzącego, zostanie przypisany nowy publiczny adres IP. Dane wyjściowe powinny wyglądać podobnie do poniższych przykładowych danych wyjściowych.

  • kubectl get service Użyj polecenia , aby uzyskać publiczny adres IP dla kontrolera ruchu przychodzącego.

    # 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
    

Dodawanie rekordu A do strefy DNS

Jeśli używasz domeny niestandardowej, musisz dodać rekord A do strefy DNS. Jeśli nie używasz domeny niestandardowej, możesz skonfigurować publiczny adres IP przy użyciu nazwy FQDN.

  • Dodaj rekord A do strefy DNS z zewnętrznym adresem IP usługi NGINX przy użyciu polecenia az network dns record-set a add-record.

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

Konfigurowanie nazwy FQDN dla kontrolera ruchu przychodzącego

Opcjonalnie można skonfigurować nazwę FQDN dla adresu IP kontrolera ruchu przychodzącego zamiast domeny niestandardowej, ustawiając etykietę DNS. Nazwa FQDN powinna być zgodna z następującym formularzem: <CUSTOM DNS LABEL>.<AZURE REGION NAME>.cloudapp.azure.com.

Ważne

Etykieta DNS musi być unikatowa w swojej lokalizacji platformy Azure.

Nazwę FQDN można skonfigurować przy użyciu jednej z następujących metod:

  • Ustaw etykietę DNS przy użyciu interfejsu wiersza polecenia platformy Azure lub programu Azure PowerShell.
  • Ustaw etykietę DNS przy użyciu ustawień wykresu programu Helm.

Aby uzyskać więcej informacji, zobacz Etykiety nazw DNS publicznego adresu IP.

Ustawianie etykiety DNS przy użyciu interfejsu wiersza polecenia platformy Azure lub programu Azure PowerShell

Pamiętaj, aby zastąpić <DNS_LABEL> unikatową etykietą DNS.

# 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

Ustawianie etykiety DNS przy użyciu ustawień wykresu programu Helm

Możesz przekazać ustawienie adnotacji do konfiguracji wykresu helm przy użyciu parametru --set controller.service.annotations."service\.beta\.kubernetes\.io/azure-dns-label-name" . Ten parametr można ustawić po pierwszym wdrożeniu kontrolera ruchu przychodzącego lub można go skonfigurować później.

W poniższym przykładzie pokazano, jak zaktualizować to ustawienie po wdrożeniu kontrolera. Pamiętaj, aby zastąpić <DNS_LABEL> unikatową etykietą DNS.

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

Instalowanie narzędzia cert-manager

Kontroler ruchu przychodzącego NGINX obsługuje kończenie żądań protokołu TLS. Istnieje kilka sposobów pobierania i konfigurowania certyfikatów protokołu HTTPS. W tym artykule użyto menedżera certyfikatów, który zapewnia automatyczne generowanie certyfikatów i zarządzanie nimi.

Aby zainstalować kontroler cert-manager, użyj następujących poleceń.

# 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

Aby uzyskać więcej informacji na temat konfiguracji programu cert-manager, zobacz projekt cert-manager.

Tworzenie wystawcy klastra urzędu certyfikacji

Przed wystawieniem certyfikatów menedżer certyfikatów wymaga jednego z następujących wystawców:

  • Wystawca, który działa w jednej przestrzeni nazw.
  • Zasób ClusterIssuer , który działa we wszystkich przestrzeniach nazw.

Aby uzyskać więcej informacji, zobacz dokumentację wystawcy programu cert-manager.

  1. Utwórz wystawcę klastra, takiego jak cluster-issuer.yaml, przy użyciu następującego przykładowego manifestu. Zastąp MY_EMAIL_ADDRESS ciąg prawidłowym adresem z organizacji.

    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. Zastosuj wystawcę kubectl apply przy użyciu polecenia .

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

Aktualizowanie tras ruchu przychodzącego

Musisz zaktualizować trasy ruchu przychodzącego, aby obsługiwać ruch do nazwy FQDN lub domeny niestandardowej.

W poniższym przykładzie ruch jest kierowany w następujący sposób:

  • Ruch do ruchu przychodzącego hello-world-ingress. MY_CUSTOM_DOMAIN jest kierowany do usługi aks-helloworld-one .
  • Ruch do ruchu przychodzącego hello-world-ingress. MY_CUSTOM_DOMAIN/hello-world-two jest kierowany do usługi aks-helloworld-two .
  • Ruch do ruchu przychodzącego hello-world-ingress. MY_CUSTOM_DOMAIN/statyczny jest kierowany do usługi o nazwie aks-helloworld-one dla zasobów statycznych.

Uwaga

Jeśli skonfigurowano nazwę FQDN dla adresu IP kontrolera ruchu przychodzącego zamiast domeny niestandardowej, użyj nazwy FQDN zamiast ruchu przychodzącego hello-world-ingress. MY_CUSTOM_DOMAIN.

Jeśli na przykład nazwa FQDN jest demo-aks-ingress.eastus.cloudapp.azure.com, zastąp wartość hello-world-ingress. MY_CUSTOM_DOMAIN za pomocą demo-aks-ingress.eastus.cloudapp.azure.com w pliku hello-world-ingress.yaml.

  1. Utwórz lub zaktualizuj hello-world-ingress.yaml plik przy użyciu następującego przykładowego pliku YAML. Zaktualizuj element spec.tls.hosts i spec.rules.host do nazwy DNS utworzonej w poprzednim kroku.

    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. Zaktualizuj zasób ruchu przychodzącego kubectl apply przy użyciu polecenia .

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

Sprawdź, czy obiekt certyfikatu został utworzony

Następnie należy utworzyć zasób certyfikatu. Zasób certyfikatu definiuje żądany certyfikat X.509. Aby uzyskać więcej informacji, zobacz certyfikaty cert-manager.

Narzędzie Cert-manager automatycznie tworzy obiekt certyfikatu za pomocą podkładki ruchu przychodzącego, który jest automatycznie wdrażany z programem cert-manager od wersji 0.2.2. Aby uzyskać więcej informacji, zobacz dokumentację ingress-shim.

Aby sprawdzić, czy certyfikat został utworzony pomyślnie, użyj kubectl get certificate --namespace ingress-basic polecenia i sprawdź, czy wartość READY ma wartość True. Pobranie danych wyjściowych może potrwać kilka minut.

kubectl get certificate --namespace ingress-basic

Następujące dane wyjściowe pokazują stan certyfikatu.

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

Testowanie konfiguracji ruchu przychodzącego

Otwórz przeglądarkę internetową w celu wejścia hello-world-ingress. MY_CUSTOM_DOMAIN lub nazwę FQDN kontrolera ruchu przychodzącego Kubernetes. Upewnij się, że spełnione są następujące warunki:

  • Nastąpi przekierowanie w celu użycia protokołu HTTPS.
  • Certyfikat jest zaufany.
  • Aplikacja demonstracyjna jest wyświetlana w przeglądarce internetowej.
  • Dodaj /hello-world-two na końcu domeny i upewnij się, że druga aplikacja demonstracyjna z tytułem niestandardowym jest wyświetlana.

Czyszczenie zasobów

W tym artykule użyto programu Helm do zainstalowania składników ruchu przychodzącego, certyfikatów i przykładowych aplikacji. Podczas wdrażania wykresu programu Helm jest tworzonych wiele zasobów kubernetes. Te zasoby obejmują zasobniki, wdrożenia i usługi. Aby wyczyścić te zasoby, możesz usunąć całą przykładową przestrzeń nazw lub poszczególne zasoby.

Usuwanie przykładowej przestrzeni nazw i wszystkich zasobów

Usunięcie przykładowej przestrzeni nazw powoduje również usunięcie wszystkich zasobów w przestrzeni nazw.

  • Usuń całą przykładową przestrzeń nazw przy użyciu kubectl delete polecenia i określ nazwę przestrzeni nazw.

    kubectl delete namespace ingress-basic
    

Usuwanie zasobów indywidualnie

Alternatywnie możesz usunąć zasób indywidualnie.

  1. Usuń zasoby wystawcy klastra.

    kubectl delete -f cluster-issuer.yaml --namespace ingress-basic
    
  2. Wyświetl listę wydań programu Helm za helm list pomocą polecenia . Poszukaj wykresów o nazwach nginx i cert-manager, jak pokazano w poniższych przykładowych danych wyjściowych.

    $ 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. Odinstaluj wydania przy helm uninstall użyciu polecenia . W poniższym przykładzie odinstalowuje wdrożenia ruchu przychodzącego NGINX i menedżera certyfikatów.

    $ helm uninstall cert-manager nginx --namespace ingress-basic
    
    release "cert-manager" uninstalled
    release "nginx" uninstalled
    
  4. Usuń dwie przykładowe aplikacje.

    kubectl delete -f aks-helloworld-one.yaml --namespace ingress-basic
    kubectl delete -f aks-helloworld-two.yaml --namespace ingress-basic
    
  5. Usuń trasę ruchu przychodzącego, która kierowała ruch do przykładowych aplikacji.

    kubectl delete -f hello-world-ingress.yaml --namespace ingress-basic
    
  6. Usuń samą przestrzeń nazw. kubectl delete Użyj polecenia i określ nazwę przestrzeni nazw.

    kubectl delete namespace ingress-basic
    

Następne kroki

W tym artykule zawarto niektóre składniki zewnętrzne usługi AKS. Aby dowiedzieć się więcej o tych składnikach, zobacz następujące strony projektu:

Możesz również wykonać następujące czynności: