# Data Object - CnsContainerCluster(vim.cns.ContainerCluster)

Property of
  CnsVolumeMetadata
Extends
  DynamicData
Since
  vSAN API vSAN 6.7U3

## Data Object Description

Data object to identify a container orchestrator cluster uniquely.
This data object is aimed to link the container volumes with their corresponding container orchestrator clusters.
One example of container orchestrator cluster is Kubernetes. Kubernetes cluster deployed on vSphere would consist of virtual machines on which cloud native application can be deployed using Kubernetes constructs.

Properties

Name | Type | Description
--- | --- | ---
clusterDistribution* | xsd:string | Distribution name of this container cluster. The distribution name length is limited to 128 bytes. Since vSAN API vSAN 7.0U2
clusterFlavor* | xsd:string | Flavor of this container orchestrator cluster. See CnsClusterFlavor for supported types and valid values for this field. If not set, the server will assume VANILLA cluster flavor. Since vSAN API 7.0
clusterId | xsd:string | Cluster ID, provided by CNS client. E.g.: vSphere volume plugin for Kubernetes cluster will be responsible for passing this container ID to CNS. This ID will get used to link a cluster with its container volumes, for filtering read operations. CNS will not try to enforce uniqueness of this ID and will rely on clients to ensure uniqueness. Duplicate cluster ID will not cause any problem in provisioning workflow. But it will make cluster ID based filtering of volume less useful for end user. For VANILLA flavor of Kubernetes, this field must be set to a unique ID. For example, a combination of name and UUID. For WORKLOAD flavor of Kubernetes, this field will be set to the Virtual Center cluster managed object ID that has supervisor cluster enabled. The associated Kubernetes entity metadata for a CNS volume like namespace, PVC, PV and Pods will refer to corresponding entities in supervisor cluster. For GUEST_CLUSTER flavor of Kubernetes, this field will be set to the sub resource pool managed object ID where the guest cluster is deployed.
clusterType | xsd:string | Type of this container orchestrator cluster. See CnsClusterType for supported types and valid values for this field.
delete* | xsd:boolean | Default value is False if not set. If True, the ContainerCluster should be deleted in VolumeManager.Update API call. But if any EntityMetadata is associating with this ContainerCluster, CNS Fault will be thrown. So to delete the ContainerCluster, user must also delete the EntityMetadata associate with this ContainerCluster. If False, the ContainerCluster should be added in VolumeManager.Update API call. This field will be ignored in VolumeManager.Create API call. Since vSAN API 8.0.0.2
vSphereUser | xsd:string | vSphere user corresponding to container orchestrator cluster user. This property is aimed to help associate container volumes with the vSphere user, responsible for managing lifecycle of those volumes. vSphere user management, like keeping track that which vSphere user is responsible for which all container orchestrator clusters, needs to happen out-of-band and is out of the scope for CNS. This information will not be used for authorization. It's for association purpose only.
Properties inherited from DynamicData
None

*Need not be set
Show WSDL type definition
<complexType xmlns="http://www.w3.org/2001/XMLSchema" xmlns:vsan="urn:vsan" name="CnsContainerCluster"> <complexContent> <extension base="vsan:DynamicData"> <sequence> <element name="clusterType" type="xsd:string"/> <element name="clusterId" type="xsd:string"/> <element name="vSphereUser" type="xsd:string"/> <element name="clusterFlavor" type="xsd:string" minOccurs="0"/> <element name="clusterDistribution" type="xsd:string" minOccurs="0"/> <element name="delete" type="xsd:boolean" minOccurs="0"/> </sequence> </extension> </complexContent> </complexType>