Tworzenie niezarządzanego kontrolera ruchu przychodzącego
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 16.
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
healthzkondycji interfejsu API platformy Kubernetes został wycofany w wersji 1.16 platformy Kubernetes. Ten punkt końcowylivezmożna zastąpić zamiast tego punktami końcowymi ireadyz. 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 musisz zainstalować lub uaktualnić, zobacz [Instalowanie interfejsu wiersza polecenia platformy Azure][azure-cli-install]. - 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 16.
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 16.
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 16.
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 16.
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 .
aks-helloworld-one.yamlUtwó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-oneaks-helloworld-two.yamlUtwó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-twoUruchom 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.
Utwórz plik o nazwie
hello-world-ingress.yamli 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: 80Utwórz zasób ruchu przychodzącego
kubectl applyprzy 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:
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:
Testowanie wewnętrznego adresu IP
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-basicZainstaluj
curlw zasobniku przy użyciu poleceniaapt-get.apt-get update && apt-get install -y curlUzyskaj 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.42Nie 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> [...]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-twoZwracana 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.
Wyświetl listę wydań programu Helm za
helm listpomocą polecenia .helm list --namespace ingress-basicPoszukaj 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.1Odinstaluj wydania za
helm uninstallpomocą polecenia .helm uninstall ingress-nginx --namespace ingress-basicUsuń dwie przykładowe aplikacje.
kubectl delete -f aks-helloworld-one.yaml --namespace ingress-basic kubectl delete -f aks-helloworld-two.yaml --namespace ingress-basicUsuń trasę ruchu przychodzącego, która kierowała ruch do przykładowych aplikacji.
kubectl delete -f hello-world-ingress.yamlUsuń przestrzeń nazw przy użyciu
kubectl deletepolecenia 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:
Skontaktuj się z nami, aby uzyskać pomoc
Jeśli masz pytania lub potrzebujesz pomocy, utwórz wniosek o pomoc techniczną lub zadaj pytanie w społeczności wsparcia dla platformy Azure. Możesz również przesłać opinię o produkcie do społeczności opinii na temat platformy Azure.