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

An example for AWS (Network Load Balancer)

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

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

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

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.

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

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.

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”

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

An example for 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”

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

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

Пример для OpenStack

An example for OpenStack

Пример для bare metal

An example for Bare metal

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

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

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

An example for Bare metal (MetalLB Load Balancer)

Модуль metallb на текущий момент доступен только в редакции Enterprise Edition Deckhouse.

The metallb module is currently available only in the Enterprise Edition version.

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

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

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

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.

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

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

Пример для bare metal (L2 Load Balancer)

An example for Bare metal (L2 Load Balancer)

Доступно только в редакции Enterprise Edition.

Available in Enterprise Edition only.

yaml apiVersion: deckhouse.io/v1 kind: IngressNginxController metadata: name: main spec: nodeSelector: node.deckhouse.io/frontend: “” ingressClass: “nginx” inlet: “L2LoadBalancer” l2LoadBalancer: addressPool: mypool

yaml apiVersion: deckhouse.io/v1 kind: IngressNginxController metadata: name: main spec: nodeSelector: node.deckhouse.io/group: worker ingressClass: “nginx” inlet: “L2LoadBalancer” l2LoadBalancer: addressPool: mypool sourceRanges:

• 10.0.0.0/8

конфигурация L2 Load Balancer:

L2 Load Balancer’s speaker Pods must be run on the same Nodes as the Ingress controller Pods.

yaml apiVersion: deckhouse.io/v1alpha1 kind: ModuleConfig metadata: name: l2-load-balancer spec: enabled: true settings: addressPools:

• addresses:
• 192.168.122.100-192.168.122.130 name: mypool version: 1

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.

So for the current example L2 Load Balancer should be like this:

yaml apiVersion: deckhouse.io/v1alpha1 kind: ModuleConfig metadata: name: l2-load-balancer spec: enabled: true settings: addressPools:

• addresses:
• 192.168.122.100-192.168.122.130 name: mypool version: 1