Tworzenie niezarządzanego kontrolera ruchu przychodzącego

  • Artykuł

Kontroler ruchu przychodzącego to element oprogramowania dostarczający odwrotny serwer proxy, konfigurowalne trasowanie ruchu oraz zakończenie protokołu TLS dla usług Kubernetes. Zasoby ruchu przychodzącego usług Kubernetes są używane do skonfigurowania zasad ruchu przychodzącego oraz tras dla poszczególnych usług Kubernetes. Dzięki korzystaniu z kontrolera ruchu przychodzącego oraz zasad ruchu przychodzącego można użyć jednego adresu IP do trasowania ruchu w wielu usługach w klastrze Kubernetes.

W tym artykule pokazano, jak wdrożyć kontroler ruchu przychodzącego NGINX w klastrze usługi Azure Kubernetes Service (AKS). Dwie aplikacje są następnie uruchamiane w klastrze usługi AKS, z których każda jest dostępna za pośrednictwem pojedynczego 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).

Uwaga

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 będzie używany kontroler ruchu przychodzącego społeczności Platformy Kubernetes.

Zanim rozpoczniesz

  • 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 repozytorium ingress-nginx helm. 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 za pomocą zintegrowanego rejestru ACR, zobacz Uwierzytelnianie za pomocą usługi Azure Container Registry z poziomu usługi Azure Kubernetes Service.
  • Punkt końcowy healthz kondycji interfejsu API platformy Kubernetes został wycofany w wersji 1.16 platformy Kubernetes. Ten punkt końcowy livez można zastąpić zamiast tego punktami końcowymi i readyz . Zobacz Punkty końcowe interfejsu API platformy Kubernetes, aby określić, który punkt końcowy ma być używany w danym scenariuszu.
  • 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.

Konfiguracja podstawowa

Aby utworzyć podstawowy kontroler ruchu przychodzącego NGINX bez dostosowywania ustawień domyślnych, użyjesz programu Helm. Poniższa konfiguracja używa domyślnej konfiguracji dla uproszczenia. Możesz dodać parametry do dostosowywania wdrożenia, na przykład --set controller.replicaCount=3.

Uwaga

Jeśli chcesz włączyć zachowywanie źródłowego adresu IP klienta dla żądań do kontenerów w klastrze, dodaj --set controller.service.externalTrafficPolicy=Local polecenie instalacji programu Helm. Źródłowy adres IP klienta jest przechowywany w nagłówku żądania w obszarze X-Forwarded-For. Jeśli używasz kontrolera ruchu przychodzącego z włączonym zachowaniem źródłowego adresu IP klienta, przekazywanie protokołu TLS nie będzie działać.

NAMESPACE=ingress-basic

helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm repo update

helm install ingress-nginx ingress-nginx/ingress-nginx \
  --create-namespace \
  --namespace $NAMESPACE \
  --set controller.service.annotations."service\.beta\.kubernetes\.io/azure-load-balancer-health-probe-request-path"=/healthz \
  --set controller.service.externalTrafficPolicy=Local

Uwaga

W tym samouczku service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path jest ustawiona wartość /healthz. Oznacza to, że jeśli kod odpowiedzi żądań do /healthz nie 200jest , cały kontroler ruchu przychodzącego nie będzie działać. Możesz zmodyfikować wartość na inny identyfikator URI we własnym scenariuszu. Nie można usunąć tej części lub usunąć jej ustawienia albo kontroler ruchu przychodzącego nadal nie działa. Pakiet ingress-nginx używany w tym samouczku, który jest dostarczany przez urzędnika platformy Kubernetes, zawsze zwraca 200 kod odpowiedzi w przypadku żądania /healthz, ponieważ jest on zaprojektowany jako domyślny zaplecze dla użytkowników, którzy mają szybki start, chyba że jest zastępowany przez reguły ruchu przychodzącego.

Konfiguracja niestandardowa

Zamiast podstawowej konfiguracji przedstawionej w powyższej sekcji następny zestaw kroków pokaże, jak wdrożyć dostosowany kontroler ruchu przychodzącego. Możesz użyć wewnętrznego statycznego adresu IP lub dynamicznego publicznego adresu IP.

Importowanie obrazów używanych przez pakiet Helm do usługi ACR

Aby kontrolować wersje obrazów, należy zaimportować je do własnej usługi Azure Container Registry. Wykres helm kontrolera ruchu przychodzącego NGINX opiera się na trzech obrazach kontenerów. Służy az acr import do importowania tych obrazów do usługi ACR.

REGISTRY_NAME=<REGISTRY_NAME>
SOURCE_REGISTRY=registry.k8s.io
CONTROLLER_IMAGE=ingress-nginx/controller
CONTROLLER_TAG=v1.8.1
PATCH_IMAGE=ingress-nginx/kube-webhook-certgen
PATCH_TAG=v20230407
DEFAULTBACKEND_IMAGE=defaultbackend-amd64
DEFAULTBACKEND_TAG=1.5

az acr import --name $REGISTRY_NAME --source $SOURCE_REGISTRY/$CONTROLLER_IMAGE:$CONTROLLER_TAG --image $CONTROLLER_IMAGE:$CONTROLLER_TAG
az acr import --name $REGISTRY_NAME --source $SOURCE_REGISTRY/$PATCH_IMAGE:$PATCH_TAG --image $PATCH_IMAGE:$PATCH_TAG
az acr import --name $REGISTRY_NAME --source $SOURCE_REGISTRY/$DEFAULTBACKEND_IMAGE:$DEFAULTBACKEND_TAG --image $DEFAULTBACKEND_IMAGE:$DEFAULTBACKEND_TAG

Uwaga

Oprócz importowania obrazów kontenerów do usługi ACR można również zaimportować wykresy helm do usługi ACR. Aby uzyskać więcej informacji, zobacz Wypychanie i ściąganie wykresów helm do usługi Azure Container Registry.

Tworzenie kontrolera ruchu przychodzącego

Aby utworzyć kontroler ruchu przychodzącego, użyj programu Helm, aby zainstalować element ingress-nginx. Kontroler ruchu przychodzącego musi być zaplanowany w węźle systemu Linux. Nie należy go uruchamiać w węzłach z systemem Windows Server. Za pomocą parametru --set nodeSelector podaje się selektor węzła, który nakazuje harmonogramowi usługi Kubernetes uruchomienie kontrolera wejściowego NGINX w węźle opartym na systemie Linux.

W celu zwiększenia nadmiarowości za pomocą parametru --set controller.replicaCount wdrażane są dwie repliki kontrolerów wejściowych NGINX. Aby w pełni korzystać z uruchomionych replik kontrolera ruchu przychodzącego, upewnij się, że w klastrze usługi AKS znajduje się więcej niż jeden węzeł.

Poniższy przykład tworzy przestrzeń nazw kubernetes dla zasobów przychodzących o nazwie ingress-basic i ma działać w tej przestrzeni nazw. Określ przestrzeń nazw dla własnego środowiska zgodnie z potrzebami. Jeśli klaster usługi AKS nie jest włączony kontrolą dostępu opartą na rolach platformy Kubernetes, dodaj --set rbac.create=false do poleceń programu Helm.

Uwaga

Jeśli chcesz włączyć zachowywanie źródłowego adresu IP klienta dla żądań do kontenerów w klastrze, dodaj --set controller.service.externalTrafficPolicy=Local polecenie instalacji programu Helm. Źródłowy adres IP klienta jest przechowywany w nagłówku żądania w obszarze X-Forwarded-For. Jeśli używasz kontrolera ruchu przychodzącego z włączonym zachowaniem źródłowego adresu IP klienta, przekazywanie protokołu TLS nie będzie działać.

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

# Set variable for ACR location to use for pulling images
ACR_LOGIN_SERVER=<REGISTRY_LOGIN_SERVER>

# Use Helm to deploy an NGINX ingress controller
helm install ingress-nginx ingress-nginx/ingress-nginx \
    --version 4.7.1 \
    --namespace ingress-basic \
    --create-namespace \
    --set controller.replicaCount=2 \
    --set controller.nodeSelector."kubernetes\.io/os"=linux \
    --set controller.image.registry=$ACR_LOGIN_SERVER \
    --set controller.image.image=$CONTROLLER_IMAGE \
    --set controller.image.tag=$CONTROLLER_TAG \
    --set controller.image.digest="" \
    --set controller.admissionWebhooks.patch.nodeSelector."kubernetes\.io/os"=linux \
    --set controller.service.annotations."service\.beta\.kubernetes\.io/azure-load-balancer-health-probe-request-path"=/healthz \
    --set controller.service.externalTrafficPolicy=Local \
    --set controller.admissionWebhooks.patch.image.registry=$ACR_LOGIN_SERVER \
    --set controller.admissionWebhooks.patch.image.image=$PATCH_IMAGE \
    --set controller.admissionWebhooks.patch.image.tag=$PATCH_TAG \
    --set controller.admissionWebhooks.patch.image.digest="" \
    --set defaultBackend.nodeSelector."kubernetes\.io/os"=linux \
    --set defaultBackend.image.registry=$ACR_LOGIN_SERVER \
    --set defaultBackend.image.image=$DEFAULTBACKEND_IMAGE \
    --set defaultBackend.image.tag=$DEFAULTBACKEND_TAG \
    --set defaultBackend.image.digest=""

Tworzenie kontrolera ruchu przychodzącego przy użyciu wewnętrznego adresu IP

Domyślnie kontroler ruchu przychodzącego NGINX jest tworzony przy użyciu dynamicznego przypisania publicznego adresu IP. Typowym wymaganiem konfiguracyjnym jest użycie wewnętrznej, prywatnej sieci i adresu IP. Takie podejście umożliwia ograniczenie dostępu do usług użytkownikom wewnętrznym bez dostępu zewnętrznego.

--set controller.service.loadBalancerIP Użyj parametrów i--set controller.service.annotations."service\.beta\.kubernetes\.io/azure-load-balancer-internal"=true, aby przypisać wewnętrzny adres IP do kontrolera ruchu przychodzącego. Podaj własny wewnętrzny adres IP do użycia z kontrolerem ruchu przychodzącego. Upewnij się, że ten adres IP nie jest jeszcze używany w sieci wirtualnej. Jeśli używasz istniejącej sieci wirtualnej i podsieci, musisz skonfigurować klaster usługi AKS z odpowiednimi uprawnieniami do zarządzania siecią wirtualną i podsiecią. Aby uzyskać więcej informacji, zobacz Use kubenet networking with your own IP address ranges in Azure Kubernetes Service (AKS) or Configure Azure CNI networking in Azure Kubernetes Service (AKS) (Konfigurowanie sieci usługi Azure CNI w usłudze Azure Kubernetes Service (AKS).

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

# Set variable for ACR location to use for pulling images
ACR_LOGIN_SERVER=<REGISTRY_LOGIN_SERVER>

# Use Helm to deploy an NGINX ingress controller
helm install ingress-nginx ingress-nginx/ingress-nginx \
    --version 4.7.1 \
    --namespace ingress-basic \
    --create-namespace \
    --set controller.replicaCount=2 \
    --set controller.nodeSelector."kubernetes\.io/os"=linux \
    --set controller.image.registry=$ACR_LOGIN_SERVER \
    --set controller.image.image=$CONTROLLER_IMAGE \
    --set controller.image.tag=$CONTROLLER_TAG \
    --set controller.image.digest="" \
    --set controller.admissionWebhooks.patch.nodeSelector."kubernetes\.io/os"=linux \
    --set controller.service.loadBalancerIP=10.224.0.42 \
    --set controller.service.annotations."service\.beta\.kubernetes\.io/azure-load-balancer-internal"=true \
    --set controller.service.annotations."service\.beta\.kubernetes\.io/azure-load-balancer-health-probe-request-path"=/healthz \
    --set controller.admissionWebhooks.patch.image.registry=$ACR_LOGIN_SERVER \
    --set controller.admissionWebhooks.patch.image.image=$PATCH_IMAGE \
    --set controller.admissionWebhooks.patch.image.tag=$PATCH_TAG \
    --set controller.admissionWebhooks.patch.image.digest="" \
    --set defaultBackend.nodeSelector."kubernetes\.io/os"=linux \
    --set defaultBackend.image.registry=$ACR_LOGIN_SERVER \
    --set defaultBackend.image.image=$DEFAULTBACKEND_IMAGE \
    --set defaultBackend.image.tag=$DEFAULTBACKEND_TAG \
    --set defaultBackend.image.digest=""

Sprawdzanie usługi modułu równoważenia obciążenia

Sprawdź usługę modułu równoważenia obciążenia przy użyciu polecenia kubectl get services.

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

Po utworzeniu usługi modułu równoważenia obciążenia Kubernetes dla kontrolera ruchu przychodzącego NGINX adres IP jest przypisywany w obszarze EXTERNAL-IP, jak pokazano w następujących przykładowych danych wyjściowych:

NAME                       TYPE           CLUSTER-IP    EXTERNAL-IP     PORT(S)                      AGE   SELECTOR
ingress-nginx-controller   LoadBalancer   10.0.65.205   EXTERNAL-IP     80:30957/TCP,443:32414/TCP   1m   app.kubernetes.io/component=controller,app.kubernetes.io/instance=ingress-nginx,app.kubernetes.io/name=ingress-nginx

Jeśli na tym etapie przechodzisz do zewnętrznego adresu IP, zostanie wyświetlona strona 404. Jest to spowodowane tym, że nadal trzeba skonfigurować połączenie z zewnętrznym adresem IP, co jest wykonywane w następnych sekcjach.

Uruchamianie aplikacji demonstracyjnych

Aby zobaczyć, jak działa kontroler ruchu przychodzącego, uruchom dwie aplikacje demonstracyjne w klastrze usługi AKS. W tym przykładzie użyjesz polecenia kubectl apply , aby wdrożyć dwa wystąpienia prostej aplikacji Hello world .

  1. aks-helloworld-one.yaml Utwórz plik i skopiuj go w następującym przykładzie YAML:

    apiVersion: apps/v1
kind: Deployment
metadata:
  name: aks-helloworld-one  
spec:
  replicas: 1
  selector:
    matchLabels:
      app: aks-helloworld-one
  template:
    metadata:
      labels:
        app: aks-helloworld-one
    spec:
      containers:
      - name: aks-helloworld-one
        image: mcr.microsoft.com/azuredocs/aks-helloworld:v1
        ports:
        - containerPort: 80
        env:
        - name: TITLE
          value: "Welcome to Azure Kubernetes Service (AKS)"
---
apiVersion: v1
kind: Service
metadata:
  name: aks-helloworld-one  
spec:
  type: ClusterIP
  ports:
  - port: 80
  selector:
    app: aks-helloworld-one

  2. aks-helloworld-two.yaml Utwórz plik i skopiuj go w następującym przykładzie YAML:

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

  3. Uruchom dwie aplikacje demonstracyjne przy użyciu polecenia kubectl apply:

    kubectl apply -f aks-helloworld-one.yaml --namespace ingress-basic
kubectl apply -f aks-helloworld-two.yaml --namespace ingress-basic

Tworzenie trasy ruchu przychodzącego

Obie aplikacje są teraz uruchomione w klastrze Kubernetes. Aby kierować ruch do każdej aplikacji, utwórz zasób ruchu przychodzącego Kubernetes. Zasób ruchu przychodzącego konfiguruje reguły kierujące ruch do jednej z dwóch aplikacji.

W poniższym przykładzie ruch do EXTERNAL_IP/hello-world-one jest kierowany do usługi o nazwie aks-helloworld-one. Ruch do EXTERNAL_IP/hello-world-two jest kierowany do aks-helloworld-two usługi. Ruch do EXTERNAL_IP/statyczny jest kierowany do usługi o nazwie aks-helloworld-one dla zasobów statycznych.

  1. Utwórz plik o nazwie hello-world-ingress.yaml i skopiuj w poniższym przykładzie YAML:

    apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: hello-world-ingress
  annotations:
    nginx.ingress.kubernetes.io/ssl-redirect: "false"
    nginx.ingress.kubernetes.io/use-regex: "true"
    nginx.ingress.kubernetes.io/rewrite-target: /$2
spec:
  ingressClassName: nginx
  rules:
  - http:
      paths:
      - path: /hello-world-one(/|$)(.*)
        pathType: Prefix
        backend:
          service:
            name: aks-helloworld-one
            port:
              number: 80
      - path: /hello-world-two(/|$)(.*)
        pathType: Prefix
        backend:
          service:
            name: aks-helloworld-two
            port:
              number: 80
      - path: /(.*)
        pathType: Prefix
        backend:
          service:
            name: aks-helloworld-one
            port:
              number: 80
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: hello-world-ingress-static
  annotations:
    nginx.ingress.kubernetes.io/ssl-redirect: "false"
    nginx.ingress.kubernetes.io/rewrite-target: /static/$2
spec:
  ingressClassName: nginx
  rules:
  - http:
      paths:
      - path: /static(/|$)(.*)
        pathType: Prefix
        backend:
          service:
            name: aks-helloworld-one
            port: 
              number: 80

  2. Utwórz zasób ruchu przychodzącego kubectl apply przy użyciu polecenia .

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

Testowanie kontrolera ruchu przychodzącego

Aby przetestować trasy dla kontrolera ruchu przychodzącego, przejdź do dwóch aplikacji. Otwórz przeglądarkę internetową na adres IP kontrolera ruchu przychodzącego NGINX, na przykład EXTERNAL_IP. Pierwsza aplikacja demonstracyjna jest wyświetlana w przeglądarce internetowej, jak pokazano w poniższym przykładzie:

First app running behind the ingress controller

Teraz dodaj ścieżkę /hello-world-two do adresu IP, na przykład EXTERNAL_IP/hello-world-two. Zostanie wyświetlona druga aplikacja demonstracyjna z tytułem niestandardowym:

Second app running behind the ingress controller

Testowanie wewnętrznego adresu IP

  1. Utwórz zasobnik testowy i dołącz do niego sesję terminalu.

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

  2. Zainstaluj curl w zasobniku przy użyciu polecenia apt-get.

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

  3. Uzyskaj dostęp do adresu kontrolera ruchu przychodzącego Kubernetes przy użyciu polecenia curl, takiego jak http://10.224.0.42. Podaj własny wewnętrzny adres IP określony podczas wdrażania kontrolera ruchu przychodzącego.

    curl -L http://10.224.0.42

    Nie podano żadnej ścieżki z adresem, więc kontroler ruchu przychodzącego domyślnie jest kierowany / do trasy. Zwracana jest pierwsza aplikacja demonstracyjna, jak pokazano w następujących skondensowanych przykładowych danych wyjściowych:

    <!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
    <link rel="stylesheet" type="text/css" href="/static/default.css">
    <title>Welcome to Azure Kubernetes Service (AKS)</title>
[...]

  4. Dodaj ścieżkę /hello-world-two do adresu, na przykład http://10.224.0.42/hello-world-two.

    curl -L -k http://10.224.0.42/hello-world-two

    Zwracana jest druga aplikacja demonstracyjna z tytułem niestandardowym, jak pokazano w następujących skondensowanych przykładowych danych wyjściowych:

    <!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
    <link rel="stylesheet" type="text/css" href="/static/default.css">
    <title>AKS Ingress Demo</title>
[...]

Czyszczenie zasobów

W tym artykule użyto programu Helm do zainstalowania składników ruchu przychodzącego 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

Aby usunąć całą przykładową przestrzeń nazw, użyj kubectl delete polecenia i określ nazwę przestrzeni nazw. Wszystkie zasoby w przestrzeni nazw są usuwane.

kubectl delete namespace ingress-basic

Usuwanie zasobów indywidualnie

Alternatywnie bardziej szczegółowe podejście polega na usunięciu utworzonych pojedynczych zasobów.

  1. Wyświetl listę wydań programu Helm za helm list pomocą polecenia .

    helm list --namespace ingress-basic

    Poszukaj wykresów o nazwach ingress-nginx i aks-helloworld, jak pokazano w następujących przykładowych danych wyjściowych:

    NAME                    NAMESPACE       REVISION        UPDATED                                 STATUS          CHART                   APP VERSION
ingress-nginx           ingress-basic   1               2020-01-06 19:55:46.358275 -0600 CST    deployed        nginx-ingress-1.27.1    0.26.1

  2. Odinstaluj wydania za helm uninstall pomocą polecenia .

    helm uninstall ingress-nginx --namespace ingress-basic

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

  4. Usuń trasę ruchu przychodzącego, która kierowała ruch do przykładowych aplikacji.

    kubectl delete -f hello-world-ingress.yaml

  5. Usuń przestrzeń nazw przy użyciu kubectl delete polecenia i określ nazwę przestrzeni nazw.

    kubectl delete namespace ingress-basic

Następne kroki

Aby skonfigurować protokół TLS przy użyciu istniejących składników ruchu przychodzącego, zobacz Używanie protokołu TLS z kontrolerem ruchu przychodzącego.

Aby skonfigurować klaster usługi AKS do korzystania z routingu aplikacji HTTP, zobacz Włączanie dodatku routingu aplikacji HTTP.

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: