Bonjour à tous,
On est entrain de "jouer" avec Kubernetes. On a dépassé le stade du "Ah mais c'est magique ! Ca marche tout seul." (on savait que ce stade n'allait pas durer longtemps ^^). Pour nos tests on a utilisé "d'anciens" serveurs physiques pour faire un cluster 1 master + 3 workers.
J'aimerais bien avoir vos retours sur le maintien en prod de votre/vos cluster K8s, que vous avez déployé(s) en interne (pas de AKS, ou autre GKE).
- Êtes-vous parti sur des bare-metal (qui demande surement plus de config) ? ou est-ce que vos workers sont des VMs ? - L'utilisation de VMs permet d'être plus flexible, mais en terme de performances, ne faut-il pas plutôt utiliser des srv physiques (pour éviter d'avoir une couche de virtu supplémentaire) ? - Comment est-ce que vous gérer le stockage ? Infra dédiée du type Ceph/autre ? - Quelle est votre gestions des logs (container + infra) ? Solution maison ? ou artillerie lourde du genre cluster Elasticsearch ?
Merci d'avance.
*Cordialement / Regards*
*Pierrick CHOVELON* Administrateur Systèmes *Département Infrastructure & Production* *A-SIS - 04 77 49 47 00* *pierrick.chovelon@a-sis.com pierrick.chovelon@a-sis.com*
On 06/12/2019 10:34, Pierrick CHOVELON wrote:
- Êtes-vous parti sur des bare-metal (qui demande surement plus de config) ? ou est-ce que vos workers sont des VMs ?
- L'utilisation de VMs permet d'être plus flexible, mais en terme de performances, ne faut-il pas plutôt utiliser des srv physiques (pour éviter d'avoir une couche de virtu supplémentaire) ?
L'overhead des vm(s) étant quasi négligeable de nos jours je pense que cela vaut le coup d'ajouter cet abstractions.
Le truc c'est qu'avec Kubernetes tu vas densifier. La question qui se pose en général c'est quel est le bon nombre de pods/processus pour un seul kernel linux ? bah oui parce que c'est pas magique et quand on densifie on hit les limites du kernel (et donc on doit tuner, aka faire du sysctl).
Chez nous on était arrivé à un compromis aka prendre des vm(s) moyenne (genre 4vcpu, 32g de ram) plutôt que des très grosse.
Après évidement si tu as un pod qui doit consommer plus que ça, la ça se discute et il vaux mieux à mon avis lui dédier un pool de worker.
- Comment est-ce que vous gérer le stockage ? Infra dédiée du type Ceph/autre ?
Le meilleur c'est aucun, que du stateless. Sinon de l'objet avec un protocole type s3 (avec du Ceph/openio). En tout éviter le FS distribué ou autre NFS.
- Quelle est votre gestions des logs (container + infra) ? Solution maison ? ou artillerie lourde du genre cluster Elasticsearch ?
ELK c'est pas si compliqué. Sinon Graylog (mais il te faut de l'ES aussi). Ou tu peux regarde le plus jeune Loki qui est prometteur sur le papier et beaucoup plus light.
--
Raphael Mazelier
Bonjour,
Tu trouvera sur la page Github https://github.com/hjacobs/kubernetes-failure-stories beaucoup de retours d'expériences sur ces différentes questions.
Ca demande un peu de lecture mais cela t'évitera de mauvaises surpises.
On Fri, Dec 6, 2019 at 3:17 PM Raphael Mazelier raph@futomaki.net wrote:
On 06/12/2019 10:34, Pierrick CHOVELON wrote:
- Êtes-vous parti sur des bare-metal (qui demande surement plus de
config) ? ou est-ce que vos workers sont des VMs ?
- L'utilisation de VMs permet d'être plus flexible, mais en terme de
performances, ne faut-il pas plutôt utiliser des srv physiques (pour éviter d'avoir une couche de virtu supplémentaire) ?
L'overhead des vm(s) étant quasi négligeable de nos jours je pense que cela vaut le coup d'ajouter cet abstractions.
Le truc c'est qu'avec Kubernetes tu vas densifier. La question qui se pose en général c'est quel est le bon nombre de pods/processus pour un seul kernel linux ? bah oui parce que c'est pas magique et quand on densifie on hit les limites du kernel (et donc on doit tuner, aka faire du sysctl).
Chez nous on était arrivé à un compromis aka prendre des vm(s) moyenne (genre 4vcpu, 32g de ram) plutôt que des très grosse.
Après évidement si tu as un pod qui doit consommer plus que ça, la ça se discute et il vaux mieux à mon avis lui dédier un pool de worker.
- Comment est-ce que vous gérer le stockage ? Infra dédiée du type
Ceph/autre ?
Le meilleur c'est aucun, que du stateless. Sinon de l'objet avec un protocole type s3 (avec du Ceph/openio). En tout éviter le FS distribué ou autre NFS.
- Quelle est votre gestions des logs (container + infra) ? Solution
maison ? ou artillerie lourde du genre cluster Elasticsearch ?
ELK c'est pas si compliqué. Sinon Graylog (mais il te faut de l'ES aussi). Ou tu peux regarde le plus jeune Loki qui est prometteur sur le papier et beaucoup plus light.
--
Raphael Mazelier _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
On 06/12/2019 15:33, Vincent Mercier wrote:
Bonjour,
Tu trouvera sur la page Github https://github.com/hjacobs/kubernetes-failure-stories beaucoup de retours d'expériences sur ces différentes questions.
Ca demande un peu de lecture mais cela t'évitera de mauvaises surpises.
Ah j'aurais beaucoup à partager aussi. Mais à la question si c'était à refaire, je referais sans hésiter.
--
Raphael Mazelier
Bonsoir,
A investir dans ce domaine, ca vaut le cout de regarder serieusement, Singularity (https://sylabs.io/docs/ (https://sylabs.io/docs/)).
-- FAI associatif [Viviers Fibre] http://viviers-fibre.net (http://viviers-fibre.net) https://yunohost.viviers-fibre.net (https://yunohost.viviers-fibre.net)
6 décembre 2019 17:52 "Raphael Mazelier" <raph@futomaki.net (mailto:raph@futomaki.net?to=%22Raphael%20Mazelier%22%20raph@futomaki.net)> a écrit: On 06/12/2019 15:33, Vincent Mercier wrote: Bonjour,
Tu trouvera sur la page Github https://github.com/hjacobs/kubernetes-failure-stories (https://github.com/hjacobs/kubernetes-failure-stories) beaucoup de retours d'expériences sur ces différentes questions.
Ca demande un peu de lecture mais cela t'évitera de mauvaises surpises. Ah j'aurais beaucoup à partager aussi. Mais à la question si c'était à refaire, je referais sans hésiter.
--
Raphael Mazelier
Bonjour,
Assez d'accord pour dire que garder la couche VM c'est pratique et ça ne consomme pratiquement rien.
Il ne faut surtout pas perdre de vue que du Docker c'est temporaire moyenne à 5 min (cf https://www.zdnet.fr/actualites/duree-de-vie-des-conteneurs-moins-de-cinq-mi...) ce qui signifie que toute volonté de faire du docker comme des VM est voué à l'échec. Je te passe les catastrophes de clients qui ont des docker avec des uptimes de plusieurs mois ou années et où la maintenance du host est impossible car les images sont trop anciennes, les dépendances plus en place, ... donc reboot impossible...
Ensuite vient K8s où sérieusement tant que tu n'as pas dans les 100 images identiques à faire pop sur un même cluster alors j'estime que ça n'en vaut pas la chandelle. Si l'objectif est de faire un cluster de baremetal et avoir dessus plein de services différents avec autant d'images docker alors il vaut mieux partir sur une autre solution.
L'autre solution c'est ton baremetal est un cluster de virtualisation au choix, et tu mets des VM qui font juste du Docker host. Ça permet d'une de faire des points de montage (base de données, applis, ...) sans se prendre la tête avec le stockage partagé. Et tu orchestres le tout avec de l'infrastructure as a code comme Ansible. Ca permet de démarrer rapidement une image sur plusieurs vm pour faire un cluster, tu évites tous les crashs K8s qui vont éclater ta prod, puisque là les vms sont indépendantes.
Et pour tous les services qui ont une durées de vie de plus d'une semaine, pas de Docker, un OS en VM piloté par Ansible c'est bien plus stable dans le temps.
Pour les logs il faut clairement externalisé du cluster, rappel au passage l'obligation légale de stocker pendant 1 an, combien de client en Docker ont les logs qui disparaissent quand l'image ou le K8s est explosé, s'il y a une requête judiciaire qui arrive pour avoir les logs de juste avant l'incident, le patron est quitte pour une prune et de la prison potentiellement ...
Voila mon point de vue, pour moi c'est génial quand tu déploies plein de conteneurs ayant la même fonctionnalité pour piloter le scale up and down. Pour faire une infra docker de tout un service / produit alors plutôt des docker hosts sinon des VMs en infra as a code c'est très efficace aussi.
Le 06/12/2019 à 10:34, Pierrick CHOVELON a écrit :
Bonjour à tous,
On est entrain de "jouer" avec Kubernetes. On a dépassé le stade du "Ah mais c'est magique ! Ca marche tout seul." (on savait que ce stade n'allait pas durer longtemps ^^). Pour nos tests on a utilisé "d'anciens" serveurs physiques pour faire un cluster 1 master + 3 workers.
J'aimerais bien avoir vos retours sur le maintien en prod de votre/vos cluster K8s, que vous avez déployé(s) en interne (pas de AKS, ou autre GKE).
- Êtes-vous parti sur des bare-metal (qui demande surement plus de config) ? ou est-ce que vos workers sont des VMs ?
- L'utilisation de VMs permet d'être plus flexible, mais en terme de performances, ne faut-il pas plutôt utiliser des srv physiques (pour éviter d'avoir une couche de virtu supplémentaire) ?
- Comment est-ce que vous gérer le stockage ? Infra dédiée du type Ceph/autre ?
- Quelle est votre gestions des logs (container + infra) ? Solution maison ? ou artillerie lourde du genre cluster Elasticsearch ?
Merci d'avance.
/Cordialement / Regards/
*Pierrick CHOVELON* Administrateur Systèmes *Département Infrastructure & Production* **A-SIS - /04 77 49 47 00/** _pierrick.chovelon@a-sis.com mailto:pierrick.chovelon@a-sis.com_
Liste de diffusion du FRsAG http://www.frsag.org/
On 06/12/2019 18:14, Wallace wrote:
Bonjour,
Assez d'accord pour dire que garder la couche VM c'est pratique et ça ne consomme pratiquement rien.
Il ne faut surtout pas perdre de vue que du Docker c'est temporaire moyenne à 5 min (cf https://www.zdnet.fr/actualites/duree-de-vie-des-conteneurs-moins-de-cinq-mi...) ce qui signifie que toute volonté de faire du docker comme des VM est voué à l'échec. Je te passe les catastrophes de clients qui ont des docker avec des uptimes de plusieurs mois ou années et où la maintenance du host est impossible car les images sont trop anciennes, les dépendances plus en place, ... donc reboot impossible...
En effet si on essaye de faire de la vm avec des containers c'est l'échec assuré. Un container est éphémère et doit pouvoir redémarrer à tout instant.
A l'époque on avais instauré un rollout complet de notre cluster tout les vendredis matin, et chose incroyable cela marchait très bien.
Ensuite vient K8s où sérieusement tant que tu n'as pas dans les 100 images identiques à faire pop sur un même cluster alors j'estime que ça n'en vaut pas la chandelle. Si l'objectif est de faire un cluster de baremetal et avoir dessus plein de services différents avec autant d'images docker alors il vaut mieux partir sur une autre solution.
L'autre solution c'est ton baremetal est un cluster de virtualisation au choix, et tu mets des VM qui font juste du Docker host. Ça permet d'une de faire des points de montage (base de données, applis, ...) sans se prendre la tête avec le stockage partagé. Et tu orchestres le tout avec de l'infrastructure as a code comme Ansible. Ca permet de démarrer rapidement une image sur plusieurs vm pour faire un cluster, tu évites tous les crashs K8s qui vont éclater ta prod, puisque là les vms sont indépendantes.
Et pour tous les services qui ont une durées de vie de plus d'une semaine, pas de Docker, un OS en VM piloté par Ansible c'est bien plus stable dans le temps.
C'est discutable. De quels crash k8s parle tu ? des crash du control plane ? parce qu'au final je n'ai quasiment jamais eu de problème lié à k8s lui même.
Pour les logs il faut clairement externalisé du cluster, rappel au passage l'obligation légale de stocker pendant 1 an, combien de client en Docker ont les logs qui disparaissent quand l'image ou le K8s est explosé, s'il y a une requête judiciaire qui arrive pour avoir les logs de juste avant l'incident, le patron est quitte pour une prune et de la prison potentiellement ...
De souvenir il y a obligation de moyen, pas de résultat ;) et puis il ne s'agit que des logs d'accès pas des logs techniques.
Mais bon oui il te faut une infra de log avec k8s puisque la bonne pratique selon les 12 factors apps étant de logguer stdout/stderr, après tu utilises ce que tu veux pour centraliser.
Voila mon point de vue, pour moi c'est génial quand tu déploies plein de conteneurs ayant la même fonctionnalité pour piloter le scale up and down. Pour faire une infra docker de tout un service / produit alors plutôt des docker hosts sinon des VMs en infra as a code c'est très efficace aussi.
Il faut utiliser ce avec quoi tu es à l'aise.
--
Raphael Mazelier
-
François Laperruque -
Pierrick CHOVELON -
Raphael Mazelier -
Vincent Mercier -
Wallace