Поделиться через

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

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

Требуемые условия

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

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

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

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

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

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

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

В этой таблице показано, какие свойства можно задать для настройки объекта NginxIngressController.

Поле Тип Описание Обязательно По умолчанию
controllerNamePrefix струна Имя для ресурсов Ingress-контроллера NGINX, которыми осуществляется управление. Да nginx
customHTTPErrors массив Массив кодов ошибок, отправляемых серверной части по умолчанию в случае ошибки. нет
defaultBackendService объект Служба для маршрутизации несовпадного HTTP-трафика. Содержит вложенные свойства: нет
 name струна Имя службы. Да
 namespace струна Пространство имен службы. Да
defaultSSLCertificate объект Содержит сертификат по умолчанию для доступа к серверной службе по умолчанию. Содержит вложенные свойства: нет
 forceSSLRedirect булевый Принудительно выполняет перенаправление HTTPS при установке сертификата. нет false
 keyVaultURI струна Универсальный код ресурса (URI) для секрета Key Vault, сохраняющего сертификат. нет
 secret объект Содержит секретные сведения для SSL-сертификата по умолчанию. Содержит вложенные свойства: нет
  name струна Имя секрета. Да
  namespace струна Секретное пространство имен. Да
httpDisabled булевый Пометка, чтобы отключить HTTP-трафик к контроллеру. нет
ingressClassName струна Имя IngressClass, используемое контроллером. Да nginx.approuting.kubernetes.azure.com
loadBalancerAnnotations объект Карта аннотаций для управления поведением службы контроллера входящего трафика NGINX путем задания аннотаций балансировщика нагрузки. нет
scaling объект Настройка масштабирования контроллера. Содержит вложенные свойства: нет
 maxReplicas целое число Верхний предел для реплик. нет 100
 minReplicas целое число Меньшее ограничение для реплик. нет 2
 threshold струна Пороговое значение масштабирования, определяющее, как агрессивно масштабироваться. rapid быстро масштабируется для внезапных пиков, steady предпочитает экономичность, а balanced представляет собой комбинацию. нет balanced

Распространенные способы конфигурирования

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

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

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

Ниже приведены возможные параметры конфигурации:

  • None: контроллер входящего трафика nginx по умолчанию не создается и не удаляется, если он уже существует. При желании пользователи должны удалить настраиваемый ресурс по умолчанию NginxIngressController вручную.
  • Internal: контроллер входящего трафика Nginx по умолчанию создается с внутренней подсистемой балансировки нагрузки. Любые изменения примечаний настраиваемого NginxIngressController ресурса, чтобы сделать его внешним, будут перезаписаны.
  • External: контроллер входящего трафика Nginx по умолчанию, созданный с внешним балансировщиком нагрузки. Любые изменения аннотаций настраиваемого ресурса NginxIngressController для его внутреннего использования будут перезаписаны.
  • AnnotationControlled (по умолчанию): контроллер ingress nginx по умолчанию создается с внешним балансировщиком нагрузки. Пользователи могут изменить настраиваемый ресурс по умолчанию NginxIngressController, чтобы настроить аннотации балансировщика нагрузки.

Управление конфигурацией контроллера входящего трафика по умолчанию при создании кластера

Чтобы включить маршрутизацию приложений в новом кластере, используйте az aks create команду, указав --enable-app-routing флаг и --app-routing-default-nginx-controller флаг. Необходимо установить <DefaultIngressControllerType> в один из параметров конфигурации, описанных ранее.

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

Обновление конфигурации контроллера входящего трафика по умолчанию в существующем кластере

Чтобы обновить конфигурацию контроллера входящего трафика по умолчанию для маршрутизации приложений в существующем кластере, используйте az aks approuting update команду, указав --nginx флаг. Необходимо установить <DefaultIngressControllerType> в один из параметров конфигурации, описанных ранее.

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

Создание другого общедоступного контроллера входящего трафика 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.

    Примечание.

    Обновите <ClusterName> и <ClusterResourceGroup> именами вашего кластера 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

Проверьте, что управляемый Ingress создан.

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

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

В следующем примере выходных данных показан созданный управляемый Ingress. Класс входящего трафика, узел и 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 поддерживает добавление заметок в определенные объекты входящего трафика для настройки их поведения.

Вы можете аннотировать объект Ingress, добавив соответствующую аннотацию в metadata.annotations поле.

Примечание.

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

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

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

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

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

Вот пример конфигурации Ingress с использованием этой аннотации:

Примечание.

Обновите <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"

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

Вот пример конфигурации Ingress с использованием этой аннотации:

Примечание.

Обновите <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"

или

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

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

Вот пример конфигурации Ingress с использованием этой аннотации:

Примечание.

Обновите <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) в правиле Ingress, используйте аннотацию:

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

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

Вот пример конфигурации Ingress с использованием этой аннотации:

Примечание.

Обновите <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 с помощью серверного перенаправления для других параметров конфигурации.

Вот пример конфигурации Ingress с использованием этой аннотации:

Примечание.

Обновите <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-адрес в серверной службе отличается от указанного пути в правиле Ingress. Без перезаписи любого запроса возвращается значение 404. Эта конфигурация полезна с маршрутизацией на основе пути, где можно обслуживать два разных веб-приложения в одном домене. Вы можете задать путь, ожидаемый службой, с помощью заметки:

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

Вот пример конфигурации Ingress с использованием этой аннотации:

Примечание.

Обновите <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 в рамках анализа производительности и использования приложения.