Lors de la création d'un cluster Kubernetes, plusieurs questions peuvent se poser : combien de nœuds de travail configurer et quel type ? Qu'est-ce qui est mieux pour un cluster on-premise : acheter plusieurs serveurs puissants ou utiliser une dizaine de machines anciennes dans votre centre de données ? Et dans le cloud, vaut-il mieux choisir huit instances uniprocesseur ou deux instances quadruple processeur ?
Les réponses à ces questions se trouvent dans l'article dans la traduction de l'équipe .
Capacité du cluster
En général, un cluster Kubernetes peut être vu comme un grand « super-nœud ». Sa puissance de calcul totale est la somme des puissances de tous les nœuds qui le composent.
Il existe plusieurs façons d'atteindre la capacité cible souhaitée du cluster. Par exemple, nous avons besoin d'un cluster avec une capacité totale de 8 cœurs CPU et 32 Go de RAM, car l'ensemble d'applications nécessite cette quantité de ressources. On peut alors configurer deux nœuds de 16 Go de RAM ou quatre nœuds de 8 Go, avec soit deux processeurs quadruple cœur, soit quatre processeurs double cœur.
Voici juste deux façons possibles de créer un cluster :
Les deux options donnent un cluster avec la même capacité, mais la configuration du bas contient quatre nœuds plus petits, tandis que la configuration du haut contient deux grands nœuds.
Quelle option est la meilleure ?
Pour répondre à cette question, examinons les avantages de chaque option. Nous les avons résumés dans un tableau.
Plusieurs grands nœuds
Beaucoup de petits nœuds
Gestion du cluster plus simple (s'il est on-premise)
Mise à l'échelle automatique fluide
Moins cher (s'il est on-premise)
Le prix est à peine différent (dans le cloud)
Peut exécuter des applications gourmandes en ressources
Réplicabilité complète
Les ressources sont utilisées plus efficacement (moins de surcharge pour les démons système)
Meilleure résilience du cluster
Notez que nous parlons uniquement des nœuds de travail. Le choix du nombre et de la taille des nœuds principaux est un sujet totalement différent.
Donc, examinons plus en détail chaque point du tableau.
Première option : plusieurs grands nœuds
La manière la plus extrême est d'avoir un seul nœud de travail pour l'ensemble de la capacité du cluster. Dans l'exemple ci-dessus, cela aurait été un nœud de travail avec 16 cœurs CPU et 16 Go de RAM.
Avantages
Avantage n° 1. Gestion plus simple
Il est plus facile de gérer plusieurs machines que tout un parc. Les mises à jour et les corrections sont plus rapides à appliquer et la synchronisation est plus simple. Le nombre d'incidents en chiffres absolus est également moindre.
Veuillez noter que tout ce qui précède concerne votre propre matériel, vos propres serveurs, et non les instances cloud.
La situation est différente dans le cloud. Là, la gestion est assurée par le fournisseur de services cloud. En conséquence, gérer dix nœuds dans le cloud ne diffère guère de la gestion d'un unique nœud.
La routage du trafic et la répartition de la charge entre les pods dans le cloud : le trafic entrant d'Internet est dirigé vers le répartiteur de charge principal, qui redirige le trafic vers le port de l'un des nœuds (le service NodePort expose un port dans la plage 30000-32767 sur chaque nœud du cluster). Les règles établies par kube-proxy redirigent le trafic du nœud vers le pod. Voici à quoi cela ressemble pour dix pods sur deux nœuds :
Avantage n° 2. Moins de coûts par nœud
Une machine puissante coûte plus cher, mais la hausse des prix n'est pas nécessairement linéaire. En d'autres termes, un serveur à dix cœurs avec 10 Go de mémoire est généralement moins cher que dix serveurs à un cœur avec la même quantité de mémoire.
Mais veuillez noter que cette règle ne s'applique généralement pas aux services cloud. Dans les schémas de tarification actuels de tous les principaux fournisseurs de services cloud, les prix augmentent linéairement avec la capacité.
Ainsi, dans le cloud, il n'est généralement pas possible de faire des économies sur des serveurs plus puissants.
Avantage n° 3. Possibilité d'exécuter des applications gourmandes en ressources
Certaines applications nécessitent des serveurs puissants dans le cluster. Par exemple, si un système d'apprentissage automatique nécessite 8 Go de mémoire, vous ne pourrez pas l'exécuter sur des nœuds de 1 Go, sauf si vous avez au moins un grand nœud de travail.
Inconvénients
Inconvénient n° 1. Beaucoup de pods par nœud
Si la même tâche est effectuée sur un plus petit nombre de nœuds, il y aura naturellement plus de pods sur chacun d'eux.
Cela peut poser problème.
La raison en est que chaque module entraîne des frais généraux pour l'environnement d'exécution des conteneurs (par exemple, Docker), ainsi que pour kubelet et cAdvisor.
Par exemple, kubelet sonde régulièrement la disponibilité de tous les conteneurs sur le nœud - plus il y a de conteneurs, plus le travail pour kubelet est important.
CAdvisor collecte des statistiques sur l'utilisation des ressources de tous les conteneurs sur le nœud, et kubelet demande régulièrement ces informations et les fournit via l'API. Encore une fois, plus il y a de conteneurs, plus le travail augmente pour cAdvisor et kubelet.
Si le nombre de modules augmente, cela peut ralentir le système et même compromettre sa fiabilité.
Dans le dépôt Kubernetes, certains , que les nœuds fluctuent entre les statuts Ready/NotReady, car les vérifications régulières de kubelet pour tous les conteneurs sur le nœud prennent trop de temps.
Pour cette raison, Kubernetes . En fonction de la performance du nœud, vous pouvez exécuter plus de pods par nœud, mais il est difficile de prédire si des problèmes surviendront ou si tout fonctionnera bien. Il est recommandé de tester le fonctionnement à l'avance.
Inconvénient n° 2. Limite de réplication
Un nombre trop réduit de nœuds limite le degré efficace de réplication des applications. Par exemple, si vous avez une application à haute disponibilité composée de cinq répliques, mais seulement deux nœuds, le degré efficace de réplication de l'application est réduit à deux.
Cinq répliques ne peuvent être réparties que sur deux nœuds, et si l'un d'eux tombe en panne, plusieurs répliques sont immédiatement hors service.
Si vous avez cinq nœuds ou plus, chaque réplique sera exécutée sur un nœud distinct, et la défaillance d'un nœud n'éliminera qu'une seule réplique.
Ainsi, les exigences de haute disponibilité peuvent nécessiter un nombre minimum de nœuds dans le cluster.
Inconvénient n° 3. Conséquences plus graves en cas de défaillance
Avec un faible nombre de nœuds, chaque défaillance a des conséquences plus importantes. Par exemple, si vous avez seulement deux nœuds, et que l'un d'eux tombe en panne, la moitié de vos modules est immédiatement hors service.
Bien sûr, Kubernetes déplacera la charge de travail du nœud défaillant vers d'autres. Mais s'ils sont peu nombreux, il se peut qu'il n'y ait pas assez de capacité disponible. En conséquence, une partie de vos applications sera inaccessible tant que vous ne redémarrez pas le nœud défaillant.
Ainsi, plus il y a de nœuds, moins l'impact des défaillances matérielles est important.
Inconvénient n° 4. Plus de démarches d'autoscaling
Dans Kubernetes, un système d'autoscaling de cluster fonctionne pour l'infrastructure cloud, ce qui permet d'ajouter ou de supprimer automatiquement des nœuds en fonction des besoins actuels. Avec de grands nœuds, l'autoscaling devient plus abrupt et maladroit. Par exemple, sur deux nœuds, l'ajout d'un nœud supplémentaire augmentera la capacité du cluster de 50 % immédiatement. Et vous devrez payer pour ces ressources, même si vous n'en avez pas besoin.
Ainsi, si vous prévoyez d'utiliser l'autoscaling de cluster, plus les nœuds sont petits, plus l'échelle se révèle flexible et économique.
Examinons maintenant les avantages et les inconvénients d'un grand nombre de petits nœuds.
Deuxième option : de nombreux petits nœuds
Les avantages de cette approche découlent essentiellement des inconvénients de l'option opposée avec quelques grands nœuds.
Avantages
Avantage n° 1. Moins de conséquences en cas de défaillance
Plus il y a de nœuds, moins il y a de pods sur chaque nœud. Par exemple, si vous avez cent modules sur dix nœuds, alors en moyenne, il y aura dix modules sur chaque nœud.
Ainsi, si l'un des nœuds tombe en panne, vous ne perdez que 10 % de la charge de travail. Il est probable qu'un petit nombre de répliques soit touché, et les applications restent globalement opérationnelles.
De plus, sur les nœuds restants, il y a fort à parier qu'il y a suffisamment de ressources libres pour la charge de travail du nœud en panne, permettant ainsi à Kubernetes de reprogrammer les pods sans problème, et vos applications retrouveront un état fonctionnel relativement rapidement.
Avantage n° 2. Bonne réplication
S'il y a suffisamment de nœuds, le planificateur Kubernetes peut attribuer toutes les répliques à des nœuds différents. Ainsi, en cas de défaillance d'un nœud, une seule réplique est touchée, et l'application reste disponible.
Inconvénients
Inconvénient n° 1. Gestion plus difficile
Gérer un grand nombre de nœuds est plus compliqué. Par exemple, chaque nœud Kubernetes doit interagir avec tous les autres, ce qui signifie que le nombre de connexions croît de manière quadratique, et toutes ces connexions doivent être suivies.
Le contrôleur de nœuds dans le contrôleur manager Kubernetes parcourt régulièrement tous les nœuds du cluster pour vérifier leur état de fonctionnement — plus il y a de nœuds, plus la charge sur le contrôleur est élevée.
La charge sur la base de données etcd augmente également — chaque kubelet et kube-proxy appelle pour etcd (via l'API), auquel etcd doit transmettre les mises à jour d'objet.
En général, chaque nœud de travail impose une charge supplémentaire sur les composants système des nœuds maîtres.
Officiellement, Kubernetes prend en charge des clusters avec Cependant, en pratique, déjà 500 nœuds .
Pour gérer un grand nombre de nœuds de travail, il est préférable de choisir des nœuds maîtres plus performants. Par exemple, kube-up la taille correcte de la machine virtuelle pour le nœud maître en fonction du nombre de nœuds de travail. C'est-à-dire que plus il y a de nœuds de travail, plus les nœuds maîtres doivent être performants.
Pour résoudre ces problèmes spécifiques, il existe des développements spéciaux, tels que Ce système permet de contourner les limitations et de construire des clusters avec un nombre énorme de nœuds de travail.
Inconvénient n° 2. Plus de frais généraux.
Sur chaque nœud de travail, Kubernetes exécute un ensemble de démons système — cela inclut l'environnement d'exécution des conteneurs (par exemple, Docker), kube-proxy et kubelet, y compris cAdvisor. Ensemble, ils consomment une certaine quantité fixe de ressources.
Si vous avez beaucoup de petits nœuds, la part de ces frais généraux sur chaque nœud est plus importante. Par exemple, imaginez que tous les démons système d'un nœud consomment ensemble 0,1 cœur de processeur et 0,1 Go de mémoire. Si vous avez un nœud décacœur avec 10 Go de mémoire, alors les démons consomment 1 % de la capacité du cluster. En revanche, sur dix nœuds monocores avec 1 Go de mémoire, les démons prendront 10 % de la capacité du cluster.
Ainsi, moins il y a de nœuds, plus l'infrastructure est utilisée efficacement.
Inconvénient n° 3. Utilisation inefficace des ressources.
Sur de petits nœuds, il se peut que les fragments de ressources restants soient trop petits pour leur attribuer une charge de travail, donc ils restent inutilisés.
Par exemple, chaque pod nécessite 0,75 Go de mémoire. Si vous avez dix nœuds et que chacun a 1 Go de mémoire, vous pouvez exécuter dix pods — au final, il restera 0,25 Go de mémoire inutilisée sur chaque nœud.
Cela signifie que 25 % de la mémoire totale du cluster est gaspillée.
Sur un grand nœud avec 10 Go de mémoire, vous pouvez exécuter 13 de ces modules — et il ne restera qu'un seul fragment inutilisé de 0,25 Go.
Dans ce cas, seulement 2,5 % de la mémoire est gaspillée.
Ainsi, les ressources sont mieux utilisées sur de grands nœuds.
Plusieurs grands nœuds ou beaucoup de petits ?
Alors, qu'est-ce qui est mieux : plusieurs grands nœuds dans un cluster ou beaucoup de petits ? Comme toujours, il n'y a pas de réponse unique. Tout dépend du type d'application.
Par exemple, si une application nécessite 10 Go de mémoire, le choix en faveur de grands nœuds est évident. Et si l'application nécessite une réplication dix fois pour une haute disponibilité, il serait risqué de placer les répliques uniquement sur deux nœuds - un cluster devrait avoir au moins dix nœuds.
Dans les situations intermédiaires, faites un choix en fonction des avantages et des inconvénients de chaque option. Certains arguments peuvent être plus pertinents pour votre situation que d'autres.
Il n'est pas nécessaire de rendre tous les nœuds de la même taille. Rien n'empêche d'expérimenter d'abord avec des nœuds de même taille, puis d'ajouter des nœuds d'une autre taille, en les combinant dans le cluster. Les nœuds de travail du cluster Kubernetes peuvent être entièrement hétérogènes. Vous pouvez donc essayer de combiner les avantages des deux approches.
Il n'existe pas de recette unique, chaque situation ayant ses nuances, et seule la production montrera la vérité.
La traduction a été préparée par l'équipe de la plateforme cloud .
Encore sur Kubernetes : .
Source : habr.com
