|
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 À partir de la version 1.26 de Kubernetes, les types de volumes persistants intégrés |
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).
-
Sélectionnez Azure Active Directory.
-
Sélectionnez Enregistrements d’application.
-
Sélectionnez Nouvel enregistrement d’application.
-
Choisissez un Nom, sélectionnez
Web app / APIcomme Type d’application et un URL de connexion qui peut être n’importe quoi dans ce cas. -
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 :
-
Ouvrez votre enregistrement d’application créé.
-
Dans la vue Paramètres, ouvrez Clés.
-
Entrez une Description de la clé, sélectionnez une durée d’expiration et sélectionnez Enregistrer.
-
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.
-
Allez dans Plus de services, recherchez Abonnements et ouvrez-le.
-
Ouvrez Contrôle d’accès (IAM).
-
Sélectionnez Ajouter.
-
Pour Rôle, sélectionnez
Contributor. -
Pour Sélectionner, sélectionnez le nom de votre enregistrement d’application créé.
-
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é. |
-
Choisissez "Azure" dans le menu déroulant du fournisseur de cloud dans la section de configuration du cluster.
-
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 }+
-
-
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 -
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.
|
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
-
Sélectionnez Externe dans le menu déroulant Fournisseur Cloud dans la section Configuration du Cluster.
-
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. -
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.
-
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, } -
Cliquez sur Créer pour soumettre le formulaire et créer le cluster.
-
Choisissez Externe dans le menu déroulant Fournisseur de Cloud dans la section Options de Cluster. Cela définit
--cloud-provider=externalpour les composants Kubernetes. -
Installez le chart
cloud-provider-azureaprè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 étatuninitializedjusqu’à 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.
-
Créez un secret
azure-cloud-configavec la Configuration du fournisseur de cloud requise.kubectl apply -f azure-cloud-config.yaml -
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 -
Créez un fichier
values.yamlavec le contenu suivant pour remplacer levalues.yamlpar 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> -
-
Installez le chart Helm :
helm upgrade --install cloud-provider-azure azure-cloud-controller-manager/cloud-provider-azure -n kube-system --values values.yamlVérifiez que le chart Helm a été installé avec succès :
helm status cloud-provider-azure -n kube-system -
(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 -
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
-
Cliquez sur ☰, puis sélectionnez le nom du cluster dans la navigation à gauche.
-
Sélectionnez Applis > Dépôts.
-
Cliquez sur le bouton Créer.
-
Entrez
https://raw.githubusercontent.com/kubernetes-sigs/cloud-provider-azure/master/helm/repodans le champ URL de l’Index. -
Sélectionnez Applis > Charts dans la navigation à gauche et installez le chart cloud-provider-azure.
-
Sélectionnez l’espace de noms,
kube-system, et activez Personnaliser les options Helm avant l’installation. -
Remplacez
cloudConfig: /etc/kubernetes/azure.jsonpour lire à partir du Secret de configuration cloud et activez le rechargement dynamique :cloudConfigSecretName: azure-cloud-config enableDynamicReloading: 'true' -
Mettez à jour les champs suivants selon les besoins :
allocateNodeCidrs: 'false' configureCloudRoutes: 'false' clusterCIDR: null
-
RKE2
-
RKE
-
Les nœuds RKE2 provisionnés par Rancher ont le sélecteur
node-role.kubernetes.io/control-planedéfini surtrue. Mettez à jour le nodeSelector :nodeSelector: node-role.kubernetes.io/control-plane: 'true'
-
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/controlplanenodeSelector: node-role.kubernetes.io/controlplane: 'true'
-
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 -
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 |
La documentation officielle en amont pour l’installation du Helm chart peut être trouvée sur Github.
-
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 -
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 -
(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 -
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 EOFVérifiez que la classe de stockage a été provisionnée :
kubectl get storageclasses -
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 EOFVérifiez que le PersistentVolumeClaim et le PersistentVolume ont été créés :
kubectl get persistentvolumeclaim kubectl get persistentvolume -
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