Обзор

Сервис типа LoadBalancer позволяет предоставить доступ к приложению, развернутому в кластере Managed Kubernetes. При создании сервиса автоматически разворачивается сетевой балансировщик нагрузки. Балансировщик получает IP-адрес, принимает входящий трафик и направляет его к узлам кластера, на которых доступны поды приложения.

Информация о созданном балансировщике также доступна в сервисе Network Load Balancer.

В зависимости от типа доступа к приложению балансировщик нагрузки может быть внешним или внутренним:

• внешний — обеспечивает доступ из интернета по внешнему IP-адресу;
• внутренний — обеспечивает доступ из внутренней сети по внутреннему IP-адресу.

Пример описания внешнего балансировщика нагрузки:

1
apiVersion: v1
2
kind: Service
3
metadata:
4
  name: lb-external
5
  labels:
6
    app: my-app
7
  annotations:
8
    mk8s.mws.ru/load-balancer-external-ip-name: <имя внешнего IP-адреса>
9
spec:
10
  selector:
11
    app: my-app
12
  ports:
13
      port: 6379
14
      protocol: TCP
15
  type: LoadBalancer

Пример описания внутреннего балансировщика нагрузки:

1
apiVersion: v1
2
kind: Service
3
metadata:
4
  name: lb-internal
5
  labels:
6
    app: my-app
7
  annotations:
8
    mk8s.mws.ru/load-balancer-internal-ip-name: <имя внутреннего IP-адреса>
9
spec:
10
  selector:
11
    app: my-app
12
  ports:
13
    - port: 6379
14
      protocol: TCP
15
  type: LoadBalancer

Аннотации вида mk8s.mws.ru/load-balancer-* определяют тип балансировщика:

• mk8s.mws.ru/load-balancer-external-ip-name — для внешнего балансировщика. В аннотации указывается имя внешнего IP-адреса, который будет назначен балансировщику.

• mk8s.mws.ru/load-balancer-internal-ip-name — для внутреннего балансировщика. В аннотации указывается имя внутреннего IP-адреса, который будет назначен балансировщику.

Если не указать ни одну из этих аннотаций, будет создан внешний балансировщик со случайным свободным внешним IP-адресом.

Внешний и внутренний балансировщики могут работать одновременно. В этом случае приложение будет доступно как по внутреннему, так и по внешнему IP-адресам. Балансировщики необходимо создавать с помощью двух разных манифестов. Если указать обе аннотации в одном манифесте, создание балансировщика завершится с ошибкой.

Подробнее о том, как опубликовать приложение с помощью балансировщиков нагрузки, читайте в руководстве.

Трафик, который поступает в кластер Managed Kubernetes через сервис типа LoadBalancer, может быть направлен на узел, на котором нет подов целевого приложения. В этом случае трафик пересылается на другой узел, где есть подходящий под, а исходный IP-адрес клиента заменяется на IP-адрес промежуточного узла с помощью SNAT. Это затрудняет контроль доступа по IP-адресам, определение географического расположения клиента и логирование.

Чтобы сохранить исходный IP-адрес клиента, укажите в описании балансировщика параметр externalTrafficPolicy: Local:

1
apiVersion: v1
2
kind: Service
3
metadata:
4
  name: lb-external
5
spec:
6
  externalTrafficPolicy: Local
7
  loadBalancerSourceRanges:
8
    - 0.0.0.0/0
9
  selector:
10
    app: my-app
11
  ports:
12
    - name: tcp
13
      protocol: TCP
14
      port: 80
15
      targetPort: 80
16
  type: LoadBalancer

При использовании externalTrafficPolicy: Local балансировщик проверяет доступность приложения на узле через специальный порт (healthCheckNodePort) и направляет трафик только на те узлы, где есть поды приложения. В результате трафик не пересылается между узлами, и приложение получает исходный IP-адрес клиента.

Подробнее о сохранении исходного IP-адреса клиента читайте в руководстве.

Для публикации приложения через балансировщик нагрузки может потребоваться разрешить входящий трафик на один или несколько портов NodePort с помощью правил файрвола. Сервис Managed Kubernetes помогает автоматизировать создание таких правил. Пользователю нужно лишь указать диапазон разрешенных IP-адресов при развертывании сервиса, а все нужные правила файрвола будут созданы автоматически.

При таком подходе пользователю не нужно вручную отслеживать изменения IP-адресов узлов, портов или состав группы узлов. Control plane (управляющий слой) кластера Managed Kubernetes автоматически отслеживает состояние балансировщика и самого кластера. При изменении компонентов балансировщика или кластера соответствующие правила файрвола обновятся автоматически.

Для управления доступом к сервисам балансировщика используются следующие поля в описании сервиса:

• spec.loadBalancerSourceRanges — IP-адрес или диапазон IP-адресов в нотации CIDR, с которых нужно разрешить доступ;
• spec.ports — целевые порты балансировщика.

На основании этих настроек система автоматически сформирует набор правил файрвола.

Пример описания правила:

1
apiVersion: v1
2
kind: Service
3
metadata:
4
  name: lb-external
5
  namespace: default
6
spec:
7
  type: LoadBalancer
8
  loadBalancerSourceRanges:
9
    - 10.0.0.0/8
10
    - 178.248.238.27/32
11
  ports:
12
    - name: http
13
      protocol: TCP
14
      port: 80
15
      targetPort: 8080
16
...

При создании правил существуют ограничения:

• Количество элементов в spec.loadBalancerSourceRanges — 10 шт.
• Число портов в spec.ports — 10 шт.
• Количество рабочих узлов, для которых будет создано уникальное правило файрвола, — 10 шт. Например, если в вашем кластере 12 рабочих узлов, то будет создано два отдельных правила — для первых десяти узлов и для оставшихся двух.

Правила файрвола создаются для каждого IP-адреса узла кластера с использованием маски /32. Это ограничивает область применения правила только теми узлами, которые участвуют в обслуживании сервисов балансировщика.

Если в спецификации сервиса не указать настройку spec.loadBalancerSourceRanges или spec.ports, правила файрвола созданы не будут, и внешний доступ к балансировщику будет закрыт. При необходимости правила можно создать вручную, однако такие правила не будут актуализироваться автоматически при обновлении кластера или сервиса.

Подробнее об управлении правилами файрвола при развертывании балансировщиков нагрузки читайте в руководстве.

Проверки работоспособности позволяют оценить доступность узлов кластера. Если проверочный запрос к узлу не сработает (например, если узел не готов принимать трафик), этот узел будет исключен из балансировки. Если проверочный запрос не сработает на всех узлах, приложение не будет доступно через балансировщик, даже если само приложение работает.

Для работы проверок работоспособности требуется правило файрвола, которое позволяет балансировщику нагрузки проверять здоровье узлов кластера, отправляя периодические HTTP-запросы на специальный порт сервиса kube-proxy.

Правило создается автоматически при создании любого балансировщика нагрузки и автоматически обновляется при изменении параметров балансировщика, группы узлов или кластера. При удалении последнего балансировщика правило удалится автоматически.

Параметры правила приведены в таблице:

Если в описании балансировщика есть параметр externalTrafficPolicy: Local, в качестве целевого порта будет выступать порт, указанный в поле healthCheckNodePort.

Не изменяйте правило вручную: при первом обновлении конфигурации сервиса, кластера или группы узлов оно будет перезаписано. Чтобы переопределить настройки доступа вы можете вручную создать отдельное правило с более высоким приоритетом.