Lors de la création d’un cluster Kubernetes, des questions peuvent se poser : combien de nœuds de travail configurer et de quel type ? Quoi de mieux pour un cluster on-premise : acheter plusieurs serveurs puissants ou utiliser une douzaine de vieilles machines dans votre data center ? Est-il préférable de prendre huit instances monocœur ou deux instances quadricœurs dans le cloud ?
Les réponses à ces questions se trouvent dans l'article. dans la traduction de la commande .
Capacité du cluster
En général, un cluster Kubernetes peut être considéré comme un grand « super-nœud ». Sa puissance de calcul totale est la somme des puissances de tous ses nœuds constitutifs.
Il existe plusieurs façons d'atteindre l'objectif de capacité de cluster souhaité. Par exemple, nous avons besoin d'un cluster d'une capacité totale de 8 cœurs de processeur et de 32 Go de RAM car un ensemble d'applications nécessite beaucoup de ressources. Ensuite, vous pouvez installer deux nœuds avec 16 Go de mémoire ou quatre nœuds avec 8 Go de mémoire, deux processeurs quad-core ou quatre dual-core.
Voici deux manières possibles de créer un cluster :
Les deux options produisent un cluster de même capacité, mais la configuration inférieure comporte quatre nœuds plus petits et la configuration supérieure comporte deux nœuds plus grands.
Quelle option est la meilleure ?
Pour répondre à cette question, examinons les avantages des deux options. Nous les avons résumés dans un tableau.
Plusieurs gros nœuds
Beaucoup de petits nœuds
Gestion du cluster plus facile (s'il est sur site)
Mise à l'échelle automatique fluide
Moins cher (si sur site)
Le prix est un peu différent (dans le cloud)
Peut exécuter des applications gourmandes en ressources
Réplication complète
Les ressources sont utilisées plus efficacement (moins de surcharge sur les démons système
Tolérance aux pannes de cluster plus élevée
Veuillez noter que nous ne parlons que de nœuds de travail. Choisir le nombre et la taille des nœuds principaux est un tout autre sujet.
Discutons donc de chaque point du tableau plus en détail.
Première option : plusieurs gros nœuds
L'option la plus extrême consiste à utiliser un seul nœud de travail pour toute la capacité du cluster. Dans l'exemple ci-dessus, il s'agirait d'un seul nœud de travail doté de 16 cœurs de processeur et de 16 Go de RAM.
Avantages
Plus n°1. Une gestion plus simple
Il est plus facile de gérer quelques machines que toute une flotte. Il est plus rapide de déployer des mises à jour et des correctifs, et plus facile à synchroniser. Le nombre d’échecs en chiffres absolus est également moindre.
Veuillez noter que tout ce qui précède s'applique à votre matériel, à vos serveurs et non aux instances cloud.
La situation est différente dans le cloud. Là, la gestion est assurée par le fournisseur de services cloud. Ainsi, gérer dix nœuds dans le cloud n’est pas très différent de gérer un seul nœud.
Routage du trafic et répartition de la charge entre les pods dans le cloud : le trafic provenant d'Internet est envoyé à l'équilibreur de charge principal, qui transfère le trafic vers le port de l'un des nœuds (le service NodePort définit le port dans la plage 30000-32767 dans chaque nœud du cluster). Les règles définies 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ût par nœud
Une voiture puissante coûte plus cher, mais la hausse des prix n’est pas forcément 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 monocœur avec la même quantité de mémoire.
Mais notez que cette règle ne fonctionne généralement pas dans les services cloud. Dans les systèmes tarifaires actuels de tous les principaux fournisseurs de cloud, les prix augmentent linéairement avec la capacité.
Ainsi, dans le cloud, vous ne pouvez généralement pas économiser sur des serveurs plus puissants.
Avantage n°3 : Vous pouvez exécuter des applications gourmandes en ressources
Certaines applications nécessitent des serveurs puissants dans un cluster. Par exemple, si un système de machine learning nécessite 8 Go de mémoire, vous ne pourrez pas l'exécuter sur des nœuds de 1 Go, mais uniquement avec au moins un nœud de travail de grande taille.
Moins
Inconvénient n°1. De nombreux pods par nœud
Si la même tâche est effectuée sur moins de nœuds, alors chacun d’eux aura naturellement plus de pods.
Cela pourrait poser un problème.
La raison en est que chaque module introduit une surcharge dans le runtime du conteneur (par exemple Docker), ainsi que dans le kubelet et le cAdvisor.
Par exemple, un kubelet sonde régulièrement tous les conteneurs d'un nœud pour vérifier leur capacité de survie : plus il y a de conteneurs, plus le kubelet doit effectuer du travail.
CAdvisor collecte des statistiques d'utilisation des ressources pour tous les conteneurs d'un nœud, et kubelet interroge régulièrement ces informations et les fournit via une API. Encore une fois, plus de conteneurs signifie plus de travail pour cAdvisor et kubelet.
Si le nombre de modules augmente, cela peut ralentir le système et même nuire à sa fiabilité.
Dans le dépôt Kubernetes, certains que les nœuds sautent entre les statuts Prêt/NotReady car les vérifications kubelet régulières de tous les conteneurs sur un nœud prennent trop de temps.
Pour cette raison Kubernetes . En fonction des performances du nœud, vous pouvez exécuter plus de pods par nœud, mais il est difficile de prédire s'il y aura des problèmes ou si tout fonctionnera correctement. Cela vaut la peine de tester le travail à l'avance.
Inconvénient n°2. Limitation de la réplication
Trop peu de nœuds limitent l’étendue effective de la réplication des applications. Par exemple, si vous disposez d'une application haute disponibilité avec cinq réplicas mais seulement deux nœuds, le degré de réplication effectif de l'application est réduit à deux.
Cinq réplicas ne peuvent être distribués que sur deux nœuds, et si l'un d'eux échoue, il supprime plusieurs réplicas à la fois.
Si vous disposez de cinq nœuds ou plus, chaque réplique s'exécutera sur un nœud distinct et la défaillance d'un nœud supprimera au plus une réplique.
Ainsi, les exigences de haute disponibilité peuvent nécessiter un certain nombre minimum de nœuds dans le cluster.
Inconvénient n°3. Pires conséquences de l'échec
Avec un petit nombre de nœuds, chaque panne a des conséquences plus graves. Par exemple, si vous n'avez que deux nœuds et que l'un d'eux tombe en panne, la moitié de vos modules disparaissent immédiatement.
Bien entendu, Kubernetes migrera la charge de travail du nœud défaillant vers d’autres. Mais s’il y en a peu, il se peut qu’il n’y ait pas suffisamment de capacité libre. Par conséquent, certaines de vos applications seront indisponibles jusqu'à ce que vous ayez affiché le nœud défaillant.
Ainsi, plus il y a de nœuds, moins l’impact des pannes matérielles est important.
Inconvénient n°4 : plus d'étapes de mise à l'échelle automatique
Kubernetes dispose d'un système de mise à l'échelle automatique de cluster pour l'infrastructure cloud, qui vous permet d'ajouter ou de supprimer automatiquement des nœuds en fonction de vos besoins actuels. Avec des nœuds plus gros, la mise à l’échelle automatique devient plus abrupte et maladroite. Par exemple, sur deux nœuds, l'ajout d'un nœud supplémentaire augmentera immédiatement la capacité du cluster de 50 %. Et vous devrez payer pour ces ressources, même si vous n’en avez pas besoin.
Ainsi, si vous envisagez d'utiliser la mise à l'échelle automatique du cluster, plus les nœuds sont petits, plus vous obtiendrez une mise à l'échelle flexible et rentable.
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 proviennent essentiellement des inconvénients de l’option inverse avec plusieurs gros nœuds.
Avantages
Avantage n°1 : Moins d’impact de l’échec
Plus il y a de nœuds, moins il y a de pods sur chaque nœud. Par exemple, si vous disposez de cent modules pour dix nœuds, chaque nœud aura en moyenne dix modules.
De cette façon, si l’un des nœuds tombe en panne, vous ne perdez que 10 % de la charge de travail. Il y a de fortes chances que seul un petit nombre de réplicas soient concernés et que l’application globale reste opérationnelle.
De plus, les nœuds restants disposeront probablement de suffisamment de ressources libres pour gérer la charge de travail du nœud défaillant, de sorte que Kubernetes puisse librement replanifier les pods et vos applications reviendront à un état fonctionnel relativement rapidement.
Avantage n°2 : bonne réplication
S'il y a suffisamment de nœuds, le planificateur Kubernetes peut attribuer différents nœuds à toutes les répliques. De cette façon, si un nœud tombe en panne, une seule réplique sera affectée et l'application restera disponible.
Moins
Inconvénient n°1. Difficile à contrôler
Un grand nombre de nœuds est plus difficile à gérer. Par exemple, chaque nœud Kubernetes doit communiquer avec tous les autres, c'est-à-dire que le nombre de connexions augmente quadratiquement et que toutes ces connexions doivent être suivies.
Le contrôleur de nœuds dans Kubernetes Controller Manager parcourt régulièrement tous les nœuds du cluster pour vérifier l'état : plus il y a de nœuds, plus la charge sur le contrôleur est importante.
La charge sur la base de données etcd augmente également - chaque appel kubelet et kube-proxy pour etcd (via l'API), auquel etcd doit diffuser les mises à jour des objets.
En général, chaque nœud travailleur impose une charge supplémentaire sur les composants système des nœuds maîtres.
Kubernetes prend officiellement en charge les clusters avec . Or, en pratique, il existe déjà 500 nœuds .
Pour gérer un grand nombre de nœuds de travail, vous devez choisir des nœuds maîtres plus puissants. Par exemple, kube-up la taille de machine virtuelle correcte pour le nœud maître en fonction du nombre de nœuds de travail. Autrement dit, plus il y a de nœuds de travail, plus les nœuds maîtres doivent être productifs.
Pour résoudre ces problèmes spécifiques, il existe des développements spéciaux, tels que . Ce système vous permet de contourner les restrictions et de créer des clusters avec un grand nombre 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 : ceux-ci incluent le runtime du conteneur (tel que Docker), kube-proxy et kubelet, y compris cAdvisor. Ensemble, ils consomment une certaine quantité fixe de ressources.
Si vous disposez de nombreux petits nœuds, la proportion de cette surcharge sur chaque nœud est plus importante. Par exemple, imaginez que tous les démons système sur un seul nœud utilisent ensemble 0,1 cœurs de processeur et 0,1 Go de mémoire. Si vous disposez d'un nœud à dix cœurs avec 10 Go de mémoire, les démons consomment 1 % de la capacité du cluster. En revanche, sur dix nœuds monocœur dotés de 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 les petits nœuds, il se peut que les morceaux de ressources restants soient trop petits pour qu'on puisse leur attribuer une charge de travail, et qu'ils restent donc inutilisés.
Par exemple, chaque pod nécessite 0,75 Go de mémoire. Si vous disposez de dix nœuds, chacun avec 1 Go de mémoire, vous pouvez exécuter dix pods, laissant à chaque nœud 0,25 Go de mémoire inutilisée.
Cela signifie que 25 % de la mémoire totale du cluster est gaspillée.
Sur un gros nœud doté de 10 Go de mémoire, vous pouvez exécuter 13 de ces modules - et il n'y aura 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 utilisées de manière plus optimale sur les nœuds plus grands.
Plusieurs gros nœuds ou plusieurs petits nœuds ?
Alors, quel est le meilleur choix : quelques gros nœuds dans un cluster ou plusieurs petits nœuds ? Comme toujours, il n’y a pas de réponse claire. Tout dépend du type d'application.
Par exemple, si une application nécessite 10 Go de mémoire, des nœuds plus grands constituent un choix évident. Et si l'application nécessite une réplication décuplée pour une haute disponibilité, cela ne vaut guère la peine de prendre le risque de placer des répliques sur seulement deux nœuds : il doit y avoir un minimum de dix nœuds dans le cluster.
Dans les situations intermédiaires, faites un choix en fonction des avantages et des inconvénients de chaque option. Peut-être que certains arguments sont plus pertinents que d’autres à votre situation.
Et il n'est pas du tout nécessaire que tous les nœuds aient la même taille. Rien ne vous empêche d'expérimenter d'abord avec des nœuds de même taille, puis de leur ajouter des nœuds de taille différente, en les combinant dans un cluster. Les nœuds de travail dans un cluster Kubernetes peuvent être complètement hétérogènes. Vous pouvez donc essayer de combiner les avantages des deux approches.
Il n’y a pas de recette unique, chaque situation a ses propres nuances et seule la production montrera la vérité.
Traduction préparée par l'équipe de la plateforme cloud .
En savoir plus sur Kubernetes : .
Source: habr.com