Dieses Dokument wurde mithilfe automatisierter maschineller Übersetzungstechnologie übersetzt. Wir bemühen uns um korrekte Übersetzungen, übernehmen jedoch keine Gewähr für die Vollständigkeit, Richtigkeit oder Zuverlässigkeit der übersetzten Inhalte. Im Falle von Abweichungen ist die englische Originalversion maßgebend und stellt den verbindlichen Text dar.

Einrichtung des Azure Cloud Providers

Wichtig:

In Kubernetes 1.30 und später müssen Sie einen externen Azure Cloud Provider verwenden. Der Azure Cloud Provider wurde vollständig entfernt und funktioniert nach einem Upgrade auf Kubernetes 1.30 nicht mehr. Die nachstehenden Schritte sind weiterhin erforderlich, um einen Azure Cloud Provider einzurichten. Sie können einen externen Cloud Provider einrichten, nachdem Sie die Voraussetzungen für Azure erfüllt haben.

Sie können auch von einem internen zu einem externen Azure Cloud Provider in Kubernetes 1.29 und früher migrieren. Alle bestehenden Cluster müssen vor dem Upgrade auf v1.30 migrieren, um funktionsfähig zu bleiben.

Beginnend mit Kubernetes 1.29 wurden interne Cloud Provider deaktiviert. Sie müssen die DisableCloudProviders und DisableKubeletCloudCredentialProviders Feature-Gates auf false setzen, um den internen Azure Cloud Provider zu verwenden. Sie können dies tun, indem Sie feature-gates=DisableCloudProviders=false,DisableKubeletCloudCredentialProviders=false als zusätzliches Argument für den Kubelet, Controller-Manager und API-Server des Clusters in der erweiterten Clusterkonfiguration festlegen. Das Setzen von DisableKubeletCloudCredentialProviders=false in den Argumenten von Kubelet, Controller-Manager und API-Server aktiviert die interne Funktionalität zur Authentifizierung bei Azure Container Registries für Image-Pull-Anmeldeinformationen. Siehe die Kubernetes 1.29: Mandala Versionshinweise und diesen Blogbeitrag für weitere Details.

Beginnend mit Kubernetes Version 1.26 sind die internen Persistent Volume-Typen kubernetes.io/azure-disk und kubernetes.io/azure-file als veraltet markiert und werden nicht mehr unterstützt. Für neue Cluster, installieren Sie die CSI-Treiber oder migrieren Sie zu den entsprechenden CSI-Treibern disk.csi.azure.com und file.csi.azure.com, indem Sie der Upstream-Migrationsdokumentation folgen.

Bei Verwendung des Azure Cloud Providers können Sie die folgenden Funktionen nutzen:

  • Lastenausgleicher: Startet einen Azure Lastenausgleicher innerhalb einer bestimmten Netzwerksicherheitsgruppe.

  • Persistente Volumes: Unterstützt die Verwendung von Azure Blob-Datenträgern und Azure Managed Disks mit Standard- und Premium-Speicherkonten.

  • Netzwerkspeicher: Unterstützt Azure Files über CIFS-Mounts.

Die folgenden Kontotypen werden für Azure-Abonnements nicht unterstützt:

  • Einzelmieterkonten (d.h. Konten ohne Abonnements).

  • Multi-Abonnement-Konten.

Voraussetzungen für RKE und SUSE® Rancher Prime: RKE2

Um den Azure-Cloud-Anbieter sowohl für RKE als auch für RKE2 einzurichten, müssen die folgenden Anmeldeinformationen konfiguriert werden:

1. Richten Sie die Azure Tenant ID ein

Besuchen Sie Azure Portal, melden Sie sich an und gehen Sie zu Azure Active Directory und wählen Sie Eigenschaften aus. Ihre Verzeichnis-ID ist Ihre Tenant ID (tenantID).

Wenn Sie die Azure CLI verwenden möchten, können Sie den Befehl az account show ausführen, um die Informationen zu erhalten.

2. Richten Sie die Azure Client ID und das Azure Client Secret ein

Besuchen Sie Azure Portal, melden Sie sich an und folgen Sie den untenstehenden Schritten, um eine App-Registrierung und die entsprechende Azure Client ID (aadClientId) sowie das Azure Client Secret (aadClientSecret) zu erstellen.

  1. Wählen Sie Azure Active Directory aus.

  2. Wählen Sie App-Registrierungen aus.

  3. Wählen Sie Neue Anwendungsregistrierung aus.

  4. Wählen Sie einen Namen aus, wählen Sie Web app / API als Anwendungstyp und eine Sign-on-URL, die in diesem Fall beliebig sein kann.

  5. Wählen Sie Erstellen.

Im App-Registrierungen-Bereich sollten Sie Ihre erstellte App-Registrierung sehen. Der in der Spalte ANWENDUNGS-ID angezeigte Wert ist der, den Sie als Azure Client ID verwenden müssen.

Der nächste Schritt besteht darin, das Azure Client Secret zu generieren:

  1. Öffnen Sie Ihre erstellte App-Registrierung.

  2. Im Einstellungen-Bereich öffnen Sie Schlüssel.

  3. Geben Sie eine Schlüsselbeschreibung ein, wählen Sie eine Ablaufzeit aus und wählen Sie Speichern aus.

  4. Der generierte Wert, der in der Spalte Wert angezeigt wird, ist der, den Sie als Azure Client Secret verwenden müssen. Dieser Wert wird nur einmal angezeigt.

3. Konfigurieren Sie die Berechtigungen der App-Registrierung

Das Letzte, was Sie tun müssen, ist, die entsprechenden Berechtigungen Ihrer App-Registrierung zuzuweisen.

  1. Gehen Sie zu Weitere Dienste, suchen Sie nach Abonnements und öffnen Sie es.

  2. Öffnen Sie Zugriffskontrolle (IAM).

  3. Wählen Sie Hinzufügen aus.

  4. Für Rolle wählen Sie Contributor aus.

  5. Für Auswählen wählen Sie den Namen Ihrer erstellten App-Registrierung aus.

  6. Wählen Sie Speichern aus.

4. Richten Sie den Namen der Azure-Netzwerksicherheitsgruppe ein

Eine benutzerdefinierte Azure-Netzwerksicherheitsgruppe (securityGroupName) ist erforderlich, um Azure-Lastenausgleicher zu ermöglichen.

Wenn Sie Hosts mit dem Rancher Machine Azure-Treiber bereitstellen, müssen Sie diese manuell bearbeiten, um sie dieser Netzwerksicherheitsgruppe zuzuweisen.

Sie sollten bereits während der Bereitstellung benutzerdefinierte Hosts dieser Azure-Netzwerksicherheitsgruppe zuweisen.

Nur Hosts, die als Backend für den Load Balancer erwartet werden, müssen in dieser Gruppe sein.

SUSE® Rancher Prime: RKE2 Cluster-Einrichtung in Rancher

Wichtig:

Dieser Abschnitt ist nur für die Erstellung von Clustern mit dem integrierten Cloud-Anbieter gültig.

  1. Wählen Sie "Azure" aus dem Dropdown-Menü für Cloud-Anbieter im Abschnitt Cluster-Konfiguration.

  2. Geben Sie die Cloud-Anbieter-Konfiguration an. Beachten Sie, dass Rancher automatisch eine neue Netzwerk-Sicherheitsgruppe, eine Ressourcengruppe, ein Verfügbarkeitsset, ein Subnetz und ein virtuelles Netzwerk erstellt. Wenn Sie bereits einige oder alle davon erstellt haben, müssen Sie diese vor der Erstellung des Clusters angeben.

    • Klicken Sie auf Erweiterte Optionen anzeigen, um diese automatisch generierten Namen anzuzeigen oder zu bearbeiten. Ihre Cloud-Anbieter-Konfiguration muss mit den Feldern im Abschnitt Maschinenpools übereinstimmen. Wenn Sie mehrere Pools haben, müssen alle dieselbe Ressourcengruppe, dasselbe Verfügbarkeitsset, dasselbe Subnetz, dasselbe virtuelle Netzwerk und dieselbe Netzwerk-Sicherheitsgruppe verwenden.

    • Ein Beispiel ist unten angegeben. Ändern Sie es nach Bedarf.

    Beispiel für Cloud-Anbieter-Konfiguration

    +

     {
         "cloud":"AzurePublicCloud",
         "tenantId": "YOUR TENANTID HERE",
         "aadClientId": "YOUR AADCLIENTID HERE",
         "aadClientSecret": "YOUR AADCLIENTSECRET HERE",
         "subscriptionId": "YOUR SUBSCRIPTIONID HERE",
         "resourceGroup": "docker-machine",
         "location": "westus",
         "subnetName": "docker-machine",
         "securityGroupName": "rancher-managed-KA4jV9V2",
         "securityGroupResourceGroup": "docker-machine",
         "vnetName": "docker-machine-vnet",
         "vnetResourceGroup": "docker-machine",
         "primaryAvailabilitySetName": "docker-machine",
         "routeTableResourceGroup": "docker-machine",
         "cloudProviderBackoff": false,
         "useManagedIdentityExtension": false,
         "useInstanceMetadata": true
     }

    +

  3. Unter dem Abschnitt menu:Cluster-Konfiguration[Erweitert] klicken Sie auf Hinzufügen unter Zusätzliche Controller-Manager-Argumente und fügen Sie dieses Flag hinzu: --configure-cloud-routes=false

  4. Klicken Sie auf Erstellen, um das Formular abzusenden und den Cluster zu erstellen.

Cloud-Anbieter-Konfiguration

Rancher erstellt automatisch eine neue Netzwerk-Sicherheitsgruppe, eine Ressourcengruppe, ein Verfügbarkeitsset, ein Subnetz und ein virtuelles Netzwerk. Wenn Sie bereits einige oder alle davon erstellt haben, müssen Sie diese vor der Erstellung des Clusters angeben. Sie können RKE1-Knotenvorlagen oder RKE2-Maschinenpools überprüfen, um diese automatisch generierten Namen anzuzeigen oder zu bearbeiten.

Verweisen Sie auf die vollständige Liste der Konfigurationsoptionen in den Upstream-Dokumenten.

  1. useInstanceMetadata muss auf true gesetzt werden, damit der Cloud-Anbieter providerID korrekt konfigurieren kann.

  2. excludeMasterFromStandardLB muss auf false gesetzt werden, wenn Sie Knoten mit dem Label node-role.kubernetes.io/master zum Backend des Azure Load Balancers (ALB) hinzufügen müssen.

  3. loadBalancerSku kann auf basic oder standard gesetzt werden. Das Basic SKU wird im September 2025 eingestellt. Verweisen Sie auf die Azure Upstream-Dokumente für weitere Informationen.

Azure unterstützt das Lesen der Cloud-Konfiguration aus Kubernetes-Secrets. Das Secret ist eine serialisierte Version der Datei azure.json. Wenn das Secret geändert wird, rekonstruiert sich der Cloud-Controller-Manager selbst, ohne den Pod neu zu starten. Es wird empfohlen, dass das Helm-Chart die Cloud Provider-Konfiguration aus dem Secret liest.

Beachten Sie, dass das Helm-Chart die Cloud Provider-Konfiguration aus einem Secret mit dem angegebenen Namen im kube-system Namespace liest. Da Azure Kubernetes-Secrets liest, muss auch RBAC konfiguriert werden. Ein Beispiel für ein Secret für die Cloud Provider-Konfiguration ist unten dargestellt. Ändern Sie es nach Bedarf und erstellen Sie das Secret.

# azure-cloud-config.yaml
apiVersion: v1
kind: Secret
metadata:
  name: azure-cloud-config
  namespace: kube-system
type: Opaque
stringData:
  cloud-config: |-
    {
      "cloud": "AzurePublicCloud",
      "tenantId": "<tenant-id>",
      "subscriptionId": "<subscription-id>",
      "aadClientId": "<client-id>",
      "aadClientSecret": "<client-secret>",
      "resourceGroup": "docker-machine",
      "location": "westus",
      "subnetName": "docker-machine",
      "securityGroupName": "rancher-managed-kqmtsjgJ",
      "securityGroupResourceGroup": "docker-machine",
      "vnetName": "docker-machine-vnet",
      "vnetResourceGroup": "docker-machine",
      "primaryAvailabilitySetName": "docker-machine",
      "routeTableResourceGroup": "docker-machine",
      "cloudProviderBackoff": false,
      "useManagedIdentityExtension": false,
      "useInstanceMetadata": true,
      "loadBalancerSku": "standard",
      "excludeMasterFromStandardLB": false,
    }

Verwendung des Out-of-tree Azure Cloud Providers

  • RKE2

  • RKE1

  1. Wählen Sie Extern aus dem Cloud Provider Dropdown im Abschnitt Cluster-Konfiguration aus.

  2. Unter menu:Cluster-Konfiguration[Erweitert] klicken Sie auf Hinzufügen unter Zusätzliche Controller-Manager-Argumente und fügen Sie dieses Flag hinzu: --configure-cloud-routes=false.

  3. Bereiten Sie die Cloud Provider-Konfiguration vor, um sie im nächsten Schritt festzulegen. Beachten Sie, dass Rancher automatisch eine neue Netzwerk-Sicherheitsgruppe, eine Ressourcengruppe, ein Verfügbarkeitsset, ein Subnetz und ein virtuelles Netzwerk erstellt. Wenn Sie bereits einige oder alle davon erstellt haben, müssen Sie diese vor der Erstellung des Clusters angeben.

    Klicken Sie auf Erweiterte Optionen anzeigen, um diese automatisch generierten Namen anzuzeigen oder zu bearbeiten. Ihre Cloud Provider-Konfiguration muss mit den Feldern im Maschinenpools übereinstimmen. Wenn Sie mehrere Pools haben, müssen alle dieselbe Ressourcengruppe, dasselbe Verfügbarkeitsset, dasselbe Subnetz, dasselbe virtuelle Netzwerk und dieselbe Netzwerk-Sicherheitsgruppe verwenden.

  4. Unter Cluster-Konfiguration > Add-on-Konfiguration fügen Sie das unten gezeigte Manifest des Cloud-Controller-Managers in Zusätzliches Manifest ein.

    Beachten Sie, dass dieses Chart die Cloud Provider-Konfiguration aus dem Secret im kube-system Namespace liest. Ein Beispiel für ein Secret für die Cloud Provider-Konfiguration ist unten dargestellt; passen Sie es nach Bedarf an. Siehe die vollständige Liste der Konfigurationsoptionen in der Upstream-Dokumentation.

    Alternativ können Sie auch den Cloud-Controller-Manager mit der Helm-Kommandozeilenschnittstelle installieren.

    apiVersion: helm.cattle.io/v1
    kind: HelmChart
    metadata:
      name: azure-cloud-controller-manager
      namespace: kube-system
    spec:
      chart: cloud-provider-azure
      repo: https://raw.githubusercontent.com/kubernetes-sigs/cloud-provider-azure/master/helm/repo
      targetNamespace: kube-system
      bootstrap: true
      valuesContent: |-
        infra:
          clusterName: <cluster-name>
        cloudControllerManager:
          cloudConfigSecretName: azure-cloud-config
          cloudConfig: null
          clusterCIDR: null
          enableDynamicReloading: 'true'
          nodeSelector:
            node-role.kubernetes.io/control-plane: 'true'
          allocateNodeCidrs: 'false'
          hostNetworking: true
          caCertDir: /etc/ssl
          configureCloudRoutes: 'false'
          enabled: true
          tolerations:
            - effect: NoSchedule
              key: node-role.kubernetes.io/master
            - effect: NoSchedule
              key: node-role.kubernetes.io/control-plane
              value: 'true'
            - effect: NoSchedule
              key: node.cloudprovider.kubernetes.io/uninitialized
              value: 'true'
    ---
    apiVersion: v1
    kind: Secret
    metadata:
      name: azure-cloud-config
      namespace: kube-system
    type: Opaque
    stringData:
      cloud-config: |-
        {
          "cloud": "AzurePublicCloud",
          "tenantId": "<tenant-id>",
          "subscriptionId": "<subscription-id>",
          "aadClientId": "<client-id>",
          "aadClientSecret": "<client-secret>",
          "resourceGroup": "docker-machine",
          "location": "westus",
          "subnetName": "docker-machine",
          "securityGroupName": "rancher-managed-kqmtsjgJ",
          "securityGroupResourceGroup": "docker-machine",
          "vnetName": "docker-machine-vnet",
          "vnetResourceGroup": "docker-machine",
          "primaryAvailabilitySetName": "docker-machine",
          "routeTableResourceGroup": "docker-machine",
          "cloudProviderBackoff": false,
          "useManagedIdentityExtension": false,
          "useInstanceMetadata": true,
          "loadBalancerSku": "standard",
          "excludeMasterFromStandardLB": false,
        }
  5. Klicken Sie auf Erstellen, um das Formular abzusenden und den Cluster zu erstellen.

  1. Wählen Sie Extern aus dem Cloud Provider-Dropdown im Abschnitt Cluster-Optionen aus. Dies setzt --cloud-provider=external für Kubernetes-Komponenten.

  2. Installieren Sie das cloud-provider-azure Chart, nachdem der Cluster bereitgestellt wurde. Beachten Sie, dass der Cluster nicht erfolgreich bereitgestellt ist und die Knoten sich weiterhin in einem uninitialized Zustand befinden, bis Sie den Cloud-Controller-Manager bereitstellen. Dies kann manuell über die Kommandozeilenschnittstelle oder über Helm-Charts in der UI erfolgen.

Verweisen Sie auf die offizielle Azure-Upstream-Dokumentation für weitere Details zur Bereitstellung des Cloud-Controller-Managers.

Installation des Helm-Charts über die Kommandozeilenschnittstelle

Offizielle Upstream-Dokumente für die Installation des Helm-Charts finden Sie auf Github.

  1. Erstellen Sie ein azure-cloud-config Secret mit der erforderlichen Cloud Provider-Konfiguration.

    kubectl apply -f azure-cloud-config.yaml
  2. Fügen Sie das Helm-Repository hinzu:

    helm repo add azure-cloud-controller-manager https://raw.githubusercontent.com/kubernetes-sigs/cloud-provider-azure/master/helm/repo
    helm repo update
  3. Erstellen Sie eine values.yaml Datei mit den folgenden Inhalten, um die Standard-values.yaml zu überschreiben:

    • RKE2

    • RKE

    # values.yaml
    infra:
      clusterName: <cluster-name>
    cloudControllerManager:
      cloudConfigSecretName: azure-cloud-config
      cloudConfig: null
      clusterCIDR: null
      enableDynamicReloading: 'true'
      configureCloudRoutes: 'false'
      allocateNodeCidrs: 'false'
      caCertDir: /etc/ssl
      enabled: true
      replicas: 1
      hostNetworking: true
      nodeSelector:
        node-role.kubernetes.io/control-plane: 'true'
      tolerations:
        - effect: NoSchedule
          key: node-role.kubernetes.io/master
        - effect: NoSchedule
          key: node-role.kubernetes.io/control-plane
          value: 'true'
        - effect: NoSchedule
          key: node.cloudprovider.kubernetes.io/uninitialized
          value: 'true'
    # values.yaml
    cloudControllerManager:
      cloudConfigSecretName: azure-cloud-config
      cloudConfig: null
      clusterCIDR: null
      enableDynamicReloading: 'true'
      configureCloudRoutes: 'false'
      allocateNodeCidrs: 'false'
      caCertDir: /etc/ssl
      enabled: true
      replicas: 1
      hostNetworking: true
      nodeSelector:
        node-role.kubernetes.io/controlplane: 'true'
        node-role.kubernetes.io/control-plane: null
      tolerations:
        - effect: NoSchedule
          key: node-role.kubernetes.io/controlplane
          value: 'true'
        - effect: NoSchedule
          key: node.cloudprovider.kubernetes.io/uninitialized
          value: 'true'
    infra:
      clusterName: <cluster-name>
  4. Installieren Sie das Helm-Chart:

    helm upgrade --install cloud-provider-azure azure-cloud-controller-manager/cloud-provider-azure -n kube-system --values values.yaml

    Überprüfen Sie, ob das Helm-Chart erfolgreich installiert wurde:

    helm status cloud-provider-azure -n kube-system
  5. (Optional) Überprüfen Sie, ob das Update des Cloud-Controller-Managers erfolgreich war:

    kubectl rollout status deployment -n kube-system cloud-controller-manager
    kubectl rollout status daemonset -n kube-system cloud-node-manager
  6. Der Cloud-Anbieter ist verantwortlich für die Festlegung der ProviderID des Knotens. Überprüfen Sie, ob alle Knoten mit der ProviderID initialisiert sind:

    kubectl describe nodes | grep "ProviderID"

Helm Chart-Installation über die Benutzeroberfläche

  1. Klicken Sie auf und wählen Sie dann den Namen des Clusters aus der linken Navigation aus.

  2. Wählen Sie Apps > Repositories aus.

  3. Klicken Sie auf die Erstellen Schaltfläche.

  4. Geben Sie https://raw.githubusercontent.com/kubernetes-sigs/cloud-provider-azure/master/helm/repo im Feld Index-URL ein.

  5. Wählen Sie Apps > Charts aus der linken Navigation und installieren Sie das Helm-Chart cloud-provider-azure.

  6. Wählen Sie den Namespace kube-system aus und aktivieren Sie Helm-Optionen vor der Installation anpassen.

  7. Ersetzen Sie cloudConfig: /etc/kubernetes/azure.json , um aus dem Cloud-Config-Secret zu lesen, und aktivieren Sie das dynamische Nachladen:

      cloudConfigSecretName: azure-cloud-config
      enableDynamicReloading: 'true'
  8. Aktualisieren Sie die folgenden Felder nach Bedarf:

      allocateNodeCidrs: 'false'
      configureCloudRoutes: 'false'
      clusterCIDR: null
  • RKE2

  • RKE

  1. Von Rancher bereitgestellte RKE2-Knoten haben den Selektor node-role.kubernetes.io/control-plane auf true gesetzt. Aktualisieren Sie den nodeSelector:

    nodeSelector:
      node-role.kubernetes.io/control-plane: 'true'
  1. Von Rancher bereitgestellte RKE-Knoten sind mit node-role.kubernetes.io/controlplane markiert. Aktualisieren Sie die Toleranzen und den nodeSelector:

    tolerations:
      - effect: NoSchedule
        key: node.cloudprovider.kubernetes.io/uninitialized
        value: 'true'
      - effect: NoSchedule
        value: 'true'
        key: node-role.kubernetes.io/controlplane
    nodeSelector:
      node-role.kubernetes.io/controlplane: 'true'
  1. Installieren Sie das Helm-Chart und bestätigen Sie, dass der Cloud-Controller und der Cloud-Node-Manager erfolgreich bereitgestellt wurden:

    kubectl rollout status deployment -n kube-system cloud-controller-manager
    kubectl rollout status daemonset -n kube-system cloud-node-manager
  2. Der Cloud-Anbieter ist verantwortlich für die Festlegung der ProviderID des Knotens. Überprüfen Sie, ob alle Knoten mit der ProviderID initialisiert sind:

    kubectl describe nodes | grep "ProviderID"

Installation von CSI-Treibern

Installieren Sie Azure Disk CSI-Treiber oder Azure File CSI-Treiber, um auf Azure Disk oder Azure File-Volumes zuzugreifen.

Die Schritte zur Installation des Azure Disk CSI-Treibers sind unten aufgeführt. Sie können den Azure File CSI-Treiber auf ähnliche Weise installieren, indem Sie die Dokumentation zur Helm-Installation befolgen.

Wichtig

Cluster müssen mit Managed Disk bereitgestellt werden, um Azure Disk zu verwenden. Sie können dies beim Erstellen von RKE1-Knotenvorlagen oder *RKE2-Maschinenpools konfigurieren.

Offizielle Upstream-Dokumente für die Installation des Helm-Charts finden Sie auf Github.

  1. Fügen Sie das Helm-Repository hinzu und aktualisieren Sie es:

    helm repo add azuredisk-csi-driver https://raw.githubusercontent.com/kubernetes-sigs/azuredisk-csi-driver/master/charts
    helm repo update azuredisk-csi-driver
  2. Installieren Sie das Chart wie unten gezeigt und aktualisieren Sie das --Versionsargument nach Bedarf. Verweisen Sie auf die vollständige Liste der neuesten Chart-Konfigurationen in der Upstream-Dokumentation.

    helm install azuredisk-csi-driver azuredisk-csi-driver/azuredisk-csi-driver --namespace kube-system --version v1.30.1 --set controller.cloudConfigSecretName=azure-cloud-config --set controller.cloudConfigSecretNamespace=kube-system --set controller.runOnControlPlane=true
  3. (Optional) Überprüfen Sie, ob die Installation des azuredisk-csi-drivers erfolgreich war:

    kubectl --namespace=kube-system get pods --selector="app.kubernetes.io/name=azuredisk-csi-driver" --watch
  4. Stellen Sie eine Beispiel-Speicherklasse bereit:

    cat <<EOF | kubectl create -f -
    kind: StorageClass
    apiVersion: storage.k8s.io/v1
    metadata:
      name: standard
    provisioner: kubernetes.io/azure-disk
    parameters:
      storageaccounttype: Standard_LRS
      kind: Managed
    EOF

    Überprüfen Sie, ob die Speicherklasse bereitgestellt wurde:

    kubectl get storageclasses
  5. Erstellen Sie eine PersistentVolumeClaim:

    cat <<EOF | kubectl create -f -
    kind: PersistentVolumeClaim
    apiVersion: v1
    metadata:
      name: azure-disk-pvc
    spec:
      storageClassName: standard
      accessModes:
     ** ReadWriteOnce
      resources:
     requests:
    storage: 5Gi
    EOF

    Überprüfen Sie, ob die PersistentVolumeClaim und PersistentVolume erstellt wurden:

    kubectl get persistentvolumeclaim
    kubectl get persistentvolume
  6. Hängen Sie die neue Azure-Disk an:

    Sie können jetzt das Kubernetes PersistentVolume in einen Kubernetes-Pod einbinden. Die Disk kann von jedem Kubernetes-Objekttyp verwendet werden, einschließlich eines Deployments, DaemonSets oder StatefulSets. Das folgende Beispiel bindet jedoch einfach das PersistentVolume in einen eigenständigen Pod ein.

    cat <<EOF | kubectl create -f -
    kind: Pod
    apiVersion: v1
    metadata:
      name: mypod-dynamic-azuredisk
    spec:
      containers:
        - name: mypod
          image: nginx
          ports:
            - containerPort: 80
              name: "http-server"
          volumeMounts:
            - mountPath: "/usr/share/nginx/html"
              name: storage
      volumes:
        - name: storage
          persistentVolumeClaim:
            claimName: azure-disk-pvc
    EOF