Noter. trad.: ce matériel est issu d'un projet pédagogique est la réponse à une question courante lors de la conception d’une infrastructure basée sur Kubernetes. Nous espérons que des descriptions assez détaillées des avantages et des inconvénients de chaque option vous aideront à faire le meilleur choix pour votre projet.
TL; DR: le même ensemble de charges de travail peut être exécuté sur plusieurs grands clusters (chaque cluster aura un grand nombre de charges de travail) ou sur plusieurs petits (avec un petit nombre de charges dans chaque cluster).
Vous trouverez ci-dessous un tableau qui évalue les avantages et les inconvénients de chaque approche :
Lorsque vous utilisez Kubernetes comme plate-forme pour exécuter des applications, plusieurs questions fondamentales se posent souvent concernant les subtilités de la configuration des clusters :
- Combien de clusters dois-je utiliser ?
- Quelle taille dois-je leur faire ?
- Que doit inclure chaque cluster ?
Dans cet article, je vais tenter de répondre à toutes ces questions en analysant les avantages et les inconvénients de chaque approche.
Énoncé d'une question
En tant que développeur de logiciels, vous développez et exploitez probablement de nombreuses applications en même temps.
En outre, de nombreuses instances de ces applications sont susceptibles de s'exécuter dans des environnements différents - par exemple, celles-ci peuvent être dev, tester и poussée.
Le résultat est toute une matrice d’applications et d’environnements :
Applications et environnements
L'exemple ci-dessus représente 3 applications et 3 environnements, ce qui donne un total de 9 options possibles.
Chaque instance d'application est une unité de déploiement autonome avec laquelle vous pouvez travailler indépendamment des autres.
S'il vous plaît noter que instance d'application peut être composé de plusieurs composants, comme le frontend, le backend, la base de données, etc. Dans le cas d’une application microservices, l’instance inclura tous les microservices.
En conséquence, les utilisateurs de Kubernetes se posent plusieurs questions :
- Toutes les instances d’application doivent-elles être placées dans un seul cluster ?
- Vaut-il la peine d’avoir un cluster distinct pour chaque instance d’application ?
- Ou peut-être faudrait-il utiliser une combinaison des approches ci-dessus ?
Toutes ces options sont tout à fait viables, puisque Kubernetes est un système flexible qui ne limite pas les capacités de l'utilisateur.
Voici quelques-unes des méthodes possibles :
- un grand cluster commun ;
- de nombreux petits clusters hautement spécialisés ;
- un cluster par application ;
- un cluster par environnement.
Comme le montre ci-dessous, les deux premières approches se situent aux extrémités opposées de l’échelle des options :
De quelques gros clusters (à gauche) à de nombreux petits clusters (à droite)
En général, un cluster est considéré comme « plus grand » qu’un autre s’il possède une plus grande somme de nœuds et de pods. Par exemple, un cluster avec 10 nœuds et 100 pods est plus grand qu'un cluster avec 1 nœud et 10 pods.
Eh bien, commençons !
1. Un grand cluster commun
La première option consiste à placer toutes les charges de travail dans un seul cluster :
Un grand cluster
Dans cette approche, le cluster est utilisé comme un outil universel plateforme d'infrastructure — vous déployez simplement tout ce dont vous avez besoin dans un cluster Kubernetes existant.
Kubernetes permet aux parties du cluster d'être logiquement séparées les unes des autres, afin que chaque instance d'application puisse avoir son propre espace de noms.
Examinons les avantages et les inconvénients de cette approche.
+ Utilisation efficace des ressources
Avec un seul cluster, vous n'avez besoin que d'une seule copie de toutes les ressources nécessaires pour exécuter et gérer le cluster Kubernetes.
Par exemple, cela est vrai pour les nœuds maîtres. Généralement, chaque cluster Kubernetes possède 3 nœuds maîtres, donc pour un seul cluster, leur nombre restera ainsi (à titre de comparaison, 10 clusters auront besoin de 30 nœuds maîtres).
La subtilité ci-dessus s'applique également à d'autres services fonctionnant sur l'ensemble du cluster, tels que les équilibreurs de charge, les contrôleurs Ingress, les systèmes d'authentification, de journalisation et de surveillance.
Dans un seul cluster, tous ces services peuvent être utilisés en même temps pour toutes les charges de travail (il n'est pas nécessaire d'en créer des copies, comme c'est le cas avec plusieurs clusters).
+ Pas cher
En conséquence de ce qui précède, moins de clusters sont généralement moins chers car il n'y a pas de frais généraux.
Cela est particulièrement vrai pour les nœuds maîtres, qui peuvent coûter très cher, quelle que soit la manière dont ils sont hébergés (sur site ou dans le cloud).
Certains services Kubernetes gérés, tels que ou , fournissez la couche de contrôle gratuitement. Dans ce cas, la question du coût est moins aiguë.
Il existe également des services gérés qui facturent des frais fixes pour le fonctionnement de chaque cluster Kubernetes (par exemple, ).
+ Administration efficace
Il est plus facile de gérer un cluster que d'en gérer plusieurs.
L'administration peut inclure les tâches suivantes :
- Mise à jour de la version Kubernetes ;
- mise en place d'un pipeline CI/CD ;
- installer le plugin CNI ;
- mettre en place un système d'authentification des utilisateurs;
- installation d'un contrôleur d'accès;
et plein d'autres…
Dans le cas d'un cluster, vous ne devrez faire tout cela qu'une seule fois.
Pour de nombreux clusters, les opérations devront être répétées plusieurs fois, ce qui nécessitera probablement une certaine automatisation des processus et des outils pour garantir la cohérence et la cohérence du processus.
Et maintenant quelques mots sur les inconvénients.
− Point de défaillance unique
En cas de refus semelle le cluster cessera de fonctionner immédiatement tous charges de travail!
Les choses peuvent mal tourner de plusieurs manières :
- la mise à jour de Kubernetes entraîne des effets secondaires inattendus ;
- Un composant à l'échelle du cluster (par exemple, un plugin CNI) commence à ne pas fonctionner comme prévu ;
- l'un des composants du cluster n'est pas configuré correctement ;
- défaillance de l’infrastructure sous-jacente.
Un tel incident peut causer de graves dommages à toutes les charges de travail hébergées dans un cluster partagé.
− Pas d'isolation rigide
L'exécution dans un cluster partagé signifie que les applications partagent le matériel, les capacités réseau et le système d'exploitation sur les nœuds du cluster.
Dans un sens, deux conteneurs avec deux applications différentes exécutées sur le même nœud sont comme deux processus exécutés sur la même machine exécutant le même noyau de système d'exploitation.
Les conteneurs Linux offrent une certaine forme d'isolation, mais elle est loin d'être aussi solide que celle fournie, par exemple, par les machines virtuelles. Essentiellement, un processus dans un conteneur est le même processus exécuté sur le système d’exploitation hôte.
Cela peut poser un problème de sécurité : cette disposition permet théoriquement à des applications non liées de communiquer entre elles (intentionnellement ou accidentellement).
De plus, toutes les charges de travail d'un cluster Kubernetes partagent certains services à l'échelle du cluster, tels que - cela permet aux applications de trouver les services d'autres applications dans le cluster.
Tous les points ci-dessus peuvent avoir des significations différentes selon les exigences de sécurité de l'application.
Kubernetes fournit divers outils pour prévenir les problèmes de sécurité tels que и . Cependant, les configurer correctement nécessite une certaine expérience et ils ne sont pas en mesure de combler absolument toutes les failles de sécurité.
Il est important de toujours se rappeler que Kubernetes a été initialement conçu pour partage, pas pour isolement et sécurité.
− Absence de multilocation stricte
Compte tenu de l'abondance de ressources partagées dans un cluster Kubernetes, différentes applications peuvent se marcher sur les pieds de nombreuses manières.
Par exemple, une application peut monopoliser une ressource partagée (telle que le processeur ou la mémoire) et en refuser l'accès aux autres applications exécutées sur le même nœud.
Kubernetes fournit divers mécanismes pour contrôler ce comportement, tels que (voir aussi l'article «" - environ. trad.), и . Cependant, comme dans le cas de la sécurité, leur configuration n’est pas triviale et ils ne sont pas en mesure d’éviter absolument tous les effets secondaires imprévus.
− Grand nombre d'utilisateurs
Dans le cas d’un cluster unique, il faut en ouvrir l’accès à de nombreuses personnes. Et plus ils sont nombreux, plus le risque qu’ils « cassent » quelque chose est élevé.
Au sein du cluster, vous pouvez contrôler qui peut faire quoi en utilisant (voir article «" - environ. trad.). Cependant, cela n’empêchera pas les utilisateurs de « casser » quelque chose dans les limites de leur domaine de responsabilité.
− Les clusters ne peuvent pas croître indéfiniment
Le cluster utilisé pour toutes les charges de travail sera probablement assez volumineux (en termes de nombre de nœuds et de pods).
Mais ici, un autre problème se pose : les clusters dans Kubernetes ne peuvent pas croître indéfiniment.
Il existe une limite théorique à la taille des clusters. Dans Kubernetes, c'est environ .
Cependant, dans la vraie vie, les problèmes peuvent commencer beaucoup plus tôt - par exemple, simplement avec .
Le fait est que les grands clusters imposent une charge élevée à la couche de contrôle Kubernetes. En d’autres termes, maintenir le cluster opérationnel et efficace nécessite un réglage minutieux.
Ce problème est exploré dans un article connexe sur le blog original intitulé "».
Mais considérons l'approche inverse : de nombreux petits clusters.
2. De nombreux petits clusters spécialisés
Avec cette approche, vous utilisez un cluster distinct pour chaque élément que vous déployez :
De nombreux petits clusters
Aux fins de cet article, sous élément déployable fait référence à une instance d'une application - par exemple, une version de développement d'une application distincte.
Cette stratégie utilise Kubernetes comme outil spécialisé Durée pour les instances d'application individuelles.
Examinons les avantages et les inconvénients de cette approche.
+ « Rayon de souffle » limité
Lorsqu'un cluster tombe en panne, les conséquences négatives se limitent uniquement aux charges de travail déployées dans ce cluster. Toutes les autres charges de travail restent intactes.
+ Isolation
Les charges de travail hébergées dans des clusters individuels ne partagent pas de ressources telles que le processeur, la mémoire, le système d'exploitation, le réseau ou d'autres services.
Le résultat est un isolement étroit entre des applications non liées, ce qui peut être bénéfique pour leur sécurité.
+ Petit nombre d'utilisateurs
Étant donné que chaque cluster ne contient qu'un ensemble limité de charges de travail, le nombre d'utilisateurs y ayant accès est réduit.
Moins il y a de personnes ayant accès au cluster, plus le risque que quelque chose se « casse » est faible.
Regardons les inconvénients.
− Utilisation inefficace des ressources
Comme mentionné précédemment, chaque cluster Kubernetes nécessite un ensemble spécifique de ressources de gestion : nœuds maîtres, composants de couche de contrôle, solutions de surveillance et de journalisation.
Dans le cas d'un grand nombre de petits clusters, une part plus importante des ressources doit être allouée à la gestion.
− Cher
Une utilisation inefficace des ressources entraîne automatiquement des coûts élevés.
Par exemple, maintenir 30 nœuds maîtres au lieu de trois avec la même puissance de calcul affectera nécessairement les coûts.
− Difficultés administratives
La gestion de plusieurs clusters Kubernetes est bien plus difficile que la gestion d’un seul.
Par exemple, vous devrez configurer l'authentification et l'autorisation pour chaque cluster. La version Kubernetes devra également être mise à jour plusieurs fois.
Vous devrez probablement utiliser l'automatisation pour rendre toutes ces tâches plus efficaces.
Examinons maintenant des scénarios moins extrêmes.
3. Un cluster par application
Dans cette approche, vous créez un cluster distinct pour toutes les instances d'une application particulière :
Cluster par application
Cette voie peut être considérée comme une généralisation du principe «cluster séparé par équipe», car généralement une équipe d'ingénieurs développe une ou plusieurs applications.
Examinons les avantages et les inconvénients de cette approche.
+ Le cluster peut être ajusté à l'application
Si une application a des besoins particuliers, elle peut être implémentée dans un cluster sans affecter les autres clusters.
Ces besoins peuvent inclure des travailleurs GPU, certains plugins CNI, un maillage de services ou un autre service.
Chaque cluster peut être adapté à l'application qui y est exécutée afin qu'il ne contienne que ce qui est nécessaire.
− Différents environnements dans un cluster
L’inconvénient de cette approche est que des instances d’applications provenant d’environnements différents coexistent dans le même cluster.
Par exemple, la version prod de l'application s'exécute dans le même cluster que la version dev. Cela signifie également que les développeurs opèrent dans le même cluster dans lequel la version de production de l'application est exploitée.
Si, en raison des actions des développeurs ou de problèmes dans la version dev, une panne se produit dans le cluster, alors la version prod pourrait potentiellement en souffrir également - un énorme inconvénient de cette approche.
Et enfin, le dernier scénario de notre liste.
4. Un cluster par environnement
Ce scénario implique l'allocation d'un cluster distinct pour chaque environnement :
Un cluster par environnement
Par exemple, vous pouvez avoir des clusters dev, tester и poussée, dans lequel vous exécuterez toutes les instances de l’application dédiées à un environnement spécifique.
Voici les avantages et les inconvénients de cette approche.
+ Isolation de l'environnement de production
Dans cette approche, tous les environnements sont isolés les uns des autres. Cependant, en pratique, cela est particulièrement important dans un environnement de production.
Les versions de production de l'application sont désormais indépendantes de ce qui se passe dans les autres clusters et environnements.
De cette façon, si un problème survient soudainement dans le cluster de développement, les versions de production des applications continueront à fonctionner comme si de rien n'était.
+ Le cluster peut être ajusté à l'environnement
Chaque cluster peut être ajusté à son environnement. Par exemple, vous pouvez :
- installer des outils de développement et de débogage dans le cluster de développement ;
- installer des frameworks et des outils de test dans le cluster tester;
- utiliser du matériel et des canaux réseau plus puissants dans le cluster poussée.
Cela vous permet d'augmenter l'efficacité du développement et de l'exploitation des applications.
+ Restreindre l'accès au cluster de production
La nécessité de travailler directement avec un cluster de production se pose rarement, vous pouvez donc limiter considérablement le cercle de personnes qui y ont accès.
Vous pouvez aller encore plus loin et refuser complètement l’accès à ce cluster et effectuer tous les déploiements à l’aide d’un outil CI/CD automatisé. Une telle approche minimisera le risque d’erreurs humaines là où cela est le plus pertinent.
Et maintenant quelques mots sur les inconvénients.
− Pas d'isolation entre les applications
Le principal inconvénient de cette approche est le manque d’isolation du matériel et des ressources entre les applications.
Les applications indépendantes partagent les ressources du cluster : le cœur du système, le processeur, la mémoire et certains autres services.
Comme mentionné, cela peut être potentiellement dangereux.
− Incapacité de localiser les dépendances des applications
Si une application a des exigences particulières, celles-ci doivent être satisfaites dans tous les clusters.
Par exemple, si une application nécessite un GPU, chaque cluster doit contenir au moins un travailleur doté d'un GPU (même s'il est utilisé uniquement par cette application).
En conséquence, nous risquons des coûts plus élevés et une utilisation inefficace des ressources.
Conclusion
Si vous disposez d'un ensemble spécifique d'applications, elles peuvent être placées dans plusieurs grands clusters ou dans plusieurs petits.
L'article discute des avantages et des inconvénients de diverses approches, allant d'un cluster mondial à plusieurs petits clusters hautement spécialisés :
- un grand cluster général ;
- de nombreux petits clusters hautement spécialisés ;
- un cluster par application ;
- un cluster par environnement.
Alors, quelle approche devriez-vous adopter ?
Comme toujours, la réponse dépend du cas d'utilisation : vous devez peser le pour et le contre des différentes approches et choisir l'option la plus optimale.
Cependant, le choix ne se limite pas aux exemples ci-dessus : vous pouvez en utiliser n'importe quelle combinaison !
Par exemple, vous pouvez organiser quelques clusters pour chaque équipe : un cluster de développement (dans lequel se trouveront des environnements dev и tester) et cluster pour production (où sera situé l’environnement de production).
Sur la base des informations contenues dans cet article, vous pouvez optimiser les avantages et les inconvénients en conséquence pour un scénario spécifique. Bonne chance!
PS
A lire aussi sur notre blog :
- «";
- «";
- «";
- «».
Source: habr.com