Préparer Linux pour Edge Volumes

Article
10/16/2024

L’article explique comment préparer Linux pour Edge Volumes avec AKS activé par Azure Arc, Edge Essentials ou Ubuntu.

Remarque

La version minimale prise en charge du noyau Linux est 5.1. À ce stade, il existe des problèmes connus avec la version 6.4 et la version 6.2.

Prérequis

Remarque

Le Stockage de conteneurs Azure activé par Azure Arc est disponible uniquement dans les régions suivantes : USA Est, USA Est 2, USA Ouest, USA Ouest 2, USA Ouest 3, Europe Nord, Europe Ouest.

Désinstaller l’instance précédente de l’extension Stockage de conteneurs Azure activé par Azure Arc

Si vous avez déjà installé une version du Stockage de conteneurs Azure activé par Azure Arc antérieure à 2.1.0-preview, vous devez désinstaller cette instance précédente pour installer la version la plus récente. Si vous avez installé la version 1.2.0-preview ou une version antérieure, utilisez ces instructions. Les versions après 2.1.0-preview peuvent être mises à niveau et ne nécessitent pas d’être désinstallées.

Pour supprimer l’ancienne version de l’extension, les ressources Kubernetes contenant des références à l’ancienne version de l’extension doivent être nettoyées. Toutes les ressources en attente peuvent retarder le nettoyage de l’extension. Il existe au moins deux façons de nettoyer ces ressources : soit en utilisant kubectl delete <resource_type> <resource_name>, soit en « désappliquant » les fichiers YAML utilisés pour créer les ressources. Les ressources qui doivent être supprimées sont généralement les pods, la revendication PVC référencée et le CRD de sous-volume (si Cloud Ingest Edge Volume a été configuré). Vous pouvez également passer les quatre fichiers YAML suivants à kubectl delete -f en utilisant les commandes suivantes dans l’ordre spécifié. Ces variables doivent être mises à jour avec vos informations :
- YOUR_DEPLOYMENT_FILE_NAME_HERE : Ajoutez vos noms de fichiers de déploiement. Dans l’exemple de cet article, le nom de fichier utilisé était deploymentExample.yaml. Si vous avez créé plusieurs déploiements, chacun d’eux doit être supprimé sur une ligne distincte.
- YOUR_PVC_FILE_NAME_HERE : Ajoutez les noms de vos fichiers de revendication de volume persistant. Dans l’exemple de cet article, si vous avez utilisé Cloud Ingest Edge Volume, le nom de fichier utilisé était cloudIngestPVC.yaml. Si vous avez utilisé Local Shared Edge Volume, le nom de fichier utilisé était localSharedPVC.yaml. Si vous avez créé plusieurs revendications PVC, chacune d’elles doit être supprimée sur une ligne distincte.
- YOUR_EDGE_SUBVOLUME_FILE_NAME_HERE : Ajoutez les noms de vos fichiers de sous-volume Edge. Dans l’exemple de cet article, le nom de fichier utilisé était edgeSubvolume.yaml. Si vous avez créé plusieurs sous-volumes, chacun d’eux doit être supprimé sur une ligne distincte.
- YOUR_EDGE_STORAGE_CONFIGURATION_FILE_NAME_HERE : Ajoutez le nom de votre fichier de configuration de stockage Edge ici. Dans l’exemple de cet article, le nom de fichier utilisé était edgeConfig.yaml.
```
kubectl delete -f "<YOUR_DEPLOYMENT_FILE_NAME_HERE.yaml>"
kubectl delete -f "<YOUR_PVC_FILE_NAME_HERE.yaml>"   
kubectl delete -f "<YOUR_EDGE_SUBVOLUME_FILE_NAME_HERE.yaml>"
kubectl delete -f "<YOUR_EDGE_STORAGE_CONFIGURATION_FILE_NAME_HERE.yaml>"
```
Après avoir supprimé les fichiers de vos déploiements, revendications PVC, sous-volumes Edge et configuration de stockage Edge à l’étape précédente, vous pouvez désinstaller l’extension en utilisant la commande suivante. Remplacez YOUR_RESOURCE_GROUP_NAME_HERE, YOUR_CLUSTER_NAME_HERE et YOUR_EXTENSION_NAME_HERE par vos informations respectives :
```
az k8s-extension delete --resource-group YOUR_RESOURCE_GROUP_NAME_HERE --cluster-name YOUR_CLUSTER_NAME_HERE --cluster-type connectedClusters --name YOUR_EXTENSION_NAME_HERE
```

Cluster Kubernetes connecté à Arc

Ces instructions supposent que vous disposez déjà d’un cluster Kubernetes connecté à Arc. Pour connecter un cluster Kubernetes existant à Azure Arc, consultez ces instructions.

Si vous souhaitez utiliser le Stockage de conteneurs Azure activé par Azure Arc avec les Opérations Azure IoT, suivez les instructions pour créer un cluster pour les Opérations Azure IoT.

Clusters à nœud unique et à nœuds multiples

Un cluster à nœud unique est couramment utilisé à des fins de développement ou de test en raison de sa simplicité dans l’installation et les exigences minimales en ressources. Ces clusters offrent un environnement léger et simple pour que les développeurs expérimentent avec Kubernetes sans la complexité d’une configuration à plusieurs nœuds. En outre, dans les situations où les ressources telles que le processeur, la mémoire et le stockage sont limitées, un cluster à nœud unique est plus pratique. Sa facilité d’installation et les exigences minimales des ressources en font un choix approprié dans les environnements limités par les ressources.

Toutefois, les clusters à nœud unique présentent des limitations, principalement sous la forme de fonctionnalités manquantes, notamment leur manque de haute disponibilité, de tolérance de panne, d’extensibilité et de performances.

Une configuration Kubernetes à plusieurs nœuds est généralement utilisée pour les scénarios de production, de préproduction ou à grande échelle en raison de la présence de fonctionnalités comme la haute disponibilité, la tolérance de panne, la scalabilité et les performances. Un cluster à plusieurs nœuds présente également des défis et des compromis, notamment la complexité, la surcharge, le coût et l’efficacité. Par exemple, la configuration et la maintenance d’un cluster à plusieurs nœuds demandent des connaissances, des compétences, des outils et des ressources (réseau, stockage, calcul) supplémentaires. Le cluster doit gérer la coordination et la communication entre les nœuds, ce qui entraîne une latence et des erreurs potentielles. En outre, l’exécution d’un cluster à plusieurs nœuds est plus gourmande en ressources et est plus coûteuse qu’un cluster à nœud unique. L’optimisation de l’utilisation des ressources entre les nœuds est essentielle pour maintenir l’efficacité et les performances du cluster et des applications.

En résumé, un cluster Kubernetes à nœud unique peut convenir aux environnements de développement, de test et limités en ressources. Un cluster à plusieurs nœuds est plus approprié pour les déploiements de production, la haute disponibilité, la scalabilité et les scénarios où des applications distribuées sont requises. Ce choix dépend finalement de vos besoins et objectifs spécifiques pour votre déploiement.

Conditions matérielles minimales requises

Cluster à nœud unique ou à 2 nœuds

Machine virtuelle Standard_D8ds_v5 recommandée
Spécifications équivalentes par nœud :
- 4 CPU
- 16 Go de RAM

Cluster à plusieurs nœuds

Machine virtuelle Standard_D8as_v5 recommandée
Spécifications équivalentes par nœud :
- 8 CPU
- 32 Go de RAM

Une RAM de 32 Go sert de mémoire tampon ; toutefois, une RAM de 16 Go devrait suffire. Les configurations Edge Essentials nécessitent 8 processeurs avec 10 Go de RAM par nœud. Par conséquent, une RAM de 16 Go est le minimum requis.

Stockage minimum requis

Stockage requis pour Edge Volumes

Lorsque vous utilisez l’option de stockage à tolérance de panne, Edge Volumes alloue de l’espace disque venant d’un pool de stockage à tolérance de panne, qui est constitué du stockage exporté par chaque nœud du cluster.

Le pool de stockage est configuré pour utiliser une réplication tridirectionnelle pour garantir la tolérance de panne. Lorsqu’un Edge Volume est approvisionné, il alloue de l’espace disque venant du pool de stockage et alloue le stockage sur 3 des réplicas.

Par exemple, dans un cluster à 3 nœuds avec 20 Go d’espace disque par nœud, le cluster dispose d’un pool de stockage de 60 Go. Toutefois, en raison de la réplication, il a une taille de stockage effective de 20 Go.

Lorsqu’un Edge Volume est approvisionné avec une taille demandée de 10 Go, il alloue un volume système réservé (dimensionné statiquement à 1 Go) et un volume de données (dimensionné à la taille du volume demandé, par exemple 10 Go). Le volume système réservé consomme 3 Go (3 x 1 Go) d’espace disque dans le pool de stockage, tandis que le volume de données consomme 30 Go (3 x 10 Go) d’espace disque dans le pool de stockage, ce qui donne un total de 33 Go.

Stockage requis pour Cache Volumes

Cache Volumes nécessite au moins 4 Go par nœud de stockage. Par exemple, si vous avez un cluster à 3 nœuds, vous avez besoin d’au moins 12 Go de stockage.

Partager via