Облачная платформаAdvanced

Создание LoadBalancer Ingress в Console

Язык статьи: Русский
Показать оригинал
Страница переведена автоматически и может содержать неточности. Рекомендуем сверяться с английской версией.

В Kubernetes ingress — это объект ресурса, который управляет тем, как Services внутри кластера могут быть доступны извне кластера. Вы можете использовать ingress'ы для настройки различных правил переадресации доступа к pod'ам в кластере. Ниже используется Nginx workload в качестве примера, чтобы описать, как создать LoadBalancer ingress в console.

Требования

Примечания и ограничения

  • Только кластеры v1.17 и новее поддерживают выделенные load balancers.
  • Рекомендуется, чтобы другие ресурсы не использовали load balancer, автоматически создаваемый ingress'ом. В противном случае load balancer будет занят после удаления ingress, что приведёт к оставшимся ресурсам.
  • После создания ingress обновляйте и поддерживайте конфигурацию выбранных load balancers в консоли CCE. Не изменяйте конфигурацию в консоли ELB. В противном случае сервис ingress может работать некорректно.
  • URL, зарегистрированный в политике переадресации ingress, должен совпадать с URL, используемым для доступа к backend Service. В противном случае будет возвращена ошибка 404.
  • В кластере IPVS, если LoadBalancer ingress и Service используют один и тот же load balancer, доступ к ingress из узлов и контейнеров кластера невозможен. Это происходит потому, что kube-proxy привязывает адрес LoadBalancer Service к мосту ipvs-0, перехватывающему трафик ELB. Используйте разные load balancers для LoadBalancer ingress и Service.
  • Выделенные load balancers должны быть типа application (HTTP/HTTPS) и поддерживать частные сети (частные IP-адреса).
  • Если несколько ingress'ов обращаются к одному и тому же порту ELB в кластере, параметры конфигурации listener'а (например, сертификат, связанный с listener'ом, и атрибут HTTP/2 listener'а) подчиняются конфигурации первого ingress.

Добавление LoadBalancer Ingress

В этом разделе используется Nginx workload в качестве примера, чтобы описать, как добавить LoadBalancer ingress.

  1. Войдите в CCE console и нажмите имя кластера, чтобы открыть консоль кластера.
  2. Выберите Services and Ingresses в панели навигации, нажмите вкладку Ingresses и нажмите Create Ingress в правом верхнем углу.
  3. Настройте параметры Ingress.

    • Name: Введите имя для Ingress, например, ingress-demo.
    • Namespace: пространство имён, к которому относится LoadBalancer Ingress.
    • Interconnect with Nginx: This option is displayed only after the NGINX Ingress Controller add-on is installed. If this option is available, the NGINX Ingress Controller add-on has been installed. Enabling this option will create an Nginx ingress. Disable it if you want to create a LoadBalancer ingress. For details, see Creating an Nginx Ingress on the Console.
    • Protocol Version: Select a protocol version of the LoadBalancer ingress. This parameter is only available for IPv4/IPv6 dual-stack clusters.
    • Load Balancer: Select a load balancer type and creation mode.

      Балансировщик нагрузки может быть выделенным или общим. Выделенный балансировщик нагрузки должен быть типа 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.

      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.

      Автосоздание

      • Instance Name: Введите имя балансировщика нагрузки.
      • Enterprise Project (только для выделенных балансировщиков нагрузки): Этот параметр доступен только для корпоративных пользователей, которые включили проект предприятия. Проекты предприятия упрощают управление на уровне проекта и группировку облачных ресурсов и пользователей.
      • AZ: доступно только для выделенных балансировщиков нагрузки. Вы можете создавать балансировщики нагрузки в нескольких AZ, чтобы повысить доступность сервиса. Если требуется восстановление после катастрофы, выберите несколько AZ.
      • Frontend Subnet: доступно только для выделенных балансировщиков нагрузки. Он используется для выделения IP‑адресов балансировщикам нагрузки для предоставления сервисов во внешнюю сеть.
      • Backend Subnet: доступно только для выделенных балансировщиков нагрузки. Он используется для выделения IP‑адресов балансировщикам нагрузки для доступа к бэкенд‑сервису.
      • Network Specifications, Application-oriented Specifications или Specifications (доступно только для выделенных балансировщиков нагрузки)
        • Elastic: применяется к переменному трафику. Вы оплачиваете фактическое использование Load Balancer Capacity Unit (LCU). Кластеры v1.21.10-r10, v1.23.8-r10, v1.25.3-r10 и более поздние версии поддерживают эластичные спецификации.
        • Fixed: применяется к стабильному трафику, оплата производится на основе спецификаций.
      • EIP: Если вы выберете Auto assign, вы можете настроить пропускную способность для публичной сети.
      • Resource Tag: Вы можете добавлять теги ресурсов для классификации ресурсов. Вы можете создать предопределённые теги в консоли TMS. Эти теги доступны всем ресурсам, поддерживающим теги. Вы можете использовать эти теги для повышения эффективности создания тегов и миграции ресурсов.

    • Listener: An ingress configures a listener for the load balancer, which listens to requests from the load balancer and distributes traffic. After the configuration is complete, a listener is created on the load balancer. The default listener name is k8s_<Protocol type>_<Port number>, for example, k8s_HTTP_80.
      • Frontend Protocol: Установите протокол listener балансировщика нагрузки для установления соединений с клиентами.
      • External Port: номер порта, открытый для адреса сервиса ELB. Номер порта настраиваемый. Если вы выбираете существующий балансировщик нагрузки, порты listener разных кластеров нельзя переиспользовать. Несколько ingress в одном кластере могут использовать один и тот же порт listener, но рабочая конфигурация listener определяется самой ранней конфигурацией ingress.
      • Контроль доступа
        • Inherit ELB Configurations: CCE не изменяет существующие конфигурации контроля доступа в консоли ELB.
        • Allow all IP addresses: Конфигурация контроля доступа не задана.
        • Trustlist: Доступ к балансировщику нагрузки имеет только выбранная группа IP-адресов.
        • Blocklist: Выбранная группа IP-адресов не может получить доступ к балансировщику нагрузки.
        Note

        Для кластеров 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-адресов для контроля доступа.

      • Certificate Source: Поддерживаются TLS secret и сертификаты сервера ELB.
        • TLS secret: Подробную информацию о создании секретного сертификата см. в Creating a Secret.
        • ELB server certificate: Используйте сертификат, созданный в ELB.
      • Server Certificate: При создании HTTPS‑listener для балансировщика нагрузки привяжите к нему сертификат, чтобы обеспечить зашифрованную аутентификацию при передаче данных по HTTPS.
        Note

        Если для выбранного порта на балансировщике нагрузки уже существует HTTPS‑ingress, сертификат нового HTTPS‑ingress должен совпадать с сертификатом существующего ingress. Это означает, что у listener может быть только один сертификат. Если к одному listener того же балансировщика нагрузки добавить два сертификата, каждый с разным ingress, действующим будет только тот сертификат, который был добавлен первым.

      • SNI: обозначает Server Name Indication (SNI) — расширенный протокол TLS. SNI позволяет нескольким доменным именам TLS использовать одну пару IP:порт, при этом для каждого доменного имени применяется отдельный сертификат. При включённом SNI клиент может передать запрашиваемое доменное имя во время TLS‑handshake. Балансировщик нагрузки использует доменное имя из TLS‑запроса для поиска соответствующего сертификата. Если сертификат найден, он возвращается; иначе возвращается сертификат сервера по умолчанию.
        Note
        • Параметр SNI доступен только при использовании HTTPS.
        • Эта функция поддерживается только в кластерах версии v1.15.11 и новее.
        • Для каждого сертификата SNI можно указать только одно доменное имя. Поддерживаются сертификаты с подстановочным доменом.
        • Для ingress, подключённых к одному порту ELB, не настраивайте SNI с одинаковым доменным именем, но разными сертификатами. В противном случае SNI будут перезаписаны.
      • Security Policy: комбинации различных версий TLS и поддерживаемых наборов шифров, доступные для HTTPS‑слушателей. Значение по умолчанию — TLS-1-2.

        Подробную информацию о политиках безопасности см. в Elastic Load Balance User Guide.

        Note
        • Security Policy доступна только при выборе HTTPS.
        • Эта функция поддерживается только в кластерах версии v1.17.9 и новее.
      • Backend Protocol:

        Когда listener соответствует HTTP, можно выбрать только HTTP.

        Если это HTTPS listener, этот параметр можно установить в HTTP или HTTPS.

      • Advanced Options

        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

        Если эта функция включена, определённые файлы будут сжаты. Если она не включена, файлы не будут сжаты.

        • Brotli может сжимать все форматы файлов.
        • GZIP может сжимать файлы следующих типов:

          text/xml, text/plain, text/css, application/javascript, application/x-javascript, application/rss+xml, application/atom+xml, application/xml, and application/json

        Эта функция доступна только для 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.

    • Forwarding Policy: Когда адрес доступа запроса соответствует политике перенаправления (которая состоит из доменного имени, порта и URL, например, 10.117.117.117:80/helloworld), запрос перенаправляется к целевому Service для обработки. Вы можете нажать , чтобы добавить несколько политик перенаправления.
      • Domain Name: Укажите фактическое доменное имя для доступа. Если оставить поле пустым, вход может быть доступен по IP‑адресу. Доменное имя должно быть зарегистрировано и оформлено. После использования в политике перенаправления будет приниматься только это доменное имя.
      • Path Matching Rule:
        • Prefix match: Если URL установлен как /healthz, можно получить доступ к URL, соответствующим префиксу, например, /healthz/v1 и /healthz/v2.
        • Exact match: URL доступен только при полном совпадении. Например, если URL установлен как /healthz, доступен только /healthz.
        • RegEx match: URL сопоставляется на основе регулярного выражения. Например, если регулярное выражение /[A-Za-z0-9_.-]+/test, все URL, соответствующие этому правилу, могут быть доступны, например, /abcA9/test и /v1-Ab/test. Поддерживаются два стандарта регулярных выражений: POSIX и Perl.
      • Path: путь доступа, например, /healthz
        Note

        Добавленный здесь путь доступа должен существовать в бекенд‑приложении. В противном случае переадресация завершится неудачей.

        Например, URL доступа по умолчанию для приложения Nginx — /usr/share/nginx/html. При добавлении /test в политику переадресации ingress убедитесь, что URL доступа вашего приложения Nginx содержит /usr/share/nginx/html/test. В противном случае будет возвращена ошибка 404.

      • Destination Service: выберите существующий Service. В список Service автоматически отображаются только Service, соответствующие требованиям.
      • Destination Service Port: выберите порт доступа destination Service. Порт destination Service должен использовать TCP.
      • Set ELB:
        • Algorithm: можно выбрать Weighted round robin, Weighted least connections или Source IP hash.
          Note
          • Weighted round robin: запросы распределяются между бекенд‑серверами пропорционально их назначенным весам, отражающим относительные вычислительные возможности. Сервера с одинаковым весом получают одинаковое количество соединений. Этот алгоритм подходит для короткоживущих соединений, например HTTP‑сервисов.
          • Weighted least connections: запросы направляются на сервер с наименьшим соотношением количество соединений к весу. Помимо веса каждого сервера, алгоритм учитывает количество активных соединений, обрабатываемых в данный момент. Подходит для длительных соединений, например соединений с базой данных.
          • Source IP hash: IP‑адрес источника каждого запроса хешируется для получения постоянного ключа, который сопоставляет клиенту конкретный бекенд‑сервер. Это распределяет запросы между клиентами, обеспечивая при этом постоянство сессии для одного и того же клиента. Алгоритм подходит для TCP‑соединений, когда недоступна привязка сессии на основе cookie.
        • Sticky Session: функция отключена по умолчанию. Доступные варианты:
          • Load balancer cookie: введите Stickiness Duration, значение от 1 до 1440 минут.
          • Application cookie: введите Cookie Name от 1 до 1024 символов.
          Note
          • Если distribution policy использует source IP hash, sticky session нельзя задать.
          • Выделенные балансировщики нагрузки в кластерах версии ранее v1.21 не поддерживают sticky sessions. Если требуются sticky sessions, используйте общие балансировщики нагрузки.
        • Health Check: Установите конфигурацию проверки состояния балансировщика нагрузки. Если эта функция включена, поддерживаются следующие параметры:

          Параметр

          Описание

          Протокол

          Поддерживаются HTTP и TCP.

          • Check Path: Этот параметр доступен только для HTTP‑проверок состояния. Он указывает URL проверки состояния. Путь проверки должен начинаться со слеша (/) и содержать от 1 до 80 символов.

          Порт

          По умолчанию для проверки состояния используется порт сервиса (NodePort или контейнерный порт Service). Вы также можете указать другой порт для проверки состояния. После указания порта для Service будет добавлен порт сервиса с именем cce-healthz.

          • Node Port: Если используется общий балансировщик нагрузки или не привязан экземпляр ENI, в качестве порта проверки состояния используется node port. Если параметр не указан, используется случайный порт. Диапазон значений от 30000 до 32767.
          • Container Port: Когда выделенный балансировщик нагрузки связан с сетевым интерфейсом, для проверки состояния используется контейнерный порт. Диапазон значений от 1 до 65535.

          Период проверки (с)

          Максимальный интервал между проверками состояния. Диапазон значений от 1 до 50.

          Тайм-аут (с)

          Максимальное время ожидания ответа каждой проверки состояния. Диапазон значений от 1 до 50.

          Max. Retries

          Максимальное количество попыток повторного запроса до пометки backend как нездорового. Значение может быть от 1 до 10.

      • Operation: нажмите Delete, чтобы удалить конфигурацию.
    • Annotation: Ingresses предоставляют некоторые расширенные функции CCE, которые реализуются с помощью аннотаций. При использовании kubectl для создания контейнера будут применяться аннотации. Подробнее см. Automatically Creating a Load Balancer While Creating an Ingress или Associating an Existing Load Balancer to an Ingress While Creating the Ingress.

  4. Нажмите OK. После создания ingress он отображается в списке ingress.

    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.

    Notice

    После создания ingress обновляйте и обслуживайте выбранный load balancer в консоли CCE. Не изменяйте конфигурацию в консоли ELB. В противном случае сервис ingress может работать некорректно.

  5. Получите доступ к интерфейсу /healthz рабочей нагрузки, например, workload defaultbackend.

    1. Получите адрес доступа к интерфейсу /healthz рабочей нагрузки. Адрес доступа состоит из IP-адреса load balancer, внешнего порта и URL‑отображения, например, 10.**.**.**:80/healthz.
    2. Введите URL интерфейса /healthz, например http://10.**.**.**:80/healthz, в адресную строку браузера для доступа к workload, как показано на Figure 1.

      Figure 1 Accessing the /healthz interface of defaultbackend