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-minutes-douche-comprise-39893735.htm) 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.
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
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/