{"id":38965,"date":"2019-10-31T22:27:03","date_gmt":"2019-10-31T19:27:03","guid":{"rendered":"https:\/\/prohoster.info\/blog\/liveness-probes-v-kubernetes-mogut-byt-opasny\/"},"modified":"2019-10-31T22:27:03","modified_gmt":"2019-10-31T19:27:03","slug":"liveness-probes-v-kubernetes-mogut-byt-opasny","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/liveness-probes-v-kubernetes-mogut-byt-opasny","title":{"rendered":"Liveness probes i Kubernetes kan v\u00e6re farlige","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Bem. overs.<\/b>: Leading engineer from Zalando \u2014 Henning Jacobs \u2014 has repeatedly noticed issues among Kubernetes users regarding the understanding of the purpose of liveness (and readiness) probes and their correct application. Therefore, he has compiled his thoughts into this concise note, which will become part of the K8s documentation over time.<\/i><\/p>\n

\"Liveness
\n
\nHealth checks, known in Kubernetes as liveness probes<\/i> (i.e., literally, \u201cvitality tests\u201d \u2014 ed. note)<\/i>, can be quite dangerous. I recommend avoiding them whenever possible: exceptions are only cases where they are truly necessary and you fully understand the specifics and consequences of their use. This publication will discuss liveness and readiness checks, as well as situations in which st\u00e5r<\/i> and when not to apply them.<\/a><\/noindex><\/p>\n

Min kollega Sandor delte for nylig p\u00e5 Twitter de mest almindelige fejl, han st\u00f8der p\u00e5, herunder dem relateret til brugen af readiness\/liveness probes:<\/p>\n

\"Liveness<\/a><\/noindex><\/p>\n

A misconfigured livenessProbe<\/code> can aggravate situations with high load (avalanche shutdown + potentially long container\/application startup) and lead to other negative consequences such as crashing dependencies (see also my recent article<\/a><\/noindex> on rate limiting in conjunction with K3s+ACME)<\/i>. Endnu v\u00e6rre er det, n\u00e5r liveness probe kombineres med en afh\u00e6ngighedshelsecheck (health check), som er en ekstern database: a single database failure will restart all your containers<\/b>!<\/p>\n

The general message \u201cDo not use liveness probes\u201d<\/i> in this case helps little, so let\u2019s consider the purpose of readiness and liveness checks. <\/p>\n

Note: much of the test provided below was originally included in the internal documentation for Zalando developers.<\/i><\/p>\n

Readiness and Liveness Checks<\/h2>\n

\nKubernetes provides two important mechanisms called liveness probes and readiness probes<\/a><\/noindex>. They periodically perform some action \u2014 for example, send an HTTP request, open a TCP connection, or execute a command in the container \u2014 to confirm that the application is functioning properly.<\/p>\n

Kubernetes uses readiness probes<\/b>, for at forst\u00e5 hvorn\u00e5r en container er klar til at modtage trafik. En Pod anses for at v\u00e6re klar, hvis alle dens containere er klar. En af anvendelserne af denne mekanisme er at kontrollere, hvilke pods der bruges som backends for Kubernetes-tjenester (og is\u00e6r Ingress).<\/p>\n

Liveness probes<\/b> hj\u00e6lper Kubernetes med at forst\u00e5, hvorn\u00e5r det er tid til at genstarte en container. For eksempel g\u00f8r en s\u00e5dan kontrol det muligt at opfange deadlocks, n\u00e5r en applikation \"sidder fast\". Genstart af containeren i en s\u00e5dan tilstand hj\u00e6lper med at f\u00e5 applikationen i gang igen, p\u00e5 trods af fejl, men det kan ogs\u00e5 f\u00f8re til kaskadefejl (se nedenfor).<\/p>\n

Hvis du fors\u00f8ger at udrulle en opdatering af applikationen, der fejler liveness\/readiness-tjek, vil udrulningen stoppe, da Kubernetes venter p\u00e5 status Klar<\/code> af alle pods.<\/p>\n

Eksempel<\/h2>\n

\nHer er et eksempel p\u00e5 en readiness probe, der kontrollerer stien \/health<\/code> via HTTP med standardindstillinger (interval<\/i>: 10 sekunder, timeout<\/i>: 1 sekund, success threshold<\/i>: 1, failure threshold<\/i>: 3):<\/p>\n

# \u0447\u0430\u0441\u0442\u044c \u043e\u0431\u0449\u0435\u0433\u043e \u043e\u043f\u0438\u0441\u0430\u043d\u0438\u044f deployment'\u0430\/\u0441\u0442\u0435\u043a\u0430\npodTemplate:\n  spec:\n    containers:\n    - name: my-container\n      # ...\n      readinessProbe:\n        httpGet:\n          path: \/health\n          port: 8080<\/code><\/pre>\n
<\/p>\n
Anbefalinger<\/h2>\n
<\/p>\n
    \n
  1.  For mikrotjenester med HTTP-endpoint (REST osv.) skal du altid definere en readiness probe<\/b>, der kontrollerer, om applikationen (pod) er klar til at modtage trafik.<\/li>\n
  2.  S\u00f8rg for, at readiness probe d\u00e6kker klarheden af den faktiske webserverport<\/b>:\n