- Ê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