Esta página foi traduzida pela API Cloud Translation.

Configure verificações de funcionamento

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

Salvo indicação em contrário, Google Cloud as verificações de estado são implementadas por tarefas de software dedicadas que se ligam a back-ends de acordo com os parâmetros especificados num recurso de verificação de estado. Cada tentativa de ligação é denominada uma sondagem. Google Cloud registra o sucesso ou a falha de cada sondagem.

O estado de saúde de cada back-end é determinado por um número configurável de sondagens bem-sucedidas ou falhadas consecutivas. Ou seja, configura o número de êxitos consecutivos da sondagem necessários para marcar um back-end como saudável e o número de falhas consecutivas para o marcar como não saudável.

Este estado de saúde determina se um back-end é elegível para receber novos pedidos ou ligações. Um back-end não saudável, conforme identificado pela verificação de estado, não recebe tráfego através do equilibrador de carga. Define os critérios para uma sondagem bem-sucedida. Para mais informações, consulte a secção Como funcionam as verificações de estado.

Protocolos de verificação de funcionamento

As verificações de estado suportam os seguintes protocolos:

TCP
HTTP
HTTPS

Selecione uma verificação de funcionamento

As verificações de estado têm de ser compatíveis com o tipo de equilibrador de carga e os tipos de back-end. Considere os seguintes fatores ao selecionar uma verificação de estado:

Protocolo: o protocolo que o GDC usa para sondar os back-ends. Os protocolos suportados são TCP, HTTP e HTTPS. O protocolo TCP é útil para verificações de funcionamento básicas que validam a conetividade a um back-end, enquanto os protocolos HTTP e HTTPS oferecem mecanismos de verificação de funcionamento mais detalhados para VMs que já executam cargas de trabalho HTTP ou HTTPS.
Especificação da porta: a porta que o GDC usa com o protocolo para sondar o estado de funcionamento de um back-end. Tem de especificar uma porta para a verificação de estado.
Categoria: as verificações de funcionamento podem ser globais ou zonais. As verificações de funcionamento globais abrangem todas as zonas de uma implementação do GDC, enquanto as verificações de funcionamento zonais correspondem a uma zona.

Como funcionam as verificações de funcionamento

As secções seguintes descrevem o funcionamento das verificações de estado.

Sondas

Quando estabelece uma verificação de funcionamento, define ou aceita as predefinições que regem a frequência com que cada teste avalia o estado dos pontos finais associados. Estas definições são cruciais porque o equilibrador de carga deixa de encaminhar pedidos para um back-end considerado não saudável através dos critérios que configurou. A sondagem persiste nas suas avaliações e retoma o envio de tráfego para o back-end depois de ser considerada novamente em bom estado.

É importante ter em atenção que as definições de verificação de estado de funcionamento aplicam-se uniformemente a todos os back-ends num serviço de back-end ou num conjunto de destinos e não podem ser configuradas por back-end.

Sinalização de configuração	Explicação	Valor predefinido
intervalo de verificação `check-interval`	O tempo (em segundos) desde o início de uma sondagem até ao início da sondagem seguinte pelo mesmo verificador.	`5s` (5 segundos)
timeoutSec `timeoutSec`	O tempo (em segundos) de espera por uma sondagem antes de declarar falha.	`5s` (5 segundos)
healthyThreshold `healthyThreshold`	O número de sondagens sequenciais que têm de ser bem-sucedidas para que o ponto final seja considerado em bom estado.	2
unhealthyThreshold `unhealthyThreshold`	O número de sondagens sequenciais que têm de falhar para que o ponto final seja considerado não saudável.	2

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

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

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

Configure cada verificador de estado para enviar pedidos HTTP para um caminho de pedido específico em vez do caminho de pedido predefinido,/.
Configure cada verificador de funcionamento para verificar a presença de uma string de resposta esperada no corpo da resposta HTTP. A string de resposta esperada tem de consistir apenas em carateres ASCII imprimíveis de byte único, localizados nos primeiros 1024 bytes do corpo da resposta HTTP.

A tabela seguinte apresenta combinações válidas dos campos requestPath e response que estão disponíveis para verificações de estado HTTP e HTTPS.

Sinalizações de configuração	Comportamento do verificador	Critérios de sucesso
Não foi especificado RequestPath nem Response	O verificador usa `/` como o caminho do pedido.	Apenas o código de resposta HTTP `200 (OK)`.
RequestPath e Response especificados	O verificador usa o caminho do pedido configurado.	O código de resposta HTTP `200 (OK)` e até aos primeiros 1024 carateres ASCII do corpo da resposta HTTP têm de corresponder à string de resposta esperada.
Apenas Response especificado	O verificador usa `/` como o caminho do pedido.	O código de resposta HTTP `200 (OK)` e até aos primeiros 1024 carateres ASCII do corpo da resposta HTTP têm de corresponder à string de resposta esperada.
Apenas RequestPath especificado	O verificador usa o caminho do pedido configurado.	Apenas o código de resposta HTTP `200 (OK)`.

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

As verificações de funcionamento de TCP têm os seguintes critérios de sucesso base:

Para verificações de estado de TCP, um verificador de estado tem de abrir com êxito uma ligação TCP ao back-end antes do limite de tempo da verificação de estado.
Para verificações de estado de TCP, a ligação TCP tem de ser fechada de uma das seguintes formas:
- Através da sonda de verificação de estado de funcionamento que envia um pacote FIN ou RST (reposição).
- Através do envio de um pacote FIN pelo back-end.
- Se um back-end enviar um pacote TCP RST, a sondagem pode ser considerada sem êxito se o verificador de estado do teste de verificação de estado já tiver enviado um pacote FIN.

Antes de começar

Para configurar as sondas de verificação de funcionamento, tem de ter o seguinte:

Ser proprietário do projeto para o qual está a configurar o balanceador de carga. Para mais informações, consulte Crie um projeto.
As funções de identidade e acesso necessárias:
- Peça ao administrador de IAM da organização para lhe conceder a função de administrador do Load Balancer (load-balancer-admin).
- Para ILBs globais, peça ao administrador de IAM da organização para lhe conceder a função de administrador do balanceador de carga global (global-load-balancer-admin). Para mais informações, consulte o artigo Descrições de funções predefinidas.

Crie e faça a gestão de verificações de funcionamento

O GDC suporta verificações de estado globais e zonais.

API HealthCheck

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

apiVersion zonal: networking.gdc.goog
apiVersion global: networking.global.gdc.goog

Também pode usar a CLI gdcloud para criar e gerir verificações de funcionamento.

Crie um `HealthCheck` global

O exemplo seguinte mostra como criar uma verificação de estado de funcionamento através da 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

Crie um `HealthCheck` zonal

O exemplo seguinte mostra como criar uma verificação de estado de funcionamento através da 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 associar uma verificação de funcionamento a um balanceador de carga, consulte o seguinte:

Validação da configuração

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

Notas de utilização adicionais

As secções seguintes incluem notas adicionais sobre a utilização de verificações de funcionamento no Google Cloud.

Certificados e verificações de funcionamento

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

Os certificados podem ser autoassinados ou de qualquer autoridade de certificação (AC).
Os certificados expirados ou com data futura são aceitáveis.

Cabeçalhos

Quando configurar verificações de estado para protocolos HTTP ou HTTPS, pode especificar um cabeçalho HTTP Host através da flag --host.

É importante ter em atenção que o balanceador de carga adiciona os cabeçalhos de pedidos personalizados que configurar apenas aos pedidos de clientes e não às sondagens de verificação do estado. Por conseguinte, se o seu back-end exigir um cabeçalho específico para autorização que esteja ausente do pacote de verificação de funcionamento, a verificação de funcionamento pode falhar.

Exemplo de verificação de funcionamento

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

Intervalo: 30 segundos
Limite de tempo: 5 segundos
Protocolo: HTTP
Limite não saudável: 2 (predefinição)
Limite saudável: 2 (predefinição)

A verificação de funcionamento funciona da seguinte forma:

Cada verificador de funcionamento:
1. Inicia uma ligação HTTP a partir de um endereço IP de origem para a instância de back-end a cada 30 segundos.
2. Aguarde até cinco segundos para que seja devolvido um código de estado HTTP 200 (OK) (os critérios de êxito designados para protocolos HTTP e HTTPS).
Um back-end é considerado não saudável se, pelo menos, um sistema de sondagem de verificação de estado fizer o seguinte:
1. Não recebe uma resposta HTTP 200 (OK) para duas sondagens consecutivas devido a uma ligação recusada, um limite de tempo da ligação ou um limite de tempo do socket.
2. Recebe duas respostas consecutivas que não se alinham com os critérios de êxito específicos do protocolo.
Um back-end é considerado em bom estado quando, pelo menos, um sistema de sondagem de verificação do estado recebe duas respostas consecutivas que cumprem os critérios de êxito específicos do protocolo.

Neste exemplo, cada verificador inicia uma ligação a cada 30 segundos. Decorrem 30 segundos entre as tentativas de ligação de um verificador, independentemente da duração do limite de tempo (se o limite de tempo da ligação foi atingido ou não). Por outras palavras, o limite de tempo tem de ser sempre inferior ou igual ao intervalo, e o limite de tempo nunca aumenta o intervalo.

Limitações

As verificações de estado do GDC só servem pontos finais de VMs.
Não é possível configurar equilibradores de carga com verificações de funcionamento com pods e VMs como back-ends mistos. Um balanceador de carga tem de ser composto apenas por pods ou apenas por VMs como respetivos pontos finais. Atualmente, um balanceador de carga tem de ser composto apenas por pods ou apenas por VMs como pontos finais.
A capacidade de alteração do equilibrador de carga e da verificação de estado associada ainda não é suportada.