Kubernetes, aussi puissant que difficile.

Kubernetes a vraisemblablement gagné la guerre des conteneurs. Cependant, Kubernetes est toujours difficile et cause beaucoup de douleur.

Je pense que je devrais donner une petite préface à cet article. Kubernetes est le nouveau runtime pour de nombreuses applications, et lorsqu'il est utilisé correctement, il peut être un outil puissant pour éliminer la complexité de votre cycle de vie de développement. Cependant, ces dernières années, j'ai vu de nombreuses personnes et entreprises trébucher sur le désir de gérer leur propre installation. Il reste souvent en phase expérimentale et n'entre jamais en production.

Comment fonctionne Kubernetes ?

De manière générale, Kubernetes, ou K8s, semble très simple. Les nœuds (machines) exécutant Kubernetes sont divisés en (au moins) deux types : le maître et les nœuds de travail. Par défaut, le ou les maîtres n'exécutent aucune charge de travail ; cette tâche incombe aux nœuds de travail. Le maître Kubernetes comprend un composant appelé serveur d'API, qui fournit une API avec laquelle vous pouvez interagir via kubectl. Il comprend également un planificateur, qui décide quels conteneurs s'exécutent et où (planification des conteneurs). Le dernier composant est le gestionnaire de contrôleurs, qui est en réalité un ensemble de contrôleurs chargés de gérer les pannes de nœuds, la réplication, la fusion des services et des pods (ensembles de conteneurs), et enfin la gestion des comptes de service et des jetons d'accès à l'API. Toutes les données sont stockées dans etcd, une base de données clé-valeur hautement cohérente (dotée de fonctionnalités très intéressantes). En résumé, le maître est responsable de la gestion du cluster. Logique. Les nœuds de travail, quant à eux, gèrent les charges de travail. Pour ce faire, il comprend à nouveau plusieurs composants. Tout d'abord, il exécute le kubelet, une API qui interagit avec les conteneurs sur ce nœud. On trouve également le kube-proxy, qui redirige les connexions réseau, containerd pour l'exécution des conteneurs et, selon la configuration, d'autres éléments comme kube-dns ou gVisor. Vous aurez également besoin d'une couche réseau ou d'une intégration avec votre configuration réseau sous-jacente pour que Kubernetes puisse gérer la communication entre vos pods.

Kubernetes prêt pour la production

Cela, jusqu'à présent, ne sonne pas trop mal. Installez quelques programmes, configurations, certificats, etc. Ne vous méprenez pas, c'est toujours une courbe d'apprentissage, mais ce n'est rien qu'un administrateur système moyen n'ait pas traité dans le passé. Cependant, la simple installation manuelle de Kubernetes n'est pas exactement prête pour la production, alors parlons des étapes nécessaires à la mise en place de cette chose. Tout d'abord, l'installation.

Vous voulez vraiment avoir une sorte d'installation automatisée. Peu importe qu'il s'agisse d'Ansible, Terraform ou d'autres outils, vous voulez qu'il soit automatisé. kops, par exemple, aide à cela, mais l'utilisation de kops signifie que vous ne savez pas exactement comment il est configuré et peut causer des problèmes lorsque vous souhaitez déboguer quelque chose plus tard. Cette automatisation doit être testée et testée régulièrement. Ensuite, vous devez surveiller l'installation de Kubernetes. Donc tout de suite, vous avez besoin de quelque chose comme Prometheus, Grafana, etc. L'exécutez-vous dans votre Kubernetes ? Si votre Kubernetes a un problème, votre surveillance est-elle interrompue ? Ou le gérez-vous séparément ? Si oui, alors où le gérez-vous ?

A noter également les sauvegardes.

Que ferez-vous si votre maître plante, si les données sont irrécupérables et si vous devez restaurer tous les pods du système ? Avez-vous testé combien de temps il faut pour exécuter à nouveau toutes les tâches de votre système ? Avez-vous un plan de reprise après sinistre ? Maintenant, puisque nous parlons du système CI, nous devons exécuter un registre Docker pour les images. Ceci, bien sûr, peut être refait dans Kubernetes, mais si Kubernetes plante. Le système CI est évidemment aussi un problème, tout comme le système de contrôle de version. Idéalement, isolé de votre environnement de production afin que si ce système a un problème, vous puissiez au moins accéder à votre git, le redéployer, etc.

Stockage de données

Parlons de l'éléphant dans la salle : la mémorisation. Kubernetes en soi ne fournit pas de solution de stockage. Bien sûr, il est possible de monter un dossier depuis la machine hôte, mais ce n'est ni recommandé ni simple. Rok, par exemple, rend relativement facile l'utilisation de Ceph comme mémoire de bloc sous-jacente pour vos besoins de stockage de données, mais mon expérience avec Ceph est qu'il a beaucoup de valeurs et de configurations qui doivent être ajustées, donc vous n'êtes pas absent de la question du tout, de la difficulté à simplement passer à l'étape suivante.

Débogage

Lors de discussions avec des développeurs au sujet de Kubernetes, un constat revenait fréquemment : l’utilisation de Kubernetes managé posait problème pour le débogage des applications. Même des problèmes simples, comme l’impossibilité de démarrer un conteneur, étaient source de confusion. Il s’agit là, bien sûr, d’un problème de formation. Au cours des dernières décennies, les développeurs ont appris à déboguer les configurations « classiques » (consultation des fichiers journaux dans /var/log, etc.), mais avec les conteneurs, nous ignorons même sur quel serveur ils s’exécutent, ce qui représente un changement de paradigme.

Le problème de la complexité

Vous aurez peut-être remarqué que je passe sous silence les services proposés par les fournisseurs de cloud, même s'il ne s'agit pas d'une solution Kubernetes entièrement managée. Bien sûr, si vous utilisez une solution Kubernetes managée, c'est parfait, et vous n'aurez à vous soucier de rien de tout cela, hormis du débogage. Kubernetes est un système complexe, et Kubernetes seul ne constitue pas une solution complète. Red Hat OpenShift, par exemple, le fait , mais c'est payant, et vous devrez tout de même ajouter certains éléments vous-même. Actuellement, Kubernetes se trouve à l'aube d'une nouvelle ère selon le modèle de Gartner : tout le monde le veut, mais peu le comprennent vraiment. Dans les années à venir, de nombreuses entreprises devront se rendre compte que Kubernetes n'est pas la solution à tous les problèmes et apprendre à l'utiliser correctement et efficacement.

Je pense que faire fonctionner votre Kubernetes ne vaut la peine que si vous pouvez vous permettre de dédier une équipe d'exploitation à la question de la maintenance de la plate-forme sous-jacente pour vos développeurs.