Configuração da verificação de integridade para um contêiner

Cenário

Verificação de integridade pode verificar regularmente o status de integridade dos contêineres durante o funcionamento do contêiner. Se a função de verificação de integridade não estiver configurada, um pod não poderá detectar exceções de aplicação ou reiniciar automaticamente a aplicação para restaurá-la. Isso resultará em uma situação em que o status do pod é normal, mas a aplicação no pod é anormal.

O Kubernetes fornece os seguintes testes de verificação de integridade:

• Sonda de vivacidade (livenessProbe): verifica se um contêiner ainda está ativo. É similar ao comando ps que verifica se um processo existe. Se a verificação de vivacidade de um contêiner falhar, o cluster reiniciará o contêiner. Se a verificação de vivacidade for bem-sucedida, nenhuma operação será executada.
• Sonda de prontidão (readinessProbe): verifica se um contêiner está pronto para processar solicitações do usuário. Quando o contêiner for detectado despreparado, o tráfego de serviço não será direcionado para o contêiner. Pode levar muito tempo para que algumas aplicações sejam iniciadas antes que elas possam fornecer serviços. Isso ocorre porque elas precisam carregar dados do disco ou depender da inicialização de um módulo externo. Nesse caso, o processo da aplicação está em execução, mas a aplicação não pode fornecer serviços. Para resolver esse problema, essa sonda de verificação de integridade é usada. Se verificação de prontidão do contêiner falhar, o cluster mascara todas as solicitações enviadas ao contêiner. Se a verificação de prontidão do contêiner for bem-sucedida, o contêiner poderá ser acessado.
• Sonda de inicialização (startupProbe): verifica quando uma aplicação em contêiner foi iniciada. Se tal sonda estiver configurada, ela desabilitará as verificações de vivacidade e prontidão até que seja bem-sucedida, garantindo que essas sondas não interfiram na inicialização da aplicação. Isso pode ser usado para adotar verificações de vivacidade em contêineres de partida lenta, evitando que eles sejam encerrados pelo kubelet antes de serem iniciados.

Método de verificação

• Solicitação HTTP

  Esse modo de verificação de integridade se aplica a contêineres que fornecem serviços HTTP/HTTPS. O cluster inicia periodicamente uma solicitação GET HTTP/HTTPS para esses contêineres. Se o código de retorno da resposta HTTP/HTTPS estiver entre 200 e 399, o teste será bem-sucedido. Caso contrário, a sonda falha. Neste modo de verificação de integridade, você deve especificar uma porta de escuta de contêiner e um caminho de solicitação HTTP/HTTPS.

  Por exemplo, para um contêiner que fornece serviços HTTP, o caminho de verificação HTTP é /health-check, a porta é 80 e o endereço do host é opcional (que padrão é o endereço IP do contêiner). Aqui, 172.16.0.186 é usado como um exemplo, e podemos obter tal solicitação: GET http://172.16.0.186:80/health-check. O cluster inicia periodicamente essa solicitação ao contêiner. Você também pode adicionar um ou mais cabeçalhos a uma solicitação HTTP. Por exemplo, defina o nome do cabeçalho da solicitação como Custom-Header e o valor correspondente como example.

  Figura 1 Verificação baseada em solicitação HTTP
  
• Porta TCP

  Para um contêiner que fornece serviços de comunicação TCP, o cluster estabelece periodicamente uma conexão TCP com o contêiner. Se a conexão for bem-sucedida, a sonda será bem-sucedida. Caso contrário, a sonda falha. Neste modo de verificação de integridade, você deve especificar uma porta de escuta de contêiner.

  Por exemplo, se você tiver um contêiner Nginx com porta de serviço 80, depois de especificar a porta TCP 80 para escuta do contêiner, o cluster iniciará periodicamente uma conexão TCP com a porta 80 do contêiner. Se a conexão for bem-sucedida, a sonda será bem-sucedida. Caso contrário, a sonda falha.

  Figura 2 Verificação baseada na porta TCP
  
• CLI

  CLI é uma ferramenta eficiente para verificação de integridade. Ao usar a CLI, você deve especificar um comando executável em um contêiner. O cluster executa periodicamente o comando no contêiner. Se a saída do comando for 0, a verificação de integridade será bem-sucedida. Caso contrário, a verificação de integridade falha.

  O modo CLI pode ser usado para substituir a verificação de integridade baseada em solicitação HTTP e baseada em porta TCP.

  • Para uma porta TCP, você pode usar um script de programa para se conectar a uma porta de contêiner. Se a conexão for bem-sucedida, o script retornará 0. Caso contrário, o script retorna –1.
  • Para uma solicitação HTTP, você pode usar o comando script para executar o comando wget para detectar o contêiner.

    wget http://127.0.0.1:80/health-check

    Verifique o código de retorno da resposta. Se o código de retorno estiver entre 200 e 399, o script retornará 0. Caso contrário, o script retorna –1.

    Figura 3 Verificação baseada na CLI
    
    

    • Coloque o programa a ser executado na imagem de contêiner para que o programa possa ser executado.
    • Se o comando a ser executado for um script shell, não especifique diretamente o script como o comando, mas adicione um analisador de script. Por exemplo, se o script for /data/scripts/health_check.sh, você deve especificar sh/data/scripts/health_check.sh para a execução do comando. A razão é que o cluster não está no ambiente de terminal ao executar programas em um contêiner.
• Verificação de gRPC
  As verificações do gRPC podem configurar sondas de inicialização, vivacidade e prontidão para a aplicação gRPC sem expor nenhum ponto de extremidade HTTP, nem é necessário um executável. O Kubernetes pode se conectar à sua carga de trabalho via gRPC e obter seu status.

  

  • A verificação de gRPC é suportada apenas em clusters do CCE v1.25 ou posterior.
  • Para usar gRPC para verificação, sua aplicação deve oferecer suporte ao protocolo de verificação de integridade do gRPC.
  • Semelhante às sondas HTTP e TCP, se a porta estiver incorreta ou o aplicativo não oferecer suporte ao protocolo de verificação de integridade, a verificação falhará.

  Figura 4 Verificação de gRPC
  

Parâmetros comuns

Exemplo de YAML

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-http
spec:
  containers:
  - name: liveness
    image: nginx:alpine
    args:
    - /server
    livenessProbe:
      httpGet:
        path: /healthz
        port: 80
        httpHeaders:
        - name: Custom-Header
          value: Awesome
      initialDelaySeconds: 3
      periodSeconds: 3
    readinessProbe:
      exec:
        command:
          - cat
          - /tmp/healthy
      initialDelaySeconds: 5
      periodSeconds: 5
    startupProbe:
      httpGet:
        path: /healthz
        port: 80
      failureThreshold: 30
      periodSeconds: 10