NGINX Ingress Controller

Kubernetes использует kube-proxy для экспонирования Services и обеспечения load balancing. Реализация находится на транспортном уровне. Для Internet‑приложений, где генерируется массивный объём информации, переадресация должна быть более тонкой, точно и гибко управляемой политиками и load balancers для обеспечения более высокой производительности.

Именно здесь вступают ingresses. Ingresses предоставляют функции переадресации на уровне приложения, такие как виртуальные хосты, load balancing, SSL‑прокси и HTTP‑маршрутизацию, для Services, к которым можно напрямую обращаться извне кластера.

Kubernetes официально выпустил Ingress‑controller на основе Nginx. CCE NGINX Ingress Controller напрямую использует шаблоны и образы сообщества. NGINX Ingress Controller генерирует конфигурацию Nginx и сохраняет её с помощью ConfigMaps. Конфигурация будет записана в pods Nginx через Kubernetes API. Таким образом, конфигурация Nginx изменяется и обновляется. Подробности см. How the Add-on Works.

Сообщество с открытым исходным кодом: https://github.com/kubernetes/ingress-nginx

Nginx ingress состоит из объекта ingress, контроллера ingress и Nginx. Контроллер ingress собирает ingresses в файл конфигурации Nginx (nginx.conf) и перезапускает Nginx, чтобы применить изменения конфигурации. Когда он обнаруживает изменение pods, связанных с Service, он динамически изменяет конфигурацию группы upstream‑серверов Nginx. В этом случае процесс Nginx не требует перезапуска. Figure 1 демонстрирует работу этого дополнения.

• Ingress — это набор правил доступа, которые переадресуют запросы к указанным Services на основе доменных имён или URL. Ingresses представляют собой тип объекта ресурса Kubernetes. Они хранятся в сервисе объектного хранилища etcd и добавляются, удаляются, изменяются и запрашиваются через API.
• Контроллер ingress в режиме реального времени отслеживает изменения объектных ресурсов, таких как ingresses, Services, endpoints, secrets (в основном TLS‑сертификаты и ключи), nodes и ConfigMaps, и автоматически выполняет операции над Nginx.
• Nginx реализует load balancing и контроль доступа на уровне приложения.

• Для кластеров версии ранее v1.23, kubernetes.io/ingress.class: "nginx" необходимо добавить в аннотацию ingress, созданного через API. Если в кластере установлено несколько контроллеров NGINX Ingress, необходимо заменить nginx на пользовательский ingress class, чтобы помочь идентифицировать экземпляр контроллера, связанный с ingress.
• Выделенный балансировщик нагрузки должен быть сетевого типа (TCP/UDP) и поддерживать частные сети (с частным IP-адресом).
• Если узел, на котором работает NGINX Ingress Controller, не может получить доступ к NGINX Ingress, или если другие pod‑ы на этом узле не могут получить к нему доступ, настройте anti‑affinity между pod‑ами рабочей нагрузки и pod‑ами NGINX Ingress Controller. Подробности см. в Configuring Anti-Affinity Between a Workload and NGINX Ingress Controller.
• Во время обновления pod‑ов NGINX Ingress Controller резервируется 10 секунд для удаления NGINX Ingress Controller в бэкенде ELB.
• Время ожидания для корректного завершения работы NGINX Ingress Controller составляет 300 секунд. Если время ожидания превышает 300 с во время обновления NGINX Ingress Controller, постоянные соединения будут разорваны, и связь будет прервана на короткое время.
• В стандартных кластерах CCE, когда NGINX Ingress Controller привязан к выделенному балансировщику нагрузки, узел, на котором размещён pod cceaddon-nginx-ingress-controller, а также любые другие контейнеры на этом же узле, не могут использовать частный IP‑адрес балансировщика для доступа к ingress.

Перед установкой этого дополнения у вас должен быть один доступный кластер с правильно работающим узлом. Если кластер недоступен, создайте его согласно Buying a Standard/Turbo Cluster.

1. Войдите в CCE console и нажмите название кластера, чтобы открыть консоль кластера.
2. В панели навигации выберите Add-ons. Найдите NGINX Ingress Controller справа и нажмите Install.
3. On the Install Add-on page, configure the specifications as needed.

   Вы можете при необходимости изменить количество pod‑ов дополнения и квоты ресурсов. Высокая доступность невозможна при использовании одного pod‑а. Если на узле, где работает pod дополнения, произойдёт ошибка, дополнение завершится сбоем.

4. Настройте параметры add-on.
   • Controller Name: Введите имя контроллера. Имя каждого контроллера в одном кластере должно быть уникальным и не может быть установлено в cce (это уникальный идентификатор контроллера входящего трафика LoadBalancer). При создании ingress вы можете указать имя контроллера, чтобы определить, какой контроллер будет управлять этим ingress.
   • Add-on Namespace: Выберите пространство имён для контроллера ingress.
   • Load Balancer: Выберите совместный или выделенный load balancer. Если load balancer недоступен, создайте его. У load balancer должно быть не менее двух слушателей, и порты 80 и 443 не должны быть заняты слушателями.
   • Admission Check: Контроль доступа выполняется для ingress, чтобы гарантировать, что контроллер может генерировать корректные конфигурации. После включения этой функции проверка доступа выполняется для конфигурации Nginx ingress. Если проверка не проходит, запросы будут перехвачены. Подробную информацию о проверках доступа см. в Access Control.
     Note

     • Проверка доступа замедляет ответы на запросы ingress.
     • Только add-on версии 2.4.1 и новее поддерживают проверку доступа.
   • Nginx Parameters: Вы можете настроить файл nginx.conf, который будет влиять на все управляемые ingress. Можно выбрать GUI или YAML. GUI поддерживается NGINX Ingress Controller версии v2.2.75, v2.6.26, v3.0.1 и новее.

     Чтобы настроить пользовательские параметры, поддерживаемые сообществом Kubernetes, выберите YAML и найдите соответствующие параметры в ConfigMaps. В этом примере используется параметр keep-alive-requests, установленный в 100. Это означает, что одновременно может быть активно до 100 запросов.

     {
         "keep-alive-requests": "100"
     }
     
     

     Note

     • Если настроенные параметры не указаны в ConfigMaps, конфигурации не вступят в силу.
     • Значение параметра должно быть строкой. В противном случае установка завершится с ошибкой.

     В таблице ниже показаны параметры, которые можно настроить в GUI дополнения NGINX Ingress Controller версии 2.2.75, 2.6.26, 3.0.1 и новее.

     Nginx Parameter	Description	Default Value
     Maximum Worker Connections	Указывает максимальное количество соединений, которые каждый процесс‑worker Nginx может обрабатывать одновременно. Этот параметр используется для контроля нагрузки процессов‑worker. В среде с высокой конкуренцией рекомендуется установить для этого параметра большое значение, чтобы обеспечить стабильность системы. Такие соединения включают клиентские соединения и соединения с backend‑серверами.	65536
     Maximum Keepalive Requests	Определяет, сколько запросов может быть обработано по keepalive‑соединению. Если запросы исчерпывают лимит, соединение закрывается.	100
     Maximum Keepalive Connections to the Upstream Server	Включает кэш для соединений с upstream‑серверами. Этот параметр задаёт количество простоя keepalive‑соединений, которые могут храниться в кэше каждого процесса‑worker. Если простоя соединений, хранящихся в процессе, исчерпывает лимит, соединения, не использованные дольше всего, будут закрыты.	320
     Maximum Keepalive Timeout of the Upstream Server	Указывает тайм‑аут для keepalive‑соединения между upstream‑сервером и backend‑сервером, в секундах. В течение этого периода NGINX Ingress Controller может поддерживать соединения для повторного использования. Это снижает накладные расходы на установление новых соединений и значительно повышает производительность в сценариях с высоким QPS.	900
     Request Timeout	Указывает тайм‑аут для подключения клиента к прокси‑серверу, в секундах. Если клиент не может получить доступ к backend‑серверу в течение 10 секунд, NGINX Ingress Controller вернёт ошибку 502 Bad Gateway. Применяется в сценариях с высокой скоростью соединения.	10
     Maximum Request Body Size	Указывает максимальный размер тела запроса, которое Nginx может передать backend‑серверу через прокси. Это относится к загрузке файлов и отправке больших форм данных. Если размер тела любого запроса превышает лимит, будет возвращена ошибка 413 Payload Too Large.	20m
     Allow to Pass Through the Backend Server's Header	Обычно NGINX Ingress Controller удаляет информацию заголовка server, отправляемую backend‑сервером клиенту, которая идентифицирует сервер. Однако если этот параметр установлен в true, NGINX Ingress Controller будет передавать заголовок server напрямую от backend‑сервера к клиенту. Чтобы не раскрывать тип и версию сервера, рекомендуется отключить эту опцию.	Disable
     Allow Underscores in Headers	Некоторые HTTP‑заголовки могут содержать символ подчёркивания (_), например X_Custom-Header, однако это не рекомендуется согласно стандартам Request For Comments (RFC). Поэтому многие серверы по умолчанию не разрешают подчёркивания. Вы можете включить этот параметр, если вам нужны подчёркивания в определённых заголовках, например когда сторонние сервисы или клиенты используют подчёркивания в информации заголовков.	Disable
     Generate Request ID	После получения запроса NGINX Ingress Controller генерирует уникальный идентификатор запроса. Этот идентификатор обычно записывается в логи или передаётся бэкенд‑серверу через заголовок. Это полезно для трассировки и отладки запросов, особенно для выявления проблем в распределённых системах.	Enable
     Ignore Invalid Headers	По умолчанию NGINX Ingress Controller отклоняет HTTP‑запросы, содержащие недопустимый заголовок. При включённой настройке NGINX Ingress Controller будет игнорировать недопустимые заголовки и продолжать обработку запросов. Это полезно для клиентов, которые не полностью соответствуют стандарту HTTP.	Enable
     Reuse Port	Включение SO_REUSEPORT позволяет нескольким процессам или потокам привязываться к одному и тому же {IP}:{Port}. Это может эффективно повысить конкурентную производительность серверов, особенно у тех, которые имеют многоядерные CPU. При включённой функции порт может принимать больше новых соединений.	Enable
     Allow Server Information in Response	Отключает информацию о сервере, добавляемую по умолчанию в заголовок ответа NGINX Ingress Controller. Обычно эта информация содержит версию Nginx. Отключение этой опции помогает скрыть сведения о сервере, повышая безопасность и препятствуя злоумышленникам использовать информацию о версии для атак на систему.	Disable
     Automatically Redirect HTTP to HTTPS	Отключает автоматическое перенаправление с HTTP на HTTPS. Например, если вы хотите использовать HTTPS только для определённых страниц, таких как страница входа, а HTTP — для остальных страниц, вы можете отключить перенаправление по умолчанию, используя эту опцию.	Disable
     CPU Affinity of Worker Threads	Автоматически распределяет рабочие процессы по определённым ядрам CPU для повышения производительности многопоточных систем. Например, на многопроцессорном сервере некоторые рабочие процессы могут быть привязаны к конкретному ядру CPU. Это уменьшает переключение контекстов и повышает эффективность обработки.	Auto

   • Metric Collection: Если версия дополнения 2.4.12 или новее, можно собирать метрики мониторинга Prometheus.
   • Default Server Certificate: Выберите ключ IngressTLS или kubernetes.io/tls для настройки сертификата по умолчанию при запуске NGINX Ingress Controller. Если секрет недоступен, нажмите Create TLS Secret. Подробности см. в Creating a Secret. Для получения подробной информации о сертификате сервера по умолчанию см. Default SSL Certificate.
   • 404 Service: По умолчанию используется 404 Service, предоставляемый дополнением. Чтобы настроить 404 Service, введите имя namespace/service. Если сервис не существует, установка дополнения завершится ошибкой.
   • TCP/UDP: По умолчанию NGINX Ingress Controller может перенаправлять только внешний HTTP и HTTPS трафик. Вы можете добавить сопоставление портов TCP/UDP для перенаправления внешнего трафика TCP/UDP к сервисам в кластере. Для получения дополнительной информации о добавлении сервисов TCP/UDP см. Exposing TCP and UDP services.
     • Protocol: Выберите TCP или UDP.
     • Service Port: указывает порт, используемый слушателем ELB. Номер порта может принимать значения от 1 до 65535.
     • Service Namespace: Выберите namespace, в котором находится Service.
     • Destination Service: Выберите существующий Service. Любые Service, не соответствующие критериям поиска, будут автоматически отфильтрованы.
     • Destination Service Port: Выберите порт доступа назначения Service.
     Note

     • Если версия кластера v1.19.16-r5, v1.21.8-r0, v1.23.6-r0 или более новая, гибридные протоколы TCP/UDP можно настроить.
     • Если версия кластера v1.19.16-r5, v1.21.8-r0, v1.23.6-r0, v1.25.2-r0 или более новая, можно настроить гибридные протоколы TCP/UDP для использования одного внешнего порта.
   • (Optional) Extended Parameter Settings: дополнительные расширенные параметры дополнения. Если расширенные параметры конфликтуют с настройками по умолчанию, приоритет будут иметь расширенные параметры.
     • extraArgs: дополнительные настраиваемые параметры запуска компонента nginx-ingress-controller. Подробную информацию о поддерживаемых сообществом параметрах запуска см. в documentation.
     • extraInitContainers: начальная конфигурация контейнеров nginx-ingress-controller. Этот параметр поддерживается дополнением 2.2.82, 2.6.32, 3.0.8 и более новыми версиями, с оптимизированными настройками ядра по умолчанию.
     • maxmindLicenseKey: лицензионный ключ Maxmind, который может использоваться для загрузки баз данных GeoLite2. Этот параметр поддерживается дополнением 2.2.82, 2.6.32, 3.0.8 и более новыми версиями. Он обязателен для NGINX Ingress Controller при настройке возможности use-geoip2.
     • service: определяет Services для nginx-ingress-controller. Подробности см. в parameter examples in GitHub. Параметр поддерживается дополнением 2.2.104, 2.6.53, 3.0.31 и более новыми версиями. С его помощью можно настроить сертификаты ELB для NGINX Ingress Controller. Подробности см. в Configuring an ELB Certificate for NGINX Ingress Controller.
     • extraContainers: другие контейнеры, добавляемые в pod nginx-ingress-controller. Подробности см. в parameter examples in GitHub. Параметр поддерживается дополнением 2.2.104, 2.6.53, 3.0.31 и более новыми версиями.
     • extraVolumeMounts: позволяет монтировать дополнительные тома в pod nginx-ingress-controller. Подробности см. в parameter examples in GitHub. Параметр поддерживается дополнением 2.2.104, 2.6.53, 3.0.31 и более новыми версиями.
     • extraVolumes: дополнительные тома, монтируемые в pod nginx-ingress-controller. Подробности см. в parameter examples in GitHub. Параметр поддерживается дополнением 2.2.104, 2.6.53, 3.0.31 и более новыми версиями.

5. Настройте политики развертывания для pod‑ов дополнения.
   Note

   • Политики планирования не применяются к pod‑ам DaemonSet дополнения.
   • При настройке развертывания в нескольких AZ или привязки к узлам убедитесь, что в кластере есть узлы, соответствующие политике планирования, и что ресурсов достаточно. В противном случае pod‑ы дополнения не смогут работать.

   Table 1 Конфигурации планирования дополнения

   Параметр	Описание
   Развертывание Multi-AZ	Preferred: Поды развертывания дополнения будут предпочтительно планироваться на узлы в разных AZ. Если все узлы кластера развернуты в одной AZ, поды будут планироваться на разные узлы в этой AZ. Equivalent mode: Поды развертывания дополнения равномерно планируются на узлы кластера в каждой AZ. Если добавлена новая AZ, рекомендуется увеличить количество подов дополнения для развертывания HA с перекрестным AZ. При эквивалентном развертывании multi-AZ разница в количестве подов дополнения в разных AZ будет не более 1. Если ресурсы в одной из AZ недостаточны, поды не могут быть запланированы в эту AZ. ПРИМЕЧАНИЕ: Equivalent mode поддерживает только поды в пространствах имён kube-system и monitoring. Forcible: Поды развертывания дополнения принудительно планируются на узлы в разных AZ. В каждой AZ может быть не более одного пода. Если узлы кластера не охватывают несколько AZ, некоторые поды дополнения останутся незапланированными и не запустятся. Если узел неисправен, поды дополнения на нём могут не быть перенесены.
   Node Affinity	Not configured: Node affinity отключена для подов дополнения. Specify node: Укажите узлы, на которых развертываются поды дополнения. Если узлы не указаны, поды дополнения будут случайным образом планироваться согласно политике планирования кластера по умолчанию. Specify node pool: Укажите пул узлов, в котором развертываются поды дополнения. Если пул узлов не указан, поды дополнения будут случайным образом планироваться согласно политике планирования кластера по умолчанию. Customize affinity: Введите метки узлов, на которых будут развернуты поды дополнения, для более гибкой политики планирования. Если метки узлов не указаны, поды дополнения будут случайным образом планироваться согласно политике планирования кластера по умолчанию. Если настроено несколько пользовательских политик affinity, убедитесь, что в кластере есть узлы, соответствующие всем политикам affinity. В противном случае поды дополнения не смогут работать.
   Toleration	Использование как taints, так и tolerations позволяет (но не требует) планировать pods Deployment дополнения на узлах с соответствующими taints и обеспечивает контроль над политиками выселения pod, когда узлы‑хосты помечены taint. Дополнение применяет политики toleration по умолчанию для taint node.kubernetes.io/not-ready и node.kubernetes.io/unreachable на pod. Окно времени toleration составляет 60s. Подробности см. Configuring Tolerance Policies.

6. Нажмите Install.

1. Войдите в CCE console и нажмите название кластера, чтобы открыть консоль кластера.
2. В панели навигации выберите Add-ons. Найдите NGINX Ingress Controller справа и нажмите New.
3. На отображённой странице перенастройте параметры дополнения. Подробности см. Installing the Add-on.
4. Нажмите Install.
5. Дождитесь, пока будет предоставлена инструкция по установке. Вернитесь к Add-ons, нажмите Manage и просмотрите установленные pods дополнения на странице сведений о дополнении.

Чтобы избежать ситуации, когда узел, на котором работает NGINX Ingress Controller, и его pod'ы не могут получить доступ к любому Nginx ingress, следует настроить анти‑аффинность между рабочей нагрузкой и NGINX Ingress Controller. Это означает, что pod'ы рабочей нагрузки не могут быть запланированы на тот же узел, что и NGINX Ingress Controller.