Zaawansowane konfiguracje kontrolera ruchu przychodzącego I ruchu przychodzącego NGINX z dodatkiem routingu aplikacji

Artykuł
01/30/2024

Dodatek routingu aplikacji obsługuje dwa sposoby konfigurowania kontrolerów ruchu przychodzącego i obiektów przychodzących:

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

Klaster usługi AKS z dodatkiem routingu aplikacji.

Połączenie do klastra 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 polecenia az aks install-cli . 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 -g <ResourceGroupName> -n <ClusterName>

Konfiguracja kontrolera ruchu przychodzącego 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ącą konfigurację.

NginxIngressController CrD ma loadBalancerAnnotations pole do kontrolowania zachowania usługi kontrolera ruchu przychodzącego NGINX przez ustawienie adnotacji modułu równoważenia obciążenia.

Domyślny kontroler ruchu przychodzącego 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.

Tworzenie innego publicznego kontrolera ruchu przychodzącego NGINX

Aby utworzyć inny kontroler ruchu przychodzącego NGINX z publicznym modułem równoważenia obciążenia platformy Azure:

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

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

Aby utworzyć kontroler ruchu przychodzącego NGINX z wewnętrznym modułem równoważenia obciążenia platformy Azure z prywatnym adresem IP:

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"

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

Aby utworzyć kontroler ruchu przychodzącego NGINX ze statycznym adresem IP w usłudze Azure Load Balancer:

Utwórz grupę zasobów platformy Azure przy użyciu az group create polecenia .
```
az group create --name myNetworkResourceGroup --location eastus
```
Utwórz statyczny publiczny adres IP przy użyciu az network public ip create polecenia .
```
az network public-ip create \
    --resource-group myNetworkResourceGroup \
    --name myIngressPublicIP \
    --sku Standard \
    --allocation-method static
```
Uwaga

Jeśli używasz podstawowego modułu równoważenia obciążenia jednostki SKU w klastrze usługi AKS, użyj parametru Basic dla parametru --sku podczas definiowania publicznego adresu IP. Tylko adresy IP jednostek SKU w warstwie Podstawowa współpracują z modułem równoważenia obciążenia jednostki SKU w warstwie Podstawowa, a tylko adresy IP jednostek SKU w warstwie Standardowa działają z modułami równoważenia obciążenia jednostek SKU w warstwie Standardowa.
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 polecenia [az role assignment create][az-role-assignment-create].

Uwaga

Zaktualizuj <ClusterName> element i <ClusterResourceGroup> przy użyciu nazwy klastra usługi AKS i nazwy grupy zasobów.
```
CLIENT_ID=$(az aks show --name <ClusterName> --resource-group <ClusterResourceGroup> --query identity.principalId -o tsv)
RG_SCOPE=$(az group show --name myNetworkResourceGroup --query id -o tsv)
az role assignment create \
    --assignee ${CLIENT_ID} \
    --role "Network Contributor" \
    --scope ${RG_SCOPE}
```
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 zapewnia najbardziej wydajne tworzenie modułu service.beta.kubernetes.io/azure-pip-name LoadBalancer i zdecydowanie zaleca się uniknięcie 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: "myIngressPublicIP"
    service.beta.kubernetes.io/azure-load-balancer-resource-group: "myNetworkResourceGroup"
```
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

Stan kontrolera ruchu przychodzącego NGINX można sprawdzić przy użyciu kubectl get nginxingresscontroller polecenia .

Uwaga

Zaktualizuj <IngressControllerName> element o nazwie użytej podczas tworzenia "NginxIngressController".

kubectl get nginxingresscontroller -n <IngressControllerName>

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

Możesz również wyświetlić warunki, aby rozwiązać wszelkie problemy:

kubectl get nginxingresscontroller -n <IngressControllerName> -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

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

Utwórz zasoby klastra przy użyciu kubectl apply polecenia .
```
kubectl apply -f ingress.yaml -n 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 ruch przychodzący

Możesz sprawdzić, czy zarządzany ruch przychodzący został utworzony przy użyciu kubectl get ingress polecenia .

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

W poniższych przykładowych danych wyjściowych przedstawiono utworzony zarządzany ruch przychodzący. Klasa ruchu przychodzącego, host i adres IP mogą być różne:

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

Czyszczenie kontrolerów ruchu przychodzącego

Kontroler ruchu przychodzącego NGINX można usunąć przy użyciu kubectl delete nginxingresscontroller polecenia .

Uwaga

Zaktualizuj <IngressControllerName> element o nazwie użytej podczas tworzenia elementu NginxIngressController.

kubectl delete nginxingresscontroller -n <IngressControllerName>

Konfiguracja zasobu ruchu przychodzącego za pomocą adnotacji

Kontroler ruchu przychodzącego NGINX obsługuje dodawanie adnotacji do określonych obiektów ruchu przychodzącego 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, tj. "true", "false", "100".

Poniżej przedstawiono kilka przykładów adnotacji dla typowych konfiguracji. Zapoznaj się z dokumentacją adnotacji przychodzących NGINX, aby uzyskać pełną listę.

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

Limit czasu połączenia niestandardowego

Możesz zmienić limit czasu oczekiwania kontrolera ruchu przychodzącego NGINX na zamknięcie połączenia z obciążeniem. Wszystkie wartości limitu czasu są bezjednostki i 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"

Przejrzyj niestandardowe limity czasu 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/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

Domyślnie kontroler ruchu przychodzącego NGINX używa HTTP do uzyskania dostępu do usług. Aby skonfigurować alternatywne protokoły zaplecza, takie jak HTTPS lub GRPC, użyj adnotacji:

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

lub

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

Aby włączyć współużytkowanie zasobów między źródłami (CORS) w regule ruchu przychodzącego, użyj 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

Domyślnie kontroler przekierowuje (308) do protokołu HTTPS, jeśli protokół TLS jest włączony dla ruchu przychodzącego. Aby wyłączyć tę funkcję dla określonych zasobów przychodzących, użyj 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. Jest to szczególnie przydatne 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 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

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.

Zaawansowane konfiguracje kontrolera ruchu przychodzącego I ruchu przychodzącego NGINX z dodatkiem routingu aplikacji

Wymagania wstępne

Połączenie do klastra usługi AKS

Konfiguracja kontrolera ruchu przychodzącego NGINX

Domyślny kontroler ruchu przychodzącego NGINX

Tworzenie innego publicznego kontrolera ruchu przychodzącego NGINX

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

Tworzenie kontrolera ruchu przychodzącego NGINX ze statycznym adresem IP

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

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

Sprawdź, czy utworzono zarządzany ruch przychodzący

Czyszczenie kontrolerów ruchu przychodzącego

Konfiguracja zasobu ruchu przychodzącego za pomocą adnotacji

Niestandardowy maksymalny rozmiar treści

Limit czasu połączenia niestandardowego

Protokół zaplecza

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

Wyłączanie przekierowania SSL

Ponowne zapisywanie adresów URL

Następne kroki

Dodatkowe zasoby