🥇As sondas de animación en Kubernetes poden ser perigosas

Nota. transl.: O enxeñeiro xefe de Zalando, Henning Jacobs, observou repetidamente problemas entre os usuarios de Kubernetes para comprender o propósito das sondas de vivacidade (e preparación) e o seu uso correcto. Polo tanto, recolleu os seus pensamentos nesta ampla nota, que finalmente pasará a formar parte da documentación do K8s.

Comprobacións de saúde, coñecidas en Kubernetes como sondas de vivacidade (é dicir, literalmente, "probas de viabilidade" - trad. aprox.), pode ser bastante perigoso. Recomendo evitalos se é posible: as únicas excepcións son cando son verdadeiramente necesarios e se coñece perfectamente as particularidades e as consecuencias do seu uso. Nesta publicación falarase dos controis de vida e preparación, e tamén che dirá en que casos Custo e non deberías usalos.

O meu compañeiro Sandor compartiu recentemente en Twitter os erros máis comúns que atopa, incluídos os relacionados co uso de sondas de preparación/vivencia:

Configurado incorrectamente livenessProbe pode agravar as situacións de alta carga (apagada por bola de neve + tempo de inicio do contedor/aplicación potencialmente longo) e levar a outras consecuencias negativas, como caídas de dependencia. (Ver tamén meu artigo recente sobre a limitación do número de solicitudes na combinación K3s+ACME). É aínda peor cando a sonda de vitalidade se combina cunha comprobación de saúde, que é unha base de datos externa: un único fallo de base de datos reiniciará todos os seus contedores!

Mensaxe xeral "Non uses sondas de vivacidade" neste caso non axuda moito, así que vexamos para que serven as comprobacións de preparación e vivacidade.

Nota: a maior parte da proba que aparece a continuación incluíuse orixinalmente na documentación interna do programador de Zalando.

Comprobacións de preparación e vivacidade

Kubernetes ofrece dous mecanismos importantes chamados sondas de vivacidade e sondas de preparación. Periódicamente realizan algunha acción, como enviar unha solicitude HTTP, abrir unha conexión TCP ou executar un comando no contedor, para confirmar que a aplicación funciona como se esperaba.

Utiliza Kubernetes sondas de preparaciónpara comprender cando o contedor está preparado para aceptar tráfico. Unha vaina considérase lista para o seu uso se todos os seus recipientes están listos. Un uso deste mecanismo é controlar que pods se usan como backends para os servizos de Kubernetes (e especialmente Ingress).

Sondas de vivacidade axuda a Kubernetes a comprender cando é o momento de reiniciar o contedor. Por exemplo, tal comprobación permítelle interceptar un punto morto cando unha aplicación queda atascada nun lugar. Reiniciar o contedor neste estado axuda a poñer en marcha a aplicación a pesar dos erros, pero tamén pode provocar fallos en cascada (ver a continuación).

Se tentas implementar unha actualización da aplicación que non supera as comprobacións de estado/preparación, a súa posta en marcha paralizarase mentres Kubernetes agarda polo estado. Ready de todas as vainas.

Exemplo

Aquí tes un exemplo dunha sonda de preparación que comproba un camiño /health vía HTTP con configuración predeterminada (intervalo: 10 segundos, tempo de espera: 1 segundo, umbral de éxito: 1, limiar de falla: 3):

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

Recomendacións

Para microservizos con punto final HTTP (REST, etc.) definir sempre unha sonda de preparación, que verifica se a aplicación (pod) está lista para aceptar tráfico.
Asegúrese de que a sonda de preparación cobre a dispoñibilidade do porto do servidor web real:
- usando portos para fins administrativos, chamados "administrador" ou "xestor" (por exemplo, 9090), para readinessProbe, asegúrate de que o punto final só devolve OK se o porto HTTP principal (como 8080) está preparado para aceptar tráfico*;
  *Coñezo polo menos un caso en Zalando no que isto non ocorreu, é dicir. readinessProbe Comprobei o porto de "xestión", pero o propio servidor non comezou a funcionar debido a problemas ao cargar a caché.
- conectar unha sonda de preparación a un porto separado pode provocar que a sobrecarga do porto principal non se reflicta na comprobación de estado (é dicir, o grupo de fíos do servidor está cheo, pero a comprobación de saúde aínda mostra que todo está ben? ).
Asegúrese de que a sonda de preparación permite a inicialización/migración da base de datos;
- O xeito máis sinxelo de conseguir isto é contactar co servidor HTTP só despois de que se complete a inicialización (por exemplo, migrando unha base de datos desde Pasaxea etcétera.); é dicir, en lugar de cambiar o estado da comprobación de saúde, simplemente non inicie o servidor web ata que se complete a migración da base de datos*.
  * Tamén pode executar migracións de bases de datos desde contedores de inicio fóra do pod. Aínda son un fan das aplicacións autónomas, é dicir, aquelas nas que o contedor da aplicación sabe como levar a base de datos ao estado desexado sen coordinación externa.
Usar httpGet para comprobacións de preparación a través de puntos finais de control de saúde típicos (por exemplo, /health).
Comprender os parámetros de verificación predeterminados (interval: 10s, timeout: 1s, successThreshold: 1, failureThreshold: 3):
- as opcións predeterminadas significan que o pod se converterá non listo despois duns 30 segundos (3 comprobacións de cordura fallidas).
Use un porto separado para "administrador" ou "xestión" se a pila de tecnoloxía (por exemplo, Java/Spring) o permite, para separar a xestión da saúde e das métricas do tráfico normal:
- pero non te esquezas do punto 2.
Se é necesario, a sonda de preparación pódese usar para quentar/cargar a caché e devolver un código de estado 503 ata que o contedor se quente:
- Tamén recomendo que leas o novo cheque startupProbe, apareceu na versión 1.16 (escribimos sobre iso en ruso aquí - aprox. transl.).

Adormeces

Non confíe en dependencias externas (como almacéns de datos) ao executar probas de preparación/vivencia, isto pode provocar fallos en cascada:
- Como exemplo, tomemos un servizo REST con estado con 10 pods dependendo dunha base de datos de Postgres: cando a comprobación depende dunha conexión que funcione á base de datos, os 10 pods poden fallar se hai un atraso no lado da rede ou da base de datos. todo acaba peor do que podería;
- Teña en conta que Spring Data comproba a conexión da base de datos por defecto*;
  * Este é o comportamento predeterminado de Spring Data Redis (polo menos foi a última vez que comprobei), o que provocou un fallo "catastrófico": cando Redis non estivo dispoñible brevemente, todas as vainas "fallaron".
- “externo” neste sentido tamén pode significar outros pods da mesma aplicación, é dicir, o ideal é que a comprobación non dependa do estado doutros pods do mesmo clúster para evitar fallos en cascada:
  - os resultados poden variar para aplicacións con estado distribuído (por exemplo, almacenamento na memoria caché en pods).
Non use unha sonda de vivacidade para as vainas (as excepcións son os casos en que son realmente necesarios e estás plenamente consciente das particularidades e das consecuencias do seu uso):
- Unha sonda de vitalidade pode axudar a recuperar os contedores colgados, pero como tes o control total sobre a túa aplicación, o ideal é que non se produzan cousas como procesos colgados e bloqueos: a mellor alternativa é bloquear a aplicación deliberadamente e devolvela ao estado estacionario anterior;
- un fallo da proba de activación fará que o contedor se reinicie, polo que pode agravar as consecuencias dos erros relacionados coa carga: o reinicio do contedor provocará un tempo de inactividade (polo menos durante o inicio da aplicación, digamos 30 segundos impares), causando novos erros. , aumentando a carga doutros colectores e aumentando a probabilidade de que se produzan fallas, etc.;
- As comprobacións de vitalidade combinadas cunha dependencia externa son a peor combinación posible, ameazando con fallos en cascada: un lixeiro atraso no lado da base de datos levará a un reinicio de todos os seus contedores.
Parámetros de comprobacións de vivacidade e preparación debe ser diferente:
- pode usar unha sonda de vivacidade coa mesma comprobación de saúde, pero cun limiar de resposta máis alto (failureThreshold), por exemplo, asignar o estado non listo despois de 3 intentos e considerar que a sonda de vivacidade fallou despois de 10 intentos;
Non use comprobacións executivas, xa que están asociados a problemas coñecidos que levan á aparición de procesos zombies:
- detalles: ver presentación a cargo de especialistas de Datadog.

Resumo

Use sondas de preparación para determinar cando un pod está listo para recibir tráfico.
Use sondas de vivacidade só cando sexan realmente necesarias.
O uso inadecuado das sondas de preparación/vivencia pode provocar unha redución da dispoñibilidade e fallos en cascada.

Materiais adicionais sobre o tema

Documentos de Kubernetes: Configurar probas de Liveness e Readiness;
Revisión das probas de vivacidade e preparación de Kubernetes: como evitar dispararse no outro pé;
NRE Labs Outage Post-Mortem (tamén fala de livenessProbe).

Actualización no 1 do 2019-09-29

Acerca dos contedores init para a migración de bases de datos: Engadida unha nota ao pé.

lembroume EJ sobre PDB: un dos problemas cos controles de vivacidade é a falta de coordinación entre as vainas. Kubernetes ten Orzamentos de interrupción de pod (PDB) para limitar o número de fallos simultáneos que pode experimentar unha aplicación, pero as comprobacións non teñen en conta a PDB. O ideal sería dicirlle aos K8 que "Reinicie un pod se a súa proba falla, pero non os reinicie todos para evitar empeorar as cousas".

Bryan expúxoo perfectamente: "Usa a proba de vivacidade cando sabes exactamente o que o mellor que podes facer é matar a aplicación"(de novo, non te deixes levar).

Actualización no 2 do 2019-09-29

Respecto á lectura da documentación antes do uso: creei a solicitude correspondente (solicitude de función) para engadir documentación sobre as sondas de vivacidade.

PS do tradutor

Lea tamén no noso blog:

Fonte: www.habr.com

As sondas de animación en Kubernetes poden ser perigosas