Deploiement sur K8s, LivenessProbe ReadinessProbe

Bonjour,

Pour notre besoin en Preprod et Prod, on souhaiterait déployer 2 replicaSet en autosacle (seulement pour simplicite), nous n’avons pas assez de recule pour connaitre la volumétrie pour le moment.

Quels seraient vos recommandations pour avoir une utilisation optimale, nous avons opté pour 80% de charge d’utilisation pour augumenter le nombre de ressource.

En fonction de vos retours d’experience sur un déploiement de l’application sur K8s, on aimerait bien savoir si on reste sur ce pourcentage (en attandant d’avoir des métriques sur la volumétrie attendue)?

Cordialement.
Kahina Ferroukhi

Nous n’avons pas de métriques dans l’absolu pour ce genre de chose car les performances (et donc les besoins en scalabilité) sont à 100% métier = le nombre d’utilisateurs simultanés, le nombre et le volume unitaire des données métier auxquels ils accèdent, la fréquence à laquelle il font des lectures/écritures, la complexité des traitements et des règles de gestion qui s’appliquent, etc.

Le mieux pour mesurer le comportement de votre application en charge(et de faire le tuning ad hoc si besoin) c’est de la bencher en lui injectant un scénario métier réaliste/représentatif qui correspond à cet usage effectif.

En général pour des applications métier de type “référentiels” sur lesquels il n’y a pas beaucoup de traitements lourds mais plutôt de “simples” lectures écritures, il convient de surveiller plus la mémoire que le CPU, et surtout les performances de la base de données plutôt que celles des noeuds Simplicité (qui font du “passe-plat” intelligent d’accès en base mais finalement assez peu de traitement). Mais oui effectivement ajouter un noeud quand la consommation mémoire et/ou CPU d’un noeud atteint 80% est une bonne approche à priori

Dans tous les cas si vous mettez en place de l’(auto)scaling avec plusieurs noeuds pour un usage essentiellement “UI” veillez bien à faire du load-balancing en sticky session.

NB: certain de nos clients dédient des noeuds pour les usages API et/ou batch (I/O) et d’autres pour les usages UI, dans tous les cas le composnat le plus impactant pour les performances restera la base de données qui elle sera à priori commune (à moins de mettre en place des choses complexes à ce niveau mais nous n’avons pas d’expertise pour vous aider sur ça). Assurez vous de bien avoir les bons index en base (quitte à forcer leur régénération) car ils contribuent énormément aux performances