Ce document a été traduit à l'aide d'une technologie de traduction automatique. Bien que nous nous efforcions de fournir des traductions exactes, nous ne fournissons aucune garantie quant à l'exhaustivité, l'exactitude ou la fiabilité du contenu traduit. En cas de divergence, la version originale anglaise prévaut et fait foi.

Mise en place du fournisseur de cloud Azure

Important :

Dans Kubernetes 1.30 et versions ultérieures, vous devez utiliser un fournisseur de cloud Azure hors de l’arbre. Le fournisseur de cloud Azure a été supprimé complètement, et ne fonctionnera plus après une mise à niveau vers Kubernetes 1.30. Les étapes énumérées ci-dessous sont toujours nécessaires pour configurer un fournisseur de cloud Azure. Vous pouvez configurer un fournisseur de cloud hors de l’arbre après avoir complété les prérequis pour Azure.

Vous pouvez également migrer d’un fournisseur de cloud intégré à un fournisseur de cloud Azure hors de l’arbre sur Kubernetes 1.29 et versions antérieures. Tous les clusters existants doivent migrer avant de passer à la version v1.30 afin de rester fonctionnels.

À partir de Kubernetes 1.29, les fournisseurs de cloud intégrés ont été désactivés. Vous devez définir DisableCloudProviders et DisableKubeletCloudCredentialProviders portes de fonctionnalités sur false pour utiliser le fournisseur de cloud Azure intégré. Vous pouvez le faire en définissant feature-gates=DisableCloudProviders=false,DisableKubeletCloudCredentialProviders=false comme argument supplémentaire pour le Kubelet, le gestionnaire de contrôleur et l’API Server du cluster dans la configuration avancée du cluster. Définir DisableKubeletCloudCredentialProviders=false dans les arguments du Kubelet, du gestionnaire de contrôleur et de l’API Server active la fonctionnalité intégrée pour l’authentification aux registres de conteneurs Azure pour les informations d’identification de tirage d’images. Voir les notes de version de Kubernetes 1.29 : Mandala et cet article de blog pour plus de détails.

À partir de la version 1.26 de Kubernetes, les types de volumes persistants intégrés kubernetes.io/azure-disk et kubernetes.io/azure-file sont obsolètes et ne seront plus pris en charge. Pour les nouveaux clusters, installez les pilotes CSI, ou migrez vers les pilotes CSI correspondants disk.csi.azure.com et file.csi.azure.com en suivant la documentation de migration en amont.

Lorsque vous utilisez le fournisseur de cloud Azure, vous pouvez tirer parti des capacités suivantes :

  • Équilibreurs de charge : Lance un équilibreur de charge Azure au sein d’un groupe de sécurité réseau spécifique.

  • Volumes persistants : Prend en charge l’utilisation de disques Azure Blob et de disques gérés Azure avec des comptes de stockage standard et premium.

  • Stockage réseau : Prise en charge des fichiers Azure via des montages CIFS.

Les types de compte suivants ne sont pas pris en charge pour les abonnements Azure :

  • Comptes à locataire unique (c’est-à-dire des comptes sans abonnements).

  • Comptes multi-abonnements.

Conditions préalables pour RKE et SUSE® Rancher Prime: RKE2

Pour configurer le fournisseur de cloud Azure pour RKE et RKE2, les identifiants suivants doivent être configurés :

1. Configurer l’ID de locataire Azure

Visitez le portail Azure, connectez-vous et allez à Azure Active Directory puis sélectionnez Propriétés. Votre ID de répertoire est votre ID de locataire (tenantID).

Si vous souhaitez utiliser l’interface de ligne de commande Azure, vous pouvez exécuter la commande az account show pour obtenir les informations.

2. Configurer l’ID client Azure et le secret client Azure

Visitez le portail Azure, connectez-vous et suivez les étapes ci-dessous pour créer un enregistrement d’application et les correspondants ID client Azure (aadClientId) et secret client Azure (aadClientSecret).

  1. Sélectionnez Azure Active Directory.

  2. Sélectionnez Enregistrements d’application.

  3. Sélectionnez Nouvel enregistrement d’application.

  4. Choisissez un Nom, sélectionnez Web app / API comme Type d’application et un URL de connexion qui peut être n’importe quoi dans ce cas.

  5. Sélectionnez Créer.

Dans la vue Enregistrements d’applications, vous devriez voir votre enregistrement d’application créé. La valeur affichée dans la colonne ID D’APPLICATION est celle que vous devez utiliser comme ID CLIENT Azure.

L’étape suivante consiste à générer le Secret Client Azure :

  1. Ouvrez votre enregistrement d’application créé.

  2. Dans la vue Paramètres, ouvrez Clés.

  3. Entrez une Description de la clé, sélectionnez une durée d’expiration et sélectionnez Enregistrer.

  4. La valeur générée affichée dans la colonne Valeur est celle que vous devez utiliser comme Secret Client Azure. Cette valeur ne sera affichée qu’une seule fois.

3. Configurer les autorisations d’enregistrement d’application

La dernière chose que vous devrez faire est d’assigner les autorisations appropriées à votre enregistrement d’application.

  1. Allez dans Plus de services, recherchez Abonnements et ouvrez-le.

  2. Ouvrez Contrôle d’accès (IAM).

  3. Sélectionnez Ajouter.

  4. Pour Rôle, sélectionnez Contributor.

  5. Pour Sélectionner, sélectionnez le nom de votre enregistrement d’application créé.

  6. Sélectionnez Enregistrer.

4. Configurer le nom du groupe de sécurité réseau Azure

Un groupe de sécurité réseau Azure personnalisé (securityGroupName) est nécessaire pour permettre aux équilibreurs de charge Azure de fonctionner.

Si vous provisionnez des hôtes en utilisant le pilote Azure de Rancher Machine, vous devrez les modifier manuellement pour les assigner à ce groupe de sécurité réseau.

Vous devriez déjà avoir assigné des hôtes personnalisés à ce groupe de sécurité réseau lors du provisionnement.

Seuls les hôtes prévus pour être des back-ends d’équilibreur de charge doivent être dans ce groupe.

SUSE® Rancher Prime: RKE2 Configuration de cluster dans Rancher

Important :

Cette section est valable uniquement pour la création de clusters avec le fournisseur de cloud intégré.

  1. Choisissez "Azure" dans le menu déroulant du fournisseur de cloud dans la section de configuration du cluster.

  2. Fournissez la configuration du fournisseur de cloud. Notez que Rancher crée automatiquement un nouveau groupe de sécurité réseau, un groupe de ressources, un ensemble de disponibilité, un sous-réseau et un réseau virtuel. Si vous avez déjà créé certains ou tous ces éléments, vous devez les spécifier avant de créer le cluster.

    • Cliquez sur Afficher les options avancées pour voir ou modifier ces noms générés automatiquement. Votre configuration du fournisseur de cloud doit correspondre aux champs de la section Pools de machines. Si vous avez plusieurs pools, ils doivent tous utiliser le même groupe de ressources, ensemble de disponibilité, sous-réseau, réseau virtuel et groupe de sécurité réseau.

    • Un exemple est fourni ci-dessous. Modifiez-le si nécessaire.

    Exemple de configuration du fournisseur de cloud

    +

     {
         "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. Sous la section menu:Configuration du cluster[Avancé], cliquez sur Ajouter sous Arguments supplémentaires du gestionnaire de contrôleur et ajoutez ce drapeau : --configure-cloud-routes=false

  4. Cliquez sur Créer pour soumettre le formulaire et créer le cluster.

Configuration du fournisseur de cloud

Rancher crée automatiquement un nouveau groupe de sécurité réseau, un groupe de ressources, un ensemble de disponibilité, un sous-réseau et un réseau virtuel. Si vous avez déjà créé certains ou tous ces éléments, vous devrez les spécifier avant de créer le cluster. Vous pouvez consulter Modèles de nœuds RKE1 ou Pools de machines RKE2 pour voir ou modifier ces noms générés automatiquement.

Reportez-vous à la liste complète des options de configuration dans la documentation en amont.

  1. useInstanceMetadata doit être défini sur true pour que le fournisseur de cloud configure correctement providerID.

  2. excludeMasterFromStandardLB doit être défini sur false si vous devez ajouter des nœuds étiquetés node-role.kubernetes.io/master à l’arrière-plan de l’Azure Load Balancer (ALB).

  3. loadBalancerSku peut être défini sur basic ou standard. Le SKU de base sera obsolète en septembre 2025. Consultez la documentation en amont Azure pour plus d’informations.

Azure prend en charge la lecture de la configuration cloud à partir des secrets Kubernetes. Le secret est une version sérialisée du fichier azure.json. Lorsque le secret est modifié, le gestionnaire de contrôleur cloud se reconstruit sans redémarrer le pod. Il est recommandé que le graphique Helm lise la configuration du fournisseur cloud à partir du secret.

Notez que le graphique lit la configuration du fournisseur cloud à partir d’un nom de secret donné dans l’espace de noms kube-system. Puisqu’Azure lit les secrets Kubernetes, RBAC doit également être configuré. Un exemple de secret pour la Configuration du fournisseur de cloud est montré ci-dessous. Modifiez-le selon vos besoins et créez le 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,
    }

Utilisation du fournisseur de cloud Azure hors de l’arbre.

  • RKE2

  • RKE1

  1. Sélectionnez Externe dans le menu déroulant Fournisseur Cloud dans la section Configuration du Cluster.

  2. Sous menu:Configuration du Cluster[Avancé], cliquez sur Ajouter sous Arguments supplémentaires du gestionnaire de contrôleur et ajoutez ce drapeau : --configure-cloud-routes=false.

  3. Préparez la Configuration du fournisseur de cloud pour l’étape suivante. Notez que Rancher crée automatiquement un nouveau groupe de sécurité réseau, un groupe de ressources, un ensemble de disponibilité, un sous-réseau et un réseau virtuel. Si vous avez déjà créé certains ou tous ces éléments, vous devez les spécifier avant de créer le cluster.

    Cliquez sur Afficher les options avancées pour voir ou modifier ces noms générés automatiquement. Votre configuration du fournisseur de cloud doit correspondre aux champs de la section Pools de machines. Si vous avez plusieurs pools, ils doivent tous utiliser le même groupe de ressources, ensemble de disponibilité, sous-réseau, réseau virtuel et groupe de sécurité réseau.

  4. Sous Configuration du Cluster > Configuration du produit complémentaire, ajoutez le manifeste du gestionnaire de contrôleur de cloud dans Manifeste supplémentaire.

    Notez que ce graphique lit la configuration du fournisseur cloud à partir du secret dans l’espace de noms kube-system. Un exemple de secret pour la Configuration du fournisseur de cloud est montré ci-dessous : modifiez-le selon vos besoins. Consultez la liste complète des options de configuration dans la documentation en amont.

    Alternativement, vous pouvez également installer le gestionnaire de contrôleur de cloud en utilisant le Helm CLI.

    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. Cliquez sur Créer pour soumettre le formulaire et créer le cluster.

  1. Choisissez Externe dans le menu déroulant Fournisseur de Cloud dans la section Options de Cluster. Cela définit --cloud-provider=external pour les composants Kubernetes.

  2. Installez le chart cloud-provider-azure après que le cluster ait terminé le provisionnement. Notez que le cluster n’est pas provisionné avec succès et que les nœuds sont toujours dans un état uninitialized jusqu’à ce que vous déployiez le gestionnaire de contrôleur de cloud. Cela peut être fait manuellement en utilisant le CLI, ou via des charts Helm dans l’UI.

Référez-vous à la documentation officielle Azure en amont pour plus de détails sur le déploiement du Gestionnaire de Contrôleur de Cloud.

Installation du Chart Helm depuis le CLI

Les docs officielles en amont pour l’installation du chart Helm peuvent être trouvées sur Github.

  1. Créez un secret azure-cloud-config avec la Configuration du fournisseur de cloud requise.

    kubectl apply -f azure-cloud-config.yaml
  2. Ajoutez le dépôt Helm :

    helm repo add azure-cloud-controller-manager https://raw.githubusercontent.com/kubernetes-sigs/cloud-provider-azure/master/helm/repo
    helm repo update
  3. Créez un fichier values.yaml avec le contenu suivant pour remplacer le values.yaml par défaut :

    • 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. Installez le chart Helm :

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

    Vérifiez que le chart Helm a été installé avec succès :

    helm status cloud-provider-azure -n kube-system
  5. (Optionnel) Vérifiez que la mise à jour du gestionnaire de contrôleur de cloud a réussi :

    kubectl rollout status deployment -n kube-system cloud-controller-manager
    kubectl rollout status daemonset -n kube-system cloud-node-manager
  6. Le fournisseur de cloud est responsable de la définition du ProviderID du nœud. Vérifiez si tous les nœuds sont initialisés avec le ProviderID :

    kubectl describe nodes | grep "ProviderID"

Installation du chart Helm depuis l’interface utilisateur

  1. Cliquez sur , puis sélectionnez le nom du cluster dans la navigation à gauche.

  2. Sélectionnez Applis > Dépôts.

  3. Cliquez sur le bouton Créer.

  4. Entrez https://raw.githubusercontent.com/kubernetes-sigs/cloud-provider-azure/master/helm/repo dans le champ URL de l’Index.

  5. Sélectionnez Applis > Charts dans la navigation à gauche et installez le chart cloud-provider-azure.

  6. Sélectionnez l’espace de noms, kube-system, et activez Personnaliser les options Helm avant l’installation.

  7. Remplacez cloudConfig: /etc/kubernetes/azure.json pour lire à partir du Secret de configuration cloud et activez le rechargement dynamique :

      cloudConfigSecretName: azure-cloud-config
      enableDynamicReloading: 'true'
  8. Mettez à jour les champs suivants selon les besoins :

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

  • RKE

  1. Les nœuds RKE2 provisionnés par Rancher ont le sélecteur node-role.kubernetes.io/control-plane défini sur true. Mettez à jour le nodeSelector :

    nodeSelector:
      node-role.kubernetes.io/control-plane: 'true'
  1. Les nœuds RKE provisionnés par Rancher sont marqués node-role.kubernetes.io/controlplane. Mettez à jour les tolérances et le 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. Installez le chart et confirmez que le contrôleur cloud et le gestionnaire de nœuds cloud ont été déployés avec succès :

    kubectl rollout status deployment -n kube-system cloud-controller-manager
    kubectl rollout status daemonset -n kube-system cloud-node-manager
  2. Le fournisseur de cloud est responsable de la définition du ProviderID du nœud. Vérifiez si tous les nœuds sont initialisés avec le ProviderID :

    kubectl describe nodes | grep "ProviderID"

Installation des pilotes CSI

Installez le pilote CSI de disque Azure ou le pilote CSI de fichier Azure pour accéder respectivement aux volumes de disque Azure ou de fichier Azure.

Les étapes pour installer le pilote CSI de disque Azure sont indiquées ci-dessous. Vous pouvez installer le pilote CSI de fichier Azure de manière similaire en suivant la documentation d’installation Helm.

Important

Les clusters doivent être provisionnés en utilisant Managed Disk pour utiliser le disque Azure. Vous pouvez configurer cela lors de la création de modèles de nœuds RKE1 ou *pools de machines RKE2.

La documentation officielle en amont pour l’installation du Helm chart peut être trouvée sur Github.

  1. Ajoutez et mettez à jour le dépôt Helm :

    helm repo add azuredisk-csi-driver https://raw.githubusercontent.com/kubernetes-sigs/azuredisk-csi-driver/master/charts
    helm repo update azuredisk-csi-driver
  2. Installez le chart comme indiqué ci-dessous, en mettant à jour l’argument --version si nécessaire. Référez-vous à la liste complète des dernières configurations de Helm chart dans la documentation en amont.

    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. (Optionnel) Vérifiez que l’installation du pilote azuredisk-csi-driver a réussi :

    kubectl --namespace=kube-system get pods --selector="app.kubernetes.io/name=azuredisk-csi-driver" --watch
  4. Provisionnez un exemple de classe de stockage :

    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

    Vérifiez que la classe de stockage a été provisionnée :

    kubectl get storageclasses
  5. Créez un 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

    Vérifiez que le PersistentVolumeClaim et le PersistentVolume ont été créés :

    kubectl get persistentvolumeclaim
    kubectl get persistentvolume
  6. Attachez le nouveau disque Azure :

    Vous pouvez maintenant monter le PersistentVolume Kubernetes dans un Pod Kubernetes. Le disque peut être utilisé par tout type d’objet Kubernetes, y compris un Deployment, un DaemonSet ou un StatefulSet. Cependant, l’exemple suivant monte simplement le PersistentVolume dans un Pod autonome.

    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