Стадия жизненного цикла модуля: Preview
У модуля есть требования для установки
В этом разделе приведены примеры конфигурации инфраструктуры для приёма трафика с помощью модуля alb в разных окружениях. Инфраструктура задаётся объектами ClusterALBInstance (cluster-scoped) и ALBInstance (в неймспейсе), а тип приёма трафика — параметром spec.inlet.type.
Модуль поддерживает два типа инлета:
LoadBalancer— приём трафика через объект Service с типомLoadBalancer(облачные провайдеры или bare metal с MetalLB). Доступен и для ClusterALBInstance, и для ALBInstance.HostPort— приём трафика на портах узлов без внешнего балансировщика. Доступен только для ClusterALBInstance.
Примеры публикации приложений и настройки маршрутов приведены в разделе «Руководство пользователя», а управление шлюзами и диагностика описаны в разделе «Руководство администратора».
Пример для облачного провайдера (инлет LoadBalancer)
В облачных кластерах приём трафика обычно организуется через инлет LoadBalancer: платформа создаёт объект Service с типом LoadBalancer, а облачный провайдер выделяет для него внешний адрес.
apiVersion: network.deckhouse.io/v1alpha1
kind: ClusterALBInstance
metadata:
name: main
spec:
gatewayName: public-gw
inlet:
type: LoadBalancer
loadBalancer: {}Чтобы задать параметры облачного балансировщика, укажите нужные аннотации объекта Service в параметре spec.inlet.loadBalancer.serviceAnnotations. Например, для балансировщика Network Load Balancer в AWS:
apiVersion: network.deckhouse.io/v1alpha1
kind: ClusterALBInstance
metadata:
name: main
spec:
gatewayName: public-gw
inlet:
type: LoadBalancer
loadBalancer:
serviceAnnotations:
service.beta.kubernetes.io/aws-load-balancer-type: "nlb"Пример для bare metal с балансировщиком MetalLB
Если внешнего облачного балансировщика нет, для инлета LoadBalancer можно использовать модуль metallb.
-
Включите модуль
metallb:apiVersion: deckhouse.io/v1alpha1 kind: ModuleConfig metadata: name: metallb spec: enabled: true version: 2 -
Создайте объект MetalLoadBalancerClass с пулом адресов. Разместите балансировщики MetalLB на тех же узлах, что и поды Envoy Proxy модуля
alb(в типовых сценариях для этого используются frontend-узлы с меткойnode-role.deckhouse.io/frontend):apiVersion: network.deckhouse.io/v1alpha1 kind: MetalLoadBalancerClass metadata: name: alb spec: addressPool: - 192.168.2.100-192.168.2.150 isDefault: false nodeSelector: node-role.deckhouse.io/frontend: "" type: L2 -
Создайте объект ClusterALBInstance, указав созданный класс балансировщика в параметре
spec.inlet.loadBalancer.loadBalancerClass:apiVersion: network.deckhouse.io/v1alpha1 kind: ClusterALBInstance metadata: name: main spec: gatewayName: public-gw inlet: type: LoadBalancer loadBalancer: loadBalancerClass: alb serviceAnnotations: # Количество адресов, выделяемых из пула, объявленного в MetalLoadBalancerClass. network.deckhouse.io/l2-load-balancer-external-ips-count: "1"
Пример для bare metal без внешнего балансировщика (инлет HostPort)
Если внешний балансировщик не используется, а трафик должен приниматься непосредственно на портах узлов, примените инлет HostPort. Этот тип инлета доступен только для ClusterALBInstance.
apiVersion: network.deckhouse.io/v1alpha1
kind: ClusterALBInstance
metadata:
name: main
spec:
gatewayName: public-gw
inlet:
type: HostPort
hostPort:
httpPort: 80
httpsPort: 443Чтобы поды Envoy Proxy модуля alb размещались только на выделенных узлах, задайте для ClusterALBInstance параметры nodeSelector и tolerations.
Приём трафика за внешним L7-балансировщиком (Proxy Protocol)
Если модуль alb работает за внешним L7-балансировщиком (например, Cloudflare, Qrator или сторонний балансировщик), включите Proxy Protocol, чтобы получать реальные адреса клиентов. Дополнительно ограничьте с помощью параметра spec.originalIPDetection список подсетей, из которых разрешено доверять заголовкам с адресом клиента.
apiVersion: network.deckhouse.io/v1alpha1
kind: ClusterALBInstance
metadata:
name: main
spec:
gatewayName: public-gw
inlet:
type: HostPort
hostPort:
httpPort: 80
httpsPort: 443
useProxyProtocol: true
originalIPDetection:
setRealIPFrom:
- 10.0.0.0/16Proxy Protocol и HTTP/3 нельзя включать одновременно.
Разделение публичной и административной зон
Если публичный и административный трафик нужно разделить, создайте отдельный объект Gateway для каждой зоны и ограничьте приём административного трафика с помощью параметра spec.acceptRequestsFrom. Решение о допуске соединения принимается по реальному адресу подключения, а не по заголовкам запроса.
Публичный шлюз принимает трафик отовсюду:
apiVersion: network.deckhouse.io/v1alpha1
kind: ClusterALBInstance
metadata:
name: public
spec:
gatewayName: public-gw
inlet:
type: LoadBalancer
loadBalancer: {}Административный шлюз принимает трафик только из доверенных подсетей:
apiVersion: network.deckhouse.io/v1alpha1
kind: ClusterALBInstance
metadata:
name: admin
spec:
gatewayName: admin-gw
inlet:
type: LoadBalancer
loadBalancer: {}
acceptRequestsFrom:
- 1.2.3.4/32
- 10.0.0.0/16Далее для каждого шлюза создайте отдельные объекты ListenerSet и маршруты, привязав административные приложения к объекту Gateway admin-gw, а публичные — к public-gw. Примеры создания маршрутов приведены в разделе «Объекты GRPCRoute, TLSRoute, TCPRoute и UDPRoute».
Публикация в неймспейсе (инлет LoadBalancer через ALBInstance)
Если инфраструктурой приёма трафика управляет команда приложения в пределах своего неймспейса, используйте объект ALBInstance. Он поддерживает только инлет LoadBalancer, а объекты Gateway, ListenerSet и маршруты располагаются в одном неймспейсе.
apiVersion: network.deckhouse.io/v1alpha1
kind: ALBInstance
metadata:
name: app-gw
namespace: prod
spec:
gatewayName: app-gw
inlet:
type: LoadBalancer
loadBalancer: {}После того как объект ALBInstance перейдёт в состояние Ready, создайте объекты ListenerSet и HTTPRoute в том же неймспейсе. Полный пример приведён в разделе «Публикация приложения через объект ALBInstance» руководства пользователя.