#Huawei DCS Provider

#Overview

The Huawei DCS Infrastructure Provider enables Immutable Infrastructure on Huawei Datacenter Virtualization Solution (DCS) platform.

DCS (Datacenter Virtualization Solution) is Huawei's virtualization platform that provides enterprise-grade virtualization capabilities. The DCS Provider integrates with DCS to manage virtual machines, networks, and storage resources for Kubernetes clusters.

#Key Features

• Virtual Machine Management: Provision and manage VMs on DCS platform
• Network Configuration: Support for multi-NIC configurations with customizable network settings
• Storage Management: Flexible disk configuration with template disks and IP-slot-based persistent disks across multiple datastores
• High Availability: Built-in support for highly available control plane deployments
• Rolling Updates: Automated rolling updates for zero-downtime maintenance
• Upgrade Data Preservation: Declared persistent disks can be detached from old VMs and reattached to replacement VMs during rolling upgrades so preserved node-local data is not lost with the system disk

#Cluster Management Capabilities

The DCS Provider always supports YAML-based cluster management through Cluster API manifests. It also supports UI-based cluster management when Fleet Essentials is installed and Alauda Container Platform DCS Infrastructure Provider is 1.0.13 or later. If the UI workflow relies on pool-managed persistent disks, use DCS provider v1.0.16 or later. In v1.0.16, the persistent-disk declaration on DCSIpHostnamePool remains YAML-only.

#UI-Based Management (Fleet Essentials)

Fleet Essentials provides the UI extension anchors that allow Alauda Container Platform DCS Infrastructure Provider to add DCS-specific pages dynamically. When Fleet Essentials is installed and the provider version is 1.0.13 or later, you can manage DCS clusters through the web UI. Pool-managed persistent-disk scenarios require DCS provider v1.0.16 or later, but in v1.0.16 the persistentDisk declaration on DCSIpHostnamePool must still be managed through YAML manifests:

Infrastructure Resource Management:

• Cloud Credentials - Store DCS platform access credentials
• IP Pools - Manage IP address allocations and multi-NIC settings. In v1.0.16, IP-slot persistent disks such as /var/cpaas remain YAML-managed
• Machine Templates - Define VM specifications for Control Plane and Worker Nodes, excluding pool-managed persistent disks

Cluster Lifecycle:

• Create Clusters - 5-step wizard workflow for guided cluster creation
• View cluster details with Overview, Nodes, Node Pools, and Aligned Extensions tabs
• Upgrade Clusters - Two-phase upgrade: Distribution Version → Kubernetes
• Destroy clusters with confirmation dialogs

Node Pool Management:

• View Control Plane and Worker Node Pools
• Add Worker Node Pools with configurable replicas and rollout strategies
• Delete Worker Node Pools
• Upgrade Kubernetes version per Node Pool
• View detailed Conditions for Control Plane Node Pool

#YAML-Based Management

For automation and GitOps workflows, you can manage DCS clusters using YAML manifests. This workflow does not depend on Fleet Essentials:

• Define infrastructure resources (Secret, DCSIpHostnamePool, DCSMachineTemplate)
• Create cluster resources (KubeadmControlPlane, DCSCluster, Cluster)
• Manage worker nodes (MachineDeployment, KubeadmConfigTemplate)
• Perform rolling updates and upgrades with declared persistent disks preserved across node replacement

See Creating Clusters on Huawei DCS for YAML-based instructions.

#Supported Kubernetes Versions

The DCS Provider supports Kubernetes versions as defined in the OS Support Matrix. Each MicroOS release includes a specific Kubernetes version, and VM templates must be created using the corresponding MicroOS images.

#Architecture

The DCS Provider implements the Cluster API infrastructure provider specification:

• DCSCluster: Represents the DCS infrastructure cluster
• DCSMachine: Represents individual virtual machines
• DCSMachineTemplate: Defines VM templates for machine creation
• DCSIpHostnamePool: Manages IP and hostname allocations for machines

#Concepts and Terminology

Several Huawei DCS platform concepts have names that closely resemble Cluster API custom resource names. Two of them deserve special attention because the name collision is exact: a DCS Cluster (the DCS platform's pool of physical hosts) is not the same object as a DCSCluster custom resource (the Cluster API infrastructure resource that represents a Kubernetes cluster on top of DCS). Reading the two as the same thing leads to incorrect DCSMachineTemplate and DCSCluster configurations.

This section enumerates the DCS platform concepts referenced by the provider, maps each concept to the Cluster API resource or field that references it, and clarifies the network and storage layering that is the most frequent source of configuration errors.

#DCS Platform Object Hierarchy

The DCS platform organizes its objects in a hierarchy. The provider works with the following layers (top to bottom):

• DCS Site — the top-level scope of a single DCS deployment. Identified by a site ID such as EC1C108C.
• Within a site:
  • DCS Clusters — pools of physical hosts. A site contains one or more DCS Clusters.
  • DCS VM Folders and DCS Cluster Folders — organizational labels (logical groupings) for virtual machines and clusters respectively.
  • DCS Datastores and DCS Datastore Clusters — storage containers and groups of storage containers.
  • DCS Distributed Virtual Switches (DVS) — virtual switches that span the site.
• Within a DCS Cluster:
  • DCS Hosts — physical servers (for example, CNA-01, CNA-02).
• Within a DCS DVS:
  • DCS Port Groups — network configuration entries that virtual machine NICs attach to.
• Independent of the placement hierarchy:
  • DCS VM Templates — virtual machines marked as templates, used as the source image for cloning.
  • DCS Volumes — persistent disks created on DCS Datastores.

The provider does not own any of these objects. It references them by name or URN from custom resource fields.

#DCS Platform Concepts

#DCS Site

The top-level container of a single DCS deployment. The site ID is supplied as DCSCluster.spec.site and is also stored in the cloud-credential Secret. All DCS API paths used by the provider include the site ID (/service/sites/{siteId}/...).

#DCS Cluster

A pool of physical hosts on the DCS platform. The DCS scheduler places virtual machines onto hosts that belong to a single DCS Cluster. A site can contain one or more DCS Clusters; a DCS Cluster contains one or more DCS Hosts. DCS Cluster names are visible in the DCS portal and are returned by the GET /service/sites/{siteId}/clusters API.

The name DCS Cluster collides with the DCSCluster Cluster API custom resource. See Cluster API Resource Mapping below.

#DCS Host

A single physical server registered in a DCS Cluster. Names follow the local convention on the DCS platform (for example, CNA-01). Virtual machines run on hosts; the DCS scheduler chooses which host receives a new virtual machine, based on cluster-level policies (DRS, anti-affinity rules) and host capacity. The provider does not pin virtual machines to a specific DCS Host; the DCSMachineTemplate resource does not expose a host-binding field.

#DCS VM Folder

An organizational label inside a DCS Site that groups virtual machines. A VM Folder does not affect compute placement; a virtual machine grouped under VM Folder foo still runs on a DCS Host belonging to some DCS Cluster. The provider queries VM Folders through GET /service/sites/{siteId}/folder?type=1.

VM Folders must be created on the DCS platform before being referenced from DCSMachineTemplate.spec.template.spec.location (with type: folder).

#DCS Cluster Folder

An organizational label that groups DCS Clusters themselves, returned by the same /folder endpoint with a different type parameter. The provider does not query or reference DCS Cluster Folders. This concept is listed here only to prevent confusion with DCS VM Folder.

#DCS VM Template

A virtual machine on the DCS platform that has been marked as a template (isTemplate=true). The provider clones from this template to create cluster nodes. A VM Template is identified by name (the value of DCSMachine.spec.vmTemplateName); the provider resolves the name to a URN by listing GET /service/sites/{siteId}/vms?isTemplate=true&name=<name>.

A VM Template carries its own disk on a DCS Datastore and its own network configuration. The provider overwrites the network configuration (NIC port group, customization) when cloning; it does not overwrite the disk's storage type. The cloned virtual machine inherits the template's home DCS Cluster by default; see Infrastructure → Advanced: Multi-Cluster Deployment for cross-cluster usage.

#DCS Datastore

A storage container on the DCS platform that holds the disks of virtual machines. Datastores can be backed by SAN, IPSAN, NAS, FusionStorage, or local disk. The storage backend determines whether a datastore is visible to one DCS Cluster or to several DCS Clusters: SAN, IPSAN, NAS, and FusionStorage typically support cross-cluster access; local disk does not.

Datastores are referenced from disk specifications by either datastoreName or datastoreUrn; the provider resolves the name to a URN before sending the clone request.

#DCS Datastore Cluster

A group of DCS Datastores. When a disk specification references a Datastore Cluster (via datastoreClusterName), the DCS scheduler picks a member datastore that has free capacity. This is the recommended way to declare storage when the DCS administrator has configured a datastore cluster, because it tolerates single-datastore exhaustion.

A DCS Datastore Cluster is not a DCS Cluster. The two names overlap because both use the word "cluster" but the underlying concepts are different: a DCS Cluster is a host pool, and a DCS Datastore Cluster is a datastore pool. Watch for this collision when reading platform documentation or talking to DCS administrators.

#DCS Distributed Virtual Switch (DVS)

A virtual switch on the DCS platform that spans one or more DCS Hosts. Virtual machine NICs attach to a DCS Port Group, which in turn belongs to a DCS DVS. The provider queries DVSs through GET /service/sites/{siteId}/dvswitchs.

#DCS Port Group

A network configuration entry on a DCS DVS. Each port group carries a VLAN configuration, security policies, and other network settings. The provider queries port groups through GET {dvSwitchUri}/portgroups (using the parent DVS URI) and references them by name (portGroupName) or URN (portGroupUrn).

A virtual machine NIC must attach to exactly one DCS Port Group. Additional NICs require additional port-group references.

#DCS Volume

A persistent disk on the DCS platform. Volumes live on DCS Datastores and are identified by a URN such as urn:sites:EC1C108C:volumes:9841. The provider creates volumes through POST /service/sites/{siteId}/volumes when DCSIpHostnamePool.spec.pool[].persistentDisk[] declares disks that must survive virtual machine replacement; it attaches the resulting volume to the virtual machine through the attachvol action.

A DCS Volume is conceptually different from a Kubernetes PersistentVolume. A DCS Volume is a DCS-platform storage object attached at the hypervisor level; a Kubernetes PersistentVolume is a Kubernetes API object that represents storage available to pods. The provider only manages DCS Volumes; in-cluster PersistentVolume resources are managed separately by the workload's CSI driver.

#DCS Cloud Credential

The authentication material used by the provider to call the DCS REST API. The provider obtains a session token by sending X-Auth-User and X-Auth-Key headers to POST /service/session and uses the returned X-Auth-Token header on subsequent requests. The credentials are stored as a Kubernetes Secret referenced from DCSCluster.spec.credentialSecretRef. The Secret contains authUser, authKey, endpoint, and site keys.

#Cluster API Resource Mapping

The following table disambiguates the DCS platform concepts whose names resemble Cluster API custom resources.

The following concept does not collide with any Cluster API resource but is internally confusable because of the word "cluster":

#Storage Concepts: Datastore, Datastore Cluster, and Volume

The DCS platform exposes three storage-related concepts that the provider references separately:

• A DCS Datastore is a single storage container. A virtual machine disk is pinned to one DCS Datastore.
• A DCS Datastore Cluster is a group of DCS Datastores. A virtual machine disk that references a DCS Datastore Cluster is placed on one member datastore that has free capacity; the DCS scheduler picks the member.
• A DCS Volume is a persistent disk object that lives on a DCS Datastore (or on a member datastore of a DCS Datastore Cluster). Volumes are created and attached to virtual machines through the provider when the DCSIpHostnamePool declares persistent disks; they survive virtual machine replacement.

The relationship between the three:

• A DCSMachineTemplate declares one or more disks under vmConfig.dcsMachineDiskSpec[]. Each disk binds to either a specific datastoreName or a datastoreClusterName. These template-level disks are created and destroyed together with the virtual machine.
• A DCSIpHostnamePool entry can declare one or more persistentDisk[] items. Each item binds to either a specific datastoreName or a datastoreClusterName, and the provider creates a corresponding DCS Volume that survives virtual machine replacement.

Cross-cluster visibility is determined by the underlying storage backend. SAN, IPSAN, NAS, and FusionStorage datastores are typically visible to several DCS Clusters; local-disk datastores are visible only to a single DCS Cluster. This visibility is what determines whether a single DCS VM Template can be cloned into more than one DCS Cluster.

#Network Concepts: DVS, Port Group, and IP Identity

Network configuration on a DCS-backed Kubernetes cluster is split across two layers:

• DCS-side network plumbing (Layer 2): a virtual machine NIC must attach to a DCS Port Group, which belongs to a DCS Distributed Virtual Switch. The DVS and Port Group are DCS platform objects, created and administered on the DCS side. The provider references them by name (dvSwitchName, portGroupName) or by URN (portGroupUrn).
• Cluster-side network identity (Layer 3): the IP address, subnet mask, gateway, DNS server, and hostname assigned to the virtual machine are not DCS platform objects. They are declared in DCSIpHostnamePool.spec.pool[] entries (a Cluster API resource owned by the cluster operator) and are written into the virtual machine through cloud-init or Ignition during bootstrap.

This split has two practical consequences:

• The DCS platform team owns the DVS and Port Group definitions. The cluster operator owns the IP and hostname plan. The two are coordinated through the DCSIpHostnamePool resource, which references the DCS-side port group while declaring the cluster-side IP identity.
• The provider does not call any DCS API to allocate or reserve IP addresses. Address conflicts must be avoided by the cluster operator when authoring DCSIpHostnamePool entries.

The Cluster API resource DCSIpHostnamePool and the DCS platform's port group are distinct objects. The DCS platform does not have a native "IP pool" concept; the DCSIpHostnamePool resource is the only place where per-virtual-machine network identity is recorded.

#Field-to-Concept Reference

The following tables map the most commonly used custom resource fields to the DCS platform concept they reference and to the source of the value.

#DCSCluster fields

#DCSMachineTemplate / DCSMachine fields

#DCSIpHostnamePool fields

#Requirements

• DCS platform with API access

• A DCS administrator-role user, either:

  • Interface interconnection user (default), or
  • Domain user (LDAP/AD-backed; requires DCS domain authentication configured by your DCS administrator).

  See Credential User Types for selection criteria and DCS-side requirements.

• Virtual machine templates with MicroOS images

• DCS VM templates 4.2.1 or later when you use pool-managed persistent disks, because safe shutdown and disk detach depend on guest tools

• Shared storage with cross-host access capability

#Documentation

For detailed instructions on using the DCS Provider, see:

• Installation
• Infrastructure Resources
• Creating Clusters
• Managing Nodes
• Upgrading Clusters
• API Reference