Cher ami, tu as construit Kubernetes

• Lettre à un ami

  • Explication du fait qu’en essayant d’éviter Kubernetes, on finit malgré tout par construire un système similaire.
  • L’ami a choisi une « technologie ennuyeuse » pour exécuter simplement des conteneurs, mais s’est finalement heurté à des problèmes causés par des scripts et configurations complexes.
  • Même en passant à Docker Compose, on se rend compte que cela ne résout pas tous les problèmes, et qu’il faut des solutions distinctes pour le déploiement, les rolling updates, les rollbacks et le scaling.

• Extension des serveurs et complexité réseau

  • Le besoin d’étendre l’infrastructure à un deuxième serveur se fait sentir.
  • Tentative de découverte de services à l’aide d’un réseau overlay comme Tailscale.
  • Malgré les efforts pour résoudre la complexité réseau, on finit par se retrouver face à encore plus de problèmes.

• Maintenance et automatisation

  • Une question se pose : si la personne qui a écrit les scripts part en vacances ou quitte l’entreprise, qui gérera cette configuration complexe et les changements non documentés ?
  • Pour résoudre les problèmes de maintenance des scripts personnalisés, les VM sont rendues immuables et versionnables avec Ansible.
  • On pense que ce sera plus facile à maintenir précisément parce qu’on n’utilise pas Kubernetes.

• Provisionnement de conteneurs et problèmes de sécurité

  • Un besoin apparaît : créer programmatiquement d’autres conteneurs.
  • Monter le socket Docker dans une application web étant risqué du point de vue de la sécurité, un service séparé est écrit pour résoudre ce problème.
    • Le problème est résolu en écrivant un service distinct qui n’expose que les parties sûres de l’API Docker.

• Conclusion

  • On finit par réaliser qu’on a construit un système similaire à Kubernetes.
    • Un système complexe complet, avec un format de configuration standard, une méthode de déploiement, un réseau overlay, de la découverte de services, des nœuds immuables et un serveur d’API

• PS

  • Cela ne signifie pas qu’il n’existe pas de meilleure solution pour remplacer Kubernetes.
  • Mais avant d’affirmer que Kubernetes est trop complexe, il est recommandé de bien comprendre les problèmes qu’il cherche à résoudre.

[savvykang]

J’ai du mal à comprendre l’idée d’adopter Kubernetes pour régler les passations liées aux déploiements.

[kandk]

La maintenance et l’automatisation sont faciles à gérer au niveau du code.
L’infrastructure as code est également possible.

[savvykang]

Dans un environnement de service k8s managé comme EKS, il y a un load balancer et l’intégration avec Route 53 est possible, mais avec un k8s auto-hébergé, il n’y a pas d’implémentation de load balancer et l’intégration DNS est aussi limitée. Dans une entreprise qui dispose d’une équipe dédiée à l’administration de k8s, les avantages que vous avez mentionnés peuvent effectivement être réels.

À première vue, cela semble être une bonne solution, mais en pratique, elle ne fonctionne pas dans toutes les situations.

[kandk]

C'est facile à utiliser même sans équipe dédiée à la gestion de k8s. Il suffit d'utiliser EKS.

[savvykang]

N’est-ce pas finalement la même idée que d’affirmer que la passation est terminée dès qu’on fournit uniquement le code source ? J’ai l’impression qu’un manuel des procédures et l’historique d’exécution du travail restent toujours nécessaires.

[kbumsik]

L’Infrastructure as Code, en soi, est justement là pour qu’on puisse s’arrêter au fait de fournir uniquement le code source.
Bien sûr, comme pour n’importe quel code, il faut malgré tout une documentation de base.

[kandk]

C’est possible si le code source est bien conçu et que la documentation est de qualité.
Avoir séparément un manuel de travail et un historique d’exécution des tâches peut être utile, mais j’ai l’impression que c’est un autre sujet que celui de cet article.

[GN⁺]

Avis Hacker News

• Expérience de déploiements réussis dans plusieurs entreprises à l’aide de scripts shell

  • Traitement de plus d’un milliard de requêtes par jour avec deux services PHP, avec déploiement sans interruption en transférant les fichiers sur les serveurs et en exécutant les migrations
  • Dans des secteurs qui n’ont pas besoin d’une échelle web, comme les comptes retraite, déploiements effectués via des commandes Docker dans Jenkins
  • Possibilité de disposer d’environnements de test à la demande en quelques minutes
  • L’entreprise actuelle cherche à adopter Kubernetes, mais se heurte à sa complexité

• Kubernetes nécessite deux ou trois personnes dédiées uniquement à la gestion des fichiers YAML

  • Choisir un fournisseur cloud peut résoudre les parties complexes, mais cela entraîne des coûts supplémentaires
  • Les fichiers YAML sont des fichiers de configuration qui devraient être générés par des outils, pas écrits à la main
  • La plupart des sites web et services n’ont pas besoin de Kubernetes

• L’idée que le simple est fragile est erronée

  • Il est plus difficile de comprendre et de déboguer la complexité de YAML et de Kubernetes
  • Les scripts shell constituent une alternative à Kubernetes

• Il existe aussi des cas où Kubernetes n’est pas nécessaire

  • Des instances EC2 et de simples scripts shell suffisent pour gérer plus de 100 000 utilisateurs simultanés
  • S’il n’y a pas de problème, il n’y a pas de raison de changer

• Avec des scripts shell, on peut facilement gérer les règles iptables et l’édition de sysctl

  • En utilisant une file de tâches, on peut pousser les tâches au lieu de créer des conteneurs de manière programmatique

• Critiquer Kubernetes serait non professionnel

  • Si l’on n’a pas une application à très grande échelle comme Google ou Netflix, mieux vaut écrire des scripts simples

• Il est faux de supposer que les contraintes d’un système maison ne sont que des coûts, et que la flexibilité d’une solution générique n’apporte que des avantages

  • On veut suivre des modèles similaires dans la base de code et que les services soient déployés de la même manière

• Le problème de Kubernetes est que d’innombrables bibliothèques open source rendent le système difficile à comprendre et provoquent des bugs

• Ceux qui ont dépassé la courbe d’apprentissage de Kubernetes disent que sa complexité n’est pas si grave

  • Former des développeurs à Kubernetes prend environ 30 minutes et leur permet d’écrire des charts Helm