#Создание кластеров в Huawei Cloud Stack

В этом документе приведены подробные инструкции по созданию Kubernetes-кластеров на платформе Huawei Cloud Stack с использованием Cluster API.

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

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

#1. Установка необходимых плагинов

Установите следующие плагины в кластер global :

• Alauda Container Platform Kubeadm Provider
• Alauda Container Platform HCS Infrastructure Provider

Подробные инструкции по установке см. в Руководстве по установке.

#2. Подготовка входных данных инфраструктуры HCS

Подготовьте все входные данные, специфичные для HCS, до того, как писать любой YAML в этом документе:

• значения Secret с учетными данными HCS
• распознаваемые провайдером значения вычислительных ресурсов, такие как imageName, flavorName и availabilityZone
• инвентаризацию сетей кластера, включая подсети и свободные диапазоны IP-адресов, используемые кластером
• планирование адресов ELB для control plane, включая vipAddress, vipSubnetName и фиксированные IP L4 и L7
• планирование пула статических IP для control plane и worker-нод

Полный контрольный список, исходные данные и ограничения см. в разделе Ресурсы инфраструктуры для Huawei Cloud Stack.

#Обзор создания кластера

На высоком уровне вы создадите следующие ресурсы Cluster API в кластере global , чтобы подготовить инфраструктуру и выполнить bootstrap функционального Kubernetes-кластера.

Перед тем как писать любой YAML на этой странице, завершите контрольный список подготовки в разделе Ресурсы инфраструктуры для Huawei Cloud Stack. Этот контрольный список охватывает значения, которые ожидает провайдер, источники их получения и значения, которые необходимо спланировать до заполнения манифестов.

Процесс создания кластера выполняется в следующем порядке:

1. Настроить аутентификацию HCS (Secret)
2. Создать пул конфигурации машин (HCSMachineConfigPool)
3. Настроить шаблон машины (HCSMachineTemplate)
4. Настроить KubeadmControlPlane
5. Настроить HCSCluster
6. Создать Cluster

#Конфигурация control plane

Control plane управляет состоянием кластера, планированием и Kubernetes API. В этом разделе показано, как настроить высокодоступный control plane.

#Настройка аутентификации HCS

Информация аутентификации HCS хранится в ресурсе Secret.

apiVersion: v1
kind: Secret
metadata:
  name: <credential-secret-name>
  namespace: cpaas-system
type: Opaque
data:
  accessKey: <base64-encoded-access-key>
  secretKey: <base64-encoded-secret-key>
  projectID: <base64-encoded-project-id>
  region: <base64-encoded-region>
  externalGlobalDomain: <base64-encoded-domain>
  schema: <base64-encoded-schema>

Существующие Secret с учетными данными, созданные без schema, продолжают работать без изменений. Указывайте schema только если ваш endpoint HCS IAM использует http вместо https по умолчанию.

Вы можете повторно использовать существующий Secret с учетными данными HCS. Его имя не обязано совпадать с именем кластера, но HCSCluster.spec.identityRef.name должен ссылаться на этот Secret.

#Настройка пула конфигурации машин

HCSMachineConfigPool задает предварительно настроенные имена хостов, статические IP-адреса и любые управляемые пулом постоянные диски для ВМ.

Используйте один селектор подсети для каждой записи networks[]. Для новых манифестов задавайте либо subnetName, либо subnetId, но не оба сразу. В существующих манифестах можно оставить устаревшее поле subenetName; если вы также добавляете subnetName при обновлении такого манифеста, его значение должно точно совпадать с subenetName. Не задавайте конфликтующие значения в subenetName, subnetName и subnetId.

Если вы используете subnetName в пуле конфигурации машин, укажите то же имя подсети в HCSCluster.spec.network.subnets.

Для начального сценария создания кластера достаточно указать существующую подсеть по имени, поскольку контроллер разрешает метаданные подсети до того, как кластер станет Ready. Если позже вы добавляете еще одну подсеть в существующий Ready HCSCluster, не добавляйте только name. Обновляйте запись HCSCluster.spec.network.subnets родительского ресурса, включая полный объект подсети, чтобы последующие операции с машинами или ELB могли повторно использовать разрешенные метаданные подсети.

apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: HCSMachineConfigPool
metadata:
  name: <cluster-name>-cp-pool
  namespace: cpaas-system
  labels:
    cluster.x-k8s.io/cluster-name: <cluster-name>
spec:
  configs:
    - hostname: master-1
      networks:
        - subnetName: <subnet-name>
          ipAddress: 192.168.1.11
      persistentDisks:
        - slot: 0
          size: 100
          type: SSD
          mountPath: /var/cpaas
          format: xfs
    - hostname: master-2
      networks:
        - subnetName: <subnet-name>
          ipAddress: 192.168.1.12
      persistentDisks:
        - slot: 0
          size: 100
          type: SSD
          mountPath: /var/cpaas
          format: xfs
    - hostname: master-3
      networks:
        - subnetName: <subnet-name>
          ipAddress: 192.168.1.13
      persistentDisks:
        - slot: 0
          size: 100
          type: SSD
          mountPath: /var/cpaas
          format: xfs

*Для новых манифестов задавайте либо subnetName, либо subnetId. В существующих манифестах можно продолжать использовать subenetName, а subnetName можно добавлять только если оба поля используют одно и то же значение. Не задавайте конфликтующие значения селектора подсети.

Поля постоянного диска обязательны, если указан persistentDisks.

Используйте persistentDisks[] для node-local состояния, которое должно пережить замену ВМ. Не объявляйте тот же путь монтирования в HCSMachineTemplate.spec.template.spec.dataVolumes[].

Примечание: Схема CRD перечисляет subnetName, subenetName и subnetId как необязательные поля и не выражает допустимые комбинации между ними. При написании манифестов следуйте правилам провайдера, приведенным выше.

Примечание: Чтобы подключить к одному узлу несколько NIC, добавьте несколько записей networks[]. Провайдер использует эти записи только для подключения NIC и назначения селекторов подсети и статических IP. Он не поддерживает указание ролей для отдельных NIC, шлюзов по умолчанию, статических маршрутов или настроек DNS для каждого NIC.

#Поведение hostname на узле

Провайдер получает POSIX hostname и FQDN узла из hostname следующим образом:

Форма с точкой подходит для настройки приложений, зависящих от разрешения FQDN (hostname -f, сертификаты с SAN-записями, метки журналов). Провайдер задает prefer_fqdn_over_hostname: false и включает cloud-init manage_etc_hosts только если указан hostname с точкой, поэтому POSIX-инструменты по-прежнему видят короткое имя, а hostname -f возвращает полный FQDN.

Недопустимые hostname (начальная точка, конечная точка, строки, состоящие только из точек, прописные буквы или любые значения, нарушающие ограничение поля) отклоняются до запуска ВМ. Ошибка устанавливается в Machine.status владельца и отображается в Cluster.status.conditions, чтобы она была видна в kubectl describe cluster <name> и kubectl get machines -n cpaas-system -o wide.

#Настройка шаблона машины

HCSMachineTemplate задает спецификацию ВМ для узлов control plane.

apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: HCSMachineTemplate
metadata:
  name: <cluster-name>-control-plane
  namespace: cpaas-system
spec:
  template:
    spec:
      imageName: <vm-image-name>
      flavorName: <instance-flavor>
      availabilityZone: <availability-zone>
      rootVolume:
        type: SSD
        size: 100
      configPoolRef:
        name: <cluster-name>-cp-pool
      dataVolumes:
        - size: 10
          type: SSD
          mountPath: /var/lib/etcd
          format: xfs
        - size: 100
          type: SSD
          mountPath: /var/lib/kubelet
          format: xfs
        - size: 100
          type: SSD
          mountPath: /var/lib/containerd
          format: xfs

*Обязательно, если указан dataVolumes.

dataVolumes[] пересоздаются вместе с ECS. Не используйте их для /var/cpaas или любого другого пути, который должен пережить rolling replacement. Размещайте такие пути в HCSMachineConfigPool.spec.configs[].persistentDisks[].

Примечание: Не задавайте в манифестах HCSMachineTemplate поля runtime identity, такие как providerID или serverId. Провайдер назначает эти значения при создании экземпляров HCS.

Примечание: Администраторы арендатора не могут получить из UI HCS значения flavorName и availabilityZone, распознаваемые провайдером. Получите точные значения у администратора HCS перед применением манифеста.

#Настройка KubeadmControlPlane

KubeadmControlPlane определяет конфигурацию control plane Kubernetes.

apiVersion: controlplane.cluster.x-k8s.io/v1beta1
kind: KubeadmControlPlane
metadata:
  name: <cluster-name>-kcp
  namespace: cpaas-system
spec:
  replicas: 3
  version: <kubernetes-version>
  rolloutStrategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 0
  kubeadmConfigSpec:
    files:
      - path: /etc/kubernetes/admission/psa-config.yaml
        owner: root:root
        permissions: "0644"
        content: |
          apiVersion: apiserver.config.k8s.io/v1
          kind: AdmissionConfiguration
          plugins:
          - name: PodSecurity
            configuration:
              apiVersion: pod-security.admission.config.k8s.io/v1
              kind: PodSecurityConfiguration
              defaults:
                enforce: "privileged"
                enforce-version: "latest"
                audit: "baseline"
                audit-version: "latest"
                warn: "baseline"
                warn-version: "latest"
              exemptions:
                usernames: []
                runtimeClasses: []
                namespaces:
                - kube-system
                - cpaas-system
      - path: /etc/kubernetes/patches/kubeletconfiguration0+strategic.json
        owner: root:root
        permissions: "0644"
        content: |
          {
            "apiVersion": "kubelet.config.k8s.io/v1beta1",
            "kind": "KubeletConfiguration",
            "protectKernelDefaults": true,
            "tlsCertFile": "/etc/kubernetes/pki/kubelet.crt",
            "tlsPrivateKeyFile": "/etc/kubernetes/pki/kubelet.key",
            "streamingConnectionIdleTimeout": "5m",
            "clientCAFile": "/etc/kubernetes/pki/ca.crt"
          }
      - path: /etc/kubernetes/encryption-provider.conf
        owner: root:root
        permissions: "0600"
        content: |
          apiVersion: apiserver.config.k8s.io/v1
          kind: EncryptionConfiguration
          resources:
          - resources:
            - secrets
            providers:
            - aescbc:
                keys:
                - name: key1
                  secret: bootstrap-placeholder
      - path: /etc/kubernetes/audit/policy.yaml
        owner: root:root
        permissions: "0644"
        content: |
          apiVersion: audit.k8s.io/v1
          kind: Policy
          rules:
          - level: Metadata
    clusterConfiguration:
      imageRepository: <image-repository>
      dns:
        imageTag: <dns-image-tag>
      etcd:
        local:
          imageTag: <etcd-image-tag>
      apiServer:
        extraArgs:
          audit-log-format: json
          audit-log-mode: batch
          audit-log-path: /etc/kubernetes/audit/audit.log
          audit-policy-file: /etc/kubernetes/audit/policy.yaml
          admission-control-config-file: /etc/kubernetes/admission/psa-config.yaml
          encryption-provider-config: /etc/kubernetes/encryption-provider.conf
          kubelet-certificate-authority: /etc/kubernetes/pki/ca.crt
          profiling: "false"
          tls-min-version: VersionTLS12
        extraVolumes:
          - name: vol-dir-0
            hostPath: /etc/kubernetes
            mountPath: /etc/kubernetes
            pathType: Directory
      controllerManager:
        extraArgs:
          bind-address: "::"
          flex-volume-plugin-dir: "/opt/libexec/kubernetes/kubelet-plugins/volume/exec/"
          profiling: "false"
          tls-min-version: VersionTLS12
      scheduler:
        extraArgs:
          bind-address: "::"
          profiling: "false"
          tls-min-version: VersionTLS12
    postKubeadmCommands:
      - chmod 600 /var/lib/kubelet/config.yaml
    initConfiguration:
      patches:
        directory: /etc/kubernetes/patches
      nodeRegistration:
        kubeletExtraArgs:
          node-labels: "kube-ovn/role=master"
          protect-kernel-defaults: "true"
          volume-plugin-dir: "/opt/libexec/kubernetes/kubelet-plugins/volume/exec/"
    joinConfiguration:
      patches:
        directory: /etc/kubernetes/patches
      nodeRegistration:
        kubeletExtraArgs:
          node-labels: "kube-ovn/role=master"
          volume-plugin-dir: "/opt/libexec/kubernetes/kubelet-plugins/volume/exec/"
  machineTemplate:
    nodeDrainTimeout: 1m
    nodeDeletionTimeout: 5m
    infrastructureRef:
      apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
      kind: HCSMachineTemplate
      name: <cluster-name>-control-plane

Контроллер HCS также внедряет файлы при разрешении cloud-init data. Он записывает /etc/kubernetes/pki/kubelet.crt, /etc/kubernetes/pki/kubelet.key и /etc/kubernetes/encryption-provider.conf для машин control plane. Для первой машины control plane контроллер генерирует конфигурацию encryption provider. После инициализации control plane он пытается повторно использовать существующую конфигурацию encryption provider kube-apiserver. Если вы включаете bootstrap-файл в /etc/kubernetes/encryption-provider.conf, рассматривайте его как заполнитель, поскольку приоритет имеет файл, сгенерированный или синхронизированный контроллером.

Примечание: Настраивайте apiServer.extraArgs и apiServer.extraVolumes вместе. Если том не смонтирован, kube-apiserver не сможет прочитать файлы, записанные в /etc/kubernetes.

Примечание: Пример rolloutStrategy.rollingUpdate.maxSurge: 0 выше предназначен для высокодоступных control plane со статическими IP. Сохраняйте эту настройку для пулов control plane фиксированного размера с не менее чем тремя replicas, чтобы замены выполнялись в порядке scale-down, а затем scale-up. Если вы создаете HCS-кластер с одним control plane (spec.replicas: 1), не копируйте блок rolloutStrategy в манифест создания. Валидация KubeadmControlPlane отклоняет такую конфигурацию rollout в стиле scale-in для одной replica.

Примечание: HCS также поддерживает создание кластера с одним control plane, если задать spec.replicas: 1 и подготовить одну запись конфигурации control plane в ссылочном HCSMachineConfigPool. Рассматривайте это как топологию только для создания и не задавайте strategy rollout в этом манифесте создания. Процесс upgrade в этой документации не поддерживает HCS-кластеры с одним control plane.

Используйте Матрицу поддержки ОС только для тех версий компонентов, которые она явно перечисляет, например для image tags coredns и etcd для поддерживаемых образов Alauda OS. Это не полный источник всех значений манифеста HCS. Перед применением этого YAML также используйте утвержденную базовую версию релиза для таких значений, как imageRepository, репозиторий образов DNS, версия Kube-OVN, join CIDR Kube-OVN, Pod CIDR и Service CIDR.

#Настройка HCSCluster

Ресурс HCSCluster определяет конфигурацию инфраструктуры HCS.

Провайдер HCS создает Elastic Load Balance (ELB) на платформе HCS для Kubernetes API server. Для этого ELB должен быть включен в режиме Hybrid Load Balancing, чтобы узлы кластера также могли обращаться к API server через адрес ELB.

Для описанного workflow HCS укажите vipAddress, elbVirsubnetL4Ips и elbVirsubnetL7Ips. Каждая запись elbVirsubnetL4Ips[].ips и elbVirsubnetL7Ips[].ips должна содержать два IP-адреса.

Если вы задаете vipDomainName, настройте HCS Cloud DNS Private Zones так, чтобы домен разрешался в vipAddress.

Перечислите каждую подсеть кластера в spec.network.subnets до того, как будете ссылаться на нее где-либо еще. Значения vipSubnetName, elbVirsubnetL4Ips[].subnetName, elbVirsubnetL7Ips[].subnetName и значения subnetName, используемые HCSMachineConfigPool, должны присутствовать в spec.network.subnets.

Для начального сценария создания кластера контроллер может разрешить метаданные существующей подсети по name. Для существующего Ready-кластера добавляйте полный объект подсети, а не только name. Включайте id, а также neutronSubnetId для любой подсети, которую будет использовать ELB control plane. Также сохраняйте в инвентаре подсети cidr, gatewayIp, primaryDNS и secondaryDNS.

Не отключайте Hybrid Load Balancing на ELB, созданном провайдером, после создания кластера. Кластер зависит от этого режима ELB, чтобы узлы могли обращаться к API server через адрес ELB.

apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: HCSCluster
metadata:
  name: <cluster-name>
  namespace: cpaas-system
spec:
  # Optional. Include only when you want provider-managed control-plane ECS placement.
  controlPlaneHA:
    enabled: true
    policy: soft-anti-affinity
  controlPlaneLoadBalancer:
    vipAddress: <control-plane-vip-address>
    vipSubnetName: <vip-subnet-name>
    vipDomainName: <control-plane-vip-domain-name>
    elbVirsubnetL4Ips:
      - subnetName: <subnet-name>
        ips:
          - <l4-ip-1>
          - <l4-ip-2>
    elbVirsubnetL7Ips:
      - subnetName: <subnet-name>
        ips:
          - <l7-ip-1>
          - <l7-ip-2>
  networkType: kube-ovn
  network:
    vpc:
      name: <vpc-name>
    subnets:
      - name: <subnet-name>
    securityGroup:
      name: <security-group-name>
  identityRef:
    name: <credential-secret-name>

Не включайте spec.controlPlaneEndpoint в манифест создания. В HCS create flow контроллер вычисляет и заполняет это поле на основе spec.controlPlaneLoadBalancer после создания HCSCluster. Не задавайте controlPlaneEndpoint вручную и не добавляйте пустой объект controlPlaneEndpoint. Если controlPlaneEndpoint явно присутствует в манифесте, он должен включать и host, и port.

controlPlaneHA является необязательным. Если вы включаете его, обязательны и enabled, и policy. Используйте anti-affinity для строгого разделения по хостам. Используйте soft-anti-affinity, когда вы предпочитаете распределение по хостам, но не хотите, чтобы создание ECS завершалось ошибкой только потому, что HCS не может удовлетворить жесткому правилу размещения. Рекомендации по планированию, включая требование к rolling replacement при включении функции на существующем кластере, см. в Плане размещения Control Plane HA.

#Настройка Cluster

Ресурс Cluster в Cluster API объявляет кластер и ссылается на ресурсы control plane и инфраструктуры.

apiVersion: cluster.x-k8s.io/v1beta1
kind: Cluster
metadata:
  name: <cluster-name>
  namespace: cpaas-system
  annotations:
    cpaas.io/sentry-deploy-type: Baremetal
    cpaas.io/alb-address-type: ClusterAddress
    capi.cpaas.io/resource-group-version: infrastructure.cluster.x-k8s.io/v1beta1
    capi.cpaas.io/resource-kind: HCSCluster
    cpaas.io/kube-ovn-join-cidr: <kube-ovn-join-cidr>
    cpaas.io/kube-ovn-version: <kube-ovn-version>
  labels:
    cluster-type: HCS
spec:
  clusterNetwork:
    pods:
      cidrBlocks:
        - <pods-cidr>
    services:
      cidrBlocks:
        - <services-cidr>
  controlPlaneRef:
    apiVersion: controlplane.cluster.x-k8s.io/v1beta1
    kind: KubeadmControlPlane
    name: <cluster-name>-kcp
  infrastructureRef:
    apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
    kind: HCSCluster
    name: <cluster-name>

#Проверка кластера

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

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

# Check cluster status
kubectl get cluster -n cpaas-system <cluster-name>

# Verify control plane nodes
kubectl get kubeadmcontrolplane -n cpaas-system <cluster-name>-kcp

# Check machine status
kubectl get machines -n cpaas-system

# Verify cluster deployment status
kubectl get clustermodule <cluster-name> -o jsonpath='{.status.base.deployStatus}'

#Проверка Control Plane HA

Если вы включили HCSCluster.spec.controlPlaneHA, сначала проверьте condition HCSCluster:

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

Интерпретируйте condition следующим образом:

Проверьте фактическую server group и snapshot членства:

kubectl get hcscluster <cluster-name> -n cpaas-system \
  -o jsonpath='serverGroup={.status.controlPlaneHA.name}{" id="}{.status.controlPlaneHA.id}{" policy="}{.status.controlPlaneHA.policy}{"\n"}{range .status.controlPlaneHA.members[*]}{.machineName}{" "}{.serverID}{"\n"}{end}'

Для anti-affinity HCS рассматривает политику server group как жесткое ограничение планирования. Если емкости недостаточно, создание ECS может завершиться ошибкой, и сообщение condition следует использовать как первый диагностический сигнал. Для soft-anti-affinity HCS пытается распределять членов, но все же может размещать несколько экземпляров ECS на одном и том же хосте.

#Ожидаемый результат

Успешно созданный кластер должен отображать:

• Статус кластера: Running или Provisioned
• Все машины control plane: Running
• Узлы Kubernetes: Ready
• Статус модуля кластера: Completed

#Добавление worker-нод

Инструкции по добавлению worker-нод в кластер см. в разделе Управление узлами.

#Обновление кластеров

Инструкции по обновлению компонентов кластера см. в разделе Обновление кластеров.

#Устранение неполадок

Если кластер достигает состояния Provisioned, но так и не становится Ready — например, workload-узлы остаются в состоянии NotReady, потому что CNI не развернут, — начните с независимого от провайдера раздела Устранение неполадок: workload cluster застрял в состоянии Provisioned.

Для характерных сбоев HCS (например, когда kubeadm init никогда не завершается из-за того, что hostname в HCSMachineConfigPool с точкой привел к POSIX hostname, содержащему точки), см. Устранение неполадок workload cluster Huawei Cloud Stack.