🥇As sondagens de atividade no Kubernetes podem ser perigosas

Observação. trad.: O engenheiro-chefe da Zalando, Henning Jacobs, notou repetidamente problemas entre os usuários do Kubernetes na compreensão do propósito dos testes de atividade (e prontidão) e seu uso correto. Portanto, ele reuniu seus pensamentos nesta nota ampla, que eventualmente se tornará parte da documentação do K8s.

Verificações de integridade, conhecidas no Kubernetes como sondas de vivacidade (ou seja, literalmente, “testes de viabilidade” - tradução aproximada), pode ser bastante perigoso. Recomendo evitá-los se possível: as únicas exceções são quando são realmente necessários e você tem plena consciência das especificidades e consequências do seu uso. Esta publicação falará sobre verificações de atividade e prontidão e também informará em quais casos é e você não deve usá-los.

Meu colega Sandor compartilhou recentemente no Twitter os erros mais comuns que ele encontra, incluindo aqueles relacionados ao uso de testes de prontidão/vivacidade:

Configurado incorretamente livenessProbe pode agravar situações de alta carga (desligamento em bola de neve + tempo potencialmente longo de inicialização de contêiner/aplicativo) e levar a outras consequências negativas, como quedas de dependência (Veja também meu artigo recente sobre a limitação do número de solicitações na combinação K3s+ACME). É ainda pior quando a investigação de atividade é combinada com uma verificação de integridade, que é um banco de dados externo: uma única falha no banco de dados reiniciará todos os seus contêineres!

Mensagem geral "Não use sondas de vivacidade" neste caso, não ajuda muito, então vamos ver para que servem as verificações de prontidão e vivacidade.

Nota: A maior parte do teste abaixo foi originalmente incluída na documentação interna do desenvolvedor do Zalando.

Verificações de prontidão e atividade

Kubernetes fornece dois mecanismos importantes chamados sondas de vivacidade e sondagens de prontidão. Eles realizam alguma ação periodicamente – como enviar uma solicitação HTTP, abrir uma conexão TCP ou executar um comando no contêiner – para confirmar se o aplicativo está funcionando conforme o esperado.

Usos do Kubernetes sondas de prontidãopara entender quando o contêiner está pronto para aceitar tráfego. Um pod é considerado pronto para uso se todos os seus contêineres estiverem prontos. Um uso desse mecanismo é controlar quais pods são usados como back-ends para serviços Kubernetes (e especialmente Ingress).

Sondas de vivacidade ajude o Kubernetes a entender quando é hora de reiniciar o contêiner. Por exemplo, essa verificação permite interceptar um impasse quando um aplicativo fica preso em um local. Reiniciar o contêiner nesse estado ajuda a fazer o aplicativo decolar apesar dos erros, mas também pode levar a falhas em cascata (veja abaixo).

Se você tentar implantar uma atualização de aplicativo que falhe nas verificações de atividade/prontidão, sua implementação será interrompida enquanto o Kubernetes aguarda o status Ready de todos os pods.

Exemplo

Aqui está um exemplo de uma sonda de prontidão verificando um caminho /health via HTTP com configurações padrão (intervalo: 10 segundos, tempo limite: 1 segundo, limite de sucesso: 1, limite de falha: 3):

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

Recomendações

Para microsserviços com endpoint HTTP (REST, etc.) sempre defina uma sonda de prontidão, que verifica se o aplicativo (pod) está pronto para aceitar tráfego.
Certifique-se de que a sonda de prontidão cobre a disponibilidade da porta real do servidor web:
- usando portas para fins administrativos, chamadas "admin" ou "management" (por exemplo, 9090), para readinessProbe, certifique-se de que o endpoint só retorne OK se a porta HTTP primária (como 8080) estiver pronta para aceitar tráfego*;
  *Tenho conhecimento de pelo menos um caso em Zalando onde isso não aconteceu, ou seja, readinessProbe Verifiquei a porta “gerenciamento”, mas o próprio servidor não começou a funcionar devido a problemas ao carregar o cache.
- anexar uma sonda de prontidão a uma porta separada pode fazer com que a sobrecarga na porta principal não seja refletida na verificação de integridade (ou seja, o conjunto de threads no servidor está cheio, mas a verificação de integridade ainda mostra que está tudo bem ).
Certifique-se de que A sonda de prontidão permite a inicialização/migração do banco de dados;
- A maneira mais fácil de conseguir isso é entrar em contato com o servidor HTTP somente após a conclusão da inicialização (por exemplo, migrando um banco de dados do pista de pouso e assim por diante.); isto é, em vez de alterar o status da verificação de integridade, simplesmente não inicie o servidor web até que a migração do banco de dados seja concluída*.
  * Você também pode executar migrações de banco de dados de contêineres de inicialização fora do pod. Ainda sou fã de aplicações autocontidas, ou seja, aquelas em que o contêiner da aplicação sabe como levar o banco de dados ao estado desejado sem coordenação externa.
Usar httpGet para verificações de prontidão por meio de terminais típicos de verificação de integridade (por exemplo, /health).
Entenda os parâmetros de verificação padrão (interval: 10s, timeout: 1s, successThreshold: 1, failureThreshold: 3):
- as opções padrão significam que o pod se tornará não está pronto após cerca de 30 segundos (3 falhas nas verificações de sanidade).
Use uma porta separada para "admin" ou "management" se a pilha de tecnologia (por exemplo, Java/Spring) permitir, para separar o gerenciamento de saúde e métricas do tráfego regular:
- mas não se esqueça do ponto 2.
Se necessário, a sonda de prontidão pode ser usada para aquecer/carregar o cache e retornar um código de status 503 até que o contêiner aqueça:
- Eu também recomendo que você leia o novo cheque startupProbe, apareceu na versão 1.16 (escrevemos sobre isso em russo aqui - Aproximadamente. trad.).

Advertências

Não confie em dependências externas (como data warehouses) ao executar testes de prontidão/atividade - isso pode levar a falhas em cascata:
- Como exemplo, vamos pegar um serviço REST stateful com 10 pods dependendo de um banco de dados Postgres: quando a verificação depende de uma conexão funcional com o banco de dados, todos os 10 pods podem falhar se houver um atraso no lado da rede/banco de dados - geralmente tudo termina pior do que poderia;
- Observe que o Spring Data verifica a conexão do banco de dados por padrão*;
  * Este é o comportamento padrão do Spring Data Redis (pelo menos foi a última vez que verifiquei), que levou a uma falha "catastrófica": quando o Redis ficou indisponível por um curto período de tempo, todos os pods "travaram".
- “externo” neste sentido também pode significar outros pods da mesma aplicação, ou seja, o ideal é que a verificação não dependa do estado de outros pods do mesmo cluster para evitar travamentos em cascata:
  - os resultados podem variar para aplicativos com estado distribuído (por exemplo, cache na memória em pods).
Não use uma sonda de vivacidade para pods (as exceções são os casos em que são realmente necessários e você tem pleno conhecimento das especificidades e consequências de seu uso):
- Uma investigação de atividade pode ajudar a recuperar contêineres travados, mas como você tem controle total sobre seu aplicativo, coisas como processos travados e deadlocks idealmente não deveriam acontecer: a melhor alternativa é travar deliberadamente o aplicativo e trazê-lo de volta ao estado estacionário anterior;
- uma falha na sonda de atividade fará com que o contêiner seja reiniciado, potencialmente exacerbando os efeitos de erros relacionados à inicialização: reiniciar o contêiner resultará em tempo de inatividade (pelo menos durante a inicialização do aplicativo, digamos mais de 30 segundos), causando novos erros, aumentando a carga em outros contêineres e aumentando a probabilidade de sua falha, etc.;
- verificações de atividade combinadas com uma dependência externa são a pior combinação possível, ameaçando falhas em cascata: um pequeno atraso no lado do banco de dados levará à reinicialização de todos os seus contêineres!
Parâmetros de verificações de atividade e prontidão deve ser diferente:
- você pode usar uma sonda de atividade com a mesma verificação de integridade, mas com um limite de resposta mais alto (failureThreshold), por exemplo, atribua o status não está pronto após 3 tentativas e considere que a sonda de atividade falhou após 10 tentativas;
Não use verificações executivas, pois estão associados a problemas conhecidos que levam ao aparecimento de processos zumbis:
- detalhes: veja apresentação de especialistas da Datadog.

Resumo

Use sondagens de prontidão para determinar quando um pod está pronto para receber tráfego.
Use testes de vivacidade somente quando forem realmente necessários.
O uso inadequado de testes de prontidão/atividade pode levar à redução da disponibilidade e a falhas em cascata.

Materiais adicionais sobre o tema

Documentos do Kubernetes: Configurar sondagens de atividade e prontidão;
Sondas de atividade e prontidão do Kubernetes revisitadas: como evitar dar um tiro no outro pé;
Post-mortem de interrupção do NRE Labs (ele também fala sobre livenessProbe).

Atualização nº 1 de 2019/09/29

Sobre contêineres init para migração de banco de dados: Nota de rodapé adicionada.

EJ me lembrou sobre o PDB: um dos problemas com as verificações de atividade é a falta de coordenação entre os pods. Kubernetes tem Orçamentos de interrupção de pod (PDB) para limitar o número de falhas simultâneas que um aplicativo pode enfrentar, porém as verificações não levam em consideração o PDB. Idealmente, poderíamos dizer aos K8s para “Reiniciar um pod se o teste falhar, mas não reiniciar todos para evitar piorar as coisas”.

Bryan colocou isso perfeitamente: “Use a sondagem de vivacidade quando você sabe exatamente o que a melhor coisa a fazer é encerrar o aplicativo"(de novo, não se empolgue).

Atualização nº 2 de 2019/09/29

Sobre a leitura da documentação antes de usar: criei a solicitação correspondente (pedido de recurso) para adicionar documentação sobre testes de atividade.

As sondagens de atividade no Kubernetes podem ser perigosas