🥇Les sondes de vivacitat a Kubernetes poden ser perilloses

Nota. transl.: L'enginyer principal de Zalando, Henning Jacobs, ha detectat repetidament problemes entre els usuaris de Kubernetes per entendre el propòsit de les sondes de vivacitat (i disponibilitat) i el seu ús correcte. Per tant, va recollir els seus pensaments en aquesta àmplia nota, que finalment passarà a formar part de la documentació del K8s.

Comprovacions de salut, conegudes a Kubernetes com sondes de vivacitat (és a dir, literalment, "proves de viabilitat" - aprox. traducció), pot ser força perillós. Recomano evitar-los si és possible: les úniques excepcions són quan són realment necessaris i en coneixeu perfectament les especificitats i les conseqüències del seu ús. Aquesta publicació parlarà sobre els controls de vivacitat i preparació, i també us dirà en quins casos és i no els hauries d'utilitzar.

El meu company Sandor ha compartit recentment a Twitter els errors més habituals que troba, inclosos els relacionats amb l'ús de sondes de preparació/vivència:

Configurat incorrectament livenessProbe pot agreujar situacions d'alta càrrega (apagada de bola de neu + temps d'inici de contenidor/aplicació potencialment llarg) i comportar altres conseqüències negatives, com ara caigudes de dependència (Vegeu també el meu article recent sobre limitar el nombre de sol·licituds a la combinació K3s+ACME). És encara pitjor quan la sonda de vivacitat es combina amb un control de salut, que és una base de dades externa: una sola fallada de base de dades reiniciarà tots els contenidors!

Missatge general "No utilitzeu sondes de vivacitat" en aquest cas no ajuda gaire, així que mirem per a què serveixen les comprovacions de disponibilitat i vivacitat.

Nota: la majoria de la prova següent es va incloure originalment a la documentació interna del desenvolupador de Zalando.

Comprovacions de disponibilitat i vivacitat

Kubernetes proporciona dos mecanismes importants anomenats sondes de vivacitat i sondes de preparació. Realitzen periòdicament alguna acció, com ara enviar una sol·licitud HTTP, obrir una connexió TCP o executar una ordre al contenidor, per confirmar que l'aplicació funciona com s'esperava.

Usa Kubernetes sondes de preparacióper entendre quan el contenidor està preparat per acceptar trànsit. Una beina es considera a punt per al seu ús si tots els seus contenidors estan preparats. Un ús d'aquest mecanisme és controlar quins pods s'utilitzen com a backends per als serveis de Kubernetes (i especialment Ingress).

Sondes de vivacitat ajuda Kubernetes a entendre quan és el moment de reiniciar el contenidor. Per exemple, aquesta comprovació us permet interceptar un bloqueig quan una aplicació s'encalla en un lloc. Reiniciar el contenidor en aquest estat ajuda a posar en marxa l'aplicació malgrat els errors, però també pot provocar errors en cascada (vegeu més avall).

Si intenteu desplegar una actualització de l'aplicació que falla les comprovacions de disponibilitat/vivència, el seu llançament s'aturarà mentre Kubernetes espera l'estat. Ready de totes les beines.

Exemple

Aquí teniu un exemple d'una sonda de preparació que comprova un camí /health mitjançant HTTP amb la configuració predeterminada (interval: 10 segons, temps d'espera: 1 segon, llindar d'èxit: 1, llindar de fallada: 3):

# часть общего описания deployment'а/стека
podTemplate:
  spec:
    containers:
    - name: my-container
      # ...
      readinessProbe:
        httpGet:
          path: /health
          port: 8080

Recomanacions

Per a microserveis amb punt final HTTP (REST, etc.) Definiu sempre una sonda de preparació, que comprova si l'aplicació (pod) està preparada per acceptar trànsit.
Assegureu-vos que la sonda de preparació cobreix la disponibilitat del port del servidor web real:
- utilitzar ports per a finalitats administratives, anomenats "administrador" o "gestió" (per exemple, 9090), per readinessProbe, assegureu-vos que el punt final només retorna OK si el port HTTP principal (com el 8080) està preparat per acceptar trànsit*;
  *Conec almenys un cas a Zalando on això no va passar, és a dir. readinessProbe Vaig comprovar el port de "gestió", però el servidor en si no va començar a funcionar a causa de problemes per carregar la memòria cau.
- connectar una sonda de preparació a un port independent pot provocar que la sobrecàrrega del port principal no es reflecteixi a la comprovació de salut (és a dir, el grup de fils del servidor està ple, però la comprovació de salut encara mostra que tot està bé). ).
Assegureu-vos que La sonda de preparació permet la inicialització/migració de la base de dades;
- La manera més senzilla d'aconseguir-ho és contactar amb el servidor HTTP només després de completar la inicialització (per exemple, migrar una base de dades des de Flyway etcètera.); és a dir, en comptes de canviar l'estat de la comprovació de salut, simplement no engegueu el servidor web fins que s'hagi completat la migració de la base de dades*.
  * També podeu executar migracions de bases de dades des de contenidors init fora del pod. Encara sóc un fan de les aplicacions autònomes, és a dir, aquelles en què el contenidor de l'aplicació sap portar la base de dades a l'estat desitjat sense coordinació externa.
ús httpGet per a comprovacions de preparació mitjançant els punts finals de control de salut típics (per exemple, /health).
Entendre els paràmetres de comprovació per defecte (interval: 10s, timeout: 1s, successThreshold: 1, failureThreshold: 3):
- les opcions predeterminades signifiquen que el pod esdevindrà no està llest després d'uns 30 segons (3 comprovacions de cordura fallides).
Utilitzeu un port independent per a "administrador" o "gestió" si la pila de tecnologia (p. ex., Java/Spring) ho permet, per separar la gestió de la salut i les mètriques del trànsit normal:
- però no us oblideu del punt 2.
Si cal, la sonda de preparació es pot utilitzar per escalfar/carregar la memòria cau i retornar un codi d'estat 503 fins que el contenidor s'escalfi:
- També us recomano que llegiu el nou xec startupProbe, va aparèixer a la versió 1.16 (Vam escriure sobre això en rus aquí -aprox. trad.).

Cova

No confieu en dependències externes (com ara magatzems de dades) quan s'executen proves de disponibilitat/vivència, això pot provocar errors en cascada:
- Com a exemple, prenguem un servei REST amb estat amb 10 pods depenent d'una base de dades de Postgres: quan la comprovació depèn d'una connexió que funcioni a la base de dades, els 10 pods poden fallar si hi ha un retard al costat de la xarxa/de la base de dades; tot acaba pitjor del que podria;
- Tingueu en compte que Spring Data comprova la connexió de la base de dades per defecte*;
  * Aquest és el comportament predeterminat de Spring Data Redis (almenys va ser l'última vegada que vaig comprovar), que va provocar un error "catastròfic": quan Redis no va estar disponible durant un temps, tots els pods "es van estavellar".
- "extern" en aquest sentit també pot significar altres pods de la mateixa aplicació, és a dir, idealment la comprovació no hauria de dependre de l'estat d'altres pods del mateix clúster per evitar fallades en cascada:
  - els resultats poden variar per a aplicacions amb estat distribuït (per exemple, la memòria cau en pods).
No utilitzeu una sonda de vivacitat per a les beines (excepcions són casos en què són realment necessaris i coneixeu perfectament les especificitats i les conseqüències del seu ús):
- Una sonda de vivacitat pot ajudar a recuperar contenidors penjats, però com que teniu el control total de la vostra aplicació, l'ideal no haurien de passar coses com els processos penjats i els bloquejos: la millor alternativa és bloquejar l'aplicació deliberadament i tornar-la a l'estat estacionari anterior;
- una sonda d'activació fallida farà que el contenidor es reiniciï, la qual cosa pot agreujar les conseqüències dels errors relacionats amb la càrrega: reiniciar el contenidor provocarà un temps d'inactivitat (almenys durant la durada de l'inici de l'aplicació, per exemple 30 segons), causant nous errors. , augmentant la càrrega d'altres contenidors i augmentant la probabilitat del seu fracàs, etc.;
- Les comprovacions de vivacitat combinades amb una dependència externa són la pitjor combinació possible, amenaçant errors en cascada: un lleuger retard a la base de dades comportarà un reinici de tots els contenidors!
Paràmetres de comprovació de vivacitat i preparació ha de ser diferent:
- podeu utilitzar una sonda de vivacitat amb la mateixa comprovació de salut, però un llindar de resposta més alt (failureThreshold), per exemple, assignar l'estat no està llest després de 3 intents i considerar que la sonda de vivacitat ha fallat després de 10 intents;
No utilitzeu controls executius, ja que estan associats a problemes coneguts que donen lloc a l'aparició de processos zombis:
- detalls: veure presentació a càrrec dels especialistes de Datadog.

Resum

Utilitzeu sondes de preparació per determinar quan un pod està preparat per rebre trànsit.
Utilitzeu sondes de vivacitat només quan siguin realment necessàries.
L'ús inadequat de les sondes de disponibilitat/vivència pot provocar una disponibilitat reduïda i fallades en cascada.

Material addicional sobre el tema

Documents de Kubernetes: Configurar les sondes de Liveness i Readiness;
Sondes de vivacitat i preparació de Kubernetes revisades: com evitar disparar-se a l'altre peu;
Apagada dels laboratoris de NRE post-mortem (també parla de livenessProbe).

Actualització núm. 1 del 2019-09-29

Sobre els contenidors init per a la migració de bases de dades: S'ha afegit una nota al peu.

Em va recordar EJ sobre PDB: un dels problemes amb els controls de vivacitat és la falta de coordinació entre les beines. Kubernetes té Pressupostos d'interrupció de pods (PDB) per limitar el nombre d'errors concurrents que pot experimentar una aplicació, però les comprovacions no tenen en compte el PDB. Idealment, podríem dir als K8 que "Reinicieu un pod si la seva prova falla, però no els reinicieu tots per evitar que les coses empitjorin".

Bryan ho va dir perfectament: "Feu servir la prova de vivacitat quan sàpigues exactament què el millor és matar l'aplicació"(de nou, no us deixeu portar).

Actualització núm. 2 del 2019-09-29

Respecte a la lectura de la documentació abans de l'ús: he creat la sol·licitud corresponent (sol·licitud de funció) per afegir documentació sobre sondes de vivacitat.

PS del traductor

Llegeix també al nostre blog:

Font: www.habr.com

Les sondes de vivacitat a Kubernetes poden ser perilloses