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..
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.
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.
# Commentaire
Posté par barmic 🦦 . Évalué à 2 (+1/-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é à 2 (+1/-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é à 2 (+0/-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é à 2 (+0/-0).
Quelqu’un à des retours d’expérience sur Openshift ?
[^] # Re: Commentaire
Posté par Pol' uX (site web personnel) . Évalué à 1 (+0/-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é à 1 (+0/-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.
# Ma petite expérience
Posté par Yuul B. Alwright . Évalué à 1 (+0/-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.
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.