Je suis tombé sur ce lien via le journal du hacker et comme c'est pas simple ni de commenter sur le JdH ni sur le post initial, je profite de linuxfr :p
L'article essaie de dire que kubernetes c'est très compliqué et que ce n'est pas toujours la bonne solution. C'est vrai, mais impatient de voir quels étaient ces retours d’expérience je suis un peu sur ma faim.
In the last few years, Kubernetes has been a game-changer for us.
Et explique que c'est compliqué qu'ils se sont lancé un peu tôt dans kubernetes mais qu'ils sont content de leur choix.
Et les autres expliquent simplement qu'ils sont parti chez une solution propriétaire de chez AWS ou Google avec du coup un beau vendor lockin…
L'article parle d'une meta-loi (ça fait toujours bien les méta loi) sur la complexité, mais semble ne pas voir qu'ici la complexité est déplacée d'un système que tu contrôle (si tenté que tu es les compétences pour) avec kubernetes vers un le cloud provider. Bref le paradox de Tog dont il parle s'applique encore plus aux solutions cités dans l'article…
J'ai administré un cluster kubernetes on-premise pendant quelques années. Je comprends bien le niveau de complexité que ça représente, mais j'ai pas encore trouvé de solution pour avoir un déploiement aussi souple (avec la possibilité de perdre une machine et que les services soient déplacés par exemple et du rolling déploiement). J'ai un point de vue double sur kubernetes qui est plus complexe que ce dont beaucoup de gens ont besoin mais qui est le seul à offrir ces possibilités là.
mais j'ai pas encore trouvé de solution pour avoir un déploiement aussi souple (avec la possibilité de perdre une machine et que les services soient déplacés par exemple et du rolling déploiement)
Je fais ça avec Nomad (Hashicorp) c'est passé en licence BSL mais bon c'est beaucoup plus simple et ca fait le job..
Et k3s qui se présente comme un k8s mais en plus simple.
Je suis partagé de la notion de plus simple chez k3s d'un côté un binaire unique c'est un peu plus simple, mais je ne trouve pas que traefik soit plus simple qu'un ingress nginx, je ne trouve pas non plus que kine soit plus simple qu'etcd, etc. Ils intégrent de remplaçants qui sont très bien, mais qui aussi ajoute des nouveaux projets et tout ce qui va avec.
avec la possibilité de perdre une machine et que les services soient déplacés par exemple
C'est une assez mauvaise idée de perdre une machine. Perso je les attache avec des cables RJ 45 doublés de câbles C13 et je pense à laisser un lecteur CD à ouvrir pour les identifier au cas où elles seraient noyées dans la masse (oui les leds en façade ça marche aussi). Ainsi, en plus de 20 ans de métier je n'ai jamais perdu une machine.
Il m'est déjà arrivé de pouvoir ping une machine mais de ne pas pouvoir la retrouver IRL. La personne qui l'avait installé était plus là, c'était la seul à s'en occuper et rien n'était documenté.
La joie de travailler dans une très grande structure.
Ce n'est pas parce que la boite de pizza, tout ce qu'il contient et l'armoire sont physiquement là que je ne me retrouve pas privé du serveur en question, mais si en 20 ans attacher avec des câbles RJ45 t'a permis d'éviter d'avoir à faire des sauvegardes c'est que ça doit être la bonne méthode.
Pour un précédent poste, on m'avait demandé d'étudier Kubernetes. Mais après un certain temps, changement d'avis. Kubernetes était trop complexe par rapport à leurs besoin de PME.
Finalement, la solution retenue fut Docker + Portainer. Solution qui devais déjà être géré en plus de l'ancienne infrastructures constitué de nombreuses VM. Je suis partit avant que tout ne soit déplacé vers des conteneurs.
Expérience personnelle
À titre personnel, j'ai voulu passer à Kubernetes à la maison. Histoire de pas gaspiller ce que j'avais appris. Mais au final je suis partit sur une autre solution.
J'utilise des conteneurs exécutés par Podman au niveau utilisateur.
Chaque service est définit par un pod, qui regroupe tout les conteneurs utilisés par le dit service.
Pour les images, je n'utilise que des images officiels ou des images faite maison. Pour ces dernières, j'ai une machine dédiée sur laquelle je construit les images pour les placer sur un registre local.
J'utilise également Caddy comme revers-proxy. Caddy se charge aussi de récupérer tout ce qu'il faut auprès de Let's Encrypt pour TLS. Je peux le configurer sans devoir le redémarrer. J'ai juste à déposer un fichier dans un dossier et à exécuter une commande dans le conteneur du reverse-proxy. Et j'ai un réseau qui relie le revers-proxy aux conteneurs qui en ont besoin.
Le tout est déployé et configuré avec Ansible. J'ai un rôle qui prépare chaque hôte pour accueillir les conteneurs et un autre qui prépare la machine de build.
Pour les sauvegardes, j'ai des conteneurs dont c'est le rôle. Quand ils sont exécutés, ils accèdent aux volumes qui doivent êtres sauvegardés et créent une archive. J'ai un script bash coté système qui stop et démarre les conteneurs dans le bon ordre pour que le backup soit fait. Pas optimal, il faut que j'améliore ça.
Pour les mises à jour, j'utilise la fonction auto-update de Podman.
Du coté des améliorations futures: Avec l'arrivée des Quadlets dans Podman, ça permettra de déclarer certaines ressources et conteneurs en tant qu'unités Systemd. Je pense utiliser les git-hook pour construire automatiquement les images maison. Il reste les sauvegardes, qu'il faut que je simplifie. Et peut-être la configuration du reverse-proxy.
J'ai un rôle qui prépare chaque hôte pour accueillir les conteneurs et un autre qui prépare la machine de build.
Chaque hôte ? Tu as un cluster en perso ? Et podman gère des clusters ?
Matériellement comment se présente ton déploiement ? Je veux dire c'est un fichier descriptif qui représente l'ensemble ? C'est des script ansible ou shell ? Je ne connais pas bien podman
Posté par cg .
Évalué à 5 (+3/-0).
Dernière modification le 18 novembre 2024 à 22:52.
Dans beaucoup d'entreprises, pour beaucoup de produits, avoir un simple réplica "à chaud" prêt à prendre le relais suffit. Une minute, voire deux minutes de coupure tous les deux ans ? Et après ? La plupart des utilisateurs croiront que c'est leur perruche qui s'est perchée sur l'antenne Wi-Fi.
Mon avis est qu'il y a moins de systèmes critiques que ce que l'on croit. Et pour ces systèmes vraiment critiques, Kubernetes est une bénédiction !
Mon avis est qu'il y a moins de systèmes critiques que ce que l'on croit.
En fait ça dépend du domaine dans le quel tu travail. Pour que l’expérience d'un utilisateur final soit 2 minutes d'indisponibilité tous les 2 ans, il faut que le service en question ai 2 minutes d'indisponibilité maximale sur 2 ans. Donc il faut que les services sur les quels il s'appuie en ai moins et ainsi de suite. C'est pour ça que Google prenait comme règle que tu ajoute un 9 de SLA à chaque niveau de dépendances. Un service A qui s'appuie sur le service B qui s'appuie sur le service C ? pour que A ai 99% de SLA (3 jours et demi par an), il faut que B ai 99.9% (9h par an) et C 99.99% (53 min). 2 minutes c'est 3 neuf après la virgule donc ton hébergeur devrait (selon cette règle) être à 4 neuf soit 31s. Pour te donner un ordre d'idée le service EC2 d'amazon est vendu pour être à 9.99%.
Mais globalement quand tu fourni du service aux entreprises et pas des produits pour utilisateurs finaux tu va devoir commencer à te poser ce genre de questions. Et si comme là où j'étais il n'y a pas si longtemps, tu héberge ta propre plateforme, tu va devoir faire le même travail pour l'électricité, la ligne fibre etc. La simplicité qu'offre un hébergeur même sans être "cloud" est assez fantastique.
Et pour ces systèmes vraiment critiques, Kubernetes est une bénédiction !
Avec un bon niveau de maitrise je n'en doute pas, avec mon niveau il y a des moments où il te sauve la vie et d'autres où il est très pénible.
Heu pas vraiment ça impose une complexité de dingue, par exemple voir ce blog de gitpod https://www.gitpod.io/blog/we-are-leaving-kubernetes et ils ont poncé Kube c'est loin d'être des débutants, et il y a 14 itérations de "complex" et "complexity" ..
Kube c'est pour faire "comme Google" ..
Le service discovery est la base fondamentale de k8s/nomad et permet souvent de faire de très grosse infra sans sortir l'usine à gaz (k8s). Consul ou etcd, avec un peu de nginx/caddy peut suffire. D'ailleurs beaucoup de proxy supporte le service discovery de manière avancée ou juste avec le DNS local.
Perso, (dans mon travail) je monte des services (binaire golang) via ansible et le service discovery gère le reste, via consul + traefik, et haproxy pour d'autre truc plus subtile niveau config.
C'est juste magique et facile à comprendre (donc maintenable et facile à debug en cas de soucis). Et surtout respecte la philosophie UNIX, on rajoute juste quelques outils (qui ne font qu'une chose) au système existant pas besoin de ré-apprendre tout un univers entier.
Je trouve pas que ce soit l'intérêt principal. Pour moi l'intérêt principal c'est d'avoir un déploiement as code et de pouvoir gérer des cycles de vie (vérifier qu'un service est en vie, gérer sa mise à jour, son éventuel rollback, etc). Le service discovery n'est qu'un moyen de parvenir à ça de mon point de vu.
# Commentaire
Posté par barmic 🦦 . Évalué à 4 (+3/-1).
Je suis tombé sur ce lien via le journal du hacker et comme c'est pas simple ni de commenter sur le JdH ni sur le post initial, je profite de linuxfr :p
L'article essaie de dire que kubernetes c'est très compliqué et que ce n'est pas toujours la bonne solution. C'est vrai, mais impatient de voir quels étaient ces retours d’expérience je suis un peu sur ma faim.
Déjà l'un des liens se conclue par (désolé c'est medium)
Et explique que c'est compliqué qu'ils se sont lancé un peu tôt dans kubernetes mais qu'ils sont content de leur choix.
Et les autres expliquent simplement qu'ils sont parti chez une solution propriétaire de chez AWS ou Google avec du coup un beau vendor lockin…
L'article parle d'une meta-loi (ça fait toujours bien les méta loi) sur la complexité, mais semble ne pas voir qu'ici la complexité est déplacée d'un système que tu contrôle (si tenté que tu es les compétences pour) avec kubernetes vers un le cloud provider. Bref le paradox de Tog dont il parle s'applique encore plus aux solutions cités dans l'article…
J'ai administré un cluster kubernetes on-premise pendant quelques années. Je comprends bien le niveau de complexité que ça représente, mais j'ai pas encore trouvé de solution pour avoir un déploiement aussi souple (avec la possibilité de perdre une machine et que les services soient déplacés par exemple et du rolling déploiement). J'ai un point de vue double sur kubernetes qui est plus complexe que ce dont beaucoup de gens ont besoin mais qui est le seul à offrir ces possibilités là.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Commentaire
Posté par ash . Évalué à 4 (+3/-0).
Je fais ça avec Nomad (Hashicorp) c'est passé en licence BSL mais bon c'est beaucoup plus simple et ca fait le job..
[^] # Re: Commentaire
Posté par steph1978 . Évalué à 4 (+2/-0).
Nomad m'est venu à l'esprit aussi.
Et k3s qui se présente comme un k8s mais en plus simple.
Et il y a aussi l'OTP dans un autre style.
[^] # Re: Commentaire
Posté par aiolos . Évalué à 3 (+1/-0).
Quelqu’un à des retours d’expérience sur Openshift ?
[^] # Re: Commentaire
Posté par barmic 🦦 . Évalué à 5 (+3/-0).
Je suis partagé de la notion de plus simple chez k3s d'un côté un binaire unique c'est un peu plus simple, mais je ne trouve pas que traefik soit plus simple qu'un ingress nginx, je ne trouve pas non plus que kine soit plus simple qu'etcd, etc. Ils intégrent de remplaçants qui sont très bien, mais qui aussi ajoute des nouveaux projets et tout ce qui va avec.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Commentaire
Posté par barmic 🦦 . Évalué à 2 (+0/-0).
Je regarderais nomad pour la curiosité merci.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Commentaire
Posté par ash . Évalué à 3 (+2/-0).
J'ai fais quelques articles si ça peut t'aider, à commencer par le plus ancien : https://fredix.xyz/tags/nomad/
[^] # Re: Commentaire
Posté par Pol' uX (site web personnel) . Évalué à 7 (+6/-1).
C'est une assez mauvaise idée de perdre une machine. Perso je les attache avec des cables RJ 45 doublés de câbles C13 et je pense à laisser un lecteur CD à ouvrir pour les identifier au cas où elles seraient noyées dans la masse (oui les leds en façade ça marche aussi). Ainsi, en plus de 20 ans de métier je n'ai jamais perdu une machine.
Adhérer à l'April, ça vous tente ?
[^] # Re: Commentaire
Posté par Yuul B. Alwright . Évalué à 3 (+2/-0).
Il m'est déjà arrivé de pouvoir ping une machine mais de ne pas pouvoir la retrouver IRL. La personne qui l'avait installé était plus là, c'était la seul à s'en occuper et rien n'était documenté.
La joie de travailler dans une très grande structure.
[^] # Re: Commentaire
Posté par Pol' uX (site web personnel) . Évalué à 5 (+3/-0).
Quand tu l'auras trouvée tu pourras lui adjoindre un lecteur CD (et une étiquette). :)
Adhérer à l'April, ça vous tente ?
[^] # Re: Commentaire
Posté par barmic 🦦 . Évalué à 4 (+2/-0).
Ce n'est pas parce que la boite de pizza, tout ce qu'il contient et l'armoire sont physiquement là que je ne me retrouve pas privé du serveur en question, mais si en 20 ans attacher avec des câbles RJ45 t'a permis d'éviter d'avoir à faire des sauvegardes c'est que ça doit être la bonne méthode.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# Ma petite expérience
Posté par Yuul B. Alwright . Évalué à 5 (+4/-0).
Expérience professionnelle
Pour un précédent poste, on m'avait demandé d'étudier Kubernetes. Mais après un certain temps, changement d'avis. Kubernetes était trop complexe par rapport à leurs besoin de PME.
Finalement, la solution retenue fut Docker + Portainer. Solution qui devais déjà être géré en plus de l'ancienne infrastructures constitué de nombreuses VM. Je suis partit avant que tout ne soit déplacé vers des conteneurs.
Expérience personnelle
À titre personnel, j'ai voulu passer à Kubernetes à la maison. Histoire de pas gaspiller ce que j'avais appris. Mais au final je suis partit sur une autre solution.
J'utilise des conteneurs exécutés par Podman au niveau utilisateur.
Chaque service est définit par un pod, qui regroupe tout les conteneurs utilisés par le dit service.
Pour les images, je n'utilise que des images officiels ou des images faite maison. Pour ces dernières, j'ai une machine dédiée sur laquelle je construit les images pour les placer sur un registre local.
J'utilise également Caddy comme revers-proxy. Caddy se charge aussi de récupérer tout ce qu'il faut auprès de Let's Encrypt pour TLS. Je peux le configurer sans devoir le redémarrer. J'ai juste à déposer un fichier dans un dossier et à exécuter une commande dans le conteneur du reverse-proxy. Et j'ai un réseau qui relie le revers-proxy aux conteneurs qui en ont besoin.
Le tout est déployé et configuré avec Ansible. J'ai un rôle qui prépare chaque hôte pour accueillir les conteneurs et un autre qui prépare la machine de build.
Pour les sauvegardes, j'ai des conteneurs dont c'est le rôle. Quand ils sont exécutés, ils accèdent aux volumes qui doivent êtres sauvegardés et créent une archive. J'ai un script bash coté système qui stop et démarre les conteneurs dans le bon ordre pour que le backup soit fait. Pas optimal, il faut que j'améliore ça.
Pour les mises à jour, j'utilise la fonction auto-update de Podman.
Du coté des améliorations futures: Avec l'arrivée des Quadlets dans Podman, ça permettra de déclarer certaines ressources et conteneurs en tant qu'unités Systemd. Je pense utiliser les git-hook pour construire automatiquement les images maison. Il reste les sauvegardes, qu'il faut que je simplifie. Et peut-être la configuration du reverse-proxy.
[^] # Re: Ma petite expérience
Posté par barmic 🦦 . Évalué à 3 (+1/-0).
Chaque hôte ? Tu as un cluster en perso ? Et podman gère des clusters ?
Matériellement comment se présente ton déploiement ? Je veux dire c'est un fichier descriptif qui représente l'ensemble ? C'est des script ansible ou shell ? Je ne connais pas bien podman
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# Un actif-passif simple suffit souvent
Posté par cg . Évalué à 5 (+3/-0). Dernière modification le 18 novembre 2024 à 22:52.
Dans beaucoup d'entreprises, pour beaucoup de produits, avoir un simple réplica "à chaud" prêt à prendre le relais suffit. Une minute, voire deux minutes de coupure tous les deux ans ? Et après ? La plupart des utilisateurs croiront que c'est leur perruche qui s'est perchée sur l'antenne Wi-Fi.
Mon avis est qu'il y a moins de systèmes critiques que ce que l'on croit. Et pour ces systèmes vraiment critiques, Kubernetes est une bénédiction !
[^] # Re: Un actif-passif simple suffit souvent
Posté par barmic 🦦 . Évalué à 2 (+0/-0).
En fait ça dépend du domaine dans le quel tu travail. Pour que l’expérience d'un utilisateur final soit 2 minutes d'indisponibilité tous les 2 ans, il faut que le service en question ai 2 minutes d'indisponibilité maximale sur 2 ans. Donc il faut que les services sur les quels il s'appuie en ai moins et ainsi de suite. C'est pour ça que Google prenait comme règle que tu ajoute un 9 de SLA à chaque niveau de dépendances. Un service A qui s'appuie sur le service B qui s'appuie sur le service C ? pour que A ai 99% de SLA (3 jours et demi par an), il faut que B ai 99.9% (9h par an) et C 99.99% (53 min). 2 minutes c'est 3 neuf après la virgule donc ton hébergeur devrait (selon cette règle) être à 4 neuf soit 31s. Pour te donner un ordre d'idée le service EC2 d'amazon est vendu pour être à 9.99%.
Mais globalement quand tu fourni du service aux entreprises et pas des produits pour utilisateurs finaux tu va devoir commencer à te poser ce genre de questions. Et si comme là où j'étais il n'y a pas si longtemps, tu héberge ta propre plateforme, tu va devoir faire le même travail pour l'électricité, la ligne fibre etc. La simplicité qu'offre un hébergeur même sans être "cloud" est assez fantastique.
Avec un bon niveau de maitrise je n'en doute pas, avec mon niveau il y a des moments où il te sauve la vie et d'autres où il est très pénible.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Un actif-passif simple suffit souvent
Posté par ash . Évalué à 2 (+1/-0).
Heu pas vraiment ça impose une complexité de dingue, par exemple voir ce blog de gitpod https://www.gitpod.io/blog/we-are-leaving-kubernetes et ils ont poncé Kube c'est loin d'être des débutants, et il y a 14 itérations de "complex" et "complexity" ..
Kube c'est pour faire "comme Google" ..
Une boite comme Roblox avec des millions de users utilisent Nomad : https://www.somerfordassociates.com/wp-content/uploads/2021/09/HashiCorp_Roblox_Case_Study-compressed.pdf
# Pourquoi personne ne parle jamais du service discovery ?
Posté par MookSkook . Évalué à 3 (+3/-0).
Le service discovery est la base fondamentale de k8s/nomad et permet souvent de faire de très grosse infra sans sortir l'usine à gaz (k8s). Consul ou etcd, avec un peu de nginx/caddy peut suffire. D'ailleurs beaucoup de proxy supporte le service discovery de manière avancée ou juste avec le DNS local.
Perso, (dans mon travail) je monte des services (binaire golang) via ansible et le service discovery gère le reste, via consul + traefik, et haproxy pour d'autre truc plus subtile niveau config.
C'est juste magique et facile à comprendre (donc maintenable et facile à debug en cas de soucis). Et surtout respecte la philosophie UNIX, on rajoute juste quelques outils (qui ne font qu'une chose) au système existant pas besoin de ré-apprendre tout un univers entier.
Après évidemment ça dépend du usecase.
[^] # Re: Pourquoi personne ne parle jamais du service discovery ?
Posté par barmic 🦦 . Évalué à 4 (+2/-0).
Je trouve pas que ce soit l'intérêt principal. Pour moi l'intérêt principal c'est d'avoir un déploiement as code et de pouvoir gérer des cycles de vie (vérifier qu'un service est en vie, gérer sa mise à jour, son éventuel rollback, etc). Le service discovery n'est qu'un moyen de parvenir à ça de mon point de vu.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.