Un cluster EKS est livré avec un Deployment pour core dns avec 2 replicas
ça suffit pour commencer, mais avec beaucoup de pods qui tournent on a commencé à avoir des erreurs DNS
On a passé le replicas à 5 et tout va mieux, plus d'erreurs
Tips :
start with low request and high limits
observe..
increase request to request what needed in normal processing
lower limits to... what your strategy is. It can be 10% more than request for example or the same than request if you want to be safe
Pas toujours simple de s'y retrouver :
https://github.com/coreos/prometheus-operator
https://github.com/coreos/prometheus-operator/tree/master/contrib/kube-prometheus
La différence entre ces deux là est expliqué dans le README : https://github.com/coreos/prometheus-operator#prometheus-operator-vs-kube-prometheus
Ce qu'il faut retenir, c'est que si l'on veut une solution end-to-end de monitoring de son cluster, il faut utiliser kube-prometheus qui installe le prometheus operator et plein d'autres choses. D'après le Readme de kube prometheus, le projet s'utilise comme une lib qui permet de générer des manifests yaml qu'on va ensuite apply.
Le projet a aussi été packagé avec helm. Si on veut custom les manifests, ça a l'air plus facile à utiliser que le jsonnet de kube prometheus :
https://github.com/helm/charts/tree/master/stable/prometheus-operator
Une alternative à kube2iam qui est apparemment plus secure
un projet similaire à kubetail
à voir ce que ça donne comparé à k9s
Si on a créé un Deployment avec un apply -f en spécifiant le champs replicas et qu'on décide d'enlever ce champs (pour ne plus qu'il soit géré de manière statique mais plutot dynamique avec un HPA par exemple)
Il faut faire attention car le comportement par défaut va définir replicas à 1
Pour éviter ça, avant de apply le Deployment sans le champs replicas, il faut faire un :
kubectl apply edit-last-applied deployment my-deployment
Et supprimer le champs replicas
Pour que ça marche bien il faut que ses CPU requests soient cohérents
Lorsque le HPA (horizontal pod autoscaler) démarre trop de pods, ces pods vont être en pending. Il faut plus de nodes pour les faire tourner.
C'est le but du kubernetes autoscaler qui va reconfigurer l'autoscaling group des nodes pour en ajouter/enlever suivant l'usage
https://eksworkshop.com/scaling/deploy_ca/
Le pod qui fait tourner ça doit avoir les bon droits IAM pour pouvoir modifier l'ASG
voir : https://blog.csanchez.org/2018/11/14/installing-kube2iam-in-aws-kubernetes-eks-cluster/