An example for AWS (Network Load Balancer)

Пример для AWS (Network Load Balancer)

When creating a balancer, all zones available in the cluster will be used.

При создании балансировщика будут использованы все доступные в кластере зоны.

In each zone, the balancer receives a public IP. If there is an instance with an Ingress controller in the zone, an A-record with the balancer’s IP address from this zone is automatically added to the balancer’s domain name.

В каждой зоне балансировщик получает публичный IP. Если в зоне есть инстанс с Ingress-контроллером, A-запись с IP-адресом балансировщика из этой зоны автоматически добавляется к доменному имени балансировщика.

When there are no instances with an Ingress controller in the zone, then the IP is automatically removed from the DNS.

Если в зоне не остается инстансов с Ingress-контроллером, тогда IP автоматически убирается из DNS.

If there is only one instance with an Ingress controller in a zone, when the pod is restarted, the IP address of the balancer of this zone will be temporarily excluded from DNS.

В том случае, если в зоне всего один инстанс с Ingress-контроллером, при перезапуске пода IP-адрес балансировщика этой зоны будет временно исключен из DNS.

yaml apiVersion: deckhouse.io/v1 kind: IngressNginxController metadata: name: main spec: ingressClass: “nginx” inlet: “LoadBalancer” loadBalancer: annotations: service.beta.kubernetes.io/aws-load-balancer-type: “nlb”

yaml apiVersion: deckhouse.io/v1 kind: IngressNginxController metadata: name: main spec: ingressClass: nginx inlet: LoadBalancer loadBalancer: annotations: service.beta.kubernetes.io/aws-load-balancer-type: “nlb”

An example for GCP / Yandex Cloud / Azure

Пример для GCP / Yandex Cloud / Azure

yaml apiVersion: deckhouse.io/v1 kind: IngressNginxController metadata: name: main spec: ingressClass: “nginx” inlet: “LoadBalancer”

yaml apiVersion: deckhouse.io/v1 kind: IngressNginxController metadata: name: main spec: ingressClass: nginx inlet: LoadBalancer

In GCP, nodes must have an annotation enabling them to accept connections to external addresses for the NodePort type services.

В GCP на узлах должна присутствовать аннотация, разрешающая принимать подключения на внешние адреса для сервисов с типом NodePort.

An example for OpenStack

Пример для OpenStack

An example for Bare metal

Пример для bare metal

An example for Bare metal (Behind external load balancer, e.g. Cloudflare, Qrator, Nginx+, Citrix ADC, Kemp, etc.)

Пример для bare metal (при использовании внешнего балансировщика, например Cloudflare, Qrator, Nginx+, Citrix ADC, Kemp и др.)

An example for Bare metal (MetalLB BGP LoadBalancer)

Пример для bare metal (балансировщик MetalLB в режиме BGP LoadBalancer)

This feature is available in Enterprise Edition only.

Доступно в следующих редакциях: EE, CSE Pro (1.67).

In the case of using MetalLB, its speaker Pods must be run on the same Nodes as the Ingress controller Pods.

В случае использования MetalLB его speaker-поды должны быть запущены на тех же узлах, что и поды Ingress–контроллера.

The controller must receive real IP addresses of clients — therefore its Service is created with the parameter externalTrafficPolicy: Local (disabling cross–node SNAT), and to satisfy this parameter the MetalLB speaker announce this Service only from those Nodes where the target Pods are running.

Контроллер должен получать реальные IP-адреса клиентов — поэтому его Service создается с параметром externalTrafficPolicy: Local (запрещая межузловой SNAT), и для удовлетворения данного параметра MetalLB speaker анонсирует этот Service только с тех узлов, где запущены целевые поды.

So for the current example metallb module configuration should be like this:

Таким образом, для данного примера конфигурация модуля metallb должна быть такой:

An example for Bare metal (MetalLB L2 LoadBalancer)

Пример для bare metal (балансировщик MetalLB в режиме L2 LoadBalancer)

This feature is available in the following editions: SE, SE+, EE.

Доступно в следующих редакциях: SE, SE+, EE, CSE Lite (1.67), CSE Pro (1.67).

1. Enable the metallb module:

1. Включите модуль metallb:

1. Deploy the MetalLoadBalancerClass resource:

1. Создайте ресурс MetalLoadBalancerClass:

yaml apiVersion: network.deckhouse.io/v1alpha1 kind: MetalLoadBalancerClass metadata: name: ingress spec: addressPool:

• 192.168.2.100-192.168.2.150 isDefault: false nodeSelector: node-role.kubernetes.io/loadbalancer: “” # node-balancer selector type: L2

yaml apiVersion: network.deckhouse.io/v1alpha1 kind: MetalLoadBalancerClass metadata: name: ingress spec: addressPool:

• 192.168.2.100-192.168.2.150 isDefault: false nodeSelector: node-role.kubernetes.io/loadbalancer: “” # селектор узлов-балансировщиков type: L2

1. Deploy the IngressNginxController resource:

1. Создайте ресурс IngressNginxController:

yaml apiVersion: deckhouse.io/v1 kind: IngressNginxController metadata: name: main spec: ingressClass: nginx inlet: LoadBalancer loadBalancer: loadBalancerClass: ingress annotations: The number of addresses that will be allocated from the pool described in MetalLoadBalancerClass. network.deckhouse.io/l2-load-balancer-external-ips-count: “3”

yaml apiVersion: deckhouse.io/v1 kind: IngressNginxController metadata: name: main spec: ingressClass: nginx inlet: LoadBalancer loadBalancer: loadBalancerClass: ingress annotations: Количество адресов, которые будут выделены из пула, описанного в MetalLoadBalancerClass. network.deckhouse.io/l2-load-balancer-external-ips-count: “3”

1. The platform will create a service with the type LoadBalancer, to which a specified number of addresses will be assigned:

1. Платформа создаст сервис с типом LoadBalancer, которому будет присвоено заданное количество адресов: