April 25, 2024

Aria Automation April 2024 (8.17.0) - Cloud Consumption Interface (CCI) Template Elements

In the March 2024 (8.16.2) release, we did a blog announcing the Cloud Consumption Interface (CCI), powered by Aria Automation within VMware Cloud Foundation (VCF), is available on-premises for our customers to provide a simple and secure self-service consumption of all the Kubernetes-based, desired state IaaS APIs available in the vSphere platform enabling customers to develop, deploy and manage Modern Applications with increased agility, flexibility and modern techniques on vSphere while maintaining control of their vSphere infrastructure.

In this April 2024 (8.17.0) release, we are extending the Cloud Consumption Interface to Aria Automation Templates by introducing new CCI Template Elements that you can drag, drop, and configure. This allows Administrators to use the CCI service within a template to create and orchestrate Kubernetes-based workloads using the VM Service and the TKG Service within a Supervisor Namespace.

These IaC YAML-based templates can then be version-controlled, released, and made available for project members like developers, data scientists, or non-coding users to request Kubernetes-based workloads for self-service to help develop, manage, and run modern applications on vSphere with governance through various policies such as leasing and approval policies.

Below is a template example for deploying a modern online store open-source application called Open Cart using the new CCI Template Elements types.


 

How it works

Assuming you already configured the Cloud Consumption Interface based on our official documentation, There are Three CCI Template Element types available now for use within a template that you can drag, drop and configure in the following order:

  1. Supervisor Namespace

This is used to create a new Supervisor Namespace, which provides a Kubernetes-based workspace with resource limits, user access, and available Supervisor services so we can provision our VM and TKG resources based on our application needs.

The Supervisor Namespace is governed by a project-defined Supervisor Namespace Class and a Region for accessibility set by the cloud administrator, so it is configured and provisioned on a targeted Supervisor when requested.

To quickly locate the Cloud Consumption Elements in the resource library when creating a template, we can search for “CCI” as the resource type, drag and drop the Supervisor Namespace Element to the canvas and provide the needed property values such as the name of the Supervisor Namespace, the Supervisor Namespace Class and the Region Name. 

Note: When dragging and dropping an element, you can always rename the default auto-generated resource name, CCI_Supervisor_Namespace_1, to something shorter or simpler, like Namespace.


Of course, it's super easy to create inputs and use input bind expressions, so the requester can pass these values by typing them or selecting them from a pre-defined drop-down menu within the request form.

Note that the values are the same as those used to create a Supervisor Namespace from the CCI UI or CLI.

  1. Supervisor Resource

This is used to create any supported Supervisor K8s resource within a Supervisor Namespace, such as (using their K8s object kind), virtualmachines, virtualmachineservices, tanzukubernetesclusters, persistentvolumeclaims, secrets, and so on, depending on the K8s manifest we pass to the Supervisor resource we are configuring.

You can drag and drop the Supervisor resource Element to the canvas and provide the needed property values, such as context and manifest properties. While you can add other optional properties, we will focus on the mandatory ones.

The context property value would be the ID of the Supervisor Namespace we configured in the previous step using bind expression ${resource.CCI_Supervisor_Namespace_1.id}, which means to pass the ID of the Supervisor Namespace when it is created so the Supervisor resource we want to provision can be created within the Supervisor Namespace.

The manifest property value determines what type of object we want to provision based on the k8s manifest we pass to it. We will pass the K8s manifest to create a TKG Cluster using the new ClusterClass API cluster type for our blog demo example

You are now lost in thought, gazing into the distance, your eyes reflecting the faint glimmer of curiosity as you quietly ponder. You are asking yourself if the Cloud Consumption Interface powered by Aria Automation can generate the TKG Cluster K8s manifest for you. Well, you are in luck, because IT CAN!!

Our previous announcement blog described how users could use the CCI UI to create Virtual Machines and TKG Clusters within a Supervisor Namespace. Therefore, we can create or use an existing Supervisor Namespace in Service Broker by navigating to Consume -> Supervisor Namespace, clicking Open on the Tanzu Kubernetes Grid Service Tile within a Supervisor Namespace and clicking + CREATE.


Once you select your options through the workflow, you can copy or download the generated K8s manifest from the UI and paste it into your template within the Supervisor resource Element, as shown below.


Again, creating inputs and using input bind expressions to make the request form more dynamic is super easy. The requester can pass these values by typing or selecting them from a predefined drop-down menu.

For example, the requestor can provide the desired cluster name, number of control planes and worker nodes of the TKG Cluster, Kubernetes version, etc. The administrator can expose anything in the manifest to the user if they want to provide options for the user to choose from.

  1. TKG Resource

This is used to create any supported K8s resource within a TKG Cluster. There are many upstream K8s resources, so we will not describe or list them here. Again, just like the Supervisor resource element previously, it depends on the K8s manifest we pass to the TKG resource we are configuring.

You can drag and drop the TKG Resource Element to the canvas and provide the needed property values, such as context and manifest properties. While you can add other optional properties, we will focus on the mandatory ones.

The context property value would be the ID of the Supervisor resource we configured in the previous step using bind expression ${resource.CCI_Supervisor_Resource_1.id}, which means to pass the ID of the Supervisor resource, i.e. the TKG Cluster ID, when it is created so the TKG resource we want to provision can be created within the TKG Cluster.

The manifest property value determines what type of object we want to provision based on the K8s manifest we pass to it. We will pass a K8s manifest to create a simple K8s Namespace on the provisioned TKG Cluster for our blog demo.


This IaC YAML-based template can now be version-controlled, released, and made available for project members like developers, data scientists, or non-coding users to request a catalog item that can create a TKG Cluster of certain configurations. Then, create a K8s Namespace called demo-ns on the provisioned TKG Cluster.

Of course, depending on your modern application needs, you can create many more K8s objects, such as deployments, replicasets, secrets, and services within the demo-ns Namespace, by setting the context of the subsequent TKG Resources elements to point it to the Namespace ID using bind expression  ${resource.CCI_TKG_Resource_1.id} as the value.

This allows you to provision Kubernetes-based workloads for self-service requests to help develop, manage, and run modern applications on vSphere with governance through various policies, such as leasing and approval policies.

Blog Demo Template Sample

formatVersion: 1
inputs: {}
resources:
  CCI_Supervisor_Namespace_1:
    type: CCI.Supervisor.Namespace
    properties:
      name: demo
      className: moad-default
      regionName: tmm-us-west
  CCI_Supervisor_Resource_1:
    type: CCI.Supervisor.Resource
    properties:
      context: ${resource.CCI_Supervisor_Namespace_1.id}
      manifest:
        apiVersion: cluster.x-k8s.io/v1beta1
        kind: Cluster
        metadata:
          name: tkg-cluster-demo
          labels:
            tkg-cluster-selector: tkg-cluster-demo
        spec:
          clusterNetwork:
            pods:
              cidrBlocks:
                - 192.168.156.0/20
            services:
              cidrBlocks:
                - 10.96.0.0/12
            serviceDomain: cluster.local
          topology:
            class: tanzukubernetescluster
            version: v1.26.5---vmware.2-fips.1-tkg.1
            variables:
              - name: vmClass
                value: guaranteed-xsmall
              - name: storageClass
                value: tmm-kubernetes-storage-policy
            controlPlane:
              replicas: 1
            workers:
              machineDeployments:
                - class: node-pool
                  name: tkg-cluster-demo-nodepool
                  replicas: 1
  CCI_TKG_Resource_1:
    type: CCI.TKG.Resource
    properties:
      context: ${resource.CCI_Supervisor_Resource_1.id}
      manifest:
        apiVersion: v1
        kind: Namespace
        metadata:
          name: demo-ns

One last thing I will leave you with before we close that will demonstrate the power of this capability. We recently announced the initial availability of Private AI Automation Services for Nvidia, allowing Administrators to easily publish AI-based catalog items to their developers and data scientists without writing a single line of code using the Catalog Setup Wizard within Aria Automation. The two catalog items are:

  • AI Workstation - A GPU-enabled Deep Learning VM that can be configured with the desired vCPU, vGPU, Memory, and AI/ML NGC containers from NVIDIA.
  • AI Kubernetes Cluster - A GPU-enabled Tanzu Kubernetes cluster automatically configured with NVIDIA GPU operator.

These AI-based catalog items are curated using the Cloud Consumption Interface (CCI) Template Elements.

 

Demo

 

 

Summary

Cloud Consumption Interface (CCI) Template Elements helps our customers to easily curate K8s-based Services and Modern Applications Catalog items for their users, providing a simple and secure self-service cloud experience to consume all the Kubernetes-based, desired state IaaS APIs available in the vSphere platform, enabling customers everywhere using VMware Cloud foundation (VCF) to develop, deploy and manage Modern Applications with increased agility, flexibility and modern techniques on vSphere while maintaining control of their vSphere infrastructure.

Please visit our release notes page for more information about VMware Aria Automation 8.17.0 release.

Learn More:

Filter Tags

Automation Modern Applications Kubernetes Supervisor Tanzu Kubernetes Grid Blog Announcement Deep Dive Feature Walkthrough What's New Intermediate

Maher AlAsfar

Read More from the Author

Senior Technical Marketing Architect VCF Division at VMware by Broadcom. VMware Aria Automation