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 ?

En grande partie, Kubernetes ou K8 semblent être très simples. Les nœuds (machines) sur lesquels Kubernetes s'exécute sont divisés en (au moins) deux types : le maître et les travailleurs. Le ou les maîtres, par défaut, n'effectuent aucune charge de travail réelle, c'est le travail des ouvriers. Le maître Kubernetes comprend un composant appelé serveur d'API qui fournit une API à laquelle vous pouvez parler à l'aide de kubectl. Il comprend également un planificateur, qui décide quel conteneur doit s'exécuter où (conteneurs de planification). Le dernier composant est le contrôleur-gestionnaire, qui est en fait un ensemble de plusieurs contrôleurs chargés de gérer les pannes de nœuds, de gérer les réplicas, de fusionner les services et les pods (ensembles de conteneurs), et enfin de gérer les comptes de service et les jetons d'accès aux API. Toutes les données sont stockées dans etcd, qui est une base de données de valeurs clés très cohérente (avec des fonctionnalités vraiment intéressantes). Donc, pour résumer, le maître est responsable de la gestion du cluster. Pas étonnant. Le travailleur, quant à lui, gère les charges de travail réelles. A cet effet, il comprend, encore une fois, un certain nombre de composants. Tout d'abord, il exécute le kubelet, qui est à nouveau une API qui fonctionne avec des conteneurs sur ce nœud. Il existe également le kube-proxy, qui transfère les connexions réseau, containerd pour exécuter le conteneur, et selon la configuration, il peut y avoir d'autres choses comme kube-dns ou gVisor. Vous aurez également besoin d'une sorte de réseau de superposition ou d'intégration avec votre configuration réseau sous-jacente afin que Kubernetes puisse gérer le réseau 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

Lorsque l'on parlait de Kubernetes avec les développeurs, un schéma courant s'est présenté assez régulièrement : lorsqu'ils utilisaient un Kubernetes géré, les gens avaient du mal à déboguer leurs applications. Même des problèmes simples, tels qu'un conteneur qui ne démarre pas, ont causé de la confusion. Ceci, bien sûr, est un problème d'éducation. Au cours des dernières décennies, les développeurs ont appris à déboguer des configurations « classiques » : lecture des fichiers journaux dans /var/log, etc. mais avec les conteneurs, nous ne savons même pas sur quel serveur le conteneur s'exécute, ce qui représente un changement de paradigme.

Le problème de la complexité

Vous avez peut-être remarqué que j'ignore ce que les fournisseurs de cloud vous offrent, même s'il ne s'agit pas d'un Kubernetes entièrement géré. Bien sûr, si vous utilisez une solution gérée par Kubernetes, c'est très bien et vous n'avez pas à vous soucier de tout cela, à l'exception du débogage. Kubernetes a beaucoup de pièces mobiles, et Kubernetes à lui seul ne fournit pas une pile complète de solutions. RedHat OpenShift, par exemple, fait cela, mais cela coûte et vous devez toujours ajouter des choses vous-même. À l'heure actuelle, Kubernetes est sur la colline du cycle de battage médiatique de Gartner, tout le monde le veut, mais peu le comprennent vraiment. Dans les prochaines années, plusieurs entreprises devront se rendre compte que Kubernetes n'est pas la solution à tous les maux et comprendre comment 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.