Пример для 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-контроллером, при перезапуске Pod’а, 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 Load Balancer)

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 Pod’ы должны быть запущены на тех–же узлах, что и Pod’ы 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 только с тех узлов, где запущены целевые Pod’ы.

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: