Verwenden der CCI-Elemente in VMware Aria Automation-Vorlagen

Sie können CCI-Elemente (Cloud Consumption Interface) hinzufügen, um den CCI-Dienst innerhalb einer VMware Aria Automation-Vorlage zu verwenden, sodass Ihre Benutzer Kubernetes-basierte Arbeitslasten mithilfe des VM-Diensts und des Tanzu Kubernetes Grid Service innerhalb eines Supervisor-Namespace anfordern können.

Um die CCI-Elemente anzuzeigen, erweitern Sie den Abschnitt Cloud Consumption Interface innerhalb der Ressourcenbibliothek in Ihrer Cloud-Vorlage oder geben Sie cci in das Feld Ressourcentypen durchsuchen ein.

Lokalisieren Sie die CCI-Elemente in Ihrer Cloud-Vorlage

Die folgende Tabelle zeigt die drei Typen von CCI-Ressourcen, die in der Vorlage für Benutzer zum Ziehen, Ablegen und Konfigurieren verfügbar sind.

Supervisor-Namespace-Ressource `CCI.Supervisor.Namespace`	Erstellen Sie einen neuen Supervisor-Namespace, der einen Kubernetes-basierten Arbeitsbereich mit Ressourcengrenzwerten, Benutzerzugriff und verfügbaren Supervisor-Diensten bereitstellt, sodass Benutzer VM- und TKG-Ressourcen basierend auf Anwendungsanforderungen bereitstellen können.
Supervisor-Ressource `CCI.Supervisor.Resource`	Erstellen Sie beliebige unterstützte Supervisor-Kubernetes-Ressourcen innerhalb eines Supervisor-Namespace, z. B. `virtualmachines`, `virtualmachineservices`, `tanzukubernetesclusters`, `persistentvolumeclaims`, `secrets` usw., je nach dem Kubernetes-Manifest, das an die zum gegebenen Zeitpunkt konfigurierte Supervisor-Ressource übergeben wird.
TKG-Ressource `CCI.TKG.Resource`	Erstellen Sie beliebige unterstützte Kubernetes-Ressourcen innerhalb eines TKG-Clusters.

Hinweis: Bevor Sie CCI-Elemente zu Ihrer Cloud-Vorlage hinzufügen können, muss ein VMware Aria Automation-Administrator zuerst CCI einrichten. Weitere Informationen hierzu finden Sie unter Einrichtung und Konfiguration der Cloud Consumption Interface.

Die folgenden Beispiele zeigen, wie die CCI-Ressourcen im YAML-Code Ihrer Cloud-Vorlage angezeigt werden. Jedes Beispiel ist so beschnitten, dass nur die wichtigen Zeilen angezeigt werden.

Beispiel für eine Supervisor-Namespace-Ressource

CCI.Supervisor.Namespace stellt den Supervisor-Kubernetes-basierten Arbeitsbereich dar, in dem die vom Benutzer verwalteten vSphere Supervisor-IaaS-Ressourcen für die Anwendung erstellt werden.

In diesem Beispiel wird eine CCI-Supervisor-Namespace-Ressource mit dem Namen cciNamespace definiert, um einen Supervisor-Namespace namens demo bereitzustellen.

Um sicherzustellen, dass der Namespace auf einem zielseitigen Supervisor bereitgestellt wird, müssen Sie den Supervisor-Namespace mit einem projektdefinierten className und regionName konfigurieren.

formatVersion: 1
inputs: {}
resources:
  cciNamespace:
    type: CCI.Supervisor.Namespace
    properties:
      name: demo
      className: default
      regionName: dev-us-west

Beispiel für eine Supervisor-Ressource

Sie verwenden CCI.Supervisor.Resource, um das Kubernetes-Manifest für Kubernetes-Objekte zu übergeben, die für die Ausführung innerhalb eines Supervisor-Namespace-Kontexts unterstützt werden.

Um die Supervisor-Ressource in einem bestimmten Supervisor-Namespace bereitzustellen, konfigurieren Sie die Supervisor-Ressourcenkontexteigenschaft, indem Sie sie der Supervisor-Namespace-ID mithilfe eines Vorlagenbindungsausdrucks zuordnen, z. B. context: ${resource.cciNamespace.id}.
Um die bereitzustellenden Objekte anzugeben, konfigurieren Sie die Manifesteigenschaft der Supervisor-Ressource, indem Sie das Kubernetes-Manifest an das Kubernetes-Objekt übergeben, das Sie erstellen.

In diesem Beispiel wird ein TKG-Cluster erstellt, indem ein Kubernetes-Manifest bereitgestellt wird, das neben anderen Einstellungen das Netzwerk, die Topologie, die Größe der Steuerungsebene und die Anzahl der Worker-Knoten angibt.

formatVersion: 1
inputs: {}
resources:
  cciTKGCluster:
    type: CCI.Supervisor.Resource
    properties:
      context: ${resource.cciNamespace.id}
      manifest:
        apiVersion: cluster.x-k8s.io/v1beta1
        kind: Cluster
        metadata:
          name: ${input.tkg_Name}
          labels:
            tkg-cluster-selector: ${input.tkg_Name}
        spec:
          clusterNetwork:
            cni:
              name: antrea
            pods:
              cidrBlocks:
                - 192.168.156.0/20
            services:
              cidrBlocks:
                - 10.96.0.0/12
            serviceDomain: cluster.local
          topology:
            class: tanzukubernetescluster
            version: v1.24.9---vmware.1-tkg.4
            variables:
              - name: storageClasses
                value:
                  - tmm-kubernetes-storage-policy
              - name: defaultStorageClass
                value: tmm-kubernetes-storage-policy
              - name: vmClass
                value: ${input.controlPlaneVmClassName}
              - name: storageClass
                value: tmm-kubernetes-storage-policy
            controlPlane:
              replicas: ${input.controlPlaneCount}
              metadata:
                annotations:
                  run.tanzu.vmware.com/resolve-os-image: os-name=photon
            workers:
              machineDeployments:
                - class: node-pool
                  name: ${input.tkg_Name}-nodepool
                  replicas: ${input.workerCount}
                  metadata:
                    annotations:
                      run.tanzu.vmware.com/resolve-os-image: os-name=photon
                  variables:
                    overrides:
                      - name: vmClass
                        value: ${input.workerVmClassName}

In diesem Beispiel wird eine virtuelle Maschine definiert, indem ein Kubernetes-Manifest bereitgestellt wird, das die VM-Konfiguration definiert und eine wartebasierte Bedingung enthält.

formatVersion: 1
inputs: {}
resources:
  vm:
    type: CCI.Supervisor.Resource
    properties:
      context: ${resource.cciNamespace.id}
      manifest:
        apiVersion: vmoperator.vmware.com/v1alpha1
        kind: VirtualMachine
        metadata:
          finalizers:
            - virtualmachine.vmoperator.vmware.com
          generation: 1
          labels:
            vm-selector: vm-2rfx
          name: vm-2rfx
        spec:
          className: best-effort-xsmall
          imageName: vmi-c3d184be88e1af1cd
          networkInterfaces:
            - networkType: nsx-t
          powerOffMode: hard
          powerState: poweredOn
          restartMode: hard
          storageClass: vsan-default-storage-policy
          suspendMode: hard
      wait:
        conditions:
          - type: VirtualMachinePrereqReady
            status: "False"
            reason: VirtualMachineImageNotReady
            indicatesFailure: true

Beispiel für eine TKG-Ressource

Sie verwenden CCI.TKG. Ressource, um unterstützte Kubernetes-Ressourcen innerhalb eines TKG-Clusters oder innerhalb eines Namespace zu erstellen, der auf dem TKG-Cluster ausgeführt wird.

Um eine TKG-Ressource an einen TKG-Cluster zu binden, ordnen Sie die ID der Supervisor-TKG-Clusterressource der Kontexteigenschaft zu, z. B. context: ${resource.cciTKGCluster.id}.
Wenn Sie beispielsweise einen Namespace innerhalb einer TKG-Ressource mit dem Namen cciTKGNamespace erstellen, können Sie eine TKG-Ressource an den Namespace binden, indem Sie den Namen der TKG-Ressource in die Kontexteigenschaft oder context: ${resource.cciTKGNamespace.id} einfügen.
Das Kubernetes-Manifest, das innerhalb der Ressourceneigenschaften übergeben wird, gibt den Typ des bereitzustellenden Kubernetes-Objekts an.

Dieses Beispiel zeigt einen geheimen Schlüssel als TKG-Ressource, die an einen TKG-Cluster mit dem Namen cciTKGCluster gebunden ist.

...
  tkgSecret:
    type: CCI.TKG.Resource
    properties:
      context: ${resource.cciTKGCluster.id}
      manifest:
        apiVersion: v1
        kind: Secret
        metadata:
          name: nvaie-apikey
        type: Opaque
        data:
          username: KM9hdCCodG9rZW4=
          password: ${base64_encode(input.password)}
...

Hinzufügen einer Warteeigenschaft

Sowohl die Supervisor-Ressource als auch die TKG-Ressource unterstützen eine Warteeigenschaft, die auf bestimmte Bedingungen oder Feldwerte innerhalb einer Ressource wartet, bevor die Ressourcenerstellung als abgeschlossen betrachtet wird. Die Typen der Warteeigenschaften sind:

Field Wait: Liste der Felder, in denen jedes Feld mit einem Eigenschaftspfad und einem Wert konfiguriert werden kann. Der Wert muss abgeglichen werden, bevor die Ressource als abgeschlossen betrachtet wird.
Condition Wait: Liste der Bedingungen, die eine erfolgreiche oder fehlgeschlagene Ressourcenerstellung angeben.

Dieses Beispiel zeigt eine Wartebedingung, die zu einer Supervisor-Ressource hinzugefügt wurde. Die Bedingung muss erfüllt sein, bevor die Supervisor-Ressource als abgeschlossen markiert werden kann.

...
    wait:
      fields:
        - path: status.loadBalancer.ingress[0].ip
          value: "*"
...