Un cluster est un ensemble de nœuds (machines physiques ou virtuelles) exécutant des agents Kubernetes, et gérés par le plan de contrôle.
Kubernetes v1.36 prend en charge des clusters pouvant aller jusqu’à 5 000 nœuds. Plus précisément, Kubernetes est conçu pour fonctionner avec des configurations respectant toutes les limites suivantes :
Vous pouvez faire évoluer votre cluster en ajoutant ou en supprimant des nœuds. La manière de procéder dépend du mode de déploiement de votre cluster.
Pour éviter de rencontrer des problèmes de quotas chez les fournisseurs cloud lors de la création d’un cluster comportant de nombreux nœuds, il est recommandé de :
Pour un grand cluster, vous devez disposer d’un plan de contrôle avec suffisamment de ressources de calcul et autres.
En général, il est recommandé d’exécuter une ou deux instances de plan de contrôle par zone de disponibilité, en commençant par un dimensionnement vertical, puis en passant à un dimensionnement horizontal lorsque les gains de performance deviennent faibles.
Vous devez exécuter au moins une instance par zone de disponibilité pour assurer la tolérance aux pannes. Les nœuds Kubernetes ne redirigent pas automatiquement le trafic vers les points de terminaison du plan de contrôle situés dans la même zone de défaillance ; cependant, votre fournisseur cloud peut proposer ses propres mécanismes pour cela.
Par exemple, avec un load balancer managé, vous pouvez configurer celui-ci pour diriger le trafic provenant du kubelet et des pods d’une zone de défaillance A uniquement vers les nœuds du plan de contrôle situés dans la même zone A. Si un nœud du plan de contrôle ou une zone entière devient indisponible, le trafic du plan de contrôle pour cette zone est alors redirigé entre zones. Exécuter plusieurs instances du plan de contrôle dans chaque zone réduit ce risque.
Pour améliorer les performances des grands clusters, vous pouvez stocker les objets Event dans une instance etcd dédiée séparée.
Lors de la création d’un cluster, vous pouvez (via des outils personnalisés) :
Voir Exploiter des clusters etcd pour Kubernetes et Configurer un cluster etcd haute disponibilité avec kubeadm pour plus de détails sur la configuration et la gestion d’etcd pour un grand cluster.
Les limites de ressources Kubernetes permettent de réduire l’impact des fuites mémoire et d’autres comportements des pods et conteneurs sur les autres composants. Ces limites s’appliquent également aux ressources des addons comme elles s’appliquent aux charges de travail applicatives.
Par exemple, vous pouvez définir des limites CPU et mémoire pour un composant de logging :
...
containers:
- name: fluentd-cloud-logging
image: fluent/fluentd-kubernetes-daemonset:v1
resources:
limits:
cpu: 100m
memory: 200Mi
Les limites par défaut des addons sont généralement basées sur l’expérience des clusters de petite ou moyenne taille. Dans les grands clusters, les addons consomment souvent plus de ressources que prévu. Sans ajustement, ils peuvent être constamment redémarrés en raison des limites mémoire, ou fonctionner avec de mauvaises performances à cause des restrictions CPU.
Pour éviter ces problèmes, lors de la création d’un cluster avec de nombreux nœuds, il est recommandé de :
Pour garantir que les composants essentiels du cluster (comme CoreDNS, metrics-server et autres addons critiques) soient planifiés avant les autres charges de travail et ne soient pas préemptés, ils doivent être exécutés avec une PriorityClass système, comme system-cluster-critical ou system-node-critical.
VerticalPodAutoscaler est une ressource personnalisée que vous pouvez déployer dans votre cluster pour vous aider à gérer les requests et limits des pods.
En savoir plus sur le Vertical Pod Autoscaler
et comment l’utiliser pour dimensionner les composants du cluster, y compris les addons critiques.
Lire sur l’autoscaling des nœuds
Le addon resizer vous aide à redimensionner automatiquement les addons en fonction de la taille de votre cluster.