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

Artykuł
08/14/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.

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 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 -resource-group <ResourceGroupName> --name <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ę.

Oto odwołanie do właściwości, które można ustawić w celu skonfigurowania elementu NginxIngressController.

Właściwości	opis
ingressClassName	Nazwa `IngressClass` , która będzie używana dla kontrolera ruchu przychodzącego NGINX. Wartość domyślna to nazwa elementu `NginxIngressController` , jeśli nie zostanie określona.
controllerNamePrefix	Nazwa używana do prefiksu zarządzanych zasobów kontrolera ruchu przychodzącego NGINX. Wartość domyślna to `nginx`.
loadBalancerAnnotations	Zestaw adnotacji do kontrolowania zachowania usługi kontrolera ruchu przychodzącego NGINX przez ustawienie adnotacji modułu równoważenia obciążenia
Skalowanie	Opcje konfiguracji dotyczące skalowania kontrolera ruchu przychodzącego NGINX.
scaling.minReplicas	Niższy limit liczby replik kontrolera ruchu przychodzącego. Domyślnie jest to 2 zasobniki.
scaling.maxReplicas	Górny limit liczby replik kontrolera ruchu przychodzącego. Domyślnie jest to 100 zasobników.
scaling.threshold	Określa, jak szybko zasobniki kontrolera ruchu przychodzącego NGINX powinny być skalowane na podstawie obciążenia. `Rapid` oznacza, że kontroler ruchu przychodzącego będzie szybko i agresywnie skalowany w celu obsługi nagłych i znaczących skoków ruchu. `Steady` Określa priorytety kosztów dzięki mniejszej liczbie replik obsługujących większą pracę. `Balanced` jest dobrym połączeniem między dwoma, które działa w większości przypadków użycia. Jeśli nie określono, to pole domyślnie ma wartość `Balanced`.
defaultBackendService	Usługa Kubernetes, do której kontroler ruchu przychodzącego NGINX powinien domyślnie obsługiwać wszystkie ścieżki adresów URL i hostuje kontroler Ingress-NGINX nie rozumie (tj. wszystkich żądań, które nie są mapowane na ruch przychodzący). Kontroler kieruje ruch do pierwszego portu usługi. Jeśli nie zostanie określony, zostanie użyta domyślna wewnętrzna baza danych, która jest wbudowana.
defaultBackendService.namespace	Przestrzeń nazw usługi.
defaultBackendService.name	Nazwa usługi.
defaultSSLCertificate	Wpis tajny, do którego odwołuje się ta właściwość, zawiera domyślny certyfikat, który ma być używany podczas uzyskiwania dostępu do domyślnej usługi zaplecza. Jeśli ta właściwość nie zostanie podana, serwer NGINX użyje certyfikatu z podpisem własnym. `tls:` Jeśli sekcja nie jest ustawiona na wejściu, serwer NGINX udostępni certyfikat domyślny, ale nie wymusi przekierowania HTTPS.
defaultSSLCertificate.forceSSLRedirect	Wymusza przekierowanie dla ruchu przychodzącego `tls:` , które nie określają sekcji.
defaultSSLCertificate.keyVaultURI	Identyfikator URI usługi Azure Key Vault, w którym można znaleźć domyślny certyfikat SSL. Dodatek musi być skonfigurowany do korzystania z magazynu kluczy.
defaultSSLCertificate.secret	Konfiguruje nazwę i przestrzeń nazw, w której domyślny wpis tajny SSL znajduje się w klastrze.
defaultSSLCertificate.secret.name	Nazwa wpisu tajnego.
defaultSSLCertificate.secret.namespace	Przestrzeń nazw wpisu tajnego.

Typowe konfiguracje

Kontrolowanie domyślnej konfiguracji kontrolera ruchu przychodzącego NGINX (wersja zapoznawcza)

Uwaga

Kontrolowanie konfiguracji kontrolera ruchu przychodzącego NGINX podczas włączania dodatku jest dostępne w systemie Kubernetes w API 2024-06-02-previewwersji 1.30 lub nowszej oraz wersji rozszerzenia interfejsu wiersza polecenia platformy Azure w wersji 7.0.0b5 zapoznawczej aks-preview lub nowszej. Aby sprawdzić wersję klastra usługi AKS, zobacz Sprawdzanie dostępnych uaktualnień klastra usługi AKS.

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.

Poniżej przedstawiono możliwe opcje konfiguracji:

None: domyślny kontroler ruchu przychodzącego Nginx nie jest tworzony i nie zostanie usunięty, jeśli już istnieje. W razie potrzeby użytkownicy powinni ręcznie usunąć 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 , aby uczynić je zewnętrznym, zostaną zastąpione.
External: domyślny kontroler ruchu przychodzącego Nginx utworzony za pomocą zewnętrznego modułu równoważenia obciążenia. 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. Użytkownicy mogą edytować domyślny NginxIngressController zasób niestandardowy, aby skonfigurować adnotacje modułu równoważenia obciążenia.

Interfejs wiersza polecenia platformy Azure
Bicep

Kontrolowanie domyślnej konfiguracji kontrolera ruchu przychodzącego podczas tworzenia klastra

Aby włączyć routing aplikacji w nowym klastrze, użyj az aks create polecenia , określając flagi --enable-app-routing i --app-routing-default-nginx-controller . Należy ustawić <DefaultIngressControllerType> wartość na jedną z opisanych wcześniej opcji konfiguracji.

az aks create \
--resource-group <ResourceGroupName> \
--name <ClusterName> \
--location <Location> \
--enable-app-routing \
--app-routing-default-nginx-controller <DefaultIngressControllerType>

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

Aby zaktualizować domyślną konfigurację kontrolera ruchu przychodzącego aplikacji w istniejącym klastrze, użyj az aks approuting update polecenia , określając flagę --nginx . Należy ustawić <DefaultIngressControllerType> wartość na jedną z opisanych wcześniej opcji konfiguracji.

az aks approuting update --resource-group <ResourceGroupName> --name <ClusterName> --nginx <DefaultIngressControllerType>

Profil webAppRouting ma opcjonalną nginx konfigurację z właściwością defaultIngressControllerType . Należy ustawić defaultIngressControllerType właściwość na jedną z opisanych wcześniej opcji konfiguracji.

"ingressProfile": {
  "webAppRouting": {
    "nginx": {
        "defaultIngressControllerType": "None|Internal|External|AnnotationControlled"
    }
}

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 az role assignment create polecenia .

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

Udostępnij za pośrednictwem

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

Wymagania wstępne

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

Konfiguracja kontrolera ruchu przychodzącego NGINX

Typowe konfiguracje

Kontrolowanie domyślnej konfiguracji kontrolera ruchu przychodzącego NGINX (wersja zapoznawcza)

Kontrolowanie domyślnej konfiguracji kontrolera ruchu przychodzącego podczas tworzenia klastra

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

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

Wyłączanie przekierowania SSL

Ponowne zapisywanie adresów URL

Następne kroki

Dodatkowe zasoby

Udostępnij za pośrednictwem

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

Wymagania wstępne

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

Konfiguracja kontrolera ruchu przychodzącego NGINX

Typowe konfiguracje

Kontrolowanie domyślnej konfiguracji kontrolera ruchu przychodzącego NGINX (wersja zapoznawcza)

Kontrolowanie domyślnej konfiguracji kontrolera ruchu przychodzącego podczas tworzenia klastra

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

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