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

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

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

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

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

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

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

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

#2. Подготовка входных данных для HCS Infrastructure

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

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

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

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

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

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

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

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>

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

#Настройка Machine Configuration Pool

HCSMachineConfigPool определяет предварительно настроенные имена хостов и статические IP-адреса для VM.

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

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

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

apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: HCSMachineConfigPool
metadata:
  name: <cluster-name>
  namespace: cpaas-system
spec:
  configs:
    - hostname: master-1
      networks:
        - subnetName: <subnet-name>
          ipAddress: 192.168.1.11
    - hostname: master-2
      networks:
        - subnetName: <subnet-name>
          ipAddress: 192.168.1.12
    - hostname: master-3
      networks:
        - subnetName: <subnet-name>
          ipAddress: 192.168.1.13

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

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

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

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

HCSMachineTemplate определяет спецификации VM для узлов 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>
      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
        - size: 40
          type: SSD
          mountPath: /var/cpaas
          format: xfs

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

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

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

#Настройка KubeadmControlPlane

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

apiVersion: controlplane.cluster.x-k8s.io/v1beta1
kind: KubeadmControlPlane
metadata:
  name: <cluster-name>
  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 controller также внедряет файлы при разрешении данных cloud-init. Для машин control plane он записывает /etc/kubernetes/pki/kubelet.crt, /etc/kubernetes/pki/kubelet.key и /etc/kubernetes/encryption-provider.conf. Для первой машины control plane controller генерирует конфигурацию encryption provider. После инициализации control plane он пытается повторно использовать существующую конфигурацию encryption provider для kube-apiserver. Если вы включаете bootstrap-файл в /etc/kubernetes/encryption-provider.conf, рассматривайте его как заполнитель, поскольку приоритет имеет файл, сгенерированный или синхронизированный controller.

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

Примечание: Пример rolloutStrategy.rollingUpdate.maxSurge: 0 выше предназначен для высокодоступных control plane со статическими IP. Сохраняйте эту настройку для фиксированных по размеру пулов control plane как минимум с тремя replica, чтобы замены выполнялись в порядке 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. Рассматривайте это как топологию только для создания и оставьте rollout strategy не заданной в манифесте создания. Процесс обновления в этой документации не поддерживает кластеры HCS с одним control plane.

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

#Настройка HCSCluster

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

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

Для описанного рабочего процесса 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.

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

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

apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: HCSCluster
metadata:
  name: <cluster-name>
  namespace: cpaas-system
spec:
  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 controller вычисляет и заполняет это поле из spec.controlPlaneLoadBalancer после создания HCSCluster. Не задавайте controlPlaneEndpoint вручную и не добавляйте пустой объект controlPlaneEndpoint. Если controlPlaneEndpoint явно присутствует в манифесте, он должен содержать и host, и port.

#Настройка 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>
  infrastructureRef:
    apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
    kind: HCSCluster
    name: <cluster-name>

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

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

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

# Проверить статус кластера
kubectl get cluster -n cpaas-system <cluster-name>

# Проверить узлы control plane
kubectl get kubeadmcontrolplane -n cpaas-system <cluster-name>

# Проверить статус machine
kubectl get machines -n cpaas-system

# Проверить статус развертывания кластера
kubectl get clustermodule <cluster-name> -o jsonpath='{.status.base.deployStatus}'

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

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

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

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

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

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

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