#Инфраструктурные ресурсы для Huawei DCS

#Обзор

Перед созданием кластеров в Huawei DCS необходимо настроить инфраструктурные ресурсы, включая учетные данные облака, IP-пулы и шаблоны машин.

Управлять инфраструктурными ресурсами можно либо через web UI, либо с помощью YAML-манифестов. Web UI предоставляет пошаговый интерфейс с валидацией, а YAML — возможности автоматизации.

В Huawei DCS IP-пул также содержит все диски, которые должны сохраняться при замене VM. Сюда входит обязательный для платформы диск /var/cpaas.

#Учетные данные облака

Учетные данные облака хранят информацию о доступе к платформе DCS, необходимую для операций с кластером.

#Использование Web UI

#Предварительные требования

Перед созданием учетных данных облака проверьте следующие требования платформы DCS:

Конфигурация пользователя:

• Тип пользователя: один из следующих:
  • Interface interconnection user — значение по умолчанию; существующее поведение. Используйте его, если в портале DCS уже создан учетный записи в стиле interconnect.
  • Domain user — пользователь, управляемый через LDAP/AD и directory service. Требует, чтобы в DCS была настроена доменная аутентификация вашим администратором DCS, а пользователь из directory service был заранее создан в портале DCS с приведенным ниже сопоставлением ролей.
• Роль: должна быть administrator

Политика паролей (применяется только к Interface interconnection user):

Перейдите в System Management → Rights Management → Rights Management Policy и проверьте:

• Политика: Whether to modify the password of an interface interconnection user upon password resetting and first login
• Значение: должно быть установлено в No

Если установлено значение Yes, при первом входе пароль пользователя будет принудительно изменен, что приведет к сбою аутентификации и ошибкам при создании кластера.

Для Domain user жизненным циклом пароля управляет ваша LDAP/AD directory service, а не политика портала DCS.

#Создание учетных данных облака

Путь в интерфейсе: Clusters → Cloud Credentials → Create Cloud Credential → Select Huawei DCS

Поля формы:

Правила валидации:

• Name должен содержать 1–63 символа, включать только строчные буквы, цифры и дефисы, а также начинаться и заканчиваться буквой или цифрой
• DCS Endpoint должен быть допустимым URL, начинающимся с http:// или https://

#Управление учетными данными облака

Просмотр учетных данных: перейдите в Clusters → Cloud Credentials, чтобы просмотреть все настроенные учетные данные с указанием типа, времени создания и автора.

Обновление учетных данных: нажмите Update у нужных учетных данных, чтобы изменить Display Name. Обновление пароля в текущей версии не поддерживается (планируется в одном из будущих релизов).

Удаление учетных данных: нажмите Delete, чтобы удалить учетные данные. Подтвердите удаление в диалоговом окне.

#Использование YAML

Создайте ресурс Secret для хранения информации аутентификации DCS:

apiVersion: v1
data:
  authUser: <base64-encoded-auth-user>
  authKey: <base64-encoded-auth-key>
  endpoint: <base64-encoded-endpoint>
  userType: <base64-encoded-user-type>   # optional; "interconnect" (default) or "domain"
kind: Secret
metadata:
  name: <auth-secret-name>
  namespace: cpaas-system
type: Opaque

apiVersion: v1
stringData:
  authUser: <plain-text-auth-user>
  authKey: <plain-text-auth-key>
  endpoint: <plain-text-endpoint>
  userType: <plain-text-user-type>   # optional; "interconnect" (default) or "domain"
kind: Secret
metadata:
  name: <auth-secret-name>
  namespace: cpaas-system
type: Opaque

Описание параметров:

Пример:

# Encode credentials
echo -n "admin" | base64
echo -n "your-password" | base64
echo -n "https://dcs.example.com:7443" | base64
echo -n "domain" | base64   # only when using a domain user; omit for interconnect (default)

# Apply the Secret
kubectl apply -f dcs-secret.yaml -n cpaas-system

#Типы пользователей учетных данных

DCS Provider поддерживает два типа пользователей учетных данных, которые выбираются с помощью необязательного ключа Secret userType:

Совместимость: существующие Secrets без ключа userType продолжают аутентифицироваться как и раньше; для использования учетных данных в стиле interconnect миграция не требуется.

Покрытие UI: текущая форма web UI не отображает поле userType. Чтобы использовать значение domain, настройте Secret через YAML.

#IP-пулы

IP-пулы определяют сетевую конфигурацию (IP-адреса, маски подсети, шлюзы, DNS) для узлов кластера. Каждый пул может содержать несколько записей узлов, а каждый узел — несколько конфигураций сетевых интерфейсов.

Для кластеров DCS с несколькими NIC каждая запись IP может содержать элементы additionNic. Эти дополнительные NIC привязываются к слоту IP и применяются при создании новой VM провайдером. Обновление additionNic в существующем Pool не приводит к горячему добавлению NIC уже работающим VM.

Для постоянных дисков DCS каждая запись IP также может содержать элементы persistentDisk. Эти диски привязаны к слоту IP, а не к жизненному циклу VM, поэтому их можно отсоединить от старой VM и присоединить к VM-замене во время rolling upgrade. Используйте этот механизм для обязательного платформой диска /var/cpaas и для любых других локальных данных узла, которые должны переживать операции удаления и повторного создания. Начиная с DCS provider v1.0.16, такое объявление persistentDisk поддерживается только через YAML.

#Использование Web UI

#Предварительные требования

• Учетные данные облака должны быть созданы

#Создание IP-пула

Путь в интерфейсе: Clusters → Virtual Machine → IP Pools → Create IP Pool → Select Credential

Структура формы:

Форма IP Pool состоит из списка Pools. Каждый Pool представляет один узел и содержит:

1. Node IP (обязательно, ровно один на Pool)
2. Additional NIC IPs (необязательно, несколько на Pool)

Поля Node IP:

Поля Additional NIC IPs:

Правила валидации:

• IP-адреса должны быть уникальны в пределах одного IP Pool
• IP-адреса должны иметь корректный формат IPv4
• Маска подсети должна быть указана как допустимая длина CIDR-префикса, например 24. Не используйте / и не задавайте dotted-decimal формат, например 255.255.255.0.
• IP-адрес должен находиться в пределах настроенного диапазона подсети
• Gateway должен быть корректным IPv4-адресом в пределах диапазона подсети

Советы:

• Требуется как минимум одна запись узла
• Для каждого узла требуется ровно одна конфигурация Node IP
• Записи additionNic[] необязательны для сценариев с несколькими NIC, например при разделении сети хранения

#Управление IP-пулами

Просмотр пулов: перейдите в Clusters → Virtual Machine → IP Pools, чтобы просмотреть все настроенные пулы с их IP узлов и временем создания.

Обновление пулов: нажмите Update, чтобы добавить или удалить записи узлов и изменить сетевые конфигурации.

Удаление пулов: нажмите Delete, чтобы удалить пул. Подтвердите удаление в диалоговом окне.

#Использование YAML

Создайте ресурс DCSIpHostnamePool:

apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: DCSIpHostnamePool
metadata:
  name: <iphostname-pool-name>
  namespace: cpaas-system
spec:
  pool:
  - ip: "<ip-1>"
    mask: "<cidr-prefix-length>"
    gateway: "<gateway>"
    dns: "<dns>"
    hostname: "<hostname-1>"
    machineName: "<machine-name-1>"
    additionNic:
    - ip: "<additional-ip-1>"
      mask: "<additional-cidr-prefix-length>"
      gateway: "<additional-gateway>"
      dns: "<additional-dns>"
      dvSwitchName: "<additional-dvs>"
      portGroupName: "<additional-port-group>"
  - ip: "<ip-2>"
    mask: "<cidr-prefix-length>"
    gateway: "<gateway>"
    dns: "<dns>"
    hostname: "<hostname-2>"
    machineName: "<machine-name-2>"
  - ip: "<ip-3>"
    mask: "<cidr-prefix-length>"
    gateway: "<gateway>"
    dns: "<dns>"
    hostname: "<hostname-3>"
    machineName: "<machine-name-3>"

Описание параметров:

*Поля, помеченные как Yes*, требуются провайдеру для определения целевой сети и подключения дополнительного NIC. Поля, помеченные как Recommended*, нужны для сгенерированной статической гостевой сетевой конфигурации. CRD не накладывает обязательность на эти поля.

#Дополнительные NIC в IP-пуле

Объявляйте дополнительные NIC в DCSIpHostnamePool.spec.pool[].additionNic[].

Используйте это поле, когда узлу требуется дополнительная сеть, например сеть хранения, управления или изоляции приложений. Оставляйте основной .spec.pool[].ip как IP узла Kubernetes, если вы намеренно не планируете смену IP узла.

Как это применяется:

• Провайдер копирует additionNic[] из слота Pool в DCSMachine.status.additionalNic, когда новый DCSMachine занимает этот слот.
• Провайдер добавляет эти NIC при клонировании DCS VM.
• Гостевая ОС настраивает интерфейсы при первом запуске с помощью сгенерированной конфигурации NetworkManager.
• Существующие VM не обновляются на лету при последующем изменении Pool.

Границы сети:

• DCS Provider не резервирует IP-адреса дополнительных NIC на платформе DCS. Избегайте конфликтов IP до применения Pool.
• Ссылочные DVS и Port Group должны уже существовать, и целевые хосты DCS должны иметь к ним доступ.
• Для каждого дополнительного NIC указывайте и dvSwitchName, и portGroupName. Провайдер использует их для определения URN Port Group перед клонированием VM.
• Провайдер моделирует только IP, mask, gateway, DNS, DVS и Port Group. Метрики маршрутов, статические маршруты и роли NIC должны настраиваться через MCP или конфигурацию гостевой ОС.
• Если у дополнительного NIC задан gateway, убедитесь, что он неожиданно не перехватывает маршрут по умолчанию у основного NIC.

#Постоянные диски в IP-пуле

Объявляйте диски, сохраняемые при обновлении, в DCSIpHostnamePool.spec.pool[].persistentDisk, а не в DCSMachineTemplate.

Начиная с DCS provider v1.0.16, YAML — единственный поддерживаемый способ объявлять такие постоянные диски.

• Используйте запись IP, чтобы привязать каждый постоянный диск к фиксированной идентичности (ip, slot).
• Используйте эту модель для обязательного платформой диска /var/cpaas.
• Оставляйте DCSMachineTemplate сосредоточенным на системном диске и любых локальных для шаблона дисках, которые могут быть пересозданы вместе с VM.
• Когда загружается VM-замена, скрипт настройки дисков в гостевой системе проверяет наличие существующей файловой системы. Если она уже есть, форматирование пропускается, и диск монтируется напрямую.
• Постоянные диски, управляемые пулом, требуют замены по одному. Если вы полагаетесь на эту функцию, установите KubeadmControlPlane.spec.rolloutStrategy.rollingUpdate.maxSurge = 0 и MachineDeployment.spec.strategy.rollingUpdate.maxSurge = 0.

Если вы планируете использовать постоянные диски, убедитесь, что шаблон DCS VM имеет версию 4.2.1 или новее, поскольку безопасное завершение работы и отсоединение диска зависят от guest tools внутри гостевой ОС.

Пример:

apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: DCSIpHostnamePool
metadata:
  name: <iphostname-pool-name>
  namespace: cpaas-system
spec:
  pool:
  - ip: "<ip-1>"
    mask: "<cidr-prefix-length>"
    gateway: "<gateway>"
    dns: "<dns>"
    hostname: "<hostname-1>"
    machineName: "<machine-name-1>"
    persistentDisk:
    - slot: 0
      quantityGB: 40
      datastoreClusterName: <datastore-cluster-name>
      path: /var/cpaas
      format: xfs
      mountOptions:
      - defaults

Описание полей постоянного диска:

Правила обновления:

• Вы можете добавлять новые записи persistentDisk в существующий слот IP. Controller подключает вновь добавленный диск к работающей VM на стороне DCS, но не форматирует и не монтирует диск внутри гостевой ОС. Форматирование и монтирование в гостевой системе вступают в силу только после замены VM и выполнения сгенерированной настройки диска при bootstrap.
• Controller создает новые постоянные тома как независимые persistent normal volumes. При повторном использовании существующего тома требуется только, чтобы том был независимым и постоянным; конкретный тип тома DCS не требуется.
• Не удаляйте существующие записи persistentDisk из spec. Webhook отклоняет удаление.
• Считайте format, options и pciType неизменяемыми после создания.
• Считайте изменения quantityGB и datastore как изменения, чувствительные к rollout. Когда пул имеет cluster label, webhook выполняет лучшую по усилиям проверку на стороне платформы. isThin действует только при создании: его изменение не приводит к валидации, reconciliation или конвертации существующих томов и влияет только на постоянные тома, созданные позже.
• Считайте изменения path и mountOptions изменениями на стороне гостевой системы, которые применяются на машинах-заменах во время rolling update.

#Емкость и размещение платформы DCS

Перед созданием ресурсов DCSMachineTemplate проверьте, что целевые site DCS, datastore и compute cluster имеют достаточно свободной емкости для размещения запланированных VM, а также что политика планирования на стороне DCS может разместить новые VM на доступных хостах. Пропуск этих проверок — самая частая причина VM, которые как будто зависают в состоянии creating без ошибки, возвращаемой API DCS.

#Запуск диагностических фрагментов

Проверки емкости и размещения ниже используют только операции чтения DCS REST. Перед запуском любого фрагмента задайте следующие переменные окружения в shell:

Задайте три переменные один раз в начале диагностической сессии:

# Replace the placeholders with values appropriate for your environment.
export DCS_BASE='https://<dcs-api-host>:7443'
export SITE='<site-id>'

# Read the user and key from the cloud-credential Secret without printing them.
DCS_USER="$(kubectl -n cpaas-system get secret <credential-secret-name> -o jsonpath='{.data.authUser}' | base64 -d)"
DCS_KEY="$(kubectl -n cpaas-system get secret <credential-secret-name> -o jsonpath='{.data.authKey}' | base64 -d)"

# Acquire a session token. The response header X-AUTH-TOKEN carries the value used by subsequent calls.
HEADERS="$(mktemp)"
curl -k -sS -D "$HEADERS" -o /dev/null -X POST "${DCS_BASE}/service/session" \
  -H "X-Auth-User: $DCS_USER" \
  -H "X-Auth-Key: $DCS_KEY" \
  -H 'X-ENCRYPT-ALGORITHM: 1' \
  -H 'X-Auth-UserType: 2' \
  -H 'version: 8.1'
export TOKEN="$(grep -i '^X-AUTH-TOKEN:' "$HEADERS" | tail -n1 | cut -d' ' -f2- | tr -d '\r\n ')"
rm -f "$HEADERS"
unset DCS_USER DCS_KEY

Повторно используйте $DCS_BASE, $SITE и $TOKEN во всех последующих диагностических фрагментах на этой странице. Обновляйте токен, повторно выполняя команду POST /service/session, когда API начинает возвращать errorCode: 10000002 (session expired or not logged in).

#Выбор datastore

Каждая запись DCSMachineDiskSpec привязывает диск к datastore DCS через одно из двух взаимоисключающих полей:

• datastoreName — закрепляет диск за конкретным datastore. Планировщик DCS не учитывает соседние datastores, даже если у них есть свободное место. Это самое жесткое привязывание.
• datastoreClusterName — закрепляет диск за datastore cluster (группой datastores на стороне DCS). Планировщик DCS выбирает из кластера конкретный datastore, удовлетворяющий требованиям по емкости. Это более безопасное значение по умолчанию, когда платформа предоставляет datastore cluster.

Предпочитайте datastoreClusterName, когда администратор DCS настроил datastore cluster, чтобы один почти заполненный datastore не блокировал развертывание, пока соседние datastores еще имеют свободное место.

Предварительная проверка емкости:

Перед применением нового DCSMachineTemplate перечислите существующие datastores DCS и убедитесь, что целевой имеет достаточно свободной емкости для худшего случая system disk + ∑(размер spec disk) × количество реплик. Из среды с доступом к API DCS список только для чтения выглядит так:

curl -k -sS "${DCS_BASE}/service/sites/${SITE}/datastores" \
  -H "X-Auth-Token: ${TOKEN}" -H 'version: 8.1' \
  | python3 -c "
import json,sys
for ds in json.load(sys.stdin).get('datastores',[]) or []:
  print(f\"{ds.get('name','?'):24} cap={ds.get('capacityGB','?')}GB used={ds.get('usedSizeGB','?')}GB free={ds.get('freeSizeGB','?')}GB state={ds.get('status','?')}\")"

Пара cp / worker в каждом DCSMachineTemplate обычно требует системный диск (значение по умолчанию шаблона, часто ~80 GB) плюс явные data disks, указанные в spec, поэтому один control-plane node с etcd 10G + kubelet 100G + containerd 100G + /var/cpaas 100G потребляет примерно 390 GB еще до учета системного диска шаблона. Datastore, занятый более чем примерно на 70 %, — явный сигнал выбрать другой datastore: даже если абсолютный свободный объем кажется достаточным, фрагментация и резервы могут привести к зависанию размещения новой VM.

#Размещение хостов и высокая доступность

Размещение хостов на платформе DCS выполняет DCS scheduler. DCS Provider не предоставляет способ закрепить виртуальную машину за конкретным DCS Host через DCSMachineTemplate. Поэтому виртуальные машины, созданные из одного шаблона, могут оказаться на одном и том же физическом хосте.

Из этого следуют два последствия:

• Локальные перегрузки емкости: если нагрузка хостов в DCS cluster распределена неравномерно (например, один хост сильно перегружен по CPU, а другой почти без нагрузки), DCS scheduler может отклонить новые размещения на перегруженном хосте. Задача развертывания может зависнуть, пока нагрузка не будет перераспределена на стороне DCS или не будет включен DRS. Используйте фрагмент ниже, чтобы проверить, является ли причиной именно нагрузка хоста.
• Разнесение control plane зависит от DRS: виртуальные машины control plane не привязываются через machine template к конкретным хостам. Для высокодоступных развертываний включите provider-managed правило DRS mutual exclusion, как описано ниже в разделе Cross-Host High Availability for Control Plane.

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

curl -k -sS "${DCS_BASE}/service/sites/${SITE}/hosts" \
  -H "X-Auth-Token: ${TOKEN}" -H 'version: 8.1' \
  | python3 -c "
import json,sys
for h in json.load(sys.stdin).get('hosts',[]) or []:
  print(f\"{h.get('name','?'):10} status={h.get('status','?'):10} cpuUsed/total={h.get('cpuUsedCores','?')}/{h.get('cpuTotalCores','?')}c memUsed={h.get('memUsedSizeMB','?')}MB cpuMuxRatio={h.get('cpuMuxRatio','?')}\")"

Значение cpuMuxRatio (allocation CPU / physical cores) выше примерно 3× на каждом хосте кластера указывает на то, что cluster уже насыщен и, вероятно, будет отклонять новые размещения, пока нагрузка не будет перераспределена на стороне DCS.

#Межхостовая высокая доступность для Control Plane

DCS Provider не реализует закрепление хостов и распределение Cluster API FailureDomain. Вместо этого он может поддерживать управляемое провайдером правило DCS DRS для виртуальных машин control plane, если включен DCSCluster.spec.controlPlaneHA.

Провайдер создает и обновляет правило DRS ruleType=2 mutual-exclusion после появления VM control plane и определения их VM URN. В правиле перечисляются текущие VM control plane для одного workload cluster, и DCS scheduler получает указание размещать их на разных физических хостах. DCS по-прежнему отвечает за выполнение решения о размещении и любую миграцию во время работы.

Провайдер не вызывает DCS Run DRS API и не применяет рекомендации DRS. Если ControlPlaneHAReady остается False с причиной ControlPlaneHAPending после того, как правило уже было поддержано, значит DCS scheduler еще не сошелся по размещению. Подождите, пока выполнится планирование на стороне DCS, или используйте процесс операций платформы DCS, чтобы запустить DRS и применить сгенерированные рекомендации.

Перед включением этой функции проверьте следующие требования на стороне DCS:

• Для целевого compute cluster DCS включен DRS.
• У целевого compute cluster DCS достаточно исправных хостов и емкости. Для control plane с тремя репликами обычно требуется как минимум три пригодных хоста.
• Выбранные datastores видимы со всех хостов, на которых могут работать VM control plane.
• Runtime DRS migration не блокируется ограничениями со стороны DCS, например подключенным устройством CD-ROM.

Включите функцию в DCSCluster.spec.controlPlaneHA, когда пишете манифест кластера. Пример манифеста и отслеживаемые поля статуса см. в Configure DCSCluster и Verify Control Plane HA.

После создания кластера проверьте condition и status в DCSCluster:

kubectl get dcscluster <cluster-name> -n cpaas-system \
  -o jsonpath='{range .status.conditions[?(@.type=="ControlPlaneHAReady")]}{.status}{" "}{.reason}{" "}{.message}{"\n"}{end}'

kubectl get dcscluster <cluster-name> -n cpaas-system \
  -o jsonpath='{.status.controlPlaneHA}{"\n"}'

ControlPlaneHAReady=True означает, что управляемое провайдером правило DRS существует и провайдер наблюдает текущие VM control plane на разных хостах DCS. ControlPlaneHAReady=False с причиной ControlPlaneHAPending обычно означает, что controller ждет URN VM, ждет достаточного числа участников или ждет, пока размещение на стороне DCS придет к устойчивому состоянию. ControlPlaneHAReady=False с причиной ControlPlaneHAFailed означает, что провайдер не смог запросить, проверить, создать, обновить, удалить или проверить правило DRS. Прочитайте message condition перед просмотром логов controller.

#Устранение неполадок: VM зависает в creating

Если DCSMachine остается в состоянии Provisioning, при этом у него задан status.cdRomFile (то есть аутентификация в API DCS и загрузка ISO прошли успешно), но VM на стороне DCS так и не выходит из status=creating и не получает hostName, ошибка почти всегда находится на уровне размещения DCS, а не в controller.

Диагностика по шагам:

1. Убедитесь, что это зависание на этапе размещения, а не медленная загрузка. Запросите VM и соответствующую deploy task в DCS:

   curl -k -sS "${DCS_BASE}/service/sites/${SITE}/vms?name=${VM_NAME}&limit=10" \
     -H "X-Auth-Token: ${TOKEN}" -H 'version: 8.1'
   curl -k -sS "${DCS_BASE}/service/sites/${SITE}/tasks?status=running&limit=50" \
     -H "X-Auth-Token: ${TOKEN}" -H 'version: 8.1'

   Признаки зависания на этапе размещения: status=creating, hostName= (пусто / не назначен), массив disks пустой или не меняется, а deploy task находится на одном и том же значении progress без ошибок более чем ~5 минут.

2. Проверьте свободное место в datastore и нагрузку хостов с помощью фрагментов из разделов Choosing a datastore и Host placement requirements. Наиболее частые причины — datastore, занятый более чем на 70 %, или все хосты с высоким cpuMuxRatio.

3. Перераспределите нагрузку на стороне DCS. Если один хост перегружен, а на других есть свободная емкость, попросите команду платформы DCS перераспределить нагрузку (ручной Migrate или перебалансировка через DRS) перед повторной попыткой. DCS Provider не предоставляет закрепление хоста на уровне шаблона, поэтому это исправление находится в зоне ответственности команды платформы DCS.

4. Если deploy task на стороне DCS действительно завис в состоянии deadlock (его можно отменить, но он не реагирует на ACP-driven DeleteVm), эскалируйте проблему администратору DCS с учетными данными portal-admin, чтобы он отменил задачу. REST API 7443 не предоставляет endpoint отмены задачи для неадминистраторских пользователей, поэтому путь восстановления также относится к зоне ответственности команды платформы DCS, а не ACP.

5. Учитывайте побочные эффекты сериализации. В средах с общей блокировкой DeployVM одна зависшая задача может привести к тому, что все новые развертывания будут останавливаться на одном и том же проценте выполнения. Обычно устранение исходной зависшей задачи разблокирует очередь.

DCSMachine, у которого conditions статуса показывают InfrastructureReady=False reason=WaitingForInfrastructure более 10 минут вместе с описанными выше симптомами, следует рассматривать как инцидент на платформе DCS, а не как регрессию Cluster API или DCS Provider.

#Шаблоны машин

Шаблоны машин определяют спецификацию виртуальной машины (VM template, CPU, память, диск, сеть) для узлов кластера. Каждый шаблон машины имеет Type, который определяет его назначение:

• Control Plane: для узлов control plane
• Worker Node: для рабочих узлов

#Использование Web UI

#Предварительные требования

• IP Pool должен быть создан
• VM Template должен быть создан на платформе DCS с использованием образа Alauda OS
• ConfigMap YAML должен быть применен к глобальному кластеру

VM Template и ConfigMap:

Каждый релиз Alauda OS включает YAML ConfigMap, который сопоставляет VM templates с версиями Kubernetes. Примените этот YAML перед созданием шаблонов машин:

apiVersion: v1
data:
  corednsTag: 1.12.4-v4.2.3
  etcdTag: v3.5.21-251117
  kubernetesVersion: v1.33.6
  vmImageVersion: alaudaos-42.m55.202512081125-0.x86_64
kind: ConfigMap
metadata:
  labels:
    cpaas.io/dcs-vm-template: <vm-template-name>
    cpaas.io/distribution-version: v4.2.0
    cpaas.io/kubernetes-version: v1.33
  name: 420-dcs-vm-template
  namespace: cpaas-system

Важно: значение метки cpaas.io/dcs-vm-template должно совпадать с именем VM template на платформе DCS.

#Создание шаблона машины

Путь в интерфейсе: Clusters → Virtual Machine → Machine Templates → Create Machine Template → Select Credential

Поля формы:

Конфигурация диска:

Конфигурация диска зависит от типа шаблона.

Обязательные диски для Control Plane:

Обязательные диски для Worker Node:

Вы можете добавлять дополнительные диски, но должны сохранить все обязательные диски, перечисленные выше.

Описание полей диска:

Совет по выбору VM Template:

#Управление шаблонами машин

Просмотр шаблонов: перейдите в Clusters → Virtual Machine → Machine Templates, чтобы просмотреть все шаблоны с их VM Template Name, Location, Specs и IP Pool.

Обновление шаблонов: нажмите Update, чтобы изменить спецификации. Обратите внимание, что поле Name нельзя изменить после создания.

Удаление шаблонов: нажмите Delete, чтобы удалить шаблон. Подтвердите удаление в диалоговом окне.

#Использование YAML

Создайте ресурс DCSMachineTemplate:

apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: DCSMachineTemplate
metadata:
  name: <machine-template-name>
  namespace: cpaas-system
spec:
  template:
    spec:
      vmTemplateName: <vm-template-name>
      location:
        type: folder
        name: <folder-name>
      vmConfig:
        dvSwitchName: <dv-switch-name> # Optional
        portGroupName: <port-group-name> # Optional
        dcsMachineCpuSpec:
          quantity: <cpu-cores>
        dcsMachineMemorySpec: # MB
          quantity: <memory-mb>
        dcsMachineDiskSpec: # GB
        - quantity: 0
          datastoreClusterName: <datastore-cluster-name>
          systemVolume: true
        - quantity: 100
          datastoreClusterName: <datastore-cluster-name>
          path: /var/lib/kubelet
          format: xfs
        - quantity: 100
          datastoreClusterName: <datastore-cluster-name>
          path: /var/lib/containerd
          format: xfs
        - quantity: 10
          datastoreClusterName: <datastore-cluster-name>
          path: /var/lib/etcd
          format: xfs
      ipHostPoolRef:
        name: <iphostname-pool-name>

Описание параметров:

*Обязательно, если указан родительский объект

#Продвинутый сценарий: развертывание в нескольких кластерах с общим хранилищем

Сценарий по умолчанию предполагает, что DCS VM Template (vmTemplateName) и клонированные виртуальные машины находятся в одном и том же DCS Cluster. Для большинства развертываний это предположение верно, и поле spec.template.spec.location используется только для организационной группировки в виде VM Folder.

Развертывания, которые охватывают несколько DCS Clusters и хотят клонировать одну общую DCS VM Template в другой целевой DCS Cluster, требуют выполнения следующих условий:

• DCS Datastore, в котором хранится DCS VM Template, должен быть видим для целевого DCS Cluster. Это верно для datastores SAN, IPSAN, NAS или FusionStorage, настроенных для межкластерного доступа; это не верно для datastore на локальном диске хоста.
• Сетевые ресурсы на стороне DCS (distributed virtual switches и port groups), на которые ссылается vmConfig, также должны быть видимы целевому DCS Cluster.

Когда оба условия выполнены, клонированная виртуальная машина может быть размещена в целевом DCS Cluster путем установки spec.template.spec.location.type: cluster и spec.template.spec.location.name: <target-cluster-name> вместо значения по умолчанию type: folder. Если datastore не является общим для DCS Clusters, задача клонирования завершается ошибкой на стороне платформы DCS. Рекомендуемая альтернатива — подготовить отдельный DCS VM Template внутри каждого целевого DCS Cluster, чтобы каждый DCSMachineTemplate ссылался на шаблон, который уже находится в том cluster, где будут работать виртуальные машины.

Подтвердите межкластерную видимость datastore у администратора платформы DCS перед использованием этой конфигурации.

#Связи между ресурсами

Инфраструктурные ресурсы имеют следующие зависимости:

Cloud Credential
    ↓
IP Pool
    (network settings + persistent disk declarations)
    ↓
Machine Template → references IP Pool
    ↓
Cluster Creation

Повторное использование ресурсов:

• Одни учетные данные облака можно использовать для нескольких кластеров
• Для разных сетевых сегментов можно создавать несколько IP-пулов
• Для разных типов узлов и спецификаций можно создавать несколько шаблонов машин

#Следующие шаги

После настройки инфраструктурных ресурсов:

• Создать кластер
• Управлять пулами узлов
• Обновить кластеры