Kubernetes : open source contre propriétaire

Bonjour, je m'appelle Dmitry Krasnov. Cela fait plus de cinq ans que je m'occupe de l'administration des clusters Kubernetes et de la construction d'architectures microservices complexes. Au début de cette année, nous avons lancé un service de gestion de clusters Kubernetes basé sur Containerum. Profitant de l'occasion, je vais expliquer ce qu'est exactement Kubernetes et en quoi l'intégration avec un fournisseur diffère de l'open source.

Pour commencer, qu'est-ce que Kubernetes. C'est un système de gestion des conteneurs sur un grand nombre d'hôtes. En grec, cela se traduit d'ailleurs par « pilote » ou « barreur ». Initialement développé par Google, il a ensuite été transmis à la Cloud Native Computing Foundation, une organisation internationale à but non lucratif qui regroupe les principaux développeurs mondiaux, les utilisateurs finaux et les fournisseurs de technologies de conteneur.

Gérer un grand nombre de conteneurs

Voyons maintenant ce que sont ces conteneurs. Ce sont des applications avec tout leur environnement – principalement, les bibliothèques dont dépend le bon fonctionnement du programme. Tout cela est emballé dans des archives et présenté sous forme d'image, qui peut être exécutée indépendamment du 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éé.

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

Lorsque nous souhaitons exécuter une application à partir d'un conteneur, les couches nécessaires se superposent pour former un système de fichiers superposé. Une couche d'écriture est ajoutée par-dessus, qui est supprimée lorsque le conteneur s'arrête. Cela garantit qu'à chaque lancement du conteneur, l'application dispose toujours du même environnement, qui ne peut être modifié. Cela assure la reproductibilité de l'environnement sur différents systèmes d'exploitation hôtes. Que ce soit Ubuntu ou CentOS, l'environnement sera toujours identique. De plus, le conteneur est isolé de l'hôte grâce aux mécanismes intégrés au noyau Linux. Les applications dans le conteneur ne voient pas les fichiers ni les processus de l'hôte et des conteneurs voisins. Cette isolation des applications par rapport à l'OS hôte offre une couche de sécurité supplémentaire.

Pour gérer les conteneurs sur l'hôte, il existe de nombreux outils. Le plus populaire d'entre eux est Docker. Il permet d'assurer l'ensemble du cycle de vie des conteneurs. Cependant, il fonctionne uniquement sur un seul hôte. Si la gestion de conteneurs sur de nombreux hôtes est nécessaire, Docker peut rendre la vie des ingénieurs difficile. C'est pourquoi Kubernetes a été créé.

La demande pour Kubernetes réside précisément dans sa capacité à gérer des groupes de conteneurs sur de nombreux hôtes comme s'il s'agissait d'entités uniques. La popularité du système est due à la possibilité de construire des opérations DevOps, où 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, en principe, représente l'automatisation du processus de développement. En gros, les développeurs écrivent du code, qui est ensuite téléchargé dans un référentiel. Ce code peut ensuite être automatiquement compilé dans un conteneur avec toutes les bibliothèques, testé et 'déployé' à l'étape suivante - Staging, puis immédiatement en Production.

Avec Kubernetes, DevOps permet d'automatiser ce processus de manière presque à ne demander aucune intervention des développeurs. Cela accélère considérablement la construction, car le développeur n'a pas besoin de le faire sur son ordinateur — il écrit simplement un morceau de code, le pousse dans le dépôt, puis un pipeline se déclenche, qui peut inclure le processus de construction, de test et de déploiement. Cela se produit pour chaque commit, assurant ainsi un test continu.

L'utilisation de conteneurs garantit que tout l'environnement de ce programme sera déployé en production exactement comme il a été testé. Cela évite les problèmes du type « les versions étaient différentes en test et en production, et maintenant tout est tombé ». Étant donné qu'aujourd'hui nous avons une tendance vers l'architecture microservices, où au lieu d'une énorme application, il y a des centaines de petites, la gestion manuelle nécessiterait un grand nombre d'employés. C'est pourquoi nous utilisons Kubernetes.

Avantages, avantages, avantages

En ce qui concerne les atouts de Kubernetes en tant que plateforme, il présente des avantages significatifs en matière de gestion de l'architecture microservices.

• Gestion de plusieurs répliques. Le plus important — c'est la gestion des conteneurs sur plusieurs hôtes. Et ce qui est encore plus crucial, c'est la gestion de nombreuses répliques d'applications dans des conteneurs en tant qu'entité unique. Grâce à cela, les ingénieurs n'ont pas à se soucier de chaque conteneur individuel. Si l'un des conteneurs plante, Kubernetes le détectera et le relancera.
• Réseau de cluster. Kubernetes dispose également d'un réseau de cluster avec son propre espace d'adresses. Grâce à cela, chaque pod a sa propre adresse. Un pod est la plus petite unité structurelle d'un cluster, où les conteneurs sont directement exécutés. De plus, Kubernetes intègre des fonctionnalités qui allient équilibrage de charge et découverte de services. Cela permet d'éliminer la gestion manuelle des adresses IP et de confier cette tâche à Kubernetes. Les vérifications automatiques de l'état aident à détecter les problèmes et à rediriger le trafic vers les pods opérationnels.
• Gestion des configurations. Lors de la gestion d'un grand nombre d'applications, il devient difficile de gérer les configurations des applications. Pour cela, Kubernetes dispose de ressources spéciales appelées ConfigMap. Elles permettent de stocker les configurations de manière centralisée et de les injecter dans les pods lors du démarrage des applications. Ce mécanisme garantit la cohérence des configurations, que ce soit pour dix ou pour cent répliques d'applications.
• Volumes persistants. Les conteneurs sont par nature immuables et lorsqu'un conteneur est arrêté, toutes les données enregistrées sur le système de fichiers sont perdues. Cependant, certaines applications stockent des données directement sur le disque. Pour résoudre ce problème, Kubernetes propose une fonctionnalité de gestion de stockage — les Volumes persistants. Ce mécanisme utilise un stockage externe pour les données et peut fournir aux conteneurs un stockage persistant, qu'il soit bloc ou fichier. Cette solution permet de conserver les données séparément des workers, les préservant en cas de panne de ces derniers.
• Équilibreur de charge. Bien que dans Kubernetes nous gérions des entités abstraites telles que Deployment, StatefulSet, etc., en fin de compte, les conteneurs s'exécutent sur des serveurs ordinaires des machines virtuelles ou physiques. Ils ne sont pas parfaits et peuvent tomber à tout moment. Kubernetes le détectera et redirigera le trafic interne vers d'autres répliques. Mais que faire du trafic qui provient de l'extérieur ? Si nous dirigeons simplement le trafic vers un des workers, que se passerait-il en cas de panne ? Le service deviendrait alors inaccessible. Pour résoudre ce problème, Kubernetes dispose de services de type Équilibreur de charge. Ils sont conçus pour configurer automatiquement un équilibreur de charge cloud externe vers tous les workers du cluster. Cet équilibreur de charge externe dirige le trafic externe vers les workers et surveille leur état. Si un ou plusieurs workers deviennent indisponibles, le trafic est redirigé vers d'autres. Cela permet de créer des services hautement disponibles avec Kubernetes.

Kubernetes se révèle particulièrement efficace lors du déploiement d'architectures de microservices. Il est possible d'implémenter le système dans une architecture classique, mais cela n'a pas de sens. Si une application ne peut pas fonctionner en plusieurs répliques, quelle est la différence entre Kubernetes ou non ?

Kubernetes open source

Kubernetes open source – c'est fantastique : vous l'installez et cela fonctionne. Vous pouvez le déployer sur vos serveurs physiques, sur votre infrastructure, mettre en place un maître et des travailleurs qui exécuteront toutes les applications. Et surtout, tout cela est gratuit. Cependant, il y a des nuances.

• Le premier – l'exigence en matière de connaissances et d'expérience des administrateurs et des ingénieurs qui vont déployer et maintenir tout cela. Étant donné que le client a une totale liberté d'action dans le cluster, il en assume également la responsabilité de la performance du cluster. Et il est très facile de tout casser ici.
• Deuxième point – l'absence d'intégrations. Si vous lancez Kubernetes sans avoir une plateforme de virtualisation populaire, vous ne profiterez pas de tous les avantages du programme. Tels que l'utilisation des Volumes Persistants et des services de Load balancer.

Figure 2. Architecture de k8s

Kubernetes d'un fournisseur

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

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

Voici comment cela se passe chez nous. L'ingénieur qui lance le cluster indique combien de travailleurs il a besoin et avec quelles spécifications (par exemple, 5 travailleurs, chacun avec 10 CPU, 16 Go de RAM et, disons, 100 Go de disque). Après cela, il obtient l'accès au cluster déjà formé. À ce stade, les travailleurs, sur lesquels la charge est exécutée, sont entièrement à la disposition du client, mais tout le plan de gestion reste sous la responsabilité du fournisseur (dans le cas où le service est fourni selon le modèle de service géré).

Cependant, ce schéma présente des inconvénients. En raison du fait que le plan de gestion reste chez le fournisseur, ce dernier ne donne pas un accès complet au client, ce qui réduit la flexibilité dans l'utilisation de Kubernetes. Il arrive parfois que le client veuille ajouter une fonctionnalité spécifique à 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 open source ou vendorisé ? Si vous optez pour Kubernetes open source, vous faites ce que vous voulez avec. Mais il y a un grand risque de vous tirer une balle dans le pied. Avec l'option vendorisée, c'est plus compliqué, car tout est prévu et configuré par la société. Le plus grand inconvénient de Kubernetes open source est l'exigence en matière de spécialistes. Avec l'option vendorisée, l'entreprise est libérée de ce casse-tête, mais elle devra décider : payer ses propres spécialistes ou le fournisseur.

Eh bien, les avantages sont évidents, les inconvénients aussi sont connus. Une chose reste constante : Kubernetes résout de nombreux problèmes en automatisant la gestion de multiples conteneurs. Quant au choix entre open source ou vendorisé, chacun prend sa propre décision.

Cet article a été préparé par Dmitri Krasnov, architecte principal du service Containerum du fournisseur #CloudMTS.

Source : habr.com