В Kubernetes ingress — это объект ресурса, который управляет тем, как Services внутри кластера могут быть доступны извне кластера. Вы можете использовать ingress'ы для настройки различных правил переадресации доступа к pod'ам в кластере. Ниже используется Nginx workload в качестве примера, чтобы описать, как создать LoadBalancer ingress в console.
В этом разделе используется Nginx workload в качестве примера, чтобы описать, как добавить LoadBalancer ingress.
Балансировщик нагрузки может быть выделенным или общим. Выделенный балансировщик нагрузки должен быть типа application (HTTP/HTTPS) и поддерживать частные сети.
You can select Use existing or Auto create to obtain a load balancer. For details about the configuration of different creation modes, see Table 1.
Метод создания | Конфигурация |
|---|---|
Использовать существующий | Only load balancers in the same VPC as the cluster can be selected. If no load balancer is available, click Create Load Balancer to create one on the ELB console. |
Автосоздание |
|
Для кластеров v1.25.16-r10, v1.27.16-r10, v1.28.15-r0, v1.29.10-r0, v1.30.6-r0, v1.31.1-r0 и более новых при использовании выделенного балансировщика нагрузки можно одновременно выбрать не более пяти групп IP-адресов для контроля доступа.
Если для выбранного порта на балансировщике нагрузки уже существует HTTPS‑ingress, сертификат нового HTTPS‑ingress должен совпадать с сертификатом существующего ingress. Это означает, что у listener может быть только один сертификат. Если к одному listener того же балансировщика нагрузки добавить два сертификата, каждый с разным ingress, действующим будет только тот сертификат, который был добавлен первым.
Подробную информацию о политиках безопасности см. в Elastic Load Balance User Guide.
Когда listener соответствует HTTP, можно выбрать только HTTP.
Если это HTTPS listener, этот параметр можно установить в HTTP или HTTPS.
Configuration | Description | Constraint |
|---|---|---|
Transfer Listener Port Number | Если эта функция включена, прослушиваемый порт на балансировщике нагрузки может быть передан бэкэнд‑серверам через HTTP‑заголовок пакета. | Эта функция доступна только для выделенных балансировщиков нагрузки. |
Transfer Port Number in the Request | Если эта функция включена, исходный порт клиента может передаваться бэкенд‑серверам через HTTP header пакета. | Эта функция доступна только для dedicated load balancers. |
Rewrite X-Forwarded-Host | Если эта функция включена, X-Forwarded-Host будет перезаписан с использованием поля Host в заголовке запроса клиента и передан бэкенд‑серверам. | Эта функция доступна только для dedicated load balancers. |
Data Compression | Если эта функция включена, определённые файлы будут сжаты. Если она не включена, файлы не будут сжаты.
| Эта функция доступна только для dedicated load balancers. |
Idle Timeout (s) | Продолжительность, в течение которой соединение клиента может оставаться бездействующим до его завершения. Если в течение этого периода запросы не поступают к load balancer, load balancer разорвет соединение с клиентом и установит новое соединение при появлении нового запроса. | Эта конфигурация не поддерживается, когда UDP используется на совместном load balancer. |
Request Timeout (s) | Период, в течение которого должен быть получен запрос от клиента. Существует два случая:
| Эта функция доступна только для HTTP и HTTPS listener'ов. |
Response Timeout (s) | Тайм‑аут ответа сервера backend. Если сервер backend не отвечает в течение этого периода после получения запроса, балансировщик нагрузки прекратит ожидание и вернёт ошибку HTTP 504. | Эта функция доступна только для HTTP и HTTPS listener'ов. |
Enable HTTP/2 | Определяет, включить ли HTTP/2 для HTTPS‑запросов между клиентом и балансировщиком нагрузки. Перенаправление запросов с использованием HTTP/2 повышает производительность доступа между вашим приложением и балансировщиком нагрузки. Однако балансировщик нагрузки по‑прежнему использует HTTP/1.x для перенаправления запросов к серверу backend. | Эта функция доступна только когда listener соответствует HTTPS. |
, чтобы добавить несколько политик перенаправления.Добавленный здесь путь доступа должен существовать в бекенд‑приложении. В противном случае переадресация завершится неудачей.
Например, URL доступа по умолчанию для приложения Nginx — /usr/share/nginx/html. При добавлении /test в политику переадресации ingress убедитесь, что URL доступа вашего приложения Nginx содержит /usr/share/nginx/html/test. В противном случае будет возвращена ошибка 404.
Параметр | Описание |
|---|---|
Протокол | Поддерживаются HTTP и TCP.
|
Порт | По умолчанию для проверки состояния используется порт сервиса (NodePort или контейнерный порт Service). Вы также можете указать другой порт для проверки состояния. После указания порта для Service будет добавлен порт сервиса с именем cce-healthz.
|
Период проверки (с) | Максимальный интервал между проверками состояния. Диапазон значений от 1 до 50. |
Тайм-аут (с) | Максимальное время ожидания ответа каждой проверки состояния. Диапазон значений от 1 до 50. |
Max. Retries | Максимальное количество попыток повторного запроса до пометки backend как нездорового. Значение может быть от 1 до 10. |
On the ELB console, you can check the load balancer automatically created through CCE. The default name is cce-lb-<ingress.UID>. Click the load balancer name to go to the details page. On the Listeners tab page, check the listener and forwarding policy of the target ingress.
После создания ingress обновляйте и обслуживайте выбранный load balancer в консоли CCE. Не изменяйте конфигурацию в консоли ELB. В противном случае сервис ingress может работать некорректно.
Figure 1 Accessing the /healthz interface of defaultbackend
