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

Статья
09/11/2024

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

Настройка контроллера входящего трафика 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 -resource-group <ResourceGroupName> --name <ClusterName>

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

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

Ниже приведена ссылка на свойства, которые можно задать для настройки NginxIngressController.

Свойство	Description
ingressClassName	Имя `IngressClass` , которое будет использоваться для контроллера входящего трафика NGINX. По умолчанию используется имя не указанного `NginxIngressController` значения.
controllerNamePrefix	Имя, используемое для префикса управляемых ресурсов контроллера входящего трафика NGINX. По умолчанию — `nginx`.
loadBalancerAnnotations	Набор заметок для управления поведением службы контроллера входящего трафика NGINX путем задания заметок подсистемы балансировки нагрузки
масштабирование	Параметры конфигурации для масштабирования контроллера Ingress NGINX.
scaling.minReplicas	Меньшее ограничение для числа реплик контроллера входящего трафика. По умолчанию используется 2 модуля pod.
scaling.maxReplicas	Верхний предел для числа реплик контроллера входящего трафика. По умолчанию используется 100 модулей pod.
scaling.threshold	Определяет скорость масштабирования модулей pod контроллера Ingress NGINX на основе рабочей нагрузки. `Rapid` означает, что контроллер входящего трафика быстро и агрессивно масштабируется для обработки внезапных и значительных пиков трафика. `Steady` определяет эффективность затрат с меньшим количеством реплик, обрабатывая большую работу. `Balanced` является хорошим сочетанием между двумя, которые работают для большинства вариантов использования. Если не указано, это поле по умолчанию используется `Balanced`.
defaultBackendService	Служба Kubernetes, которую контроллер входящего трафика NGINX должен по умолчанию обрабатывать все пути URL-адресов и размещать контроллер Ingress-NGINX не понимает (т. е. все запросы, которые не сопоставлены с входящего трафика). Контроллер направляет трафик к первому порту службы. Если это не указано, используется встроенная серверная часть по умолчанию.
defaultBackendService.namespace	Пространство имен службы.
defaultBackendService.name	Имя службы.
defaultSSLCertificate	Секрет, на который ссылается это свойство, содержит сертификат по умолчанию, используемый при доступе к серверной службе по умолчанию. Если это свойство не предоставлено NGINX, будет использовать самозаверяющий сертификат. `tls:` Если раздел не задан для входящего трафика, NGINX предоставит сертификат по умолчанию, но не будет принудительно перенаправлять HTTPS.
defaultSSLCertificate.forceSSSLRedirect	Принудительно выполняет перенаправление для входящего трафика, не указывающего `tls:` раздел.
defaultSSLCertificate.keyVaultURI	URI Azure Key Vault, где можно найти SSL-сертификат по умолчанию. Надстройка должна быть настроена для использования хранилища ключей.
defaultSSLCertificate.secret	Настраивает имя и пространство имен, где секрет SSL по умолчанию находится в кластере.
defaultSSLCertificate.secret.name	Имя секрета.
defaultSSLCertificate.secret.namespace	Пространство имен секрета.

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

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

Примечание.

Управление конфигурацией контроллера входящего трафика NGINX при включении надстройки доступно в API 2024-06-02-preview, Kubernetes версии 1.30 или более поздней, а также версию расширения Azure CLI или более поздней версии 7.0.0b5 aks-preview. Сведения о проверке версии кластера AKS см. в разделе "Проверка доступных обновлений кластера AKS".

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

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

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

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

Azure CLI
Bicep

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

Чтобы включить маршрутизацию приложений в новом кластере, используйте 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>

Профиль webAppRouting имеет необязательную nginx конфигурацию со свойством defaultIngressControllerType . Для свойства необходимо задать defaultIngressControllerType одно из описанных ранее параметров конфигурации.

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

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

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

Скопируйте следующий манифест YAML в новый файл с именем nginx-public-controller.yaml и сохраните файл на локальном компьютере.
```
apiVersion: approuting.kubernetes.azure.com/v1alpha1
kind: NginxIngressController
metadata:
  name: nginx-public
spec:
  ingressClassName: nginx-public
  controllerNamePrefix: nginx-public
```
Создайте ресурсы контроллера входящего трафика 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-адресом:

Скопируйте следующий манифест 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"

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

Создайте группу ресурсов Azure с помощью az group create команды.
```
az group create --name myNetworkResourceGroup --location eastus
```
Создайте статический общедоступный 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 Стандартный.
Убедитесь, что удостоверение кластера, используемое кластером AKS, имеет делегированные разрешения группе ресурсов общедоступного IP-адреса с помощью 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}
```
Скопируйте следующий манифест 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"
```
Создайте ресурсы контроллера входящего трафика 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

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

Скопируйте следующий манифест 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
```
Создайте ресурсы кластера с помощью 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"

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) в правиле входящего трафика, используйте заметку:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Дополнительные ресурсы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Дополнительные ресурсы