Расширенные конфигурации контроллера входящего трафика 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 -resource-group <ResourceGroupName> --name <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:
Скопируйте следующий манифест 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
][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"
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 в рамках анализа производительности и использования приложения.