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/