Guide pour celles et ceux qui détestent Kubernetes

Guide critique de Kubernetes

• Kubernetes a acquis, chez certains techniciens, la réputation d’être inutilement complexe et une perte de temps, et son utilisation par de petites équipes est considérée comme une forme de sur-ingénierie.
• Chez Jamsocket, après plusieurs années d’exploitation de Kubernetes en production, une manière efficace de l’utiliser a été trouvée : n’employer que les fonctionnalités nécessaires et ignorer le reste.

Pourquoi utiliser Kubernetes

• Kubernetes est la voie la plus éprouvée lorsque l’on veut simultanément les trois choses suivantes :
  • exécuter plusieurs processus/serveurs/tâches planifiées ;
  • les exécuter avec redondance et répartir la charge ;
  • configurer leur paramétrage et leurs relations mutuelles sous forme de code.
• Kubernetes est une couche d’abstraction qui permet de traiter un pool d’ordinateurs comme un seul ordinateur sans tête (headless).
• Jamsocket déploie plusieurs fois par jour, et comme un problème sur son produit affecte aussi celui de ses clients, les déploiements progressifs lui donnent la confiance nécessaire pour déployer souvent.

Comment Jamsocket utilise Kubernetes

• Jamsocket est un service qui crée des processus dynamiques capables de communiquer avec une application web, similaire à AWS Lambda, mais dont la durée de vie dépend d’une connexion WebSocket plutôt que d’un simple cycle requête/réponse.
• Kubernetes est utilisé pour faire tourner des processus de longue durée comme le serveur d’API, le registre de conteneurs, les contrôleurs, les collecteurs de logs, certains services DNS et la collecte de métriques.
• Ce qui n’utilise pas Kubernetes : les processus éphémères, les sites statiques/marketing, et les éléments qui stockent directement des données.
• Google Kubernetes Engine est utilisé pour déléguer la gestion de Kubernetes à un service externe, et une migration vers Amazon EKS reste relativement simple si nécessaire.

Ressources Kubernetes utilisées activement

• Deployments : la plupart des pods sont créés via des déploiements.
• Services : utilisation de ClusterIP pour les services internes et de LoadBalancer pour les services externes.
• CronJobs : utilisés pour les scripts de nettoyage, entre autres.
• ConfigMaps et Secrets : utilisés pour transmettre des données aux ressources ci-dessus.

Éléments utilisés avec prudence

• StatefulSet et PersistentVolumeClaim sont utilisés, mais les données importantes sont de préférence stockées dans des services managés en dehors de Kubernetes.
• Le RBAC est évité autant que possible car il ajoute de la complexité.

Éléments activement évités

• Écrire du YAML à la main : les définitions de ressources Kubernetes sont générées avec TypeScript et Pulumi.
• Ressources non standard et operators : ils permettent à des logiciels tiers d’utiliser l’infrastructure de Kubernetes, mais sont en pratique difficiles à utiliser.
• Helm : non utilisé à cause des operators et des conventions YAML.
• Tout ce qui contient "mesh" dans son nom : jugé inutile.
• Ressources Ingress : évitées pour ne pas ajouter une couche d’indirection inutile.
• Reproduire toute la stack k8s en local : seules les parties nécessaires du système sont lancées avec Docker Compose ou des scripts maison.

Les humains ne devraient pas attendre un Pod

• Kubernetes a été conçu en privilégiant la robustesse et la modularité plutôt que le temps de démarrage des conteneurs, et il n’est donc pas adapté aux cas où un humain attend le démarrage d’un Pod.
• Jamsocket utilise Plane, un orchestrateur Rust sous licence MIT, pour planifier et exécuter rapidement des processus destinés à des charges de travail interactives.

Abstractions de plus haut niveau

• Certaines alternatives à Kubernetes sont excellentes, en particulier lorsqu’il n’est pas nécessaire de décrire l’infrastructure sous forme de code.
• Il est aussi possible d’opter pour d’autres solutions à la place de Kubernetes, comme Railway, Render ou Flight Control.
• Si l’approche de Kubernetes est gérée de manière méthodique, personne ne pourra dire qu’il est adopté trop tôt.

Avis de GN⁺

• Kubernetes est un outil puissant pour la gestion de la complexité et l’automatisation, en particulier dans les systèmes à grande échelle, mais cette complexité peut représenter un fardeau pour les petits projets ou les startups.
• Cet article montre comment éviter une complexité excessive lors de l’usage de Kubernetes, afin d’aider les débutants ou les petites équipes à en tirer parti.
• Avant d’utiliser Kubernetes, il faut évaluer avec soin les fonctionnalités réellement nécessaires, les capacités techniques de l’équipe, ainsi que le rapport entre les bénéfices obtenus, la complexité de gestion et les coûts.
• À la place de Kubernetes, il peut être préférable d’utiliser des services plus simples et plus faciles à administrer. Par exemple : Docker Swarm, Apache Mesos ou Nomad, chacun avec ses avantages et ses inconvénients.
• Lors de l’adoption de Kubernetes, il faut prendre en compte l’intégration avec l’infrastructure existante, la sécurité, les coûts d’administration et la courbe d’apprentissage.
• Les bénéfices apportés par Kubernetes incluent la scalabilité, la haute disponibilité et une expérience de déploiement cohérente dans divers environnements cloud. Mais cela suppose de bien comprendre la gestion des ressources et l’orchestration nécessaires.

[GN⁺]

Avis Hacker News

• Résumé du premier commentaire :

  • Lorsqu’on adopte un système complexe comme Kubernetes, cette complexité continue de s’étendre, et divers composants se renforcent mutuellement jusqu’à devenir perçus comme indispensables.
  • Quand le cloud est apparu au départ, les gens étaient attirés par la réduction de la complexité liée aux load balancers et à la gestion des bases de données.
  • Les serveurs d’applications stateless ne posaient pas de gros problèmes de maintenance, mais l’évangélisation des microservices a créé des problèmes qui n’existaient pas.
  • Maintenant que cette culture s’est installée, il devient difficile d’acquiescer d’un simple signe de la main à l’idée que les microservices seraient indispensables.

• Résumé du deuxième commentaire :

  • En tant que personne qui introduit Kubernetes dans des PME, il y a eu des ingénieurs mécontents, mais la plupart se déclarent satisfaits.
  • Kubernetes est complexe, mais c’est un outil adapté aux problèmes complexes.
  • Avoir un standard vaut mieux qu’un chaos simple non documenté, et kubectl explain X est jugé bien meilleur que la documentation AWS.
  • Kubernetes est certes complexe, mais il fonctionne de la même manière que ce que les développeurs utilisaient dans leur emploi précédent, et la vitesse compte.

• Résumé du troisième commentaire :

  • Il est à la mode de critiquer Kubernetes, mais cela reste la meilleure solution.
  • Il permet de définir l’infrastructure de manière déclarative et fournit le load balancing, l’auto-réparation et le scaling.
  • Il offre une excellente observabilité sur l’ensemble de la stack, et permet d’utiliser de nombreux logiciels déjà packagés.
  • On peut construire pratiquement la même infrastructure dans le cloud, sur ses propres serveurs ou en local, sans dépendre d’un fournisseur cloud particulier.

• Résumé du quatrième commentaire :

  • Les grands avantages de Kubernetes sont Helm et les Operators.
  • Si l’on paie le coût de la complexité, il faut en retour bénéficier d’un « App Store » pour les composants d’infrastructure et de la possibilité de gérer les opérations par programmation.
  • Par exemple, pour mettre en place quelque chose de complexe comme Ceph, Rook est une bonne approche.
  • Helm et les Operators ne transforment pas l’infrastructure en appliance managée « clé en main », mais une interface déclarative est en général plus facile à administrer.

• Résumé du cinquième commentaire :

  • Kubernetes est une bonne technologie, mais sa complexité tend à faire des mainteneurs les héros de l’entreprise.
  • Les nombreux réglages et leviers peuvent détourner de l’objectif réel du projet.

• Résumé du sixième commentaire :

  • L’entreprise actuelle est divisée entre Kubernetes et un système de déploiement personnalisé basé sur Ansible.
  • L’approche Ansible fonctionne bien, mais migrer vers Kubernetes permettrait de réduire les temps de déploiement de plusieurs heures à quelques minutes, et d’automatiser le scaling plus rapidement et plus efficacement.
  • La difficulté à identifier la cause des échecs de déploiement Helm et la nécessité d’apprendre une nouvelle manière d’opérer sont des retours récurrents entendus de la part des équipes précédentes.

• Résumé du septième commentaire :

  • D’après une conversation avec un ancien ingénieur SRE de Google, très peu d’entreprises ont réellement besoin de Kubernetes.
  • Beaucoup de gens ont tendance à développer en suivant la mode.

• Résumé du huitième commentaire :

  • Kubernetes peut être le bon outil, mais il faut l’accepter comme un mal nécessaire.
  • Un logiciel susceptible d’échouer à faire collaborer correctement plusieurs parties en raison des défaillances de plusieurs acteurs peut souvent poser problème.

• Résumé du neuvième commentaire :

  • Écrire du YAML directement peut poser problème, donc à la place, on utilise TypeScript et Pulumi pour générer les définitions de ressources Kubernetes.
  • Au lieu de simplement lint le YAML, cela introduit tout un runtime de langage de programmation et des bibliothèques tierces, avec en plus la gestion des versions, la compilation du projet et d’autres complexités supplémentaires.

• Résumé du dixième commentaire :

  • Pour quelqu’un qui a été passionné par Kubernetes, les bonnes parties de Kubernetes sont les éléments de base (deployments, services, configmaps), et le reste ne devrait être utilisé que dans des situations particulières.
  • L’équipe préfère écrire du YAML brut et utiliser kustomize afin de garder la configuration claire et explicite.