Cloud provider — Yandex Cloud: примеры

Ниже представлен пример конфигурации cloud-провайдера Yandex Cloud.

Пример конфигурации модуля

apiVersion: deckhouse.io/v1alpha1
kind: ModuleConfig
metadata:
  name: cloud-provider-yandex
spec:
  version: 1
  enabled: true
  settings:
    additionalExternalNetworkIDs:
    - enp6t4snovl2ko4p15em

Использование зоны ru-central1-f

Чтобы размещать узлы в зоне ru-central1-f, явно укажите её в параметре zones вместо одной из зон по умолчанию. В zones можно указать не более четырёх зон.

1. Выберите одну из зон по умолчанию, которую заменит ru-central1-f.

2. Укажите ru-central1-f и остальные выбранные зоны в параметре zones ресурса YandexClusterConfiguration. Пример:

   apiVersion: deckhouse.io/v1
   kind: YandexClusterConfiguration
   layout: Standard
   nodeNetworkCIDR: 10.241.32.0/20
   sshPublicKey: ssh-rsa AAAAB3Nza...
   zones:
     - ru-central1-a
     - ru-central1-b
     - ru-central1-d
     - ru-central1-f
   

   В примере исключена зона ru-central1-e.

   Deckhouse Platform создаёт подсеть в ru-central1-f, используя часть nodeNetworkCIDR, закреплённую за исключённой зоной. В работающем кластере с зонами по умолчанию замена ru-central1-e на ru-central1-f удаляет подсеть в ru-central1-e и создаёт новую в ru-central1-f. Подсети остальных выбранных зон сохраняются.

Использование существующих подсетей

Если задан параметр existingZoneToSubnetIDMap, Deckhouse Platform использует указанные в параметре подсети, не создавая и не удаляя их. Ограничение в четыре зоны на existingZoneToSubnetIDMap не распространяется. Если zones не задан, узлы размещаются во всех зонах existingZoneToSubnetIDMap, включая зоны вне набора по умолчанию.

Изменение зон в работающем кластере

Чтобы добавить ru-central1-f, обновите параметр zones.

При изменении списка зон возможен конфликт диапазонов. Он возникает, если подсеть добавляемой зоны по умолчанию должна использовать диапазон подсети ru-central1-f. Deckhouse Platform отклоняет такое изменение с ошибкой. Чтобы устранить конфликт, примените изменения в два этапа:

1. Удалите ru-central1-f из zones и примените изменения. Deckhouse Platform удалит подсеть в ru-central1-f.
2. Укажите итоговый список зон с ru-central1-f и повторно примените изменения.

Например, такой конфликт возможен при замене ru-central1-d на ru-central1-e с сохранением ru-central1-f в списке.

Если конфликта нет, список зон можно изменить напрямую. Подсеть ru-central1-f сохраняет свой диапазон адресов.

Если в схеме WithNATInstance подсети NAT-инстанса не заданы явно, его размещение определяется по списку zones:

Пример custom resource YandexInstanceClass

apiVersion: deckhouse.io/v1
kind: YandexInstanceClass
metadata:
  name: test
spec:
  cores: 4
  memory: 8192

LoadBalancer

Аннотации объекта Service

В кластере заданы значения по умолчанию для размещения ресурсов балансировщиков (сеть для целевой группы и подсеть для Listener). Эти значения выставляются автоматически во время развёртывания кластера и могут быть переопределены аннотациями на уровне конкретного Service.

Поведение по умолчанию (внешний или внутренний LB) зависит от конфигурации кластера. Для явного выбора типа используйте аннотацию yandex.cpi.flant.com/loadbalancer-external.

В Yandex Cloud Controller Manager поддерживаются следующие аннотации:

1. yandex.cpi.flant.com/target-group-network-id — указывает NetworkID, в котором будет создана целевая группа для данного Service. Переопределяет соответствующее значение по умолчанию.
2. yandex.cpi.flant.com/listener-subnet-id — задаёт SubnetID для Listener’ов создаваемого LB для данного Service. Переопределяет соответствующее значение по умолчанию.
3. yandex.cpi.flant.com/listener-address-ipv4 — задаёт предопределённый IPv4-адрес для Listener’ов (поддерживаются и внутренние, и внешние LB).
4. yandex.cpi.flant.com/loadbalancer-external — включает создание внешнего (external) LB для данного Service (используйте, если нужно явно создать внешний балансировщик). Переопределяет поведение по умолчанию.
5. yandex.cpi.flant.com/target-group-name-prefix — задаёт префикс имени целевой группы, которую использует LoadBalancer. Аннотация на Service определяет целевую группу, но не выбирает узлы. Чтобы включить узлы в целевую группу, задайте аннотацию с тем же значением в параметре spec.nodeTemplate.annotations ресурса NodeGroup. Yandex Cloud Controller Manager включает в целевую группу все подходящие узлы с таким значением аннотации независимо от их NodeGroup. Имя целевой группы формируется как <ANNOTATION_VALUE><YANDEX_CLOUD_CLUSTER_NAME><NETWORK_ID>. Подробнее — в разделе «Использование отдельной целевой группы для NodeGroup».

Если для control plane или master-узлов создаются отдельные целевые группы, добавьте на master-узлы лейбл node.kubernetes.io/exclude-from-external-load-balancers: "". Это предотвратит попытки контроллера автоматически добавлять master-узлы в новые целевые группы для балансировщиков.

Если вы создаёте собственный балансировщик для master-узлов и хотите, чтобы YCC также мог размещать свои балансировщики на master-узлах, заранее создайте целевую группу с именем по маске ${CLUSTER-NAME}${VPC.ID}.

Проверки состояния целевой группы

Параметры healthcheck’ов (для создаваемых целевых групп балансировщика):

1. yandex.cpi.flant.com/healthcheck-interval-seconds — как часто запускать проверку, в секундах (по умолчанию 2).
2. yandex.cpi.flant.com/healthcheck-timeout-seconds — сколько ждать ответа от эндпоинта, в секундах. Если за это время ответ не получен, проверка считается неуспешной (по умолчанию 1).
3. yandex.cpi.flant.com/healthcheck-unhealthy-threshold — сколько подряд неуспешных проверок нужно, чтобы пометить эндпоинт как неработоспособный (unhealthy) и исключить его из балансировки (по умолчанию 2).
4. yandex.cpi.flant.com/healthcheck-healthy-threshold — сколько подряд успешных проверок нужно, чтобы вернуть эндпоинт в статус работоспособный (healthy) и снова включить его в балансировку (по умолчанию 2).