Стадия жизненного цикла модуля: Preview
У модуля есть требования для установки

Поддерживает ли модуль приём TCP-трафика?

Да. Модуль принимает и маршрутизирует TCP-трафик через Gateway API с помощью объекта TCPRoute.

Чтобы опубликовать TCP-сервис, выполните следующие действия:

  1. Добавьте дополнительный TCP-порт в параметр additionalPorts инлета ALBInstance или ClusterALBInstance, указав protocol: TCP.
  2. Контроллер шлюза обновит список слушателей на управляемом объекте Gateway.
  3. Создайте объект TCPRoute, который ссылается на объект Service и указывает напрямую на новый TCP-слушатель этого Gateway.

Примеры настройки приведены в разделе «Открытие дополнительного TCP/UDP-порта» руководства администратора и в разделе «Объекты GRPCRoute, TLSRoute, TCPRoute и UDPRoute» руководства пользователя.

Поддерживает ли модуль приём UDP-трафика?

Да. Модуль принимает и маршрутизирует UDP-трафик через Gateway API с помощью объекта UDPRoute.

Чтобы опубликовать UDP-сервис, выполните следующие действия:

  1. Добавьте дополнительный UDP-порт в параметр additionalPorts инлета ALBInstance или ClusterALBInstance, указав protocol: UDP.
  2. Контроллер шлюза обновит список слушателей на управляемом объекте Gateway.
  3. Создайте объект UDPRoute, который ссылается на объект Service и указывает напрямую на новый UDP-слушатель этого Gateway.

Правило UDPRoute может ссылаться только на один объект Service.

Примеры настройки приведены в разделе «Открытие дополнительного TCP/UDP-порта» руководства администратора и в разделе «Объекты GRPCRoute, TLSRoute, TCPRoute и UDPRoute» руководства пользователя.

Как настроить балансировщик нагрузки для проверки доступности ClusterALBInstance или ALBInstance?

Если ClusterALBInstance или ALBInstance развёрнут за балансировщиком нагрузки, настройте периодическую проверку доступности конечных точек экземпляра с помощью HTTP-запросов или TCP-пакетов. Проверять доступность можно по открытому TCP-порту, однако рекомендуется использовать HTTP-запросы со следующими параметрами:

  • протокол: HTTP (если включён Proxy Protocol, настройте балансировщик нагрузки так, чтобы он также использовал Proxy Protocol для проверочных соединений);
  • путь: /healthz;
  • порт: 80 или соответствующее значение httpPort, если используется инлет HostPort.

Как добавить собственный HTTP-01 ClusterIssuer или Issuer для ALB?

Если в глобальных настройках в качестве ClusterIssuer по умолчанию задан letsencrypt или letsencrypt-staging, Deckhouse Kubernetes Platform (DKP) заранее создаёт отдельный ACME ClusterIssuer для объекта Gateway DKP по умолчанию.

Имя этого ClusterIssuer будет letsencrypt-gateway-<GATEWAY_NAME> для letsencrypt и letsencrypt-staging-gateway-<GATEWAY_NAME> для letsencrypt-staging, где <GATEWAY_NAME> — значение gatewayName управляемого объекта Gateway.

Этот ClusterIssuer использует механизм проверки HTTP-01 для Gateway API из cert-manager и ссылается на встроенную HTTP-секцию d8-http-default управляемого объекта Gateway.

Если нужен другой ACME-аккаунт, другой ACME-эндпойнт или отдельный издатель сертификатов для приложений, настройте механизм проверки с помощью http01.gatewayHTTPRoute.

Если домен публикуется одновременно через ingress-nginx и alb, а сертификаты выпускаются объектами Issuer или ClusterIssuer с механизмом проверки HTTP-01, создавайте отдельные объекты Certificate для пути Gateway API. Временные ресурсы механизма проверки для Ingress API и Gateway API различаются и могут конфликтовать. В результате один из издателей может перезаписать целевой сертификат. Эта рекомендация относится только к объектам Issuer и ClusterIssuer, настроенным на механизм проверки HTTP-01, и не применяется к объектам, настроенным исключительно на механизм DNS-01.

Пример: собственный ClusterIssuer для ALB

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: <ISSUER_NAME>
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: <EMAIL>
    privateKeySecretRef:
      name: <ACCOUNT_KEY_SECRET>
    solvers:
      - http01:
          gatewayHTTPRoute:
            parentRefs:
              - group: gateway.networking.k8s.io
                kind: Gateway
                name: <GATEWAY_NAME>
                namespace: <GATEWAY_NAMESPACE>
                sectionName: d8-http-default

где:

  • <ISSUER_NAME> — имя объекта ClusterIssuer;
  • <EMAIL> — адрес электронной почты для ACME-аккаунта;
  • <ACCOUNT_KEY_SECRET> — имя объекта Secret с приватным ключом ACME-аккаунта;
  • <GATEWAY_NAME> — имя управляемого объекта Gateway;
  • <GATEWAY_NAMESPACE> — неймспейс управляемого объекта Gateway.

Используйте его в отдельном сертификате для Gateway API:

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: <CERTIFICATE_NAME>
  namespace: <CERTIFICATE_NAMESPACE>
spec:
  secretName: <TLS_SECRET>
  issuerRef:
    kind: ClusterIssuer
    name: <ISSUER_NAME>
  dnsNames:
    - <DNS_NAME>

где:

  • <CERTIFICATE_NAME> — имя объекта Certificate;
  • <CERTIFICATE_NAMESPACE> — неймспейс объекта Certificate;
  • <TLS_SECRET> — имя объекта Secret, в котором хранится выпущенный сертификат;
  • <ISSUER_NAME> — имя объекта ClusterIssuer из предыдущего примера;
  • <DNS_NAME> — DNS-имя, для которого выпускается сертификат.

Пример: Issuer в неймспейсе для ALB

apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: <ISSUER_NAME>
  namespace: <ISSUER_NAMESPACE>
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: <EMAIL>
    privateKeySecretRef:
      name: <ACCOUNT_KEY_SECRET>
    solvers:
      - http01:
          gatewayHTTPRoute:
            parentRefs:
              - group: gateway.networking.k8s.io
                kind: Gateway
                name: <GATEWAY_NAME>
                namespace: <GATEWAY_NAMESPACE>
                sectionName: d8-http-default

где:

  • <ISSUER_NAME> — имя объекта Issuer;
  • <ISSUER_NAMESPACE> — неймспейс объекта Issuer;
  • <EMAIL> — адрес электронной почты для ACME-аккаунта;
  • <ACCOUNT_KEY_SECRET> — имя объекта Secret с приватным ключом ACME-аккаунта;
  • <GATEWAY_NAME> — имя управляемого объекта Gateway;
  • <GATEWAY_NAMESPACE> — неймспейс управляемого объекта Gateway.

Используйте его в сертификате в том же неймспейсе:

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: <CERTIFICATE_NAME>
  namespace: <ISSUER_NAMESPACE>
spec:
  secretName: <TLS_SECRET>
  issuerRef:
    kind: Issuer
    name: <ISSUER_NAME>
  dnsNames:
    - <DNS_NAME>

где:

  • <CERTIFICATE_NAME> — имя объекта Certificate;
  • <ISSUER_NAMESPACE> — общий неймспейс для Issuer и Certificate;
  • <TLS_SECRET> — имя объекта Secret, в котором хранится выпущенный сертификат;
  • <ISSUER_NAME> — имя объекта Issuer из предыдущего примера;
  • <DNS_NAME> — DNS-имя, для которого выпускается сертификат.

В обоих примерах:

  • <GATEWAY_NAME> и <GATEWAY_NAMESPACE> в parentRefs должны совпадать с управляемым объектом Gateway, который используется ClusterALBInstance или ALBInstance;
  • sectionName: d8-http-default указывает cert-manager размещать временные маршруты проверок HTTP-01 на встроенном HTTP-слушателе шлюза;
  • отдельные объекты сертификатов для Gateway API помогают избежать конфликтов с ресурсами проверки HTTP-01 модуля ingress-nginx.