Configurar verificações de integridade

O Google Distributed Cloud (GDC) air-gapped fornece mecanismos de verificação de integridade que determinam se as instâncias de back-end respondem adequadamente ao tráfego. Neste documento, descrevemos como criar e usar verificações de integridade para balanceadores de carga.

Salvo indicação contrária,as verificações de integridade do Google Cloud são implementadas por tarefas de software dedicadas que se conectam a back-ends de acordo com os parâmetros especificados em um recurso de verificação de integridade. Cada tentativa de conexão é chamada de sondagem.O Google Cloud registra o sucesso ou a falha de cada sondagem.

O estado de integridade de cada back-end é determinado por um número configurável de sondagens consecutivas com sucesso ou falha. Ou seja, você configura o número de êxitos consecutivos de sondagem necessários para marcar um back-end como íntegro e o número de falhas consecutivas para marcá-lo como não íntegro.

Esse status determina se um back-end está qualificado para receber novas solicitações ou conexões. Um back-end não íntegro, conforme identificado pela verificação de integridade, não recebe tráfego pelo balanceador de carga. Você define os critérios para uma sondagem bem-sucedida. Para mais informações, consulte a seção Como as verificações de integridade funcionam.

Protocolos de verificação de integridade

As verificações de integridade são compatíveis com os seguintes protocolos:

  • TCP
  • HTTP
  • HTTPS

Selecionar uma verificação de integridade

As verificações de integridade precisam ser compatíveis com o tipo de balanceador de carga e os tipos de back-end. Considere os seguintes fatores ao selecionar uma verificação de integridade:

  • Protocolo:o protocolo que o GDC usa para analisar os back-ends. Os protocolos compatíveis são TCP, HTTP e HTTPS. O protocolo TCP é útil para verificações de integridade básicas que validam a conectividade com um back-end, enquanto os protocolos HTTP e HTTPS oferecem mecanismos de verificação de integridade mais granulares para VMs que já executam cargas de trabalho HTTP ou HTTPS.
  • Especificação de porta:a porta que o GDC usa com o protocolo para testar a integridade de um back-end. É necessário especificar uma porta para a verificação de integridade.
  • Categoria:as verificações de integridade podem ser globais ou zonais. As verificações de integridade globais abrangem todas as zonas de uma implantação do GDC, enquanto as zonais correspondem a uma zona.

Como as verificações de integridade funcionam

Veja nas seções a seguir como as verificações de integridade funcionam.

Sondagens

Ao estabelecer uma verificação de integridade, você define ou aceita as configurações padrão que regem a frequência com que cada sonda avalia a integridade dos endpoints associados. Essas configurações são essenciais porque o balanceador de carga para de rotear solicitações para um back-end considerado não íntegro usando os critérios configurados. A sondagem vai continuar as avaliações e retomar o envio de tráfego para o back-end depois que ele for considerado íntegro novamente.

É importante observar que as configurações de verificação de integridade são aplicadas de maneira uniforme a todos os back-ends em um serviço de back-end ou pool de destino e não podem ser configuradas por back-end.

Sinalização de configuração Explicação Valor padrão
intervalo de verificação

check-interval

 O tempo (em segundos) entre o início de uma sondagem e o início da próxima sondagem pela mesma sonda. 5s (5 segundos)
timeoutSec

timeoutSec

 O tempo (em segundos) para aguardar uma sondagem antes de declarar falha. 5s (5 segundos)
healthyThreshold

healthyThreshold

 O número de sondagens sequenciais que precisam ser bem-sucedidas para que o endpoint seja considerado íntegro. 2
unhealthyThreshold

unhealthyThreshold

 O número de sondagens seguidas que precisam falhar para que o endpoint seja considerado não íntegro. 2

Critérios de sucesso para verificações de integridade HTTP e HTTPS

Para verificações de integridade HTTP e HTTPS, um código de status HTTP 200 (OK) é necessário para uma resposta bem-sucedida antes do tempo limite da verificação de integridade. Outros códigos de resposta HTTP, incluindo redirecionamentos (por exemplo, 301, 302), são considerados não íntegros.

Além de exigir um código de resposta HTTP 200 (OK), você pode:

  • Configure cada sonda de verificação de integridade para enviar solicitações HTTP a um caminho de solicitação específico em vez do caminho padrão,/.
  • Configure cada sondagem de verificação de integridade para verificar a presença de uma string de resposta esperada no corpo da resposta HTTP. A string de resposta esperada precisa consistir apenas em caracteres ASCII de byte único e para impressão, localizados nos primeiros 1.024 bytes do corpo da resposta HTTP.

A tabela a seguir lista as combinações válidas dos campos requestPath e response disponíveis para verificações de integridade HTTP e HTTPS.

Sinalizações de configuração Comportamento do verificador Critérios de sucesso
Nem RequestPath nem Response especificados O verificador usa / como o caminho da solicitação. Apenas o código de resposta HTTP 200 (OK).
RequestPath e Response especificados O verificador usa o caminho de solicitação configurado. O código de resposta HTTP 200 (OK) e até os primeiros 1.024 caracteres ASCII do corpo da resposta HTTP precisam corresponder à string de resposta esperada.
Somente Response especificado O verificador usa / como o caminho da solicitação. O código de resposta HTTP 200 (OK) e até os primeiros 1.024 caracteres ASCII do corpo da resposta HTTP precisam corresponder à string de resposta esperada.
Somente RequestPath especificado O verificador usa o caminho de solicitação configurado. Apenas o código de resposta HTTP 200 (OK).

Critérios de sucesso para verificações de integridade de TCP

As verificações de integridade de TCP têm os seguintes critérios de sucesso básicos:

  • Para verificações de integridade TCP, uma sondagem precisa abrir uma conexão TCP com o back-end antes do tempo limite da verificação de integridade.
  • Para verificações de integridade TCP, a conexão TCP precisa ser fechada de uma das seguintes maneiras:
    • A sonda de verificação de integridade envia um pacote FIN ou RST (redefinição).
    • O back-end envia um pacote FIN.
    • Se um back-end enviar um pacote TCP RST, a sondagem poderá ser considerada malsucedida se a sonda de verificação de integridade já tiver enviado um pacote FIN.

Antes de começar

Para configurar sondagens de verificação de integridade, você precisa ter o seguinte:

  • Ser proprietário do projeto em que você está configurando o balanceador de carga. Para mais informações, consulte Criar um projeto.

  • Os papéis de identidade e acesso necessários:

    • Peça ao administrador do IAM da organização para conceder a você o papel de administrador do balanceador de carga (load-balancer-admin).
    • Para ILBs globais, peça ao administrador do IAM da organização para conceder a você o papel de administrador global do balanceador de carga (global-load-balancer-admin). Para mais informações, consulte Descrições de papéis predefinidos.

Criar e gerenciar verificações de integridade

O GDC é compatível com verificações de integridade globais e zonais.

API HealthCheck

É possível configurar um objeto HealthCheck como global ou zonal. Os objetos globais HealthCheck são usados para configurações de balanceador de carga global, enquanto os objetos zonais HealthCheck são usados para configurações de balanceador de carga zonal. Os dois tipos têm o mesmo nome e especificação. No entanto, eles usam valores de apiVersion e servidores de API diferentes:

Também é possível usar a CLI gdcloud para criar e gerenciar verificações de integridade.

Criar um HealthCheck global

O exemplo a seguir mostra como criar um HealthCheck usando a API:

  kubectl --kubeconfig GLOBAL_ORG_ADMIN_CLUSTER_KUBECONFIG apply -f - <<EOF 
  apiVersion: networking.global.gdc.goog/v1 
  kind: HealthCheck 
  metadata: 
    namespace: PROJECT 
    name: my-hc 
  spec: 
    httpHealthCheck: 
      port: PORT 
      host: HOST 
      requestPath: requestPath 
      response: responseT 
  EOF

Criar um HealthCheck zonal

O exemplo a seguir mostra como criar um HealthCheck usando a API:

  kubectl --kubeconfig MANAGEMENT_API_SERVER_KUBECONFIG apply -f - <<EOF 
  apiVersion: networking.gdc.goog/v1
  kind: HealthCheck
  metadata:
    namespace: PROJECT
    name: my-hc
  spec:
    httpHealthCheck:
      port: PORT
      host: HOST
      requestPath: requestPath 
      response: response 
  EOF

Para vincular uma verificação de integridade a um balanceador de carga, consulte o seguinte:

Verificação de configuração

Para garantir que a configuração esteja correta, verifique a condição Ready do objeto HealthCheck. Essa condição indica erros de configuração. Além disso, confirme se os campos refletem com precisão as configurações necessárias de HealthCheck.

Outras observações de uso

As seções a seguir incluem mais algumas observações sobre o uso de verificações de integridade no Google Cloud.

Certificados e verificações de integridade

Para protocolos como HTTPS, que exigem certificados nos back-ends,

  • Os certificados podem ser autoassinados ou de qualquer autoridade de certificação (CA).
  • Certificados expirados ou com data futura são aceitos.

Cabeçalhos

Ao configurar verificações de integridade para protocolos HTTP ou HTTPS, é possível especificar um cabeçalho Host usando a flag --host.

É importante observar que o balanceador de carga adiciona os cabeçalhos de solicitação personalizados que você configura apenas às solicitações do cliente, não às sondagens de verificação de integridade. Portanto, se o back-end exigir um cabeçalho específico para autorização que não esteja no pacote de verificação de integridade, ela poderá falhar.

Exemplo de verificação de integridade

Se uma verificação de integridade for configurada com os seguintes parâmetros:

  • Intervalo: 30 segundos
  • Tempo limite: 5 segundos
  • Protocolo: HTTP
  • Limite não íntegro: 2 (padrão)
  • Limite íntegro: 2 (padrão)

A verificação de integridade vai funcionar da seguinte maneira:

  • Cada sondagem de verificação de integridade vai:
    1. Inicia uma conexão HTTP de um endereço IP de origem com a instância de back-end a cada 30 segundos.
    2. Aguarde até cinco segundos para que um código de status HTTP 200 (OK) seja retornado (os critérios de sucesso designados para protocolos HTTP e HTTPS).
  • Um back-end é considerado não íntegro se pelo menos um sistema de sondagem de verificação de integridade fizer o seguinte:
    1. Não recebe uma resposta HTTP 200 (OK) para duas sondagens consecutivas devido a uma conexão recusada, tempo limite de conexão ou tempo limite de soquete.
    2. Recebe duas respostas consecutivas que não se alinham aos critérios de sucesso específicos do protocolo.
  • Um back-end é considerado íntegro quando pelo menos um sistema de sondagem de verificação de integridade recebe duas respostas consecutivas que atendem aos critérios de sucesso específicos do protocolo.

Neste exemplo, cada sonda inicia uma conexão a cada 30 segundos. Trinta segundos se passam entre as tentativas de conexão da sonda, independentemente da duração do tempo limite (se a conexão expirou ou não). Em outras palavras, o tempo limite precisa ser sempre menor ou igual ao intervalo, e ele nunca aumenta o intervalo.

Limitações

  1. As verificações de integridade do GDC atendem apenas a endpoints de VM.
  2. Não é possível configurar balanceadores de carga com verificações de integridade usando pods e VMs como back-ends mistos. Um balanceador de carga precisa consistir apenas em pods ou apenas em VMs como endpoints. No momento, um balanceador de carga precisa consistir apenas em pods ou apenas em VMs como endpoints.
  3. A mutabilidade do balanceador de carga e da verificação de integridade associada ainda não é compatível.