Kubernetes probes: Jak na health check aplikace
Při provozu aplikací v Kubernetes se neobejdete bez automatizovaného sledování stavu podů. To výchozí však nemusí stačit, protože neověřuje připravenost kontejnerů uvnitř podu, a ty pak vracejí chybu. V tomto návodu si ukážeme jak a proč se takové situaci vyhnout pomocí Kubernetes probes.
Co jsou Kubernetes probes
Kubernetes probes jsou techniky umožňující zjišťovat stav a připravenost aplikací na úrovni jednotlivých kontejnerů. Díky tomu poskytují lepší kontrolu než výchozí režim kontroly Kubernetes, který probíhá například prostřednictvím Deployment, DaemonSet nebo StatefulSet. Tyto kontroléry totiž sledují životní cyklus pouze na úrovni podů. V okamžiku, kdy se uvnitř podu zprovozní všechny kontejnery, považuje Kubernetes pod za připravený a začne mu posílat provoz.
Zprovoznění kontejneru ale automaticky neznamená jeho připravenost na příjem provozu. Nepřipravená aplikace pak vrátí odpověď „500 error“. Kubernetes probes prostřednictvím kubelet (agent běžící na každém nodu) stav kontejnerů prověří a pokud jej identifikuje jako nepřipravený, dojde k jeho restartu.
Typy probes a použití
V Kubernetes existují tři různé „probes“, které lze využít k diagnostice stavu kontejnerů: liveness probe, readiness probe a startup probe.
Liveness probe
Pomocí liveness probe se identifikuje stav kontejneru běžícího v podu. Pokud je liveness probe úspěšný, znamená to, že je aplikace v provozu. Při neúspěšném pokusu dojde k restartování kontejneru v souladu s pravidly, která jsou nastavena na úrovni podu.
Vhodné použití:
- odhalení aplikačních chyb a neočekávaných pádů aplikace;
- identifikace zablokovaného vlákna v aplikaci;
- identifikace vlákna ve smyčce.
Readiness probe
Readiness probe umožňuje prověřit, jestli je aplikace běžící v kontejneru připravena přijímat požadavky. Pokud ano, mohou do kontejneru odpovídající služby směrovat provoz. Jestliže readiness probe selže, je provoz odkloněn. Odklon provozu trvá až do chvíle, kdy je readiness kontrola úspěšná.
Vhodné použití:
- kontrola procesu spuštění aplikace;
- zajištění postupného spouštění aplikace.
Startup probe
Startup probe prověřuje, zda došlo ke správnému zprovoznění aplikace v kontejneru. Pokud je tato kontrola nakonfigurována, spouští se ještě před liveness a readiness probe. Stejně jako v ostatních případech, pokud je startup probe neúspěšný, dojde k restartování kontejneru v souladu s pravidly nastavenými na úrovni podu. Hlavním cílem startup probe je zajistit, aby nedošlo k restartování kontejneru ještě před tím, že se vůbec spustí.
Vhodné použití:
- korektní spuštění při delší době inicializace;
- oddělení procesu inicializace od běžného provozu.
Mechanismy pro spuštění probes
Součástí každého nodu v Kubernetes je kubelet. Kubelet pravidelně provádí diagnostiku a správu jednotlivých kontejnerů. Jsou-li v Kubernetes nakonfigurovány probes, zodpovídá též za jejich spuštění a vyhodnocení výsledné odpovědi.
K použití probes je nezbytné implementovat jeden z následujících mechanismů. Volba nejvhodnějšího závisí na konkrétní aplikaci nebo požadavcích na monitoring.
ExecAction
Provádí příkaz v kontejneru a určuje, zda byl výsledek dané kontroly úspěšný nebo ne. Je vhodný například ke kontrole vlastním voláním aplikace a pro kontroly návratových hodnot nebo obsahu. Vyžaduje však dobrou znalost vnitřního prostředí kontejneru.
Příklad:
livenessProbe:
exec:
command:
- cat
- /tmp/healthy
initialDelaySeconds: 5
periodSeconds: 5TCPSocketAction
Navazuje TCP spojení s IP adresou konkrétního portu kontejneru. Úspěšné navázání spojení znamená též úspěšnost kontroly. TCPSocket umožňuje rychle zjistit dostupnost konkrétního portu. Na rozdíl od HTTPGet není závislý na obsahu odpovědi.
Příklad:
readinessProbe:
tcpSocket:
port: 8080
initialDelaySeconds: 3
periodSeconds: 5HTTPGetAction
Provádí požadavek HTTP GET na určitou URL dostupnost v rámci kontejneru. O úspěšnosti kontroly vypovídá stavový kód odpovědi – pohybuje-li se v rozmezí 200–399 jedná se o úspěšnou kontrolu. Nejčastěji jej využívají webové aplikace a obecně aplikace, které mají definované stavové endpointy. Tento mechanismus umožňuje nastavit pro kontrolu i další parametry a lépe ji přizpůsobit určitému použití.
Příklad:
livenessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 3
periodSeconds: 3gRPC Handler
gRPC (gRPC Remote Procedure Calls) je moderní rámec pro vzdálené volání vyvinutý Googlem. Pro kontrolu stavu se definuje v aplikaci gRPC server, který naslouchá na specifickém portu. Protože používá protokol HTTP/2 a je jazykově nezávislý, hodí se pro rozmanité případy použití. Vhodný je zejména pro aplikace vyžadující vysokou propustnost a nízkou latenci.
Příklad:
livenessProbe:
exec:
command:
- grpc-health-probe
initialDelaySeconds: 3
periodSeconds: 5Příprava na health check
Než se pustíte do úpravy konfiguračního souboru pro spuštění probes, je potřeba ověřit pár klíčových aspektů. Dobře prověřte:
- že máte aktivní kubectl (příkazová řádka);
- nastavení endpointů, které se budou kontrolovat;
- konfiguraci portů kontejneru;
- přístup kubelet k probes;
- nastavení oprávnění a přístupů na úrovni konfiguračního souboru probes;
- funkčnost kontrol při různých scénářích.
Spuštění probes prakticky
Pro spuštění kontrol je nutné upravit konfigurační soubor podu nebo deployment. Následující příklady pracují se skladbou YAML pro deployment, který obsahuje všechny tři způsoby kontroly (liveness, readiness, startup) a využívá mechanismus HTTPGetAction. Aplikace běží na portu 8080 a poskytuje endpointy na /healthz, /ready a /startup.
Deployment probes
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
spec:
replicas: 3
selector:
matchLabels:
app: my-app
template:
metadata:
labels:
app: my-app
spec:
containers:
- name: my-app-container
image: my-app-image:latest
ports:
- containerPort: 8080
livenessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 3
periodSeconds: 5
readinessProbe:
httpGet:
path: /ready
port: 8080
initialDelaySeconds: 10
periodSeconds: 5
startupProbe:
httpGet:
path: /startup
port: 8080
initialDelaySeconds: 15
periodSeconds: 10Výše uvedený příklad můžete využít pro vlastní konfiguraci. Vždy se ale ujistěte že cesty a porty kontrol odpovídají skutečným endpointům vaší aplikace.
Po dokončení úprav použijte kubectl pro vytvoření nebo aktualizaci deploymentu:
kubectl apply -f nazev-souboru.yamlNásledně bude Kubernetes automaticky používat liveness, readiness a startup probe pro monitorování stavu aplikace.
Best practices pro health check
- Zvolte vhodnou dobu pro spouštění jednotlivých kontrol
initialDelaySecondsi jejich periodicituperiodSeconds. Příliš časté spouštění kontrol může negativně ovlivnit výkon aplikace. - Jednotlivé mechanismy HTTPGetAction, ExecAction, TCPSocket a gRPC můžete kombinovat podle typu služeb a operací.
- Při použití probes ve veřejné síti nezapomeňte komunikaci zabezpečit pomocí šifrování a autentizačních mechanismů; u clusterů je potřeba šifrovat i komunikaci mezi jednotlivými nody.
- Nastavte pravidla pro restartování na úrovni podu. Pokud má dojít k restartu po neúspěchu kontroly, musí být pravilo kontejneru nastaveno na
restartPolicy: AlwaysneborestartPolicy: OnFailure. - U kontejnerů s nízkou prioritou není nutné nastavovat probes.
- Pravidelně a zejména po optimalizaci nebo aktualizaci zkontrolujte funkčnost probes. Některé změny mohou ovlivnit jejich výkon.
- Výsledky kontrol monitorujte a sbírejte logy. Jejich sledování vám umožní rychle reagovat na případné problémy.