This site will be decommissioned on December 31st 2024. After that date content will be available at techdocs.broadcom.com.

 

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