( arpad | 2021. 04. 21., sze – 17:11 )

Ha nem tévedek a readinessProbe-ot csak addig használja amíg sikeresen el nem indul a pod, onnantól kezdve már csak a livenessProbe játszik. De mivel általában ugyanaz a kettő csak az időzítésekben és retry logikában tér el, így lehet hogy ezt rosszul tudom.

A VPA-t én kerülöm. Nálunk csak javaslatot tehet, de magát a pod-ot nem rúghatja újra. Főleg hogy elég hosszú ideig csak mér és aztán akkor csap le amikor nem várod. A javaslatokat a fejlesztő csapatok havonta, két havonta átfutják és reszelnek a resource igényeken ha kell. Ha megoldható érdemesebb horizontálisan skálázódni HPA-val, de abban is vannak vicces dolgok. Amikor a metrics-server megdöglött a HPA kérése hibára futott, de ezzel nem törődött és úgy számolta hogy minden pod 0% CPU-n pörög, szóval lehet lejjebb menni...

Nem írtad hogy NodePort vagy AWS VPC CNI és direkt pod címzés - az EKS miatt ez utóbbira gondolok - de mindkét esetben az ALB-ben meg kell adnod egy külön healthcheck eljárást. Az ALB nem tudja hogy ki/mi van mögötte az instance-on, ő csak azt tudja hogy itt van az instance - abból meg van az IP cím - és ezen a path-on tudja ellenőrizni hogy él-e még a szerviz. Ha csak unhealthy target van akkor - ha jól emlékszem - mindegyikre eldobja a kérést, rosszabb már nem lehet alapon. Emiatt találtunk olyan TargetGroup-okat amikben soha nem volt egyetlen egy healthy instance sem, mert a fejlesztő elírta a health check path-t.