Lesen Sie diese Anweisungen, um einen TKG-Cluster basierend auf einer benutzerdefinierten ClusterClass bereitzustellen. Beachten Sie, dass diese Anweisungen spezifisch für vSphere 8 U1-Umgebungen gelten.

Voraussetzungen

Das Verfahren für die Bereitstellung eines TKG-Clusters basierend auf einer benutzerdefinierten ClusterClass ist ab Version vSphere 8 U1 verfügbar. Wenn Sie vSphere 8 U2 verwenden, finden Sie weitere Informationen unter v1beta1-Beispiel: Cluster basierend auf einer benutzerdefinierten ClusterClass (vSphere 8 U2- und höherer Workflow).

Beachten Sie die folgenden Voraussetzungen.
  • vSphere 8 U1-Umgebung
  • Arbeitslastverwaltung aktiviert
  • Supervisor konfiguriert
  • Ubuntu-Client mit installierten Kubernetes-CLI-Tools für vSphere
Achtung: Die benutzerdefinierte ClusterClass ist eine experimentelle Kubernetes-Funktion gemäß der Upstream-Cluster-API- Dokumentation. Aufgrund der im Zusammenhang mit der benutzerdefinierten ClusterClass verfügbaren Bandbreite an Anpassungen kann VMware nicht alle möglichen Anpassungen testen oder validieren. Die Kunden sind für das Testen, Validieren und Beheben von Fehlern ihrer benutzerdefinierten ClusterClass-Cluster verantwortlich. Sie können Support-Tickets für ihre benutzerdefinierten ClusterClass-Cluster öffnen. VMware Support beschränkt sich jedoch auf eine Unterstützung nach bestem Wissen und kann nicht garantieren, dass alle Probleme behoben werden, die bei benutzerdefinierten ClusterClass-Clustern auftreten. Die Kunden sollten sich diese Risiken bewusst machen, bevor sie benutzerdefinierte ClusterClass-Cluster in Produktionsumgebungen bereitstellen.

Teil 1: Erstellen der benutzerdefinierten ClusterClass

Der erste Teil umfasst das Erstellen einer benutzerdefinierten ClusterClass, indem Sie die standardmäßige ClusterClass mit dem Namen tanzukubernetescluster klonen.
  1. Erstellen Sie einen vSphere-Namespace mit dem Namen custom-ns.
  2. Melden Sie sich bei Supervisor an.
  3. Führen Sie einen Kontextwechsel zum vSphere-Namespace mit dem Namen custom-ns durch.
  4. Rufen Sie die standardmäßige ClusterClass ab.
    kubectl get clusterclass tanzukubernetescluster -o json
  5. Erstellen Sie eine benutzerdefinierte ClusterClass mit dem Namen custom-cc, indem Sie die standardmäßige ClusterClass klonen.
    kubectl get clusterclass tanzukubernetescluster -o json | jq '.metadata.name="custom-cc"' | kubectl apply -f -
    Erwartetes Ergebnis: 
    clusterclass.cluster.x-k8s.io/custom-cc created
  6. Rufen Sie die benutzerdefinierte ClusterClass ab.
    kubectl get clusterclass custom-cc -o json

    Bei Bedarf können Sie „less“ verwenden, um die benutzerdefinierte ClusterClass anzuzeigen.

    kubectl get clusterclass custom-cc -o json | less
    Hinweis: Führen Sie den Befehl „q“ aus, um „less“ zu beenden.

Teil 2: Erstellen erforderlicher Supervisor-Objekte für die Bereitstellung des TKG-Clusters

Im nächsten Teil geht es um die Erstellung der Supervisor-Objekte, die für die anfängliche Bereitstellung eines benutzerdefinierten TKG-Clusters mithilfe der benutzerdefinierten ClusterClass erforderlich sind.
Hinweis: Standardmäßig wird der Clustername „ccc-cluster“ verwendet. Falls Sie einen anderen Clusternamen verwenden, müssen Sie die entsprechenden Felder ändern.
  1. Erstellen Sie den Aussteller für das selbstsignierte Erweiterungszertifikat.
    #self-signed-extensions-issuer.yaml
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: self-signed-extensions-issuer
spec:
  selfSigned: {}
    kubectl apply -f self-signed-extensions-issuer.yaml -n custom-ns
    Erwartetes Ergebnis: 
    issuer.cert-manager.io/self-signed-extensions-issuer created
  2. Erstellen Sie den geheimen Schlüssel für das CA-Zertifikat für Erweiterungen.
    #extensions-ca-certificate.yaml
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: ccc-cluster-extensions-ca
spec:
  commonName: kubernetes-extensions
  duration: 87600h0m0s
  isCA: true
  issuerRef:
    kind: Issuer
    name: self-signed-extensions-issuer
  secretName: ccc-cluster-extensions-ca
  usages:
  - digital signature
  - cert sign
  - crl sign
    kubectl apply -f extensions-ca-certificate.yaml -n custom-ns
    Erwartetes Ergebnis: 
    certificate.cert-manager.io/ccc-cluster-extensions-ca created
  3. Erstellen Sie den Aussteller für das CA-Zertifikat für Erweiterungen.
    #extensions-ca-issuer.yaml
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: ccc-cluster-extensions-ca-issuer
spec:
  ca:
    secretName: ccc-cluster-extensions-ca
    kubectl apply -f extensions-ca-issuer.yaml -n custom-ns
    Erwartetes Ergebnis: 
    issuer.cert-manager.io/ccc-cluster-extensions-ca-issuer created
  4. Erstellen Sie den Geheimschlüssel für das Zertifikat des Authentifizierungsdiensts.
    #auth-svc-cert.yaml
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: ccc-cluster-auth-svc-cert
spec:
  commonName: authsvc
  dnsNames:
  - authsvc
  - localhost
  - 127.0.0.1
  duration: 87600h0m0s
  issuerRef:
    kind: Issuer
    name: ccc-cluster-extensions-ca-issuer
  secretName: ccc-cluster-auth-svc-cert
  usages:
  - server auth
  - digital signature
    kubectl apply -f auth-svc-cert.yaml -n custom-ns
    Erwartetes Ergebnis: 
    certificate.cert-manager.io/ccc-cluster-auth-svc-cert created
  5. Überprüfen Sie die Erstellung der Aussteller und Zertifikate.
    kubectl get issuers -n custom-ns
NAME                               READY   AGE
ccc-cluster-extensions-ca-issuer   True    2m57s
self-signed-extensions-issuer      True    14m

    kubectl get certs -n custom-ns
NAME                        READY   SECRET                      AGE
ccc-cluster-auth-svc-cert   True    ccc-cluster-auth-svc-cert   34s
ccc-cluster-extensions-ca   True    ccc-cluster-extensions-ca   5m

Teil 3: Erstellen eines TKG-Clusters basierend auf der benutzerdefinierten ClusterClass

Sie verwenden die v1beta1-API des Clusters, um einen Cluster basierend auf einer ClusterClass zu erstellen. Ein v1beta1-Cluster, der auf einer benutzerdefinierten ClusterClass basiert, erfordert das folgende Minimum an Variablen:
Variable Beschreibung
vmClass Weitere Informationen hierzu finden Sie unter Verwenden von VM-Klassen mit TKG-Dienstclustern.
storageClass Weitere Informationen hierzu finden Sie unter Konfigurieren eines dauerhaften Speichers für den vSphere-Namespace.
ntp NTP-Server, der zum Aktivieren von Supervisor verwendet wird.
extensionCert Wird automatisch generiert, nachdem das „Erweiterungs-CA-Zertifikat“ im vorherigen Abschnitt erstellt wurde.
clusterEncryptionConfigYaml Im Abschnitt unten wird der Vorgang zum Abrufen dieser Datei Schritt für Schritt erläutert.
  1. Erstellen Sie den geheimen Verschlüsselungsschlüssel.
    #encryption-secret.yaml
apiVersion: v1
data:
  key: all3dzZpODFmRmh6MVlJbUtQQktuN2ViQzREbDBQRHlxVk8yYXRxTW9QQT0=
kind: Secret
metadata:
  name: ccc-cluster-encryption
type: Opaque
    kubectl apply -f encryption-secret.yaml -n custom-ns
    Erwartetes Ergebnis: 
    secret/ccc-cluster-encryption created
  2. Erfassen Sie den NTP-Server aus Supervisor.
    kubectl -n vmware-system-vmop get configmap vmoperator-network-config -o jsonpath={.data.ntpservers}
  3. Erstellen Sie das cluster-with-ccc.yaml-Manifest, um den Cluster bereitzustellen.
    #cluster-with-ccc.yaml
apiVersion: cluster.x-k8s.io/v1beta1
kind: Cluster
metadata:
  name: ccc-cluster
spec:
  clusterNetwork:
    pods:
      cidrBlocks:
      - 193.0.0.0/16
    serviceDomain: managedcluster1.local
    services:
      cidrBlocks:
      - 198.201.0.0/16
  topology:
    class: custom-cc
    version: v1.26.5---vmware.2-fips.1-tkg.1
    controlPlane:
      metadata: {}
      replicas: 3
    workers:
      machineDeployments:
        - class: node-pool
          metadata: { }
          name: node-pool-workers
          replicas: 3
    variables:
    - name: vmClass
      value: guaranteed-medium
    - name: storageClass
      value: tkg-storage-profile
    - name: ntp
      value: time.acme.com
    - name: extensionCert
      value:
        contentSecret:
          key: tls.crt
          name: ccc-cluster-extensions-ca
    - name: clusterEncryptionConfigYaml
      value: LS0tCm...Ht9Cg==
    Überprüfen oder aktualisieren Sie im Cluster-Manifest die folgenden Felder:
    Parameter Beschreibung
    metadata.name Name des v1beta1-Clusters.
    spec.topology.class Name der benutzerdefinierten ClusterClass.
    spec.topology.version Tanzu Kubernetes-Version-Version
    spec.topology.variables.storageClass.value Speicherrichtlinie, die an den vSphere-Namespace angehängt ist, in dem der Cluster bereitgestellt wird
    spec.topology.variables.ntp.value NTP-Serveradresse
    spec.topology.variables.extensionCert.value.contentSecret.name Überprüfen
    spec.topology.variables.clusterEncryptionConfigYaml.value Füllen Sie dieses Feld mit dem data.key-Wert aus dem geheimen ClusterEncryptionConfig-Schlüssel auf.
  4. Erstellen Sie den Cluster basierend auf der benutzerdefinierten ClusterClass.
    kubectl apply -f cluster-with-ccc.yaml -n custom-ns
    Erwartetes Ergebnis: 
    cluster.cluster.x-k8s.io/ccc-cluster created

    Stellen Sie mithilfe des vSphere Clients sicher, dass der Cluster erstellt wurde.

  5. Melden Sie sich beim TKG-Cluster an.
    kubectl vsphere login --server=xxx.xxx.xxx.xxx --vsphere-username [email protected] --tanzu-kubernetes-cluster-name ccc-cluster --tanzu-kubernetes-cluster-namespace custom-ns

Teil 4: Erstellen erforderlicher Supervisor-Objekte zum Verwalten des TKG-Clusters

Sobald der Cluster mit CCC angewendet wurde, versuchen verschiedene Controller, ihn bereitzustellen. Die zugrunde liegenden Infrastrukturressourcen erfordern jedoch weiterhin ein ordnungsgemäßes Bootstrapping zusätzlicher Objekte.
Parameter Wert
Authentifizierung Authentifizierungswerte müssen erfasst und in einer Datei mit dem Namen „values.yaml“ aktualisiert werden
Base64-verschlüsselt Die values.yaml-Datei wird in eine base64-Zeichenfolge codiert.
guest-cluster-auth-service-data-values.yaml Diese Zeichenfolge wird der guest-cluster-auth-service-data-values.yaml-Datei hinzugefügt, die vor der Anwendung der Datei aus CCC_config_yamls.tar.gz heruntergeladen wurde.
Geheimer GuestClusterAuthSvcDataValues-Schlüssel Schließlich muss das Gastcluster-Bootstrap so geändert werden, dass es auf den neu erstellten geheimen GuestClusterAuthSvcDataValues-Schlüssel verweist.
  1. Wechseln Sie den Kontext zum vSphere-Namespace, in dem der Cluster bereitgestellt wird.
    kubectl config use-context custom-ns
  2. Rufen Sie den Wert von authServicePublicKeys ab.
    kubectl -n vmware-system-capw get configmap vc-public-keys -o jsonpath="{.data.vsphere\.local\.json}"
    Kopieren Sie das Ergebnis in eine Textdatei mit dem Namen values.yaml. 
    authServicePublicKeys: '{"issuer_url":"https://...SShrDw=="]}]}}'
  3. Rufen Sie die Cluster-UID ab, um authServicePublicKeys zu aktualisieren.
    kubectl get cluster -n custom-ns ccc-cluster -o yaml | grep uid
  4. Hängen Sie im Abschnitt authServicePublicKeys der values.yaml-Datei die Cluster-UID an den Wert „client_id“ an.

    Syntax: vmware-tes:vc:vns:k8s:clusterUID

    Beispiel: 
    vmware-tes:vc:vns:k8s:7d95b50b-4fd4-4642-82a3-5dbfe87f499c
  5. Rufen Sie den Zertifikatswert ab (ersetzen Sie ccc-cluster durch den ausgewählten Clusternamen).
    kubectl -n custom-ns get secret ccc-cluster-auth-svc-cert -o jsonpath="{.data.tls\.crt}" | base64 -d
  6. Fügen Sie das Zertifikat in der Datei values.yaml hinzu.

    Fügen Sie den Zertifikatsinhalt unterhalb des Abschnitts authServicePublicKeys hinzu.

    Hinweis: Das Zertifikat muss zur Vermeidung von Fehlern um 4 Leerzeichen eingerückt werden.
    Beispiel: 
    authServicePublicKeys: '{"issuer_url":"https://...SShrDw=="]}]}}'
ceritificate: |
    -----BEGIN CERTIFICATE-----
    MIIDPTCCAiWgAwIBAgIQMibGSjeuJelQoPxCof/+xzANBgkqhkiG9w0BAQsFADAg
    ...
    sESk/RDTB1UAvi8PD3zcbEKZuRxuo4IAJqFFbAabwULhjUo0UwT+dIJo1gLf5/ep
    VoIRJS7j6VT98WbKyZp5B4I=
    -----END CERTIFICATE-----
  7. Rufen Sie den privateKey-Wert ab.
    kubectl -n custom-ns get secret ccc-cluster-auth-svc-cert -o jsonpath="{.data.tls\.key}"
  8. Überprüfen Sie Ihre values.yaml-Datei.
    authServicePublicKeys: '{"issuer_url":"https://10.197.79.141/openidconnect/vsphere.local","client_id":"vmware-tes:vc:vns:k8s:7d95...499c",...SShrDw=="]}]}}'
certificate: |
    -----BEGIN CERTIFICATE-----
    MIIDPTCCAiWgAwIBAgIQWQyXAQDRMhgrGre8ysVN0DANBgkqhkiG9w0BAQsFADAg
    ...
    uJSBP49sF0nKz5nf7w+BdYE=
    -----END CERTIFICATE-----
privateKey: LS0tLS1CRUdJTi...VktLS0tLQo=
  9. Hashen Sie die values.yaml-Datei mit Base64-Codierung, um die Ausgabe für die guest-cluster-auth-service-data-values.yaml-Datei zu erfassen.
    base64 -i values.yaml -w 0
  10. Erstellen Sie die guest-cluster-auth-service-data-values.yaml-Datei.
    Nachstehend finden Sie eine Vorlage für den geheimen Schlüssel. 
    apiVersion: v1
data:
  values.yaml: YXV0a...ExRbz0K
kind: Secret
metadata:
  labels:
    tkg.tanzu.vmware.com/cluster-name: ccc-cluster
    tkg.tanzu.vmware.com/package-name: guest-cluster-auth-service.tanzu.vmware.com.1.3.0+tkg.2-vmware
  name: ccc-cluster-guest-cluster-auth-service-data-values
type: Opaque
    Informationen zum Auffüllen der erwarteten Werte des geheimen Schlüssels finden Sie in der folgenden Tabelle.
    Parameter Wert
    data.values.yaml

    Base64-codierte Zeichenfolge von values.yaml
    metadata.labels.cluster-name

    Name des Clusters, wie z. B. ccc-cluster
    metadata.labels.package-name

    guest-cluster-auth-service.tanzu.vmware.com.version

    Führen Sie zum Abrufen dieses Werts den folgenden Befehl aus: kubectl get tkr v1.26.5---vmware.2-fips.1-tkg.1 -o yaml

    Ändern Sie die TKR-Version je nach der von Ihnen verwendeten Version
    metadata.name

    Name des Clusters, wie z. B. ccc-cluster
  11. Erstellen Sie den geheimen Schlüssel guest-cluster-auth-service-data-values.yaml.
    kubectl apply -f guest-cluster-auth-service-data-values.yaml -n custom-ns
  12. Bearbeiten Sie das Cluster-Bootstrap so, dass es auf den geheimen Schlüssel verweist.
    kubectl edit clusterbootstrap ccc-cluster -n custom-ns
  13. Fügen Sie die folgenden Zeilen unterhalb der Zeile guest-cluster-auth-service.tanzu.vmware.com.version: hinzu.
    valuesFrom:
  secretRef: ccc-cluster-guest-cluster-auth-service-data-values
    Beispiel: 
    spec:
  additionalPackages:
  - refName: guest-cluster-auth-service.tanzu.vmware.com.1.3.0+tkg.2-vmware
    valuesFrom:
      secretRef: ccc-cluster-guest-cluster-auth-service-data-values
  14. Speichern und beenden Sie, um die clusterbootstrap-Änderungen anzuwenden.

Teil 5: Konfigurieren der Pod-Sicherheit

Wenn Sie die TKR-Version 1.25 oder höhere Versionen verwenden, konfigurieren Sie die Pod-Sicherheit für den vSphere-Namespace mit dem Namen custom-ns. Weitere Informationen hierzu finden Sie unter Konfigurieren von PSA für TKR 1.25 und höher.

Wenn Sie die TKR-Version 1.24 oder frühere Versionen verwenden, müssen Pods im Cluster an die Pod-Sicherheitsrichtlinie gebunden werden. Gehen Sie wie folgt vor, um die erforderlichen Ressourcenobjekte auf Clusterebene anzuwenden.
  1. Erfassen Sie die kubeconfig des TKG-Clusters.
    kubectl -n custom-ns get secret ccc-cluster-kubeconfig -o jsonpath="{.data.value}" | base64 -d > ccc-cluster-kubeconfig
  2. Erstellen Sie die psp.yaml-Datei. 
    apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: tanzu-system-kapp-ctrl-restricted
spec:
  privileged: false
  allowPrivilegeEscalation: false
  requiredDropCapabilities:
    - ALL
  volumes:
    - configMap
    - emptyDir
    - projected
    - secret
    - downwardAPI
    - persistentVolumeClaim
  hostNetwork: false
  hostIPC: false
  hostPID: false
  runAsUser:
    rule: MustRunAsNonRoot
  seLinux:
    rule: RunAsAny
  supplementalGroups:
    rule: MustRunAs
    ranges:
      - min: 1
        max: 65535
  fsGroup:
    rule: MustRunAs
    ranges:
      - min: 1
        max: 65535
  readOnlyRootFilesystem: false
  3. Wenden Sie die Pod-Sicherheitsrichtlinie an.
    KUBECONFIG=ccc-cluster-kubeconfig kubectl apply -f psp.yaml
  4. Melden Sie sich beim TKG-Cluster an.
    kubectl vsphere login --server=10.197.154.66 --vsphere-username [email protected] --insecure-skip-tls-verify --tanzu-kubernetes-cluster-name ccc-cluster --tanzu-kubernetes-cluster-namespace custom-ns
  5. Listen Sie die Namespaces auf.
    KUBECONFIG=ccc-cluster-kubeconfig kubectl get ns -A
    NAME                           STATUS   AGE
default                        Active   13d
kube-node-lease                Active   13d
kube-public                    Active   13d
kube-system                    Active   13d
secretgen-controller           Active   13d
tkg-system                     Active   13d
vmware-system-antrea           Active   13d
vmware-system-cloud-provider   Active   13d
vmware-system-csi              Active   13d
vmware-system-tkg              Active   13d

Teil 6: Synchronisieren vSphere SSO-Rollen mit dem benutzerdefinierten TKG-Cluster

Das RoleBinding für vCenter Single Sign-On-Benutzer, das in die vSphere-Namespaces integriert ist, muss aus Supervisor in den TKG-Cluster synchronisiert werden, damit Entwickler die Cluster-Arbeitslasten verwalten können.

Dieser Vorgang erfordert den Export der vorhandenen RoleBinding-Liste aus Supervisor, das Erfassen von RoleBindings, die die Rolle „Bearbeiten“ aufweisen, das Erstellen der Datei sync-cluster-edit-rolebinding.yaml und das anschließende Anwenden auf den TKG-Cluster mithilfe seiner KUBECONFIG.
  1. Erfassen Sie vorhandene RoleBindings aus Supervisor.
    kubectl get rolebinding -n custom-ns  -o yaml
  2. Identifizieren Sie in der zurückgegebenen Liste der RoleBinding-Objekte diejenigen, deren roleRef.name „edit“ lautet.
    Beispiel: 
    apiVersion: v1
items:
- apiVersion: rbac.authorization.k8s.io/v1
  kind: RoleBinding
  metadata:
    creationTimestamp: "2023-08-25T18:44:45Z"
    name: ccc-cluster-8lr5x-ccm
    namespace: custom-ns
    ownerReferences:
    - apiVersion: vmware.infrastructure.cluster.x-k8s.io/v1beta1
      blockOwnerDeletion: true
      controller: true
      kind: ProviderServiceAccount
      name: ccc-cluster-8lr5x-ccm
      uid: b5fb9f01-9a55-4f69-8673-fadc49012994
    resourceVersion: "108766602"
    uid: eb93efd4-ae56-4d9f-a745-d2782885e7fb
  roleRef:
    apiGroup: rbac.authorization.k8s.io
    kind: Role
    name: ccc-cluster-8lr5x-ccm
  subjects:
  - kind: ServiceAccount
    name: ccc-cluster-8lr5x-ccm
    namespace: custom-ns
- apiVersion: rbac.authorization.k8s.io/v1
  kind: RoleBinding
  metadata:
    creationTimestamp: "2023-08-25T18:44:45Z"
    name: ccc-cluster-8lr5x-pvcsi
    namespace: custom-ns
    ownerReferences:
    - apiVersion: vmware.infrastructure.cluster.x-k8s.io/v1beta1
      blockOwnerDeletion: true
      controller: true
      kind: ProviderServiceAccount
      name: ccc-cluster-8lr5x-pvcsi
      uid: d9342f8f-13d2-496d-93cb-b24edfacb5c1
    resourceVersion: "108766608"
    uid: fd1820c7-7993-4299-abb7-bb67fb17f1fd
  roleRef:
    apiGroup: rbac.authorization.k8s.io
    kind: Role
    name: ccc-cluster-8lr5x-pvcsi
  subjects:
  - kind: ServiceAccount
    name: ccc-cluster-8lr5x-pvcsi
    namespace: custom-ns
- apiVersion: rbac.authorization.k8s.io/v1
  kind: RoleBinding
  metadata:
    creationTimestamp: "2023-08-25T16:58:06Z"
    labels:
      managedBy: vSphere
    name: wcp:custom-ns:group:vsphere.local:administrators
    namespace: custom-ns
    resourceVersion: "108714148"
    uid: d74a98c7-e7da-4d71-b1d5-deb60492d429
  roleRef:
    apiGroup: rbac.authorization.k8s.io
    kind: ClusterRole
    name: edit
  subjects:
  - apiGroup: rbac.authorization.k8s.io
    kind: Group
    name: sso:[email protected]
- apiVersion: rbac.authorization.k8s.io/v1
  kind: RoleBinding
  metadata:
    creationTimestamp: "2023-08-25T16:58:21Z"
    labels:
      managedBy: vSphere
    name: wcp:custom-ns:user:vsphere.local:administrator
    namespace: custom-ns
    resourceVersion: "108714283"
    uid: 07f7dbba-2670-4100-a59b-c09e4b2edd6b
  roleRef:
    apiGroup: rbac.authorization.k8s.io
    kind: ClusterRole
    name: edit
  subjects:
  - apiGroup: rbac.authorization.k8s.io
    kind: User
    name: sso:[email protected]
kind: List
metadata:
  resourceVersion: ""
  3. Erstellen Sie eine Datei mit dem Namen sync-cluster-edit-rolebinding.yaml, um gegebenenfalls zusätzlich zu [email protected] vorliegende RoleBindings hinzuzufügen. Beispiel:
    apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  labels:
    run.tanzu.vmware.com/vmware-system-synced-from-supervisor: "yes"
  name: vmware-system-auth-sync-wcp:custom-ns:group:vsphere.local:administrators
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: sso:[email protected]
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  labels:
    run.tanzu.vmware.com/vmware-system-synced-from-supervisor: "yes"
  name: vmware-system-auth-sync-wcp:custom-ns:group:SSODOMAIN.COM:testuser
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: sso:[email protected]
    Hinweis: Im Feld metadata.name wird für alle Benutzer der Benutzerrolle vmware-system-auth-sync- vorangestellt. Die metadata.name- und subjects.name-Einträge müssen für alle nicht standardmäßigen Rollen geändert werden.
  4. Wenden Sie die sync-cluster-edit-rolebinding.yaml-Konfiguration an, um Rollenbindungen zu synchronisieren.
    KUBECONFIG=ccc-cluster-kubeconfig kubectl apply -f sync-cluster-edit-rolebinding.yaml