Kubernetes, a próbkowanie liveness, readiness i startup

W Kubernetesie są trzy rodzaje próbkowania: liveness (czy żyjesz? Jak nie to restart według ustalonej polityki restartPolicy), readiness (czy jesteś gotowy na obsługę ruchu? Jak nie to nie będę do ciebie kierować ruchu) i startup (czy wystartowałeś), które mają swoje konfigurowalne parametry. Takie próbkowanie można zrealizować na trzy sposoby: przez zapytanie HTTP, sprawdzenie połączenia TCP lub uruchomienie odpowiednio zdefiniowanej komendy wewnątrz kontenera.

• https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#container-probes.

Chciałem was zapytać jak rozróżniać i czy rozróżniać *liveness *i *readiness *dla serwisów, które komunikują się tylko i wyłącznie przy pomocy kolejek? Załóżmy, że taki serwis ma dwie repliki i wystawia endpoint /health po HTTP i będziemy go odpytywać w ramach próbkowania. Czy dla takiego serwisu, gdzie obsługiwany ruch nie jest rozdzielany przez LB (a dalej chcemy robić rolling deployment), jest jakiś powód aby rozróżniać liveness od readiness? Czy jest sens definiować wtedy jednocześnie i liveness i readiness, jeśli niezdefiniowane domyślnie przyjmują wartość Success? Dla readiness preferowalibyście sprawdzenia typu smart (zanim uznam cię za gotowego na obsługę ruchu to sprawdzę czy masz połączenie z kolejką lub z innymi zależnościami) czy typu dumb (sprawdzę tylko czy jako aplikacja odpowiadasz, czyli w sumie zrobię to samo co przy sprawdzeniu liveness)?

Jeśli odpowiedź: "to zależy", to od czego?

• https://andrewlock.net/deploying-asp-net-core-applications-to-kubernetes-part-6-adding-health-checks-with-liveness-readiness-and-startup-probes/.

Podobnie dla serwisów, które wystawiają API tylko HTTP? Sprawdzacie przed ogłoszeniem, że jesteście gotowi na obsługę ruchu poprzez sprawdzenie połączenie do bazy danych albo tego czy możecie nawiązać połączenie z innym serwisem, z którym gadacie?

Jak konfigurujecie te próbki w waszych serwisach, które rozwijacie?

świetne pytanie :)
jeśli dla Ciebie ready == alive, to możesz mieć jeden endpoint i oba probe tam kierować.
Ogólnie, jest to rozdzielane dlatego, że czasami niektóre programy potrzebują trochę czasu na rozkręcenie się. Np w jednym z projektów ML readiness był ustawiona na parę minut tak, aby można było załadować wszystkie modele (ściągane były z s3 + ładowane do pamięci). Jednak liveness już miał tak jak wszystkie inne serwisy.

Dla mnie readiness jest wtedy, gdy aplikacja jest gotowa wykonywać swoją pracę, czyli w Twoim przypadku - proces wstał i ma połączenie do kolejki i bazy danych. Tylko jak dostanie już połączenie do kolejki, to po prostu zacznie konsumować, gdyż nie ma, tak jak sam wspomniałeś, żadnego mechanizmu, który by robił balancing tych eventów. Podsumowując, w tym przypadku dla mnie readiness==liveness.

Jeśli chodzi o server HTTP, to sprawa wygląda bardzo podobnie, z tym że mamy load balancer, który potrzebuje wiedzieć kiedy zacząć przekierowywać ruch. Jeśli nie ma tam jakichś większych cudów, to też możesz założyć, że readiness == liveness. W tym wypadku też sprawdzam, czy rzeczywiście połączenie do bazy danych jest aktywne.