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.

Meilleures pratiques pour SUSE Rancher Prime les clusters VMware vSphere gérés

Ce guide décrit une architecture de référence pour le provisionnement des clusters Rancher en aval dans un environnement vSphere, en plus des meilleures pratiques standard de vSphere telles que documentées par VMware.

Présentation de la solution
Figure 1. Présentation de la solution

1. Considérations sur les VM

Utilisez des modèles de VM pour construire l’environnement

Pour faciliter la cohérence des machines virtuelles déployées dans l’environnement, envisagez d’utiliser des "images de référence" sous forme de modèles de VM. Packer peut être utilisé pour accomplir cela, ajoutant de plus grandes options de personnalisation.

Utilisez les règles d’anti-affinité DRS (lorsque cela est possible) pour séparer les nœuds de cluster en aval entre les hôtes ESXi.

Cela garantira que les VM des nœuds sont réparties sur plusieurs hôtes ESXi, évitant ainsi un point de défaillance unique au niveau de l’hôte.

Utilisez les règles d’anti-affinité DRS (lorsque cela est possible) pour séparer les nœuds de cluster en aval entre les magasins de données.

Cela garantira que les VM des nœuds sont réparties sur plusieurs magasins de données, évitant ainsi un point de défaillance unique au niveau du magasin de données.

Configurez les VM comme approprié pour Kubernetes

Il est important de suivre les meilleures pratiques de K8s et d’etcd lors du déploiement de vos nœuds, y compris en désactivant le swap, en vérifiant que vous disposez d’une connectivité réseau complète entre toutes les machines du cluster, et en utilisant des noms d’hôtes, des adresses MAC et des product_uuids uniques pour chaque nœud.

2. Considérations réseau

Utilisez une connectivité à faible latence et à large bande entre les nœuds ETCD

Déployez les membres etcd dans un seul centre de données lorsque cela est possible pour éviter les surcoûts de latence et réduire la probabilité de partitionnement du réseau. Pour la plupart des configurations, des connexions de 1 Gb suffiront. Pour les grands clusters, des connexions de 10 Gb peuvent réduire le temps nécessaire pour restaurer à partir d’une sauvegarde.

Adresses IP cohérentes pour les VM

Chaque nœud utilisé doit avoir une adresse IP statique configurée. Dans le cas de DHCP, chaque nœud doit avoir une réservation DHCP pour s’assurer que le nœud obtienne la même adresse IP allouée.

3. Considérations de stockage

Exploiter des disques SSD pour les nœuds ETCD

ETCD est très sensible à la latence d’écriture. Par conséquent, exploitez des disques SSD lorsque cela est possible.

4. Sauvegardes et reprise après sinistre

Effectuez des sauvegardes régulières des clusters en aval.

Kubernetes utilise etcd pour stocker toutes ses données : de la configuration, de l’état et des métadonnées. Sauvegarder cela est crucial en cas de reprise après sinistre.

Sauvegardez les machines virtuelles des nœuds en aval.

Incorporez les machines virtuelles des nœuds en aval de Rancher dans une stratégie de sauvegarde standard des machines virtuelles.