Расширенные конфигурации контроллера входящего трафика NGINX и входящего трафика с надстройкой маршрутизации приложений

Надстройка маршрутизации приложений поддерживает два способа настройки контроллеров входящего трафика и объектов входящего трафика:

• Настройка контроллера входящего трафика NGINX, например создание нескольких контроллеров, настройка частных подсистем балансировки нагрузки и настройка статических IP-адресов.
• Настройка для каждого ресурса входящего трафика с помощью заметок.

Необходимые компоненты

Кластер AKS с надстройкой маршрутизации приложений.

Подключение к кластеру AKS

Чтобы подключиться к кластеру Kubernetes с локального компьютера, используйте kubectlклиент командной строки Kubernetes. Ее можно установить локально с помощью команды az aks install-cli . Если вы используете Azure Cloud Shell, kubectl уже установлен.

Настройте kubectl для подключения к кластеру az aks get-credentials Kubernetes с помощью команды.

az aks get-credentials -g <ResourceGroupName> -n <ClusterName>

Настройка контроллера входящего трафика NGINX

Надстройка маршрутизации приложений использует пользовательское определение ресурсов Kubernetes (CRD), вызываемое NginxIngressController для настройки контроллеров входящего трафика NGINX. Можно создать дополнительные контроллеры входящего трафика или изменить существующую конфигурацию.

NginxIngressController CRD имеет loadBalancerAnnotations поле для управления поведением службы контроллера входящего трафика NGINX, задав заметки подсистемы балансировки нагрузки.

Контроллер входящего трафика NGINX по умолчанию

Если включить надстройку маршрутизации приложений с помощью NGINX, он создает контроллер входящего трафика, вызываемый default в app-routing-namespace настроенном с общедоступным балансировщиком нагрузки Azure. Этот контроллер входящего трафика использует имя webapprouting.kubernetes.azure.comкласса входящего трафика.

Создание другого общедоступного контроллера входящего трафика NGINX

Чтобы создать другой контроллер входящего трафика NGINX с общедоступным интерфейсом Azure Load Balancer:

1. Скопируйте следующий манифест YAML в новый файл с именем nginx-public-controller.yaml и сохраните файл на локальном компьютере.

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

2. Создайте ресурсы контроллера входящего трафика NGINX с помощью kubectl apply команды.

   kubectl apply -f nginx-public-controller.yaml
   

   В следующем примере выходных данных показан созданный ресурс:

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

Создание внутреннего контроллера входящего трафика NGINX с частным IP-адресом

Чтобы создать контроллер входящего трафика NGINX с внутренним интерфейсом Azure Load Balancer с частным IP-адресом:

1. Скопируйте следующий манифест YAML в новый файл с именем nginx-internal-controller.yaml и сохраните файл на локальном компьютере.

   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. Создайте ресурсы контроллера входящего трафика NGINX с помощью kubectl apply команды.

   kubectl apply -f nginx-internal-controller.yaml
   

   В следующем примере выходных данных показан созданный ресурс:

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

Создание контроллера входящего трафика NGINX со статическим IP-адресом

Чтобы создать контроллер входящего трафика NGINX со статическим IP-адресом в Azure Load Balancer:

1. Создайте группу ресурсов Azure с помощью az group create команды.

   az group create --name myNetworkResourceGroup --location eastus
   

2. Создайте статический общедоступный IP-адрес с помощью az network public ip create команды.

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

   Примечание.

   Если вы используете подсистему балансировки нагрузки SKU уровня "Базовый" в кластере AKS, используйте базовый параметр при --sku определении общедоступного IP-адреса. Только IP-адреса с номером SKU Базовый работают с подсистемой балансировки нагрузки с номером SKU Базовый, и только IP-адреса с номером SKU Стандартный работают с подсистемой балансировки нагрузки с номером SKU Стандартный.

3. Убедитесь, что удостоверение кластера, используемое кластером AKS, имеет делегированные разрешения для группы ресурсов общедоступного IP-адреса с помощью команды [az role assignment create][az-role-assignment-create].

   Примечание.

   <ClusterResourceGroup> Обновите <ClusterName> имя кластера AKS и имя группы ресурсов.

   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. Скопируйте следующий манифест YAML в новый файл с именем nginx-staticip-controller.yaml и сохраните файл на локальном компьютере.

   Примечание.

   Можно использовать service.beta.kubernetes.io/azure-pip-name для общедоступного IP-имени или service.beta.kubernetes.io/azure-load-balancer-ipv4 использовать для IPv4-адреса и service.beta.kubernetes.io/azure-load-balancer-ipv6 для IPv6-адреса, как показано в примере YAML. service.beta.kubernetes.io/azure-pip-name Добавление заметки гарантирует наиболее эффективное создание LoadBalancer и настоятельно рекомендуется избежать потенциального регулирования.

   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. Создайте ресурсы контроллера входящего трафика NGINX с помощью kubectl apply команды.

   kubectl apply -f nginx-staticip-controller.yaml
   

   В следующем примере выходных данных показан созданный ресурс:

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

Проверка создания контроллера входящего трафика

Состояние контроллера входящего трафика NGINX можно проверить с помощью kubectl get nginxingresscontroller команды.

Примечание.

Обновите <IngressControllerName> имя, используемое при создании nginxIngressController.

kubectl get nginxingresscontroller -n <IngressControllerName>

В следующем примере выходных данных показан созданный ресурс. Для доступности контроллера может потребоваться несколько минут:

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

Вы также можете просмотреть условия для устранения неполадок:

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

В следующем примере выходных данных показаны условия работоспособного контроллера входящего трафика:

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

Использование контроллера входящего трафика в входящего трафика

1. Скопируйте следующий манифест YAML в новый файл с именем ingress.yaml и сохраните его на локальном компьютере.

   Примечание.

   Обновите <Hostname> имя узла DNS. Это <IngressClassName> тот, который вы определили при создании 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. Создайте ресурсы кластера с помощью kubectl apply команды.

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

   В следующем примере выходных данных показан созданный ресурс:

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

Проверка создания управляемого входящего трафика

Вы можете проверить, создан ли управляемый входящий трафик с помощью kubectl get ingress команды.

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

В следующем примере выходных данных показан созданный управляемый входящий трафик. Класс входящего трафика, узел и IP-адрес могут отличаться:

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

Очистка контроллеров входящего трафика

С помощью kubectl delete nginxingresscontroller команды можно удалить контроллер входящего трафика NGINX.

Примечание.

Обновите имя <IngressControllerName> , используемое NginxIngressControllerпри создании.

kubectl delete nginxingresscontroller -n <IngressControllerName>

Настройка ресурса входящего трафика с помощью заметок

Контроллер входящего трафика NGINX поддерживает добавление заметок в определенные объекты входящего трафика для настройки их поведения.

Вы можете анонимировать объект входящего трафика, добавив соответствующую заметку в metadata.annotations поле.

Примечание.

Ключи и значения заметок могут быть только строками. Другие типы, такие как логические или числовые значения, должны быть кавычки, т. е. "true", "false". "100"

Ниже приведены некоторые примеры заметок для распространенных конфигураций. Ознакомьтесь с документацией по входящего трафика NGINX, чтобы получить полный список.

Настраиваемый максимальный размер тела

Для NGINX ошибка 413 возвращается клиенту, когда размер запроса превышает максимальный допустимый размер текста запроса клиента. Чтобы переопределить значение по умолчанию, используйте заметку:

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

Ниже приведен пример конфигурации входящего трафика с помощью этой заметки:

Примечание.

Обновите <Hostname> имя узла DNS. Это <IngressClassName> тот, который вы определили при создании 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

Время ожидания пользовательского подключения

Вы можете изменить время ожидания, которое ожидает контроллер входящего трафика NGINX, чтобы закрыть подключение к рабочей нагрузке. Все значения времени ожидания являются безудельными и в секундах. Чтобы переопределить время ожидания по умолчанию, используйте следующую заметку, чтобы задать допустимое время ожидания чтения прокси-сервера в 120 секунд:

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

Просмотрите пользовательские тайм-ауты для других параметров конфигурации.

Ниже приведен пример конфигурации входящего трафика с помощью этой заметки:

Примечание.

Обновите <Hostname> имя узла DNS. Это <IngressClassName> тот, который вы определили при создании 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

Протокол серверной части

По умолчанию контроллер входящего трафика NGINX используется HTTP для доступа к службам. Чтобы настроить альтернативные внутренние протоколы, например HTTPS или GRPC, используйте заметку:

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

or

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

Просмотрите внутренние протоколы для других параметров конфигурации.

Ниже приведен пример конфигурации входящего трафика с помощью этой заметки:

Примечание.

Обновите <Hostname> имя узла DNS. Это <IngressClassName> тот, который вы определили при создании 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

Общий доступ к ресурсам между источниками (CORS)

Чтобы включить общий доступ к ресурсам между источниками (CORS) в правиле входящего трафика, используйте заметку:

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

Проверьте включение CORS для других параметров конфигурации.

Ниже приведен пример конфигурации входящего трафика с помощью этой заметки:

Примечание.

Обновите <Hostname> имя узла DNS. Это <IngressClassName> тот, который вы определили при создании 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

Отключение перенаправления SSL

По умолчанию контроллер перенаправляет (308) на HTTPS, если протокол TLS включен для входящего трафика. Чтобы отключить эту функцию для определенных ресурсов входящего трафика, используйте заметку:

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

Просмотрите принудительное применение HTTPS на стороне сервера с помощью перенаправления для других параметров конфигурации.

Ниже приведен пример конфигурации входящего трафика с помощью этой заметки:

Примечание.

Обновите <Hostname> имя узла DNS. Это <IngressClassName> тот, который вы определили при создании 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

Переопределение URL-адресов

В некоторых сценариях предоставленный URL-адрес в серверной службе отличается от указанного пути в правиле входящего трафика. Без перезаписи любого запроса возвращается значение 404. Это особенно полезно с маршрутизацией на основе пути, где можно обслуживать два разных веб-приложения в одном домене. Вы можете задать путь, ожидаемый службой, с помощью заметки:

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

Ниже приведен пример конфигурации входящего трафика с помощью этой заметки:

Примечание.

Обновите <Hostname> имя узла DNS. Это <IngressClassName> тот, который вы определили при создании 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

Следующие шаги

Узнайте о мониторинге метрик контроллера ingress-nginx, включенных в надстройку маршрутизации приложений с помощью Prometheus в Grafana в рамках анализа производительности и использования приложения.