Udostępnij za pomocą

Zaawansowany kontroler wejściowy NGINX i konfiguracje wejściowe z dodatkiem do routingu aplikacji dla usługi Azure Kubernetes Service (AKS)

W tym artykule przedstawiono dwa sposoby konfigurowania kontrolerów ruchu przychodzącego i obiektów przychodzących za pomocą dodatku routingu aplikacji dla usługi Azure Kubernetes Service (AKS):

  • Konfiguracja kontrolera ruchu przychodzącego NGINX, na przykład tworzenie wielu kontrolerów, konfigurowanie prywatnych modułów równoważenia obciążenia i ustawianie statycznych adresów IP.
  • Konfiguracja zasobu ruchu przychodzącego za pomocą adnotacji.

Wymagania wstępne

Nawiązywanie połączenia z klastrem usługi AKS

Aby nawiązać połączenie z klastrem Kubernetes z komputera lokalnego, należy użyć kubectlklienta wiersza polecenia kubernetes. Możesz zainstalować ją lokalnie przy użyciu az aks install-cli polecenia . Jeśli korzystasz z usługi Azure Cloud Shell, narzędzie kubectl jest już zainstalowane.

  • Skonfiguruj narzędzie kubectl, aby nawiązać połączenie z klastrem az aks get-credentials Kubernetes przy użyciu polecenia .

    az aks get-credentials --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME

Właściwości konfiguracji dla kontrolerów wejściowych NGINX

Dodatek routingu aplikacji używa niestandardowej definicji zasobów Kubernetes (CRD) wywoływanej NginxIngressController do konfigurowania kontrolerów ruchu przychodzącego NGINX. Można utworzyć więcej kontrolerów ruchu przychodzącego lub zmodyfikować istniejące konfiguracje.

W poniższej tabeli wymieniono właściwości, które można ustawić w celu skonfigurowania elementu NginxIngressController:

(No changes needed) Typ opis Wymagane Wartość domyślna
controllerNamePrefix ciąg Nazwa dla zarządzanych zasobów NGINX Ingress Controller. Tak nginx
customHTTPErrors macierz Tablica kodów błędów, które mają być wysyłane do domyślnego zaplecza, jeśli wystąpi błąd. Nie.
defaultBackendService obiekt Usługa przekierowywania niezidentyfikowanego ruchu HTTP. Zawiera zagnieżdżone właściwości: Nie.
 name ciąg Nazwa usługi. Tak
 namespace ciąg Przestrzeń nazw usługi. Tak
defaultSSLCertificate obiekt Zawiera certyfikat domyślny na potrzeby uzyskiwania dostępu do domyślnej usługi zaplecza. Zawiera zagnieżdżone właściwości: Nie.
 forceSSLRedirect typ logiczny (boolowski) Wymusza przekierowanie HTTPS po ustawieniu certyfikatu. Nie. false
 keyVaultURI ciąg URI dla tajemnicy w Key Vault, która przechowuje certyfikat. Nie.
 secret obiekt Przechowuje informacje tajne dla domyślnego certyfikatu SSL. Zawiera zagnieżdżone właściwości: Nie.
  name ciąg Nazwa wpisu tajnego. Tak
  namespace ciąg Tajna przestrzeń nazw. Tak
httpDisabled typ logiczny (boolowski) Flaga do wyłączenia ruchu HTTP do kontrolera. Nie.
ingressClassName ciąg IngressClass nazwa używana przez kontroler. Tak nginx.approuting.kubernetes.azure.com
loadBalancerAnnotations obiekt Mapa adnotacji do kontrolowania zachowania usługi kontrolera wejściowego NGINX przez ustawienie adnotacji równoważnika obciążenia. Nie.
scaling obiekt Konfiguracja skalowania kontrolera. Zawiera zagnieżdżone właściwości: Nie.
 maxReplicas liczba całkowita Górny limit dla replik. Nie. 100
 minReplicas liczba całkowita Niższy limit dla replik. Nie. 2
 threshold ciąg Próg skalowania definiujący, jak agresywnie skalować. rapid szybko skaluje się pod kątem nagłych skoków, steady sprzyja opłacalności i balanced jest mieszanką. Nie. balanced

Kontrolowanie domyślnej konfiguracji kontrolera wejściowego NGINX

Po włączeniu dodatku routingu aplikacji z serwerem NGINX tworzy kontroler ruchu przychodzącego wywoływany default w app-routing-namespace skonfigurowanym publicznym module równoważenia obciążenia platformy Azure. Ten kontroler ruchu przychodzącego używa nazwy klasy ruchu przychodzącego webapprouting.kubernetes.azure.com.

Możesz również kontrolować, czy ustawienie domyślne pobiera publiczny lub wewnętrzny adres IP, albo jeśli zostanie on utworzony w ogóle podczas włączania dodatku.

Możliwe opcje konfiguracji obejmują:

  • None: Domyślny kontroler wejściowy NGINX nie jest tworzony i nie jest usuwany, jeśli już istnieje. Jeśli chcesz, należy usunąć ręcznie domyślny NginxIngressController zasób niestandardowy.
  • Internal: domyślny kontroler ruchu przychodzącego NGINX jest tworzony za pomocą wewnętrznego modułu równoważenia obciążenia. Wszelkie zmiany adnotacji w zasobie niestandardowym NginxIngressController, mające na celu uczynienie go zewnętrznym, zostają nadpisane.
  • External: domyślny kontroler wejścia NGINX utworzony za pomocą zewnętrznego urządzenia równoważącego obciążenie. Wszelkie zmiany adnotacji w zasobie niestandardowym NginxIngressController , aby uczynić je wewnętrznym, zostaną zastąpione.
  • AnnotationControlled (ustawienie domyślne): domyślny kontroler ruchu przychodzącego NGINX jest tworzony za pomocą zewnętrznego modułu równoważenia obciążenia. Możesz edytować domyślny NginxIngressController zasób niestandardowy, aby skonfigurować adnotacje modułu równoważenia obciążenia).

Kontrolowanie domyślnej konfiguracji kontrolera ingress w nowym klastrze

  • Włącz routing aplikacji w nowym klastrze przy użyciu polecenia az aks create z opcjami --enable-app-routing i --app-routing-default-nginx-controller. Należy ustawić <DefaultIngressControllerType> na jedną z opcji konfiguracji opisanych w Kontrolowanie domyślnej konfiguracji kontrolera NGINX dla ruchu przychodzącego.

    az aks create \
  --resource-group $RESOURCE_GROUP \
  --name $CLUSTER_NAME \
  --location $LOCATION \
  --enable-app-routing \
  --app-routing-default-nginx-controller <DefaultIngressControllerType>

Aktualizowanie domyślnej konfiguracji kontrolera ruchu przychodzącego w istniejącym klastrze

Tworzenie innego publicznego kontrolera ruchu przychodzącego NGINX

  1. Skopiuj następujący manifest YAML do nowego pliku o nazwie nginx-public-controller.yaml i zapisz plik na komputerze lokalnym.

    apiVersion: approuting.kubernetes.azure.com/v1alpha1
kind: NginxIngressController
metadata:
  name: nginx-public
spec:
  ingressClassName: nginx-public
  controllerNamePrefix: nginx-public

  2. Utwórz zasoby kontrolera ruchu przychodzącego NGINX przy użyciu kubectl apply polecenia .

    kubectl apply -f nginx-public-controller.yaml

    W poniższych przykładowych danych wyjściowych przedstawiono utworzony zasób:

    nginxingresscontroller.approuting.kubernetes.azure.com/nginx-public created

Tworzenie wewnętrznego kontrolera ruchu przychodzącego NGINX z prywatnym adresem IP

  1. Skopiuj następujący manifest YAML do nowego pliku o nazwie nginx-internal-controller.yaml i zapisz plik na komputerze lokalnym.

    apiVersion: approuting.kubernetes.azure.com/v1alpha1
kind: NginxIngressController
metadata:
  name: nginx-internal
spec:
  ingressClassName: nginx-internal
  controllerNamePrefix: nginx-internal
  loadBalancerAnnotations: 
    service.beta.kubernetes.io/azure-load-balancer-internal: "true"

  2. Utwórz zasoby kontrolera ruchu przychodzącego NGINX przy użyciu kubectl apply polecenia .

    kubectl apply -f nginx-internal-controller.yaml

    W poniższych przykładowych danych wyjściowych przedstawiono utworzony zasób:

    nginxingresscontroller.approuting.kubernetes.azure.com/nginx-internal created

Tworzenie kontrolera ruchu przychodzącego NGINX ze statycznym adresem IP

  1. Utwórz grupę zasobów platformy Azure przy użyciu az group create polecenia .

    az group create --name $NETWORK_RESOURCE_GROUP --location $LOCATION

  2. Utwórz statyczny publiczny adres IP przy użyciu az network public ip create polecenia .

    az network public-ip create \
  --resource-group $NETWORK_RESOURCE_GROUP \
  --name $PUBLIC_IP_NAME \
  --sku Standard \
  --allocation-method static

    Uwaga

    Jeśli używasz modułu równoważenia obciążenia SKU Basic w klastrze AKS, użyj dla parametru Basic podczas określania publicznego adresu IP. Tylko Basic adresy IP SKU działają z modułem równoważenia obciążenia w warstwie Podstawowa i tylko Standard adresy IP SKU działają z modułami równoważenia obciążenia w warstwie Standardowa.

  3. Upewnij się, że tożsamość klastra używana przez klaster usługi AKS ma delegowane uprawnienia do grupy zasobów publicznego adresu IP przy użyciu az role assignment create polecenia .

    CLIENT_ID=$(az aks show --name $CLUSTER_NAME --resource-group $RESOURCE_GROUP --query identity.principalId -o tsv)
RG_SCOPE=$(az group show --name $NETWORK_RESOURCE_GROUP --query id -o tsv)
az role assignment create \
  --assignee ${CLIENT_ID} \
  --role "Network Contributor" \
  --scope ${RG_SCOPE}

  4. Skopiuj następujący manifest YAML do nowego pliku o nazwie nginx-staticip-controller.yaml i zapisz plik na komputerze lokalnym.

    Uwaga

    Możesz użyć nazwy service.beta.kubernetes.io/azure-pip-name publicznego adresu IP lub użyć service.beta.kubernetes.io/azure-load-balancer-ipv4 dla adresu IPv4 i service.beta.kubernetes.io/azure-load-balancer-ipv6 adresu IPv6, jak pokazano w przykładzie YAML. Dodanie adnotacji service.beta.kubernetes.io/azure-pip-name zapewnia najbardziej wydajne tworzenie równoważenia obciążenia i zdecydowanie zalecane jest, aby uniknąć potencjalnego ograniczania przepustowości.

    apiVersion: approuting.kubernetes.azure.com/v1alpha1
kind: NginxIngressController
metadata:
  name: nginx-static
spec:
  ingressClassName: nginx-static
  controllerNamePrefix: nginx-static
  loadBalancerAnnotations: 
    service.beta.kubernetes.io/azure-pip-name: "$PUBLIC_IP_NAME"
    service.beta.kubernetes.io/azure-load-balancer-resource-group: "$NETWORK_RESOURCE_GROUP"

  5. Utwórz zasoby kontrolera ruchu przychodzącego NGINX przy użyciu kubectl apply polecenia .

    kubectl apply -f nginx-staticip-controller.yaml

    W poniższych przykładowych danych wyjściowych przedstawiono utworzony zasób:

    nginxingresscontroller.approuting.kubernetes.azure.com/nginx-static created

Sprawdź, czy kontroler ruchu przychodzącego został utworzony

  • Sprawdź stan kontrolera wejściowego NGINX przy użyciu polecenia kubectl get nginxingresscontroller.

    kubectl get nginxingresscontroller --name $INGRESS_CONTROLLER_NAME

    Poniższe przykładowe dane wyjściowe pokazują utworzony zasób. Udostępnienie kontrolera może potrwać kilka minut:

    NAME           INGRESSCLASS   CONTROLLERNAMEPREFIX   AVAILABLE
nginx-public   nginx-public   nginx                  True

Wyświetl warunki kontrolera wejściowego

  • Wyświetl warunki kontrolera ruchu przychodzącego, aby rozwiązać wszelkie problemy przy użyciu kubectl get nginxingresscontroller polecenia .

    kubectl get nginxingresscontroller --name $INGRESS_CONTROLLER_NAME -o jsonpath='{range .items[*].status.conditions[*]}{.lastTransitionTime}{"\t"}{.status}{"\t"}{.type}{"\t"}{.message}{"\n"}{end}'

    W poniższych przykładowych danych wyjściowych przedstawiono warunki kontrolera ruchu przychodzącego w dobrej kondycji:

    2023-11-29T19:59:24Z    True    IngressClassReady       Ingress Class is up-to-date
2023-11-29T19:59:50Z    True    Available               Controller Deployment has minimum availability and IngressClass is up-to-date
2023-11-29T19:59:50Z    True    ControllerAvailable     Controller Deployment is available
2023-11-29T19:59:25Z    True    Progressing             Controller Deployment has successfully progressed

Używanie kontrolera ruchu przychodzącego w ruchu przychodzącym

  1. Skopiuj następujący manifest YAML do nowego pliku o nazwie ingress.yaml i zapisz plik na komputerze lokalnym.

    Uwaga

    Zaktualizuj <HostName> przy użyciu nazwy hosta DNS. Jest <IngressClassName> to element zdefiniowany podczas tworzenia obiektu NginxIngressController.

    apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: aks-helloworld
  namespace: hello-web-app-routing
spec:
  ingressClassName: <IngressClassName>
  rules:
  - host: <HostName>
    http:
      paths:
      - backend:
          service:
            name: aks-helloworld
            port:
              number: 80
        path: /
        pathType: Prefix

  2. Utwórz zasoby klastra przy użyciu kubectl apply polecenia .

    kubectl apply -f ingress.yaml --namespace hello-web-app-routing

    W poniższych przykładowych danych wyjściowych przedstawiono utworzony zasób:

    ingress.networking.k8s.io/aks-helloworld created

Sprawdź, czy utworzono zarządzany punkt wejścia

  • Sprawdź, czy zarządzane wejście zostało utworzone przy użyciu polecenia kubectl get ingress.

    kubectl get ingress --namespace hello-web-app-routing

    Dane wyjściowe powinny przypominać następujące przykładowe dane wyjściowe:

    NAME             CLASS                                HOSTS               ADDRESS       PORTS     AGE
aks-helloworld   webapprouting.kubernetes.azure.com   myapp.contoso.com   20.51.92.19   80, 443   4m

Usuwanie kontrolerów ruchu przychodzącego

Konfiguracja zasobu ruchu przychodzącego za pomocą adnotacji

Kontroler wejścia NGINX obsługuje dodawanie adnotacji do określonych obiektów wejściowych w celu dostosowania ich zachowania.

Możesz dodać adnotację do obiektu ruchu przychodzącego, dodając odpowiednią adnotację metadata.annotations w polu.

Uwaga

Klucze adnotacji i wartości mogą być tylko ciągami. Inne typy, takie jak wartości logiczne lub liczbowe, muszą być cytowane. Na przykład: "true", , "false""100".

W poniższych sekcjach przedstawiono przykłady typowych konfiguracji. Pełną listę można znaleźć w dokumentacji adnotacji ruchu przychodzącego NGINX.

Niestandardowy maksymalny rozmiar treści

W przypadku serwera NGINX do klienta jest zwracany błąd 413, gdy rozmiar żądania przekracza maksymalny dozwolony rozmiar treści żądania klienta. Aby zastąpić wartość domyślną, użyj adnotacji:

nginx.ingress.kubernetes.io/proxy-body-size: 4m

Oto przykładowa konfiguracja ruchu przychodzącego przy użyciu tej adnotacji:

Uwaga

Zaktualizuj <HostName> przy użyciu nazwy hosta DNS. Jest <IngressClassName> to element zdefiniowany podczas tworzenia obiektu NginxIngressController.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: aks-helloworld
  namespace: hello-web-app-routing
  annotations:
    nginx.ingress.kubernetes.io/proxy-body-size: 4m
spec:
  ingressClassName: <IngressClassName>
  rules:
  - host: <HostName>
    http:
      paths:
      - backend:
          service:
            name: aks-helloworld
            port:
              number: 80
        path: /
        pathType: Prefix

Niestandardowy limit czasu połączenia

Możesz zmienić limit czasu, jaki kontroler ingress NGINX czeka na zamknięcie połączenia z obciążeniem. Wszystkie wartości limitu czasu są bez jednostek i podawane w sekundach. Aby zastąpić domyślny limit czasu, użyj następującej adnotacji, aby ustawić prawidłowy limit czasu odczytu serwera proxy 120 sekund:

nginx.ingress.kubernetes.io/proxy-read-timeout: "120"

Sprawdź niestandardowe limity czasu pod kątem innych opcji konfiguracji.

Oto przykładowa konfiguracja ruchu przychodzącego przy użyciu tej adnotacji:

Uwaga

Zaktualizuj <HostName> przy użyciu nazwy hosta DNS. Jest <IngressClassName> to element zdefiniowany podczas tworzenia obiektu NginxIngressController.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: aks-helloworld
  namespace: hello-web-app-routing
  annotations:
    nginx.ingress.kubernetes.io/proxy-read-timeout: "120"
spec:
  ingressClassName: <IngressClassName>
  rules:
  - host: <HostName>
    http:
      paths:
      - backend:
          service:
            name: aks-helloworld
            port:
              number: 80
        path: /
        pathType: Prefix

Protokół zaplecza

Kontroler wejściowy NGINX używa HTTP domyślnie do uzyskiwania dostępu do usług. Aby skonfigurować alternatywne protokoły zaplecza, takie jak HTTPS lub GRPC, użyj jednej z następujących adnotacji:

# HTTPS annotation
nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"

# GRPC annotation
nginx.ingress.kubernetes.io/backend-protocol: "GRPC"

Przejrzyj protokoły zaplecza pod kątem innych opcji konfiguracji.

Oto przykładowa konfiguracja ruchu przychodzącego przy użyciu tej adnotacji:

Uwaga

Zaktualizuj <HostName> przy użyciu nazwy hosta DNS. Jest <IngressClassName> to element zdefiniowany podczas tworzenia obiektu NginxIngressController.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: aks-helloworld
  namespace: hello-web-app-routing
  annotations:
    nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"
spec:
  ingressClassName: <IngressClassName>
  rules:
  - host: <HostName>
    http:
      paths:
      - backend:
          service:
            name: aks-helloworld
            port:
              number: 80
        path: /
        pathType: Prefix

Udostępnianie zasobów z różnych źródeł (CORS)

Aby włączyć Cross-Origin Resource Sharing (CORS) w regule Ingress, użyj następującej adnotacji:

nginx.ingress.kubernetes.io/enable-cors: "true"

Przejrzyj artykuł Enable CORS (Włączanie mechanizmu CORS ) dla innych opcji konfiguracji.

Oto przykładowa konfiguracja ruchu przychodzącego przy użyciu tej adnotacji:

Uwaga

Zaktualizuj <HostName> przy użyciu nazwy hosta DNS. Jest <IngressClassName> to element zdefiniowany podczas tworzenia obiektu NginxIngressController.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: aks-helloworld
  namespace: hello-web-app-routing
  annotations:
    nginx.ingress.kubernetes.io/enable-cors: "true"
spec:
  ingressClassName: <IngressClassName>
  rules:
  - host: <HostName>
    http:
      paths:
      - backend:
          service:
            name: aks-helloworld
            port:
              number: 80
        path: /
        pathType: Prefix

Wyłączanie przekierowania SSL

Kontroler przekierowuje (308) do protokołu HTTPS, jeśli protokół TLS jest domyślnie włączony dla ruchu przychodzącego. Aby wyłączyć tę funkcję dla określonych zasobów ruchu przychodzącego, użyj następującej adnotacji:

nginx.ingress.kubernetes.io/ssl-redirect: "false"

Przejrzyj wymuszanie protokołu HTTPS po stronie serwera za pośrednictwem przekierowania , aby uzyskać inne opcje konfiguracji.

Oto przykładowa konfiguracja ruchu przychodzącego przy użyciu tej adnotacji:

Uwaga

Zaktualizuj <HostName> przy użyciu nazwy hosta DNS. Jest <IngressClassName> to element zdefiniowany podczas tworzenia obiektu NginxIngressController.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: aks-helloworld
  namespace: hello-web-app-routing
  annotations:
    nginx.ingress.kubernetes.io/ssl-redirect: "false"
spec:
  ingressClassName: <IngressClassName>
  rules:
  - host: <HostName>
    http:
      paths:
      - backend:
          service:
            name: aks-helloworld
            port:
              number: 80
        path: /
        pathType: Prefix

Ponowne zapisywanie adresów URL

W niektórych scenariuszach uwidoczniony adres URL w usłudze zaplecza różni się od określonej ścieżki w regule ruchu przychodzącego. Bez ponownego zapisywania żadne żądanie zwraca wartość 404. Ta konfiguracja jest przydatna w przypadku routingu opartego na ścieżkach , w którym można obsługiwać dwie różne aplikacje internetowe w tej samej domenie. Ścieżkę oczekiwaną przez usługę można ustawić przy użyciu następującej adnotacji:

nginx.ingress.kubernetes.io/rewrite-target: /$2

Oto przykładowa konfiguracja ruchu przychodzącego przy użyciu tej adnotacji:

Uwaga

Zaktualizuj <HostName> przy użyciu nazwy hosta DNS. Jest <IngressClassName> to element zdefiniowany podczas tworzenia obiektu NginxIngressController.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: aks-helloworld
  namespace: hello-web-app-routing
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /$2
    nginx.ingress.kubernetes.io/use-regex: "true"
spec:
  ingressClassName: <IngressClassName>
  rules:
  - host: <HostName>
    http:
      paths:
      - path: /app-one(/|$)(.*)
        pathType: Prefix 
        backend:
          service:
            name: app-one
            port:
              number: 80
      - path: /app-two(/|$)(.*)
        pathType: Prefix 
        backend:
          service:
            name: app-two
            port:
              number: 80

Aktualizacja ścieżki sondy kondycji serwera NGINX

Domyślna ścieżka sondy kondycji dla usługi Azure Load Balancer skojarzonej z kontrolerem ingress NGINX musi być ustawiona na "/healthz". Aby sprawdzić poprawność kontroli kondycji, sprawdź, czy usługa kontrolera ruchu przychodzącego ma następującą adnotację:

metadata:
  annotations:
    service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path: "/healthz"

Jeśli używasz programu Helm do zarządzania kontrolerem wejściowym NGINX, możesz zdefiniować adnotację sondy kondycji Azure Load Balancer w pliku wartości i zastosować ją podczas uaktualniania.

controller:
  service:
    annotations:
      service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path: "/healthz"

Ta konfiguracja pomaga zachować dostępność usługi i uniknąć nieoczekiwanych zakłóceń ruchu podczas uaktualniania.

Następne kroki

Dowiedz się więcej o monitorowaniu metryk kontrolera ruchu przychodzącego-nginx dołączonego do dodatku routingu aplikacji za pomocą rozwiązania Prometheus w narzędziu Grafana w ramach analizowania wydajności i użycia aplikacji.

  • Last updated on