⌚️ 🈲 👩🏽‍🌾 Conception de clusters Kubernetes: combien devraient-ils y en avoir? 🧓 🗾 👨🏿‍💻

Remarque perev. : Ce matériel du projet éducatif learnk8s est la réponse à une question populaire lors de la conception d'une infrastructure basée sur Kubernetes. Nous espérons que des descriptions suffisamment 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 de nombreuses petites (avec un petit nombre de charges dans chaque cluster).

Le tableau ci-dessous résume les avantages et les inconvénients de chaque approche:

Lorsque vous utilisez Kubernetes comme plate-forme pour les applications d'exploitation, plusieurs questions fondamentales sur les subtilités de la configuration de cluster se posent souvent:

Combien de clusters utiliser?
Quelle taille font-ils?
Que doit inclure chaque cluster?

Dans cet article, je vais essayer de répondre à toutes ces questions en analysant les avantages et les inconvénients de chaque approche.

Énoncé d'une question

En tant que créateur de logiciels, vous êtes susceptible de développer et d'exploiter de nombreuses applications en parallèle.

En outre, de nombreuses instances de ces applications sont susceptibles de s'exécuter dans divers environnements - par exemple, il peut s'agir de dev , test et prod .

Le résultat est une matrice complète d'applications et d'environnements:

Applications et environnements

Dans l'exemple ci-dessus, 3 applications et 3 environnements sont présentés, ce qui donne finalement 9 options possibles.

Chaque instance d'application est une unité de déploiement autonome qui peut être exploitée indépendamment des autres.

Notez qu'une instance d'application peut être constituée de nombreux composants.tels que frontend, backend, base de données, etc. Dans le cas d'une application de microservice, l'instance inclura tous les microservices.

En conséquence, les utilisateurs de Kubernetes ont plusieurs questions:

Dois-je placer toutes les instances d'application dans un cluster?
Dois-je créer un cluster distinct pour chaque instance de l'application?
Ou peut-être devriez-vous utiliser une combinaison des approches ci-dessus?

Toutes ces options sont tout à fait viables, car Kubernetes est un système flexible qui ne limite pas l'utilisateur en possibilités.

Voici quelques-unes des façons possibles:

une grande grappe commune;
de nombreux petits groupes hautement spécialisés;
un cluster pour chaque application;
un cluster pour chaque environnement.

Comme indiqué ci-dessous, les deux premières approches se trouvent aux extrémités opposées de l'échelle des options: de

plusieurs grands clusters (à gauche) à de nombreux petits (à droite)

En général, un cluster est considéré comme «plus grand» que l'autre s'il a 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 cluster:

un grand cluster

Dans le cadre de cette approche, le cluster est utilisé comme une plateforme d'infrastructure universelle - vous déployez simplement tout ce dont vous avez besoin dans un cluster Kubernetes existant.

Namespace'y Kubernetes permet de séparer logiquement une partie du cluster les unes des autres, de sorte que son espace de noms puisse être utilisé pour chaque instance de l'application.

Examinons les avantages et les inconvénients de cette approche.

+ Utilisation efficace des ressources

Dans le cas d'un cluster unique, une seule copie de toutes les ressources nécessaires pour démarrer et gérer le cluster Kubernetes est requise.

Par exemple, cela est vrai pour les nœuds maîtres. Habituellement, il y a 3 nœuds maîtres pour chaque cluster Kubernetes, donc pour un seul cluster, leur nombre le restera (à titre de comparaison, 10 clusters auront besoin de 30 nœuds maîtres).

La subtilité ci-dessus s'applique à d'autres services fonctionnant à l'échelle 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 immédiatement pour toutes les charges de travail (vous n'avez pas besoin d'en créer des copies, comme dans le cas de plusieurs clusters).

+ Pas cher

En conséquence de ce qui précède, un plus petit nombre de clusters est généralement moins cher car il n'y a aucun coût pour les ressources excédentaires.

Cela est particulièrement vrai pour les nœuds maîtres, qui peuvent coûter cher, quelle que soit la méthode de placement (sur site ou dans le cloud).

Certains services Kubernetes gérés, tels que le moteur Google Kubernetes (GKE) ou le service Azure Kubernetes (AKS) , fournissent gratuitement une couche de contrôle. Dans ce cas, la question des coûts est moins aiguë.

Il existe également des services gérés qui facturent des frais fixes pour chaque cluster Kubernetes (par exemple, Amazon Elastic Kubernetes Service, EKS ).

+ Administration efficace

La gestion d'un seul cluster est plus facile que plusieurs.

L'administration peut comprendre les tâches suivantes:

mettre à jour la version de Kubernetes;
Configuration du pipeline CI / CD
Installation du plugin CNI;
mettre en place un système d'authentification des utilisateurs;
réglage du contrôleur d'accès;

et bien d'autres ...

Dans le cas d'un cluster, tout cela ne devra être fait 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 un processus systématique et uniforme.

Et maintenant quelques mots sur les inconvénients.

- Point de défaillance unique

En cas de défaillance d'un cluster unique , toutes les charges de travail cesseront de fonctionner immédiatement !

Il y a des tonnes d'options en cas de problème:

la mise à jour de Kubernetes entraîne des effets secondaires inattendus;
le composant à l'échelle du cluster (par exemple, le plug-in CNI) ne fonctionne pas comme prévu;
L'un des composants du cluster n'est pas configuré correctement.
une défaillance de l'infrastructure sous-jacente.

Un tel incident peut endommager gravement toutes les charges de travail situées dans un cluster commun.

- Manque d'isolation dure

Travailler 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 s'exécutant sur le même hôte sont similaires à deux processus exécutés sur la même machine exécutant le même noyau de système d'exploitation.

Les conteneurs Linux fournissent une certaine forme d'isolement, mais ils sont loin d'être aussi solides que ceux fournis, disons, par des machines virtuelles. En substance, un processus dans un conteneur est le même processus exécuté sur le système d'exploitation hôte.

Cela peut être un problème de sécurité: une telle organisation permet théoriquement à des applications indépendantes d'interagir les unes avec les autres (intentionnellement ou accidentellement).

En outre, toutes les charges de travail du cluster Kubernetes partagent certains services à l'échelle du cluster, tels que DNS - cela permet aux applications de trouver les services d'autres applications du cluster.

Tous les éléments ci-dessus peuvent avoir des significations différentes selon les exigences de sécurité des applications.

Kubernetes fournit divers outils pour éviter les problèmes de sécurité, tels que PodSecurityPolicies et NetworkPolicies . Cependant, pour que leur configuration correcte nécessite une certaine expérience en plus, ils ne sont pas en mesure de fermer absolument tous les trous de sécurité.

Il est important de toujours se rappeler que Kubernetes a été initialement conçu pour le partage.et non pour l' isolement et la sécurité .

- Manque de multi-location serré

Compte tenu de l'abondance des ressources partagées dans le cluster Kubernetes, il existe de nombreuses façons dont différentes applications peuvent «se frapper les talons».

Par exemple, une application peut monopoliser une ressource partagée (comme un processeur ou une mémoire) et priver d'autres applications s'exécutant sur le même noeud d'accès.

Kubernetes fournit divers mécanismes pour contrôler un tel comportement, tels que les demandes de ressources et les limites (voir également l'article « Limites du processeur et limitation agressive dans Kubernetes » - environ la traduction ) , ResourceQuotas et LimitRanges . Cependant, comme dans le cas de la sécurité, leur configuration est assez banale et ils ne sont pas en mesure d'empêcher absolument tous les effets secondaires imprévus.

- Un grand nombre d'utilisateurs

Dans le cas d'un cluster unique, de nombreuses personnes doivent en ouvrir l'accès. Et plus leur nombre est élevé, plus ils risquent de «casser quelque chose».

À l'intérieur du cluster, vous pouvez contrôler qui et quoi faire en utilisant le contrôle d'accès basé sur les rôles (RBAC) (voir l'article « Utilisateurs et autorisation RBAC dans Kubernetes » - transfert approximatif) . 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 se développer indéfiniment.

Il existe une limite théorique à la taille du cluster. Chez Kubernetes, c'est environ 5 000 nœuds, 150 000 pods et 300 000 conteneurs .

Cependant, dans la vraie vie, les problèmes peuvent commencer beaucoup plus tôt - par exemple, à seulement 500 nœuds .

Le fait est que les grands clusters exercent une charge élevée sur la couche de contrôle Kubernetes. En d'autres termes, afin de maintenir le cluster opérationnel et d'utiliser efficacement les ressources, un réglage minutieux est nécessaire.

Ce problème est exploré dans un article connexe du blog d'origine intitulé « Architecting Kubernetes clusters - choose a worker node size ».

Mais regardons l'approche inverse: de nombreux petits clusters.

2. De nombreuses petites grappes spécialisées

Avec cette approche, vous utilisez un cluster séparé pour chaque élément déployable:

De nombreux petits clusters

Pour les besoins de cet article, un élément déployable fait référence à une instance d'une application - par exemple, la version de développement d'une application distincte.

Cette stratégie utilise Kubernetes comme un runtime spécialisé pour des 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 sont limitées uniquement aux charges de travail qui ont été déployées dans ce cluster. Toutes les autres charges de travail restent intactes.

+ Isolation

Les charges de travail hébergées sur 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.

En conséquence, nous obtenons une isolation étroite entre les applications non liées, ce qui peut nuire à 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 qui y ont accès est réduit.

Moins il y a de personnes ayant accès au cluster, plus le risque de «rupture» est faible.

Regardons les inconvénients.

- Utilisation inefficace des ressources

Comme mentionné précédemment, chaque cluster Kubernetes nécessite un certain ensemble de ressources de contrôle: nœuds maîtres, composants de la couche de contrôle, solutions de surveillance et de journalisation.

Dans le cas d'un grand nombre de petits clusters, il est nécessaire d'allouer une plus grande part des ressources à la gestion.

- Coût élevé

Une utilisation inefficace des ressources entraîne automatiquement des coûts élevés.

Par exemple, la maintenance de 30 nœuds maîtres au lieu de trois avec la même puissance de calcul affectera nécessairement les coûts.

- Difficultés d'administration

Gérer plusieurs clusters Kubernetes est beaucoup plus difficile que d'en gérer un.

Par exemple, vous devrez configurer l'authentification et l'autorisation pour chaque cluster. La mise à jour de la version de Kubernetes devra également être effectuée plusieurs fois.

Très probablement, vous devrez appliquer l'automatisation pour augmenter l'efficacité de toutes ces tâches.

Considérons maintenant des scénarios moins extrêmes.

3. Un cluster par application

Dans le cadre de cette approche, vous créez un cluster séparé pour toutes les instances d'une application particulière:

Cluster par application

Cette manière peut être considérée comme une généralisation du principe du « cluster séparé par équipe », car généralement une équipe d'ingénieurs est engagée dans le développement d'une ou plusieurs applications.

Examinons les avantages et les inconvénients de cette approche.

+ Le cluster peut être personnalisé pour l'application

Si l'application a des besoins particuliers, ils peuvent être implémentés dans un cluster sans affecter les autres clusters.

Ces besoins peuvent inclure des travailleurs GPU, des plugins CNI spécifiques, un maillage de service 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 les instances d'application 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 mènent leurs activités 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 des problèmes de la version de développement dans le cluster, une défaillance se produit, alors la version de prod peut potentiellement souffrir - un énorme inconvénient de cette approche.

Et enfin, le dernier script de notre liste.

4. Un cluster pour chaque environnement

Ce scénario prévoit l'attribution d'un groupe distinct pour chaque environnement:

Un cluster pour l'environnement

Par exemple, vous pouvez avoir dev , test de et prod les clusters dans lesquels vous exécuterez tous les cas d'application conçus pour un environnement spécifique.

Voici les avantages et les inconvénients de cette approche.

+ Isolement de l'environnement prod

Dans cette approche, tous les environnements sont isolés les uns des autres. Cependant, dans la pratique, cela est particulièrement important pour l'environnement de production.

Les versions de production de l'application sont désormais indépendantes de ce qui se passe dans d'autres clusters et environnements.

Ainsi, si un problème survient soudainement dans le cluster de développement, les versions prod des applications continueront de fonctionner comme si de rien n'était.

+ Le cluster peut être adapté à l'environnement

Chaque cluster peut être adapté à son environnement. Par exemple, vous pouvez:

installer des outils de développement et de débogage dans le cluster de développement;
installer des cadres et des outils de test dans le cluster de test ;
Utilisez des équipements et des canaux réseau plus puissants dans le cluster prod .

Cela vous permet d'augmenter l'efficacité du développement et du fonctionnement des applications.

+ Restreindre l'accès au cluster de production

La nécessité de travailler directement avec un cluster de prod se pose rarement, de sorte que vous pouvez limiter considérablement le cercle des personnes qui y ont accès.

Vous pouvez aller encore plus loin et généralement priver les utilisateurs de l'accès à ce cluster et effectuer tous les déploiements à l'aide de l'outil CI / CD automatisé. Une telle approche minimisera le risque d'erreur humaine exactement là où elle est la plus pertinente.

Et maintenant quelques mots sur les inconvénients.

- Manque d'isolement entre les applications

Le principal inconvénient de cette approche est le manque d'isolation matérielle et de 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 déjà mentionné, cela peut être potentiellement dangereux.

- Incapacité à localiser les dépendances des applications

Si l'application a des exigences particulières, elles doivent être satisfaites dans tous les clusters.

Par exemple, si une application a besoin d'un GPU, chaque cluster doit contenir au moins un travailleur avec un GPU (même s'il n'est utilisé que par cette application).

En conséquence, nous courons le risque de coûts plus élevés et d'une utilisation inefficace des ressources.

Conclusion

Si vous disposez d'un ensemble spécifique d'applications, vous pouvez les placer dans plusieurs grands clusters ou dans de nombreux petits.

L'article examine les avantages et les inconvénients de diverses approches, allant d'un cluster mondial à plusieurs petits et hautement spécialisés:

une grande grappe commune;
de nombreux petits groupes hautement spécialisés;
un cluster pour chaque application;
un cluster pour chaque environnement.

Alors, quelle approche choisir?

Comme d'habitude, 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 n'est pas limité aux exemples ci-dessus - vous pouvez utiliser n'importe quelle combinaison d'entre eux!

Par exemple, vous pouvez organiser une paire de grappes par équipe: un groupe pour le développement (qui aura dev et tester les environnements ) et un groupe de production (où l'environnement de production sera situé).

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

Lisez aussi dans notre blog:

Conception de clusters Kubernetes: combien devraient-ils y en avoir?