Kubernetes : open source ou spécifique au fournisseur

Bonjour, je m'appelle Dmitry Krasnov. Depuis plus de cinq ans, j'administre des clusters Kubernetes et construis des architectures de microservices complexes. Au début de cette année, nous avons lancé un service de gestion de clusters Kubernetes basé sur Containerum. Profitant de cette opportunité, je vais vous expliquer ce qu'est Kubernetes et en quoi l'intégration avec un 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. Soit dit en passant, du grec, il est traduit par « pilote » ou « timonier ». Développé à l'origine par Google, puis donné en tant que contribution technologique à la Cloud Native Computing Foundation, une organisation internationale à but non lucratif qui rassemble les principaux développeurs, utilisateurs finaux et fournisseurs de technologies de conteneurs au monde.

Gérer un grand nombre de conteneurs

Voyons maintenant de quel type de conteneurs il s'agit. Il s'agit d'une application avec tout son environnement - principalement les bibliothèques dont dépend le programme. Tout cela est conditionné dans des archives et présenté sous la forme d'une image qui peut être exécutée quel que soit le système d'exploitation, testée et plus encore. Mais il y a un problème : gérer des conteneurs sur un grand nombre d’hôtes est très difficile. C'est pourquoi Kubernetes a été créé.

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

Lorsque nous souhaitons exécuter une application à partir d'un conteneur, les couches nécessaires se superposent les unes aux autres et un système de fichiers superposé est formé. Une couche d'enregistrement est placée sur le dessus, qui est supprimée lorsque le conteneur s'arrête. Cela garantit que lorsque le conteneur s'exécute, l'application aura toujours le même environnement, qui ne peut pas être modifié. Cela garantit la reproductibilité de l’environnement sur différents OS hôtes. Qu'il s'agisse d'Ubuntu ou de CentOS, l'environnement sera toujours le même. De plus, le conteneur est isolé de l'hôte à l'aide de mécanismes intégrés au noyau Linux. Les applications dans un 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 disponibles pour gérer les conteneurs sur un 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 rendre la vie des ingénieurs un véritable enfer. C'est pourquoi Kubernetes a été créé.

La demande pour Kubernetes est précisément due à la capacité de gérer des groupes de conteneurs sur plusieurs hôtes comme une sorte d'entité unique. La popularité du système offre la possibilité de créer des DevOps ou des opérations de développement, dans lesquelles Kubernetes est utilisé pour exécuter les processus de ce même DevOps.

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

Automatisation complète

DevOps est essentiellement l'automatisation du processus de développement. En gros, les développeurs écrivent du code qui est téléchargé 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é » vers l'étape suivante - le staging, puis immédiatement vers la production.

Avec Kubernetes, DevOps vous permet d'automatiser ce processus afin qu'il se déroule pratiquement sans participation des développeurs eux-mêmes. De ce fait, la construction est beaucoup plus rapide, puisque le développeur n'a pas besoin de le faire sur son ordinateur - il écrit simplement un morceau de code, pousse le code vers le référentiel, après quoi le pipeline est lancé, qui peut inclure le processus. de construction, de test et de déploiement. Et cela se produit à chaque validation, donc les tests se déroulent en continu.

Dans le même temps, l'utilisation d'un conteneur permet d'être sûr que l'ensemble de l'environnement de ce programme sera mis en production exactement sous la forme sous laquelle il a été testé. Autrement dit, il n'y aura pas de problèmes du type "il y avait certaines versions en test, d'autres en production, mais lorsque nous les avons installées, tout est tombé". Et comme nous avons aujourd'hui une tendance vers une architecture de microservices, alors qu'au lieu d'une énorme application, il y en a des centaines de petites, pour les administrer manuellement, il faudra une énorme équipe d'employés. C'est pourquoi nous utilisons Kubernetes.

Avantages, avantages, avantages

Si nous parlons des avantages de Kubernetes en tant que plate-forme, alors il présente des avantages significatifs du point de vue de la gestion d'une architecture de microservices.

• Gestion de plusieurs répliques. La chose la plus importante est de gérer les conteneurs sur plusieurs hôtes. Plus important encore, gérez plusieurs réplicas d’applications dans des conteneurs comme une seule entité. Grâce à cela, les ingénieurs n'ont pas à se soucier de chaque conteneur individuel. Si l'un des conteneurs plante, Kubernetes le verra et le redémarrera.
• Réseau de clusters. Kubernetes dispose également d'un réseau de clusters avec son propre espace d'adressage. Grâce à cela, chaque pod a sa propre adresse. Un subpod s'entend comme l'unité structurelle minimale d'un cluster dans laquelle les conteneurs sont directement lancés. De plus, Kubernetes dispose de fonctionnalités combinant un équilibreur de charge et Service Discovery. Cela vous permet de vous débarrasser de la gestion manuelle des adresses IP et de déléguer cette tâche à Kubernetes. Et les contrôles de santé automatiques aideront à détecter les problèmes et à rediriger le trafic vers les pods fonctionnels.
• Gestion de la configuration. Lors de la gestion d’un grand nombre d’applications, il devient difficile de gérer la configuration des applications. À cet effet, Kubernetes dispose de ressources ConfigMap spéciales. Ils vous permettent de stocker les configurations de manière centralisée et de les exposer aux pods lors de l'exécution d'applications. Ce mécanisme permet de garantir la cohérence de la configuration dans au moins dix ou cent réplicas d'application.
• Volumes persistants. Les conteneurs sont intrinsèquement immuables et lorsque le conteneur est arrêté, toutes les données écrites dans le système de fichiers seront détruites. Mais certaines applications stockent les données directement sur disque. Pour résoudre ce problème, Kubernetes dispose d'une fonctionnalité de gestion du stockage sur disque : les volumes persistants. Ce mécanisme utilise un stockage externe pour les données et peut transférer un stockage persistant, bloc ou fichier, dans des conteneurs. Cette solution permet de stocker les données séparément des travailleurs, ce qui les sauvegarde en cas de panne de ces mêmes travailleurs.
• Équilibreur de charge. Même si dans Kubernetes nous gérons des entités abstraites telles que Deployment, StatefulSet, etc., les conteneurs s'exécutent en fin de compte sur des machines virtuelles ou des serveurs matériels classiques. Ils ne sont pas parfaits et peuvent tomber à tout moment. Kubernetes le verra et redirigera le trafic interne vers d'autres réplicas. Mais que faire du trafic venant de l’extérieur ? Si vous dirigez simplement le trafic vers l'un des travailleurs, en cas de panne, le service deviendra indisponible. Pour résoudre ce problème, Kubernetes dispose de services comme Load Balancer. Ils sont conçus pour configurer automatiquement un équilibreur cloud externe pour tous les travailleurs du cluster. Cet équilibreur externe dirige le trafic externe vers les travailleurs et surveille lui-même leur statut. Si un ou plusieurs travailleurs deviennent indisponibles, le trafic est redirigé vers d'autres. Cela vous permet de créer des services hautement disponibles à l'aide de Kubernetes.

Kubernetes fonctionne mieux lors de l'exécution d'architectures de microservices. Il est possible d’implémenter le système dans une architecture classique, mais cela ne sert à rien. Si une application ne peut pas s'exécuter sur plusieurs réplicas, quelle différence cela fait-il - dans Kubernetes ou non ?

Kubernetes open source

Kubernetes open source est une bonne chose : je l'ai installé et ça marche. Vous pouvez le déployer sur vos propres serveurs matériels, sur votre propre infrastructure, installer des maîtres et des travailleurs sur lesquels toutes les applications s'exécuteront. Et surtout, tout cela est gratuit. Il existe cependant des nuances.

• Le premier est la demande de connaissances et d’expérience des administrateurs et des ingénieurs qui déploieront et prendront en charge tout cela. Étant donné que le client bénéficie d'une totale liberté d'action dans le cluster, il est lui-même responsable des performances du cluster. Et c’est très facile de tout casser ici.
• La seconde est le manque d’intégrations. Si vous exécutez Kubernetes sans plate-forme de virtualisation populaire, vous ne bénéficierez pas de tous les avantages du programme. Comme l’utilisation des services de volumes persistants et d’équilibrage de charge.

Figure 2. Architecture k8s

Kubernetes du fournisseur

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 à être utilisé.
• Deuxièmement, le fournisseur installe lui-même le cluster et met en place l'intégration avec le cloud.

Comment ça se passe ici. L'ingénieur qui démarre le cluster précise le nombre de nœuds de calcul dont il a besoin et avec quels paramètres (par exemple, 5 nœuds de calcul, chacun avec 10 processeurs, 16 Go de RAM et, disons, 100 Go de disque). Après quoi, il accède au cluster déjà formé. Dans ce cas, les travailleurs sur lesquels la charge est lancée sont entièrement transférés au client, mais l'ensemble du plan de gestion reste sous la responsabilité du vendeur (si le service est fourni selon le modèle de service géré).

Cependant, ce schéma présente des inconvénients. Étant donné que le plan de gestion reste chez le fournisseur, celui-ci ne donne pas un accès complet au client, ce qui réduit la flexibilité de travail avec Kubernetes. Il arrive parfois qu'un client souhaite ajouter des fonctionnalités spécifiques à Kubernetes, par exemple l'authentification via LDAP, mais la configuration du plan de gestion ne le permet pas.

Figure 3. Exemple de cluster Kubernetes d'un fournisseur de cloud

Que choisir : open source ou fournisseur

Alors, Kubernetes est-il open source ou spécifique à un fournisseur ? Si nous prenons Kubernetes open source, alors l'utilisateur en fait ce qu'il veut. Mais il y a de grandes chances de se tirer une balle dans le pied. Avec le vendeur, c’est plus difficile, car tout est pensé et configuré pour l’entreprise. Le plus gros inconvénient de Kubernetes open source est le besoin de spécialistes. Avec une option fournisseur, l’entreprise est libérée de ce casse-tête, mais elle devra décider si elle paiera ses spécialistes ou le fournisseur.

Eh bien, les avantages sont évidents, les inconvénients sont également connus. Une chose est constante : Kubernetes résout de nombreux problèmes en automatisant la gestion de nombreux conteneurs. Et lequel choisir, open source ou fournisseur - chacun prend sa propre décision.

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

Source: habr.com