Cluster in Azure

In diesem Thema werden Möglichkeiten zur Konfiguration von Tanzu Kubernetes Grid (TKG)-Arbeitslastclustern beschrieben, um Microsoft Azure-spezifische Funktionen zu nutzen, die in der flachen Konfigurationsdatei oder der Objektspezifikation im Kubernetes-Stil des Clusters nicht vollständig konfiguriert werden können.

Informationen zum Konfigurieren von Arbeitslastclustern unter Azure mithilfe von Konfigurationsdateien und Objektspezifikationen finden Sie unter Azure-Clusterkonfigurationsdateien.

Wichtig

Tanzu Kubernetes Grid v2.4.x ist die letzte Version von TKG, die die Erstellung von TKG-Arbeitslastclustern in Azure unterstützt. Die Möglichkeit, TKG-Arbeitslastcluster auf Azure zu erstellen, wird in Tanzu Kubernetes Grid v2.5 entfernt.

Ab sofort empfiehlt VMware die Verwendung von Tanzu Mission Control zur Erstellung nativer Azure AKS-Cluster anstelle neuer TKG-Arbeitslastcluster auf Azure. Informationen zum Erstellen nativer Azure AKS-Cluster mit Tanzu Mission Control finden Sie unter Verwalten des Lebenszyklus von Azure AKS-Clustern in der Dokumentation zu Tanzu Mission Control.

Weitere Informationen finden Sie unter Veraltete TKG-Verwaltungs- und -Arbeitslastcluster in AWS und Azure in den Versionshinweisen zu VMware Tanzu Kubernetes Grid v2.4.

Private Azure-Cluster

Bei den Verwaltungs- und Arbeitslastclustern in Azure handelt es sich standardmäßig um öffentliche Cluster. Doch Sie können sie auch als private Cluster konfigurieren. Dies bedeutet, dass ihr API-Server einen internen Lastausgleichsdienst (ILB) in Azure verwendet und dass der Zugriff auf ihn daher nur aus dem eigenen VNet oder Peer-VNets des Clusters möglich ist.

Fügen Sie Folgendes in die Konfigurationsdatei eines Azure-Clusters ein, um ihn als privaten Cluster zu konfigurieren:

  • Legen Sie AZURE_ENABLE_PRIVATE_CLUSTER auf true fest.

  • (Optional) Legen Sie als AZURE_FRONTEND_PRIVATE_IP eine interne Adresse für den Lastausgleichsdienst des Clusters fest.

    • Diese Adresse muss sich innerhalb des Bereichs des Subnetzes seiner Steuerungsebene befinden und darf nicht von einer anderen Komponente verwendet werden.
    • Die Standardadresse lautet 10.0.0.100, sofern keine andere Adresse festgelegt wurde.
  • Legen Sie als Einstellung für AZURE_VNET_NAME, AZURE_VNET_CIDR, AZURE_CONTROL_PLANE_SUBNET_NAME, AZURE_CONTROL_PLANE_SUBNET_CIDR, AZURE_NODE_SUBNET_NAME und AZURE_NODE_SUBNET_CIDR das VNet und die Subnetze fest, die Sie für andere private Azure-Cluster verwenden.

    • Da der Zugriff auf private Azure-Cluster außerhalb ihres VNet nicht möglich ist, müssen sich der Verwaltungscluster und alle von ihm verwalteten Arbeitslastcluster und Shared Service-Cluster in demselben privaten VNet befinden.
    • Die Bootstrap-Maschine, auf der Sie die Tanzu CLI ausführen, um die privaten Cluster zu erstellen und zu verwenden, muss sich ebenfalls in demselben privaten VNet befinden.
  • (Optional) Legen Sie als Einstellung für AZURE_ENABLE_CONTROL_PLANE_OUTBOUND_LB und AZURE_ENABLE_NODE_OUTBOUND_LB den Wert true fest, wenn die Steuerungsebenen- und Worker-Knoten in der Lage sein sollen, über eine Azure-Internetverbindung auf das Internet zuzugreifen.

    • Azure Private Cluster erstellen standardmäßig eine öffentliche IP-Adresse für jeden Kubernetes-Lastausgleichsdienst. Um den Lastausgleichsdienst so zu konfigurieren, dass er stattdessen eine private IP-Adresse verwendet, fügen Sie die folgende Anmerkung zu Ihrem Bereitstellungsmanifest hinzu:

      ---
      metadata:
      annotations:
        service.beta.kubernetes.io/azure-load-balancer-internal: "true"
      

Weitere Informationen finden Sie unter API-Server-Endpoint in der Azure-Dokumentation des Cluster-API-Anbieters.

Cluster in verschiedenen Azure-Konten

Tanzu Kubernetes Grid kann Arbeitslastcluster auf mehreren Konten der Zielplattform ausführen, um beispielsweise die Cloud-Nutzung auf verschiedene Teams aufzuteilen oder unterschiedliche Sicherheitsprofile auf Produktions-, Staging- und Entwicklungsarbeitslasten anzuwenden.

Gehen Sie wie folgt vor, um Arbeitslastcluster für ein alternatives Azure-Dienstprinzipalkonto bereitzustellen, das sich von dem für die Bereitstellung des Verwaltungsclusters verwendeten Konto unterscheidet:

  1. Erstellen Sie das alternative Azure-Konto. Die Details dieses Kontos dienen Ihnen in einem späteren Schritt zum Erstellen einer AzureClusterIdentity. Informationen zum Erstellen eines Azure-Dienstprinzipalkontos finden Sie in der Anleitung: Erstellen einer Azure AD-Anwendung und eines Dienstprinzipals, der auf Ressourcen zugreifen kann, mithilfe des Portals in der Azure-Dokumentation.

  2. Legen Sie den Kontext von kubectl auf Ihren Verwaltungscluster fest:

    kubectl config use-context MY-MGMT-CLUSTER@MY-MGMT-CLUSTER
    

    Dabei ist MY-MGMT-CLUSTER der Name Ihres Verwaltungsclusters.

  3. Erstellen Sie eine secret.yaml-Datei mit den folgenden Inhalten:

    apiVersion: v1
    kind: Secret
    metadata:
      name: SECRET-NAME
    type: Opaque
    data:
      clientSecret: CLIENT-SECRET
    

    Dabei gilt:

    • SECRET-NAME ist der geheime Name für das Clientkennwort.
    • CLIENT-SECRET ist der geheime Clientschlüssel Ihrer Dienstprinzipalidentität. Der geheime Clientschlüssel muss base64-codiert sein.
  4. Verwenden Sie die Datei, um das Secret-Objekt zu erstellen:

    kubectl apply -f secret.yaml
    
  5. Erstellen Sie eine identity.yaml-Datei mit den folgenden Inhalten:

    apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
    kind: AzureClusterIdentity
    metadata:
      name: EXAMPLE-IDENTITY
      namespace: EXAMPLE-NAMESPACE
    spec:
      type: ManualServicePrincipal
      tenantID: AZURE-TENANT-ID
      clientID: CLIENT-ID
      clientSecret: {"name":"SECRET-NAME","namespace":"default"}
      allowedNamespaces:
        list:
        - CLUSTER-NAMESPACE-1
        - CLUSTER-NAMESPACE-1
    

    Dabei gilt:

    • EXAMPLE-IDENTITY ist der Name, der für die AzureClusterIdentity verwendet werden soll.
    • EXAMPLE-NAMESPACE ist der Namespace für Ihre AzureClusterIdentity.
    • AZURE-TENANT-ID ist Ihre Azure-Mandanten-ID.
    • CLIENT-ID ist die Client-ID (auch als AppID bezeichnet) für die Azure AD-Anwendung.
    • SECRET-NAME ist der geheime Name für das Clientkennwort.
    • CLUSTER-NAMESPACE-1 und CLUSTER-NAMESPACE-2 sind Kubernetes-Namespaces, von denen die Cluster Identitäten verwenden dürfen. Diese Namespaces können mithilfe eines Arrays von Namespaces ausgewählt werden.
  6. Verwenden Sie die Datei, um das AzureClusterIdentity-Objekt zu erstellen:

    kubectl apply -f identity.yaml
    

Der Verwaltungscluster kann jetzt Arbeitslastcluster für das alternative Konto mithilfe des neuen AzureClusterIdentity-Objekts bereitstellen.

Um Arbeitslastcluster zu erstellen, die das alternative Azure-Konto verwenden, fügen Sie die folgenden Variablen in der Clusterkonfigurationsdatei hinzu:

AZURE_IDENTITY_NAME: EXAMPLE-IDENTITY
AZURE_IDENTITY_NAMESPACE: EXAMPLE-NAMESPACE

Dabei gilt:

  • EXAMPLE-IDENTITY ist der Name, der für die AzureClusterIdentity verwendet werden soll.
  • EXAMPLE-NAMESPACE ist der Namespace für Ihre AzureClusterIdentity.

Nachdem Sie den Arbeitslastcluster erstellt haben, melden Sie sich mit dem alternativen Konto beim Azure-Portal an. Der Cluster sollte ausgeführt werden.

GPU-fähige Cluster

Für die Bereitstellung von NVIDIA GPU-fähigen Arbeitslastclustern unter Azure gibt es zwei Möglichkeiten:

  • Sie erstellen einen Arbeitslastcluster mit GPU-Workern und installieren manuell eine GPU-Richtlinie und einen Operator im Cluster.
  • (Tech Preview) Konfigurieren des Verwaltungsclusters mit einem ClusterResourceSet (CRS), um automatisch einen oder mehrere GPU-fähige Arbeitslastcluster zu erstellen

In den folgenden Unterabschnitten werden diese beiden Ansätze und das Testen der GPU-fähigen Cluster erläutert.

Bereitstellen und GPU-Aktivierung eines einzelnen Clusters

So stellen Sie einen Arbeitslastcluster bereit und konfigurieren ihn manuell, um die Vorteile der unter Azure verfügbaren NVIDIA GPU-VMs zu nutzen:

  1. Setzen Sie die Konfigurationsdatei für den Cluster AZURE_NODE_MACHINE_TYPE für Worker-Knoten auf eine GPU-kompatiblen VM-Typ wie beispielsweise Standard_NC4as_T4_v3.

  2. Stellen Sie den Cluster mit der Clusterkonfigurationsdatei bereit:

    tanzu cluster create MY-GPU-CLUSTER -f MY-GPU-CONFIG
    

    Dabei ist MY-GPU-CLUSTER ein Name, den Sie dem Cluster geben.

  3. Installieren Sie eine GPU-Clusterrichtlinie und einen GPU-Operator im Cluster:

    1. Legen Sie als Einstellung für kubectl context den Cluster fest, sofern er nicht bereits der aktuelle Kontext ist.

    2. Laden Sie die erforderlichen NVIDIA GPU-Ressourcen aus dem Azure-Repository des Cluster-API-Anbieters herunter und speichern Sie sie in Ihrem aktuellen Verzeichnis:

    3. Wenden Sie die Clusterrichtlinie an:

      kubectl apply clusterpolicy-crd.yaml
      
    4. Wenden Sie den GPU-Operator an:

      kubectl apply gpu-operator-components.yaml
      
  4. Führen Sie kubectl get pods -A aus. Die gpu-operator-Pods sollten im default-Namespace aufgelistet werden und die nvidia-Pods im gpu-operator-resources-Namespace.

Konfigurieren des Verwaltungsclusters für GPU-Clusterbereitstellungen (Tech Preview)

Hinweis

Diese Funktion befindet sich im nicht unterstützten Tech Preview-Zustand. Weitere Informationen finden Sie unter TKG-Funktionsstatus.

Sie können den Verwaltungscluster so konfigurieren, dass er automatisch GPU-fähige Arbeitslastcluster erstellt, wenn Sie gpu: nvidia zu den Bezeichnungen im Clustermanifest hinzufügen. Dazu installieren Sie ein ClusterResourceSet (CRS) und aktivieren es wie folgt:

  1. So konfigurieren Sie den Verwaltungscluster zum Erstellen von GPU-Clustern:

    1. Durchsuchen Sie VMware {code} Sample Exchange nach GPU CRS für TKG (GPU CRS for TKG) und laden Sie die Datei gpu-crs.yaml für Tanzu Kubernetes Grid v1.4 herunter.

    2. Legen Sie Kontext von kubectl auf den Kontext Ihres Verwaltungsclusters fest:

      kubectl config use-context my-management-cluster-admin@my-management-cluster
      
    3. Wenden Sie die CRS-Datei auf den Verwaltungscluster an, indem Sie die Option --server-side verwenden, um die großen ConfigMap-Daten zu verarbeiten:

      kubectl apply -f gpu-crs.yaml --server-side
      
  2. So erstellen Sie einen GPU-Arbeitslastcluster:

    1. Setzen Sie die Konfigurationsdatei für den Cluster AZURE_NODE_MACHINE_TYPE für Worker-Knoten auf einen GPU-kompatiblen VM-Typ wie beispielsweise Standard_NC4as_T4_v3.

    2. Verwenden Sie tanzu cluster create mit der Option --dry-run, um ein Bereitstellungsmanifest aus der Clusterkonfigurationsdatei zu generieren:

      tanzu cluster create MY-GPU-CLUSTER -f MY-GPU-CONFIG --dry-run > MY-GPU-CLUSTER-MANIFEST
      

      Dabei ist MY-GPU-CLUSTER ein Name, den Sie dem Cluster geben.

    3. Erstellen Sie den Cluster, indem Sie ihn an kubectl apply weitergeben:

      kubectl apply -f MY-GPU-CLUSTER-MANIFEST
      
    4. Führen Sie kubectl get pods -A aus. Die gpu-operator-Pods sollten im default-Namespace aufgelistet werden und die nvidia-Pods im gpu-operator-resources-Namespace.

Testen von GPU-fähigen Clustern

So testen Sie einen GPU-fähigen Cluster:

  1. Um die GPU-Verarbeitung zu testen, führen Sie den Vektorhinzufügungstest CUDA VectorAdd in der NVIDIA-Dokumentation aus.

  2. Testen Sie den GPU-Operator:

    1. Skalieren sie die Anzahl der Worker-Knoten im Arbeitslastcluster vertikal hoch:

      tanzu cluster scale MY-GPU-CLUSTER -w 2
      
    2. Führen Sie kubectl get pods -A erneut aus. Für die hinzugefügten Knoten sollten zusätzliche gpu-operator- und nvidia-Pods aufgelistet werden.

check-circle-line exclamation-circle-line close-line
Scroll to top icon