NGINX Ingress Controller

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

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

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

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

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

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

• Для кластеров версии ранее v1.23, kubernetes.io/ingress.class: "nginx" необходимо добавить в аннотацию ingress, созданного через API. Если в кластере установлено несколько контроллеров NGINX Ingress, необходимо заменить nginx на пользовательский ingress class, чтобы помочь идентифицировать экземпляр контроллера, связанный с ingress.
• Выделенный балансировщик нагрузки должен быть сетевого типа (TCP/UDP) и поддерживать частные сети (с частным IP-адресом).
• Если узел, на котором работает NGINX Ingress Controller, и поды на этом узле не могут получить доступ к Nginx ingress, необходимо настроить anti-affinity для подов рабочей нагрузки и подов 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, постоянные соединения будут разорваны, и связь будет прервана на короткое время.
• Когда дополнение NGINX Ingress Controller связано с выделенным балансировщиком нагрузки, узлы, размещающие pod‑ы NGINX Ingress Controller, не могут получить доступ к частному IP-адресу балансировщика нагрузки.

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

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

   Вы можете при необходимости изменить количество 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 версии 2.2.75, 2.6.26, 3.0.1 и новее.

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

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

     Note

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

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

     Параметр Nginx	Описание	Значение по умолчанию
     Maximum Worker Connections	Указывает максимальное количество соединений, которые каждый процесс‑worker Nginx может обрабатывать одновременно. Этот параметр используется для управления нагрузкой процессов‑worker. В среде с высокой конкуренцией рекомендуется установить этот параметр на большое значение, чтобы обеспечить стабильность системы. Такие соединения включают соединения клиентов и соединения с серверами back‑end.	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‑сервером и сервером back‑end, в секундах. В течение этого периода NGINX Ingress Controller может поддерживать соединения для повторного использования. Это уменьшает накладные расходы на установление новых соединений и значительно повышает производительность в сценариях с высоким QPS.	900
     Request Timeout	Указывает тайм‑аут подключения клиента к прокси‑серверу, в секундах. Если клиент не может получить доступ к серверу back‑end в течение 10 секунд, NGINX Ingress Controller вернёт ошибку 502 Bad Gateway. Применяется в сценариях с высокой скоростью соединения.	10
     Maximum Request Body Size	Указывает максимальный размер тела запроса, которое Nginx может отправлять на сервер back‑end через прокси. Это относится к загрузке файлов и отправке больших форм данных. Если размер тела любого запроса превышает лимит, будет возвращена ошибка 413 Payload Too Large.	20m
     Allow to Pass Through the Backend Server's Header	Обычно NGINX Ingress Controller удаляет заголовок server, отправляемый сервером back‑end клиенту, который идентифицирует сервер. Однако если этот параметр установлен в true, NGINX Ingress Controller будет передавать заголовок server напрямую от сервера back‑end клиенту. Чтобы избежать раскрытия типа и версии сервера, рекомендуется отключить эту опцию.	Disable
     Allow Underscores in Headers	Некоторые HTTP‑заголовки могут содержать символ подчёркивания (_), например X_Custom-Header, но согласно стандартам Request For Comments (RFC) это не рекомендуется. Поэтому многие серверы по умолчанию не разрешают подчёркивания. Вы можете включить этот параметр, если вам нужны подчёркивания в определённых заголовках, например когда сторонние сервисы или клиенты используют подчёркивания в информации заголовков.	Disable
     Generate Request ID	После получения запроса NGINX Ingress Controller генерирует уникальный идентификатор запроса. Этот идентификатор обычно записывается в логи или передаётся на сервер backend через заголовок. Это полезно для трассировки и отладки запросов, особенно для выявления проблем в распределённых системах.	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, введите имя пространства имён/службы. Если служба не существует, установка дополнения завершится ошибкой.
   • 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: Выберите пространство имён, в котором находится 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 или привязки к узлам убедитесь, что в кластере есть узлы, соответствующие политике планирования, и что ресурсов достаточно. В противном случае дополнение не сможет работать.

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

   Параметр	Описание
   Развертывание Multi-AZ	Preferred: Поды развертывания дополнения будут предпочтительно планироваться на узлы в разных AZ. Если все узлы кластера развернуты в одной AZ, поды будут планироваться на разные узлы в этой AZ. Equivalent mode: Поды развертывания дополнения равномерно планируются на узлы кластера в каждой AZ. Если добавлена новая AZ, рекомендуется увеличить количество подов дополнения для развертывания HA с перекрёстным AZ. При Equivalent multi-AZ deployment разница между количеством подов дополнения в разных 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: Введите метки узлов, на которых должны быть развернуты поды дополнения, для более гибкой политики планирования. Если метки узлов не указаны, поды дополнения будут случайным образом планироваться в соответствии с политикой планирования кластера по умолчанию. Если настроено несколько пользовательских политик аффинности, убедитесь, что в кластере есть узлы, соответствующие всем политикам аффинности. В противном случае дополнение не сможет работать.
   Toleration	Использование как taints, так и tolerations позволяет (не принудительно) планировать pods Deployment дополнения на узел с соответствующими taints и может управлять политиками выселения pods Deployment после того, как узлы‑хосты будут помечены taints. Дополнение добавляет политику toleration по умолчанию для taints node.kubernetes.io/not-ready и node.kubernetes.io/unreachable соответственно. Окно времени toleration составляет 60s. Для получения подробной информации см. Configuring Tolerance Policies.

6. Нажмите Install.

1. Войдите в CCE console и нажмите название кластера, чтобы открыть консоль кластера.
2. В панели навигации выберите Add-ons. Найдите NGINX Ingress Controller справа и нажмите New.
3. На отображённой странице перенастройте параметры дополнения. Для получения подробной информации см. Installing the Add-on.
4. Click Install.
5. Wait until the installation instruction is delivered. Go back to Add-ons, click Manage, and view the installed add-on pods on the add-on details page.

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