Optimisation et meilleures pratiques pour SUSE Rancher Prime à grande échelle

Les recommandations décrites dans le recommandations générales pour Rancher sont particulièrement importantes dans un contexte de grande échelle.

Etcd est la base de données sous-jacente pour Kubernetes et pour Rancher. La base de données peut éventuellement rencontrer des limitations quant au nombre d’un seul type de ressource Kubernetes qu’elle peut stocker. Les limites exactes varient et dépendent de plusieurs facteurs. Cependant, l’expérience indique que des problèmes de performance surviennent fréquemment lorsque le nombre d’objets d’un seul type de ressource dépasse 60 000. Souvent, ce type est RoleBinding.

C’est typique dans Rancher, car de nombreuses opérations créent de nouveaux objets RoleBinding dans le cluster en amont comme effet secondaire.

Vous pouvez réduire le nombre de RoleBindings dans le cluster en amont de la manière suivante :

Si vous avez cinquante utilisateurs ou plus, vous devez configurer un fournisseur d’authentification externe. C’est nécessaire pour de meilleures performances.

Après avoir configuré l’authentification externe, assurez-vous d’attribuer des permissions aux groupes plutôt qu’aux utilisateurs individuels. Cela aide à réduire le nombre d’objets RoleBinding.

Prédire combien d’objets RoleBinding une configuration donnée créera est compliqué. Cependant, les considérations suivantes peuvent offrir une estimation approximative :

Rancher utilise deux ressources d’application Kubernetes : apps.projects.cattle.io et apps.cattle.cattle.io. Les applications héritées, représentées par apps.projects.cattle.io, ont été introduites avec l’ancienne interface utilisateur du gestionnaire de cluster et sont désormais obsolètes. Les applications actuelles, représentées par apps.catalog.cattle.io, se trouvent dans l’interface utilisateur de l’explorateur de cluster pour leur cluster respectif. Les applications Apps.cattle.cattle.io sont préférables car leurs données résident dans des clusters en aval, ce qui libère des ressources dans le cluster en amont.

Vous devez supprimer toutes les applications héritées restantes qui apparaissent dans l’interface utilisateur du gestionnaire de cluster et les remplacer par des applications dans l’interface utilisateur de l’explorateur de cluster. Créez toutes les nouvelles applications uniquement dans l’interface utilisateur de l’explorateur de cluster.

Un Point de terminaison de cluster autorisé (ACE) fournit un accès à l’API Kubernetes des clusters RKE2 et K3s provisionnés par Rancher. Lorsqu’il est activé, l’ACE ajoute un contexte aux fichiers kubeconfig générés pour le cluster. Le contexte utilise un point de terminaison direct vers le cluster, contournant ainsi Rancher. Cela réduit la charge sur Rancher dans les cas où l’accès API non médié est acceptable ou préférable. Voir Point de terminaison de cluster autorisé pour plus d’informations et d’instructions de configuration.

La majeure partie de la logique de Rancher se déroule sur les gestionnaires d’événements. Ces gestionnaires d’événements s’exécutent sur un objet chaque fois que l’objet est mis à jour, et lorsque Rancher est démarré. De plus, ils s’exécutent toutes les 10 heures lorsque Rancher synchronise les caches. Dans les configurations à grande échelle, ces exécutions programmées entraînent d’énormes coûts de performance car chaque gestionnaire est exécuté sur chaque objet applicable. Cependant, l’exécution programmée des gestionnaires peut être désactivée avec la variable d’environnement CATTLE_SYNC_ONLY_CHANGED_OBJECTS. Si des pics d’allocation de ressources sont observés toutes les 10 heures, ce paramètre peut aider.

La valeur pour CATTLE_SYNC_ONLY_CHANGED_OBJECTS peut être une liste séparée par des virgules des options suivantes. Les valeurs se réfèrent aux types de gestionnaires et de contrôleurs (les structures qui contiennent et exécutent des gestionnaires). Ajouter les types de contrôleurs à la variable désactive cet ensemble de contrôleurs de l’exécution de leurs gestionnaires dans le cadre de la resynchronisation du cache.

En résumé, si vous remarquez des pics d’utilisation du CPU toutes les 10 heures, ajoutez la variable d’environnement CATTLE_SYNC_ONLY_CHANGED_OBJECTS à votre déploiement Rancher (dans la liste spec.containers.env) avec la valeur mgmt,user.

Comme Rancher peut être très exigeant sur le cluster en amont, surtout à grande échelle, vous devez avoir un contrôle administratif complet sur la configuration et les nœuds du cluster. Pour identifier la cause profonde de la consommation excessive de ressources, utilisez des techniques et des outils de dépannage Linux standard. Cela peut aider à distinguer si Rancher, Kubernetes ou les composants du système d’exploitation causent des problèmes.

Bien que les services Kubernetes gérés facilitent le déploiement et l’exécution des clusters Kubernetes, ils sont déconseillés pour le cluster en amont dans des scénarios à grande échelle. Les services Kubernetes gérés limitent généralement l’accès à la configuration et aux informations sur les nœuds et services individuels.

Utilisez RKE2 pour des cas d’utilisation à grande échelle.

Pour assurer une haute disponibilité, Kubernetes est conçu pour exécuter des nœuds et des composants de contrôle dans différentes zones. Cependant, si les nœuds et les composants du plan de contrôle sont situés dans différentes zones, le trafic réseau peut être plus lent.

Le trafic entre les composants Rancher et l’API Kubernetes est particulièrement sensible à la latence réseau, tout comme le trafic etcd entre les nœuds.

Pour améliorer les performances, exécutez tous les clusters de nœuds en amont au même endroit. En particulier, assurez-vous que la latence entre les nœuds etcd et Rancher est aussi faible que possible.

Vous devez garder le cluster Kubernetes local à jour. Cela garantira que votre cluster dispose de toutes les améliorations de performance et des correctifs disponibles.

Etcd est la base de données backend pour Kubernetes et pour Rancher. Il joue un rôle très important dans la performance de Rancher.

Les deux principaux goulets d’étranglement de la performance de etcd sont la vitesse du disque et celle du réseau. Etcd doit fonctionner sur des nœuds dédiés avec une configuration réseau rapide et des SSD ayant un nombre élevé d’opérations d’entrée/sortie par seconde (IOPS). Pour plus d’informations concernant la performance d’etcd, consultez Performance lente d’etcd (tests de performance et optimisation) et Optimisation d’etcd pour de grandes installations. Des informations sur les disques peuvent également être trouvées dans le Exigences d’installation.

Il est préférable de faire fonctionner etcd sur exactement trois nœuds, car l’ajout de nœuds supplémentaires réduira la vitesse d’opération. Cela peut sembler contre-intuitif par rapport aux approches de mise à l’échelle courantes, mais c’est dû aux mécanismes de réplication d’etcd.

La performance d’etcd sera également affectée négativement par la latence réseau entre les nœuds, car cela ralentira la communication réseau. Les nœuds etcd doivent être situés avec les nœuds Rancher.

À grande échelle, Rancher transfère plus de données du cluster en amont vers les composants de l’interface utilisateur fonctionnant dans le navigateur, et ces composants doivent également effectuer davantage de traitement.

Pour une performance optimale, assurez-vous que l’hôte exécutant le matériel répond à ces exigences :