Rozšířený kontroler příchozího přenosu dat NGINX a konfigurace příchozího přenosu dat pomocí doplňku směrování aplikací

Doplněk směrování aplikací podporuje dva způsoby konfigurace kontrolerů příchozího přenosu dat a objektů příchozího přenosu dat:

• Konfigurace kontroleru příchozího přenosu dat NGINX, například vytvoření více kontrolerů, konfigurace privátních nástrojů pro vyrovnávání zatížení a nastavení statických IP adres
• Konfigurace pro prostředek příchozího přenosu dat prostřednictvím poznámek

Požadavky

Cluster AKS s doplňkem pro směrování aplikací.

Připojení ke clusteru AKS

Pokud se chcete připojit ke clusteru Kubernetes z místního počítače, použijte kubectlklienta příkazového řádku Kubernetes. Můžete ho nainstalovat místně pomocí příkazu az aks install-cli . Pokud používáte Azure Cloud Shell, kubectl je už nainstalovaný.

Pomocí příkazu nakonfigurujte kubectl pro připojení ke clusteru az aks get-credentials Kubernetes.

az aks get-credentials --resource-group <ResourceGroupName> --name <ClusterName>

Konfigurace kontroleru příchozího přenosu dat NGINX

Doplněk směrování aplikace používá k konfiguraci kontrolerů příchozího přenosu dat NGINX vlastní definici prostředku Kubernetes (CRD). NginxIngressController Můžete vytvořit další kontrolery příchozího přenosu dat nebo upravit existující konfiguraci.

Tady je odkaz na vlastnosti, které můžete nastavit ke konfiguraci NginxIngressController.

Vlastnost	Popis
ingressClassName	Název, který se použije pro kontroler příchozího IngressClass přenosu dat NGINX. Výchozí hodnota je název NginxIngressController , pokud není zadaný.
controllerNamePrefix	Název použitý k předponě spravovaných prostředků kontroleru příchozího přenosu dat NGINX. Výchozí hodnota nginxje .
loadBalancerAnnotations	Sada poznámek pro řízení chování kontroleru příchozího přenosu dat NGINX nastavením poznámek nástroje pro vyrovnávání zatížení
změna velikosti	Možnosti konfigurace pro škálování kontroleru příchozího přenosu dat NGINX
scaling.minReplicas	Nižší limit počtu replik kontroleru příchozího přenosu dat. Výchozí hodnota je 2 pody.
scaling.maxReplicas	Horní limit počtu replik kontroleru příchozího přenosu dat. Výchozí hodnota je 100 podů.
scaling.threshold	Definuje, jak rychle se mají pody kontroleru příchozího přenosu dat NGINX škálovat na základě úloh. Rapid znamená, že kontroler příchozího přenosu dat bude rychle a agresivně škálovat pro zpracování náhlých a významných špiček provozu. Steady upřednostňuje nákladovou efektivitu s menším počtem replik, které zpracovávají více práce. Balanced je dobrá kombinace mezi dvěma, které fungují pro většinu případů použití. Pokud není zadáno, bude toto pole ve výchozím nastavení nastaveno na Balancedhodnotu .
defaultBackendService	Služba Kubernetes, na kterou by měl výchozí kontroler příchozího přenosu dat NGINX, který zpracovává všechny cesty URL a hostuje kontroler příchozího přenosu dat NGINX (tj. všechny požadavky, které nejsou namapované s příchozím přenosem dat). Kontroler směruje provoz na první port služby. Pokud není zadaný, použije se výchozí back-end , který je integrovaný.
defaultBackendService.namespace	Obor názvů služby
defaultBackendService.name	Název služby
defaultSSLCertificate	Tajný kód, na který odkazuje tato vlastnost, obsahuje výchozí certifikát, který se má použít při přístupu k výchozí back-endové službě. Pokud tato vlastnost není k dispozici, nástroj NGINX použije certifikát podepsaný svým držitelem. tls: Pokud oddíl není nastavený u příchozího přenosu dat, NGINX poskytne výchozí certifikát, ale nevynutí přesměrování HTTPS.
defaultSSLCertificate.forceSSLRedirect	Vynutí přesměrování pro příchozí přenos dat, které nezadávají tls: oddíl.
defaultSSLCertificate.keyVaultURI	Identifikátor URI služby Azure Key Vault, kde najdete výchozí certifikát SSL. Doplněk je potřeba nakonfigurovat tak, aby používal trezor klíčů.
defaultSSLCertificate.secret	Nakonfiguruje název a obor názvů, kde je výchozí tajný klíč SSL v clusteru.
defaultSSLCertificate.secret.name	Název tajného klíče.
defaultSSLCertificate.secret.namespace	Obor názvů tajného klíče

Běžné konfigurace

Řízení výchozí konfigurace kontroleru příchozího přenosu dat NGINX (Preview)

Poznámka:

Řízení konfigurace kontroleru příchozího přenosu dat NGINX při povolení doplňku je k dispozici v API 2024-06-02-previewkubernetes verze 1.30 nebo novější a verze 7.0.0b5 rozšíření Azure CLI aks-Preview nebo novější. Pokud chcete zkontrolovat verzi clusteru AKS, přečtěte si téma Kontrola dostupných upgradů clusteru AKS.

Když povolíte doplněk směrování aplikace pomocí NGINX, vytvoří kontroler příchozího přenosu dat volaný default v app-routing-namespace nakonfigurované s veřejně přístupným nástrojem pro vyrovnávání zatížení Azure. Tento kontroler příchozího přenosu dat používá název třídy příchozího webapprouting.kubernetes.azure.compřenosu dat .

Můžete také určit, jestli výchozí hodnota získá veřejnou nebo interní IP adresu nebo jestli se vůbec vytvoří při povolování doplňku.

Tady jsou možné možnosti konfigurace:

• None: Výchozí kontroler příchozího přenosu dat Nginx není vytvořen a nebude odstraněn, pokud již existuje. Uživatelé by v případě potřeby měli výchozí NginxIngressController vlastní prostředek odstranit ručně.
• Internal: Výchozí kontroler příchozího přenosu dat Nginx se vytvoří s interním nástrojem pro vyrovnávání zatížení. Všechny změny poznámek ve NginxIngressController vlastním prostředku, které ho nastaví jako externí, se přepíšou.
• External: Výchozí kontroler příchozího přenosu dat Nginx vytvořený s externím nástrojem pro vyrovnávání zatížení. Všechny změny poznámek ve NginxIngressController vlastním prostředku, které ho nastaví jako interní, se přepíšou.
• AnnotationControlled (výchozí): Výchozí kontroler příchozího přenosu dat Nginx se vytvoří s externím nástrojem pro vyrovnávání zatížení. Uživatelé můžou upravit výchozí NginxIngressController vlastní prostředek a nakonfigurovat poznámky nástroje pro vyrovnávání zatížení.

Azure CLI

Řízení výchozí konfigurace kontroleru příchozího přenosu dat při vytváření clusteru

Pokud chcete povolit směrování aplikací v novém clusteru, použijte az aks create příkaz a zadejte --enable-app-routing příznaky.--app-routing-default-nginx-controller Musíte nastavit <DefaultIngressControllerType> jednu z výše popsaných možností konfigurace.

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

Aktualizace výchozí konfigurace kontroleru příchozího přenosu dat v existujícím clusteru

Pokud chcete aktualizovat konfiguraci výchozího kontroleru příchozího přenosu dat aplikace v existujícím clusteru, použijte az aks approuting update příkaz a zadejte --nginx příznak. Musíte nastavit <DefaultIngressControllerType> jednu z výše popsaných možností konfigurace.

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

Bicep

Profil webAppRouting má volitelnou nginx defaultIngressControllerType konfiguraci s vlastností. Vlastnost musíte nastavit defaultIngressControllerType na jednu z výše popsaných možností konfigurace.

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

Vytvoření dalšího veřejně přístupného kontroleru příchozího přenosu dat NGINX

Vytvoření dalšího kontroleru příchozího přenosu dat NGINX s veřejně přístupným Nástrojem pro vyrovnávání zatížení Azure:

1. Zkopírujte následující manifest YAML do nového souboru s názvem nginx-public-controller.yaml a uložte soubor do místního počítače.

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

2. Pomocí příkazu vytvořte prostředky kontroleru příchozího přenosu dat kubectl apply NGINX.

   kubectl apply -f nginx-public-controller.yaml
   

   Následující příklad výstupu ukazuje vytvořený prostředek:

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

Vytvoření interního kontroleru příchozího přenosu dat NGINX s privátní IP adresou

Vytvoření kontroleru příchozího přenosu dat NGINX s interní službou Azure Load Balancer s privátní IP adresou:

1. Zkopírujte následující manifest YAML do nového souboru s názvem nginx-internal-controller.yaml a uložte soubor do místního počítače.

   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. Pomocí příkazu vytvořte prostředky kontroleru příchozího přenosu dat kubectl apply NGINX.

   kubectl apply -f nginx-internal-controller.yaml
   

   Následující příklad výstupu ukazuje vytvořený prostředek:

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

Vytvoření kontroleru příchozího přenosu dat NGINX se statickou IP adresou

Vytvoření kontroleru příchozího přenosu dat NGINX se statickou IP adresou v Azure Load Balanceru:

1. Pomocí příkazu vytvořte skupinu az group create prostředků Azure.

   az group create --name myNetworkResourceGroup --location eastus
   

2. Pomocí příkazu vytvořte statickou veřejnou IP adresu az network public ip create .

   az network public-ip create \
       --resource-group myNetworkResourceGroup \
       --name myIngressPublicIP \
       --sku Standard \
       --allocation-method static
   

   Poznámka:

   Pokud v clusteru AKS používáte nástroj pro vyrovnávání zatížení skladové položky Basic, při definování veřejné IP adresy použijte pro parametr Basic--sku. S nástrojem pro vyrovnávání zatížení skladové položky Basic fungují jenom IP adresy skladových položek Úrovně Basic a pouze IP adresy SKU Úrovně Standard fungují s nástroji pro vyrovnávání zatížení SKU Úrovně Standard.

3. Pomocí příkazu se ujistěte, že identita clusteru AKS používaná clusterem AKS má delegovaná oprávnění ke skupině prostředků veřejné IP adresy az role assignment create .

   Poznámka:

   Aktualizujte <ClusterName> a <ClusterResourceGroup> použijte název clusteru AKS a název skupiny prostředků.

   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}
   

4. Zkopírujte následující manifest YAML do nového souboru s názvem nginx-staticip-controller.yaml a uložte soubor do místního počítače.

   Poznámka:

   Můžete použít service.beta.kubernetes.io/azure-pip-name název veřejné IP adresy nebo použít service.beta.kubernetes.io/azure-load-balancer-ipv4 pro IPv4 adresu a service.beta.kubernetes.io/azure-load-balancer-ipv6 adresu IPv6, jak je znázorněno v příkladu YAML. Přidáním poznámky service.beta.kubernetes.io/azure-pip-name zajistíte nejúčinnější vytváření LoadBalanceru a důrazně se doporučuje zabránit potenciálnímu omezování.

   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"
   

5. Pomocí příkazu vytvořte prostředky kontroleru příchozího přenosu dat kubectl apply NGINX.

   kubectl apply -f nginx-staticip-controller.yaml
   

   Následující příklad výstupu ukazuje vytvořený prostředek:

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

Ověření vytvoření kontroleru příchozího přenosu dat

Pomocí příkazu můžete ověřit stav kontroleru kubectl get nginxingresscontroller příchozího přenosu dat NGINX.

Poznámka:

Aktualizujte <IngressControllerName> název, který jste použili při vytváření NginxIngressController.

kubectl get nginxingresscontroller -n <IngressControllerName>

Následující příklad výstupu ukazuje vytvořený prostředek. Dostupnost kontroleru může trvat několik minut:

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

Můžete také zobrazit podmínky pro řešení jakýchkoli problémů:

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

Následující příklad výstupu ukazuje podmínky kontroleru příchozího přenosu dat, který je v pořádku:

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

Použití kontroleru příchozího přenosu dat v příchozím přenosu dat

1. Zkopírujte následující manifest YAML do nového souboru s názvem ingress.yaml a uložte ho do místního počítače.

   Poznámka:

   Aktualizujte <Hostname> název hostitele DNS. Jedná se <IngressClassName> o ten, který jste definovali při vytváření 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. Pomocí příkazu vytvořte prostředky clusteru kubectl apply .

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

   Následující příklad výstupu ukazuje vytvořený prostředek:

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

Ověření vytvoření spravovaného příchozího přenosu dat

Spravovaný příchozí přenos dat můžete ověřit pomocí kubectl get ingress příkazu.

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

Následující příklad výstupu ukazuje vytvořený spravovaný příchozí přenos dat. Třída příchozího přenosu dat, hostitel a IP adresa se může lišit:

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

Vyčištění kontrolerů příchozího přenosu dat

Kontroler příchozího přenosu dat NGINX můžete odebrat pomocí kubectl delete nginxingresscontroller příkazu.

Poznámka:

Aktualizujte <IngressControllerName> název, který jste použili při vytváření souboru NginxIngressController.

kubectl delete nginxingresscontroller -n <IngressControllerName>

Konfigurace pro prostředek příchozího přenosu dat prostřednictvím poznámek

Kontroler příchozího přenosu dat NGINX podporuje přidávání poznámek ke konkrétním objektům příchozího přenosu dat pro přizpůsobení jejich chování.

Objekt příchozího přenosu dat můžete přidat přidáním příslušné poznámky do metadata.annotations pole.

Poznámka:

Klíče a hodnoty poznámek můžou být pouze řetězce. Jiné typy, například logické nebo číselné hodnoty, musí být uvozovány, tj. "true", "false". "100"

Tady je několik příkladů poznámek pro běžné konfigurace. Úplný seznam najdete v dokumentaci k příchozím datům NGINX.

Vlastní maximální velikost těla

V případě serveru NGINX se klientovi vrátí chyba 413, když velikost požadavku překročí maximální povolenou velikost textu požadavku klienta. Pokud chcete přepsat výchozí hodnotu, použijte poznámku:

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

Tady je příklad konfigurace příchozího přenosu dat pomocí této poznámky:

Poznámka:

Aktualizujte <Hostname> název hostitele DNS. Jedná se <IngressClassName> o ten, který jste definovali při vytváření 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

Časový limit vlastního připojení

Můžete změnit časový limit, který kontroler příchozího přenosu dat NGINX čeká na zavření připojení k vaší úloze. Všechny hodnoty časového limitu jsou bez jednotkové a v sekundách. Pokud chcete výchozí časový limit přepsat, nastavte platný časový limit 120sekundového čtení proxy serveru pomocí následující poznámky:

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

Zkontrolujte vlastní časové limity pro další možnosti konfigurace.

Tady je příklad konfigurace příchozího přenosu dat pomocí této poznámky:

Poznámka:

Aktualizujte <Hostname> název hostitele DNS. Jedná se <IngressClassName> o ten, který jste definovali při vytváření 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

Protokol back-endu

Ve výchozím nastavení se kontroler příchozího přenosu dat NGINX používá HTTP k dosažení služeb. Ke konfiguraci alternativních back-endových protokolů, jako HTTPS je například nebo GRPC, použijte poznámku:

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

nebo

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

Zkontrolujte back-endové protokoly a vyhledejte další možnosti konfigurace.

Tady je příklad konfigurace příchozího přenosu dat pomocí této poznámky:

Poznámka:

Aktualizujte <Hostname> název hostitele DNS. Jedná se <IngressClassName> o ten, který jste definovali při vytváření 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

Cross-Origin Resource Sharing (CORS)

Pokud chcete povolit sdílení prostředků mezi zdroji (CORS) v pravidle příchozího přenosu dat, použijte poznámku:

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

Další možnosti konfigurace najdete v povolení CORS .

Tady je příklad konfigurace příchozího přenosu dat pomocí této poznámky:

Poznámka:

Aktualizujte <Hostname> název hostitele DNS. Jedná se <IngressClassName> o ten, který jste definovali při vytváření 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

Zakázání přesměrování SSL

Ve výchozím nastavení kontroler přesměruje (308) na HTTPS, pokud je pro příchozí přenos dat povolený protokol TLS. Pokud chcete tuto funkci zakázat pro konkrétní prostředky příchozího přenosu dat, použijte poznámku:

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

Zkontrolujte vynucení HTTPS na straně serveru prostřednictvím přesměrování a zkontrolujte další možnosti konfigurace.

Tady je příklad konfigurace příchozího přenosu dat pomocí této poznámky:

Poznámka:

Aktualizujte <Hostname> název hostitele DNS. Jedná se <IngressClassName> o ten, který jste definovali při vytváření 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

Přepisování adres URL

V některých scénářích se vystavená adresa URL v back-endové službě liší od zadané cesty v pravidle příchozího přenosu dat. Bez přepsání jakéhokoli požadavku vrátí hodnotu 404. Tato konfigurace je užitečná se směrováním na základě cest, kde můžete obsluhovat dvě různé webové aplikace ve stejné doméně. Cestu očekávanou službou můžete nastavit pomocí poznámky:

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

Tady je příklad konfigurace příchozího přenosu dat pomocí této poznámky:

Poznámka:

Aktualizujte <Hostname> název hostitele DNS. Jedná se <IngressClassName> o ten, který jste definovali při vytváření 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

Další kroky

Přečtěte si o monitorování metrik kontroleru ingress-nginx, které jsou součástí doplňku směrování aplikací pomocí nástroje Prometheus v Grafana jako součást analýzy výkonu a využití vaší aplikace.