Noções básicas sobre exemplos do Kubernetes: tipos, configuração e práticas recomendadas



Fonte



Este artigo é sobre como configurar probes de prontidão, integridade e inicialização para detectar e trabalhar com módulos não íntegros, conforme traduzido pela equipe aaS do Kubernetes .



Por que as validações do Kubernetes são necessárias?



Um dos desafios dos sistemas distribuídos e da arquitetura de microsserviços é a detecção automática de aplicativos defeituosos, redirecionando solicitações para outros sistemas disponíveis e reparando componentes danificados. As verificações de saúde são uma forma de resolver esse problema e garantir a confiabilidade. No Kubernetes, as verificações de integridade são configuradas usando sondas para determinar o status de cada pod.



Por padrão, o Kubernetes monitora o ciclo de vida do pod e começa a rotear o tráfego para o pod quando os contêineres passam de Pendente para Bem-sucedido. O Kubelet também monitora travamentos de aplicativos e reinicia o módulo para recuperação.



Muitos desenvolvedores acreditam que essa configuração básica é suficiente, especialmente quando o aplicativo dentro do módulo é configurado usando gerenciadores de processo, como PM2 para Node.js.



No entanto, como o Kubernetes considera o módulo íntegro e pronto para solicitações, assim que todos os contêineres são iniciados, o aplicativo pode começar a receber tráfego antes de estar realmente pronto. Isso pode acontecer se o aplicativo precisar inicializar algum estado, estabelecer uma conexão com o banco de dados ou carregar dados antes de processar a lógica do aplicativo.



Esse período de tempo entre a disponibilidade real do aplicativo e o momento em que o Kubernetes o considera pronto se torna um problema quando a implantação começa a escalar e os aplicativos despreparados recebem tráfego e devolvem um erro 500.



É nessas situações que as sondagens do Kubernetes são usadas para determinar quando o contêiner está pronto para aceitar o tráfego e quando deve ser reiniciado. A partir do Kubernetes 1.16, três tipos de sondagens são compatíveis.



Neste artigo, o autor discute diferentes tipos de probes, bem como práticas recomendadas e ferramentas para detectar implantações com possíveis problemas de configuração.



Sondas Kubernetes



O Kubernetes oferece suporte a sondagens de prontidão e integridade para versões ≤ 1.15. As probes de lançamento foram adicionadas no 1.16 como um recurso alfa e movido para o beta no 1.18.



AVISO: na versão 1.16, partes da API Kubernetes foram descontinuadas. Use este guia de migração para verificar a compatibilidade.



Todas as amostras têm os seguintes parâmetros:



  • initialDelaySeconds



    : ;
  • periodSeconds



    : ;
  • timeoutSeconds



    : - ( );
  • successThreshold



    : , ;
  • failureThreshold



    : . . , .




As sondagens de prontidão são usadas para informar ao kubelet quando o aplicativo está pronto para aceitar novo tráfego. Se seu aplicativo demorar para inicializar depois de iniciar um processo, configure uma sondagem de prontidão para que o Kubernetes espere antes de enviar novo tráfego. O principal caso de uso para sondagens de prontidão é direcionar o tráfego para implantações de serviços.





Fonte



É importante lembrar que as sondas de prontidão funcionam durante toda a vida de um módulo. Isso significa que eles serão iniciados não apenas na inicialização, mas também durante todo o tempo de operação do módulo.



Isso é necessário para situações em que o aplicativo está temporariamente indisponível, como carregar big data ou aguardar conexões externas. Nesse caso, não queremos encerrar o aplicativo, mas esperar até que seja restaurado. As sondagens de prontidão são usadas para detectar esse cenário e não enviam tráfego para esses módulos até que eles passem na verificação de prontidão novamente.



Testes de performance



As análises de integridade são usadas para reiniciar contêineres não íntegros. O Kubelet invoca periodicamente um teste de integridade, detecta a integridade do pod e o mata se falhar em uma verificação de integridade.



Uma avaliação pode ajudar um aplicativo a sair de um impasse. Sem verificações de integridade, o Kubernetes se considera bloqueado como íntegro porque o processo principal continua a ser executado da perspectiva do Kubernetes. Ao configurar uma investigação de integridade, o kubelet pode determinar se o aplicativo está em um estado inválido e reiniciará o pod para restaurar a disponibilidade.





Fonte



Amostras de lançamento



Os testes de inicialização são semelhantes aos testes prontos, mas são executados apenas na inicialização. Eles são otimizados para inicialização lenta de contêineres ou aplicativos com processos de inicialização imprevisíveis. Com as análises de prontidão, podemos ajustar initialDelaySeconds



para determinar quanto tempo esperar antes de verificar a prontidão.



Agora, considere um aplicativo que às vezes precisa carregar grandes quantidades de dados ou executar uma operação com uso intensivo de recursos no início do processo. Por initialDelaySeconds



ser um número estático, somos obrigados a sempre pegar o pior cenário (ou aumentar o valor failureThreshold



, o que pode afetar mais o comportamento) e esperar muito tempo, mesmo que este aplicativo não precise realizar uma inicialização longa.



Em vez disso, usando probes de inicialização, podemos configurarfailureThreshold



e periodSeconds



para lidar melhor com essa incerteza. Por exemplo, uma configuração failureThreshold



de 15 e periodSeconds



5 significa que o aplicativo terá 15 x 5 = 75 segundos para iniciar antes que uma falha seja diagnosticada.



Configuração de amostra



Agora que entendemos os diferentes tipos de amostra, podemos explorar três maneiras diferentes de configurar cada amostra.



HTTP



O Kubelet envia uma solicitação HTTP GET para o URL especificado e verifica se há uma resposta 2xx ou 3xx. Você pode usar um endpoint HTTP existente ou configurar um servidor HTTP leve para teste (por exemplo, um servidor Express com um endpoint /healthz



).



As sondagens HTTP usam parâmetros adicionais:



  • host



    : hostname para conexão (por padrão, este é o endereço IP do módulo);
  • scheme



    : HTTP ou HTTPS padrão;
  • path



    : caminho no servidor HTTP / S;
  • httpHeaders



    : cabeçalhos personalizados se você precisar de valores de cabeçalho para autenticação, configurações de CORS, etc.
  • port



    : nome ou número da porta para acessar o servidor.


livenessProbe:
  httpGet:
    path: /healthz
    port: 8080

      
      





TCP



Se você só precisa verificar se uma conexão TCP pode ser estabelecida, use uma sonda TCP. Um módulo é marcado como íntegro se puder estabelecer uma conexão TCP. O uso de probes TCP pode ser útil para gRPC ou servidor FTP em que as chamadas HTTP não são apropriadas.



readinessProbe:
  tcpSocket:
    port: 21

      
      





Comando



Você também pode configurar o probe para executar um comando shell. A verificação é aprovada se o comando retornar com um código de saída 0. Caso contrário, o módulo é marcado como defeituoso.



Este tipo de validação pode ser útil se você não quiser abrir um servidor / porta HTTP ou se for mais fácil validar as etapas de inicialização usando comandos. Por exemplo, verifique se um arquivo de configuração foi criado ou execute um comando CLI.



readinessProbe:
  exec:
    command: ["/bin/sh", "-ec", "vault status -tls-skip-verify"]

      
      





Práticas recomendadas para amostragem de Kubernetes



Os parâmetros de amostra exatos dependem do seu aplicativo, mas aqui estão algumas diretrizes gerais para você começar:



  1. Para clusters Kubernetes mais antigos (≤ 1,15), use uma sondagem inicial de lag pronto para lidar com a fase de inicialização do contêiner. Para fazer isso, use o tempo de percentil 99%. Mas torne essa verificação fácil, pois o teste de prontidão será executado durante toda a vida do módulo. Não queremos que a sonda atinja o tempo limite porque a verificação de prontidão leva muito tempo.
  2. (≥ 1.16) Kubernetes . (, /healthz



    ), . failureThreshold



    , , . .
  3. , . , , , . .
  4. , . , , , . , .


Resumindo, as sondas bem definidas geralmente aumentam a estabilidade e a disponibilidade. Monitore os tempos de inicialização e o comportamento do sistema para ajustar as configurações de amostra à medida que os aplicativos mudam.



Ferramentas



Dada a importância das probes do Kubernetes, você pode usar as ferramentas de análise de recursos do Kubernetes para encontrar probes ausentes. Essas ferramentas podem ser executadas em clusters existentes ou incorporadas em um processo de CI / CD para falhar automaticamente na implantação de cargas de trabalho sem recursos configurados corretamente:



  • polaris é um utilitário de análise de recursos com uma bela barra de ferramentas que também pode ser usada como um webhook de validação ou ferramenta de linha de comando.
  • kube-score é uma ferramenta de análise de código estática que funciona com Helm, Kustomize e arquivos YAML padrão.
  • popeye é uma ferramenta de utilitário somente leitura que verifica os clusters do Kubernetes e relata possíveis problemas de configuração.


Nestes dois canais do Telegram, você encontrará notícias de nosso Kubernetes aaS e anúncios de eventos do @Kubernetes Meetup .



O que mais ler:






All Articles