Get best of the week

Kubernetes: open source vs fournisseur

Bonjour, je m'appelle Dmitry Krasnov. Depuis plus de cinq ans maintenant, j'administre des clusters Kubernetes et je construis des architectures de microservices complexes. Plus tôt cette année, nous avons lancé le service de gestion de cluster Kubernetes basé sur Containerum. Profitant de cette opportunité, je vais vous dire ce qu'est ce Kubernetes et en quoi l'intégration avec le fournisseur diffère de l'open source.

Pour commencer, qu'est-ce que Kubernetes. Il s'agit d'un système de gestion de conteneurs sur un grand nombre d'hôtes. Du grec, d'ailleurs, il est traduit par «pilote» ou «timonier». Développé à l'origine par Google, après quoi la Cloud Native Computing Foundation, une organisation internationale à but non lucratif qui rassemble les principaux développeurs mondiaux, les utilisateurs finaux et les fournisseurs de technologies de conteneurs, a été transférée en tant que contribution technologique.



Piloter un grand nombre de conteneurs


Voyons maintenant de quel type de conteneurs il s'agit. Cette application avec tout son environnement - principalement les bibliothèques dont dépend le programme. Tout cela est emballé dans des archives et présenté sous la forme d'une image qui peut être exécutée indépendamment du système d'exploitation, testée et pas seulement. Mais il y a un problème - la gestion des conteneurs sur un grand nombre d'hôtes est très difficile. Par conséquent, Kubernetes a été créé.

Une image conteneur est une application plus ses dépendances. L'application, ses dépendances et l'image du système de fichiers OS sont situées dans différentes parties de l'image, les couches dites. Les couches peuvent être réutilisées pour différents conteneurs. Par exemple, pour toutes les applications de l'entreprise, la couche de base Ubuntu peut être utilisée. Lors du démarrage de conteneurs, il n'est pas nécessaire de stocker plusieurs copies d'une couche de base sur l'hôte. Cela vous permet d'optimiser le stockage et la livraison des images.

Lorsque nous voulons démarrer l'application à partir du conteneur, les couches nécessaires sont superposées les unes aux autres et un système de fichiers de superposition est formé. Une couche d'enregistrement est superposée sur le dessus, qui, lorsque le conteneur est arrêté, est supprimée. Cela garantit que lorsque vous démarrez le conteneur, l'application aura toujours le même environnement, qui ne peut pas être modifié. Cela garantit la reproductibilité de l'environnement sur différents systèmes d'exploitation hôtes. Que ce soit Ubuntu ou CentOS, l'environnement sera toujours le même. De plus, le conteneur est isolé de l'hôte à l'aide des mécanismes intégrés au noyau Linux. Les applications dans le conteneur ne voient pas les fichiers, les processus de l'hôte et les conteneurs voisins. Cette isolation des applications du système d'exploitation hôte fournit une couche de sécurité supplémentaire.

Il existe de nombreux outils pour gérer les conteneurs sur l'hôte. Le plus populaire d'entre eux est Docker. Il vous permet d'assurer le cycle de vie complet des conteneurs. Cependant, cela ne fonctionne que sur un seul hôte. Si vous devez gérer des conteneurs sur plusieurs hôtes, Docker peut transformer la vie des ingénieurs en enfer. C'est pourquoi Kubernetes a été créé.

La demande pour Kubernetes est précisément due à la capacité de diriger des groupes de conteneurs sur plusieurs hôtes en tant qu'entités uniques. La popularité du système permet de créer des DevOps ou des opérations de développement, dans lesquelles Kubernetes est utilisé pour démarrer les processus de ce DevOps lui-même.



Figure 1. Représentation schématique du fonctionnement de Kubernetes

Automatisation complète


DevOps, en principe, est une automatisation du processus de développement. En gros, les développeurs écrivent du code qui est versé dans le référentiel. Ensuite, ce code peut être automatiquement collecté immédiatement dans un conteneur avec toutes les bibliothèques, testé et déployé à l'étape suivante - Staging, puis immédiatement en Production.

Avec Kubernetes, DevOps vous permet d'automatiser ce processus afin qu'il se déroule avec peu ou pas de participation des développeurs eux-mêmes. Pour cette raison, l'assemblage est considérablement accéléré, car le développeur n'a pas à le faire sur son ordinateur - il écrit simplement un morceau de code, pousse le code dans le référentiel, puis le pipeline démarre, ce qui peut inclure l'assemblage, les tests, le processus de déploiement. Et cela se produit à chaque validation, les tests sont donc en cours.

Dans le même temps, l'utilisation du conteneur vous permet d'être sûr que l'environnement entier de ce programme entrera en production exactement sous la forme dans laquelle il a été testé. Autrement dit, il n'y aura pas de problèmes de la catégorie "sur le test, il y avait des versions, en production - d'autres, mais une fois réglées - tout est tombé". Et depuis aujourd'hui, nous avons une tendance vers l'architecture de microservices, alors qu'au lieu d'une énorme application, il y en a des centaines de petites, afin de les administrer manuellement, vous aurez besoin d'un énorme personnel. C'est pourquoi nous utilisons Kubernetes.

Pour, Pour, Pour


Si nous parlons des avantages de Kubernetes en tant que plate-forme, alors il présente des avantages importants en termes de gestion de l'architecture de microservices.

  • . — . , — . . , Kubernetes .
  • . Kubernetes . . , . Kubernetes , Service Discovery. IP- Kubernetes. health check` .
  • . . Kubernetes ConfigMap`. . , .
  • Persistent Volumes. , , . . Kubernetes — Persistent Volumes. , , . , .
  • Load Balancer. , Kubernetes Deployment, StatefulSet .., . . Kubernetes . , ? , . Kubernetes Load Balancer. . . , . Kubernetes.

Kubernetes est le meilleur pour lancer des architectures de microservices. La mise en œuvre d'un système dans l'architecture classique est possible, mais inutile. Si l'application ne peut pas fonctionner dans plusieurs répliques, quelle est la différence - dans Kubernetes ou non?

Kubernetes open source


Open source Kubernetes est une grande chose: il a installé et fonctionne. Vous pouvez déployer sur vos serveurs de fer, sur votre infrastructure, mettre des assistants et des travailleurs sur lesquels toutes les applications s'exécuteront. Et surtout - tout cela est gratuit. Cependant, il y a des nuances.

  • Le premier est l'exactitude des connaissances et de l'expérience des administrateurs et des ingénieurs qui déploieront et accompagneront tout cela. Le client bénéficiant d'une totale liberté d'action dans le cluster, il porte la responsabilité de l'opérabilité du cluster. Et tout casser ici est très simple.
  • Le deuxième est le manque d'intégration. Si vous exécutez Kubernetes sans une plate-forme de virtualisation populaire, vous n'obtiendrez pas tous les avantages du programme. Telles que l'utilisation des volumes persistants et des services d'équilibrage de charge.



Figure 2. L'architecture k8s

Kubernetes du vendeur


L'intégration avec un fournisseur de cloud offre deux options:

  • Tout d'abord, une personne peut simplement cliquer sur le bouton «créer un cluster» et obtenir un cluster déjà configuré et prêt à fonctionner.
  • Deuxièmement, le fournisseur lui-même met en place un cluster et configure l'intégration avec le cloud.

Comment cela se passe-t-il avec nous. L'ingénieur qui lance le cluster indique le nombre de travailleurs dont il a besoin et avec quels paramètres (par exemple, 5 travailleurs, chacun avec 10 CPU, 16 Go de RAM et, disons, 100 Go de disque). Il accède ensuite au cluster déjà formé. Dans le même temps, les travailleurs sur lesquels la charge est lancée sont entièrement remis au client, mais l'ensemble du plan de gestion reste dans la zone de responsabilité du fournisseur (dans le cas où le service est fourni selon le modèle de service géré).

Cependant, un tel schéma a ses inconvénients. Étant donné que le plan de gestion reste avec le fournisseur, le fournisseur ne donne pas un accès complet au client, ce qui réduit la flexibilité de travailler avec Kubernetes. Il arrive parfois que le client veuille associer certaines fonctionnalités spécifiques à Kubernetes, par exemple, l'authentification via LDAP, et la configuration du plan de gestion ne le permet pas.



Figure 3. Un exemple de cluster Kubernetes d'un fournisseur de cloud

Que choisir: open source ou fournisseur


Alors, Kubernetes open source ou fournisseur? Si nous prenons Kubernetes open source, alors l'utilisateur veut faire ce qu'il fait. Mais une grande chance de se tirer une balle dans la jambe. Avec les éditeurs, c'est plus compliqué, car tout est pensé et configuré pour l'entreprise. Le plus gros inconvénient de l'open source Kubernetes est l'exigence de spécialistes. Avec un vendeur, l'entreprise est épargnée par ce mal de tête, mais elle devra décider de payer ses spécialistes ou le vendeur.





Eh bien, les avantages sont évidents, les inconvénients sont également connus. Invariablement, une chose: Kubernetes résout de nombreux problèmes en automatisant la gestion de plusieurs conteneurs. Et lequel choisir, open source ou fournisseur - chacun décide pour lui-même.

L'article a été préparé par Dmitry Krasnov, architecte en chef du service Containerum du fournisseur #CloudMTS

More articles:


All Articles