As a VMware Aria Automation cloud administrator, you can use a command line interface to enable Cloud Consumption Interface (CCI) access and configure governance constructs. The command line interface uses the Kubernetes command-line tool, or kubectl.
For a complete list of actions that you can perform using the CLI, see Kubernetes API Reference for the Cloud Consumption Interface.
Prerequisites
- Verify that a Supervisor Cluster is enabled on a vCenter instance and is registered with VMware Aria Automation.
- Verify that you are at least an organization member in VMware Aria Automation with the Administrator service role for Automation Assembler or Automation Service Broker.
- Verify that you have:
- Downloaded the CCI kubectl plug-in.
- Obtained an API token for the admin user or defined a variable to store your user password.
- Used your token with the -t option or used your admin credentials with the -u option to log in to the CCI server and changed the default context to CCI.
- Verify that you have added a vCenter cloud account in Automation Assembler.
For more information about any of these prerequisites, see Cloud Consumption Interface setup and configuration
Step 1: Create a project and project role bindings
To group Automation users and set access to infrastructure resources, you create a project and project role bindings.
- Create a project.
kubectl create -f project.yaml
Exampleproject.yaml
file.apiVersion: project.cci.vmware.com/v1alpha1 kind: Project metadata: name: <project_name> spec: description: <description_of_project> sharedResources: true
- Create a project role binding to assign roles to users or groups within a created project.
kubectl create -f projectrolebinding.yaml
The following exampleprojectrolebinding.yaml
file adds a user with the admin project role. Project role values are: admin, view, or edit.apiVersion: authorization.cci.vmware.com/v1alpha1 kind: ProjectRoleBinding metadata: name: cci:user:vmware.com:<user_alias> namespace: <project_name> roleRef: apiGroup: authorization.cci.vmware.com kind: ProjectRole name: admin subjects: - kind: User name: <[email protected]>
Step 2: Create a region
You create a region so that you can assign Supervisors to that region.
kubectl create -f region.yaml
region.yaml
file.
apiVersion: topology.cci.vmware.com/v1alpha1 kind: Region metadata: name: <region_name> spec: description: <description_of_region>
Step 3: Associate a Supervisor with a region
To associate a Supervisor with a region, you find the Supervisor that you want to update then add the region and labels that will be used for namespace placement.
- To find the Supervisor that you want to update, list the supervisors. Supervisor resources are visible after vCenter data-collection.
kubectl -n cci-config get supervisors
The following is an example result.NAME AGE demo-self-service:domain-c50 75d adminannie-vcenter:domain-c8 5d18h scale-test-vc-01:domain-c8 56d
- Update the Supervisor named
adminannie-vcenter:domain-c8
.kubectl -n cci-config edit supervisor adminannie-vc:domain-c8
The following example includesmetadata.labels
key-value pairs and regionsspec.regionNames
. The labels environment: testing and fipsMode: strict can be used to help with supervisor placement decisions.apiVersion: infrastructure.cci.vmware.com/v1alpha1 kind: Supervisor metadata: labels: environment: testing fipsMode: strict name: adminannie-vc:domain-c8 namespace: cci-config uid: ccd3d154-6404-47b7-8786-bb2d49ad9f5d spec: cloudAccountName: adminannie-vc externalId: domain-c8 externalName: wcp-test-dc-cluster regionNames: - <region_name>
- Or click the Supervisor Regions tab for a project located at
Step 4: Create a region binding and region binding config
You create a region binding and region binding config so that users in a project can create Supervisor Namespaces on Supervisors in a region.
- Create a region binding.
kubectl create -f regionbinding.yaml
Exampleregionbinding.yaml
file.apiVersion: topology.cci.vmware.com/v1alpha1 kind: RegionBinding metadata: name: <region_name> namespace: <project_name>
A region binding does not include any Supervisor placement settings, so you must also create a Region Binding Config.
- Create a Region Binding Config for every region binding created. You can include match expressions that are used for additional filtering of Supervisors. Supervisor labels are used to allow Supervisor Namespace placement on a subset of the Supervisors in a region.
kubectl create -f regionbindingconfig.yaml
In the following exampleregionbindingconfig.yaml
file, any supervisors that match the testing environment label can host the Supervisor Namespaces created in that project and region.apiVersion: topology.cci.vmware.com/v1alpha1 kind: RegionBindingConfig metadata: name: <region_name> namespace: <project_name> spec: supervisorSelector: matchExpressions: - key: environment operator: In values: - testing
Step 5: Create a Supervisor Namespace Class and add a Supervisor Namespace Class config
To define namespace templates with optional parameters that can be used to customize the namespace settings during creation, you create a Supervisor Namespace Class. Then you can create a Supervisor Namespace Class Config with match expressions that are used for additional filtering of Supervisors that are used for Supervisor Namespace placement.
- Create a Supervisor Namespace Class.
kubectl create -f supervisornamespaceclass.yaml
In the following examplesupervisornamespaceclass.yaml
file, the optional input underparameters
reflect Namespace Class parameters that users provide when creating the namespace. All input must have default values. The values are used to customize the storage classes, limits, and additional constraints.apiVersion: infrastructure.cci.vmware.com/v1alpha1 kind: SupervisorNamespaceClass metadata: name: <class_name> spec: description: supervisor namespace class parameters: - name: podCountLimit type: Integer minimum: 100 maximum: 1000 default: 500
The Supervisor Namespace Class does not contain any Supervisor placement settings, so you must also create a Supervisor Namespace Class Config.
- Create a Supervisor Namespace Class Config.
kubectl create -f supervisornamespaceclassconfig.yaml
The YAML is configured with all the supervisor namespace configurations that you want the supervisor namespace to inherit and can include:- Content libraries that contain the images the VM Service uses when provisioning Virtual Machines.
- Virtual Machine Classes such as T-Shirt Sizes.
- CPU, Memory and Storage enforced Resource Limits.
- Storage Classes to use.
- SupervisorSelector to decide which supervisor to use for supervisor namespace creation.
In the following examplesupervisornamespaceclassconfig.yaml
file, thesupervisorSelector
is used to match supervisor labels.apiVersion: infrastructure.cci.vmware.com/v1alpha1 kind: SupervisorNamespaceClassConfig metadata: name: <class_name> spec: storageClasses: - name: management-storage-policy-thin vmClasses: - name: big-vm-class - name: small-vm-class contentSources: - name: global-content-library type: ContentLibrary # Below limits are an EXAMPLE! Setting them may cause unexpected behavior in your namespace # Either set reasonable limits, or remove the below section to get unlimited resources limits: - name: pod_count limit: "((parameters.podCountLimit))" supervisorSelector: matchExpressions: - key: environment operator: In values: - testing
Step 6: Associate a Namespace Class with a project
To allow the creation of a Supervisor Namespace using the Supervisor Namespace Class in a project, you create a Supervisor Namespace Class Binding.
kubectl create -f supervisornamespaceclassbinding.yaml
supervisornamespaceclassbinding.yaml
file.
namespace
specifies the name of the project name that you want to associate with the Supervisor Namespace Class.overrideParameters
are optional. They are used to force a parameter value while ignoring the user provided parameter values when the Supervisor Namespace is created. Valid types are Integer, String, or Boolean.
apiVersion: infrastructure.cci.vmware.com/v1alpha1 kind: SupervisorNamespaceClassBinding metadata: name: <class_name> namespace: <project_name> spec: overrideParameters: - name: podCountLimit type: Integer const: 1000