Aviso de upgrade dos balanceadores de carga 1.7.0 a 1.7.2

No Kubernetes versão 1.7.0 ou posterior, qualquer novo serviço que você criar com type LoadBalancer terá verificações de integridade ativadas por padrão, desde que todos os nós no cluster estejam executando as versões mencionadas.

No entanto, há um problema conhecido no Kubernetes versões 1.7.0 e 1.7.1 que faz os nós responderem incorretamente às verificações de integridade do balanceador de carga de rede do GCP. Quando isso ocorre, o balanceador de carga de rede configurado pelo Kubernetes mostra falhas de verificação de integridade consistentes em todos os nós do cluster, mas o tráfego ainda é encaminhado para os back-ends.

Esse problema foi corrigido na versão 1.7.2, mas você precisará agir quando fizer upgrade de um cluster existente da versão 1.7.0 ou 1.7.1 para a 1.7.2. O upgrade pode causar um potencial desequilíbrio de carga. Quando as verificações de integridade estão funcionando corretamente para os nós que executam a versão 1.7.2, o balanceador de carga do GCP encaminha todo o tráfego para esses nós e para longe dos nós da versão 1.7.0 ou 1.7.1 com falhas nas verificações de integridade. Esse desequilíbrio pode causar interrupções do serviço se não houver nós "íntegros" suficientes (por exemplo, nós que executam a versão 1.7.2) para administrar a carga de tráfego do cluster.

Você pode atenuar esse problema removendo manualmente as verificações de integridade de todos os balanceadores de carga afetados antes de fazer upgrade dos nós para a versão 1.7.2.

Como determinar se o cluster foi afetado

Se os nós do cluster estiverem executando o Kubernetes versão 1.7.0 ou 1.7.1, o cluster poderá ser afetado caso você tenha feito um dos seguintes procedimentos:

  • Você criou um novo serviço com --type LoadBalancer.
  • Você atualizou um serviço atual com --type LoadBalancer para outro tipo (ClusterIP, ExternalName etc.) e, posteriormente, o revogou LoadBalancer.
  • Você atualizou o campo sessionAffinity em um serviço LoadBalancer atual.
  • Você definiu o campo externalTrafficPolicy como Cluster em um serviço LoadBalancer atual.

Para confirmar se o cluster foi afetado:

  1. No Console do Google Cloud, vá para o GKE e selecione seu cluster.
  2. Clique na guia Descoberta e balanceamento de carga.
  3. Procure um serviço em que o campo Tipo seja LoadBalancer e clique no nome do serviço.
  4. No painel Detalhes do serviço, encontre o campo Balanceador de carga. Esse é o recurso do balanceador de carga do GCP anexado ao cluster.
  5. Clique em Nome do balanceador de carga.
  6. Você verá o painel Balanceamento de carga. Procure as verificações de integridade anexadas. Se houver uma verificação de integridade anexada chamada k8s-XXX-node, seu cluster será afetado.

Repita as etapas acima para todos os serviços de balanceador de carga no cluster.

É possível determinar o serviço do Kubernetes correspondente usando o Menu avançado da seguinte maneira:

  1. Clique na guia Regras de encaminhamento.
  2. Selecione a entrada do balanceador de carga.
  3. Você verá o nome do serviço na Descrição com o seguinte formato: {"kubernetes.io/service-name":"$NAMESPACE/$SERVICE_NAME"}.

Fazer upgrade da atenuação de riscos

Para atenuar o risco de um potencial desequilíbrio de carga e garantir um upgrade seguro para a versão 1.7.2, faça o seguinte:

  1. Antes de fazer upgrade, remova manualmente as verificações de integridade de todos os balanceadores de carga afetados no cluster.
  2. Faça upgrade dos nós para a versão 1.7.2.
  3. Depois de fazer o upgrade, substitua as verificações de integridade de cada balanceador de carga no cluster.

Antes de fazer upgrade

Para remover a verificação de integridade do nó de um balanceador de carga:

  1. No Console do Google Cloud, vá para o GKE e selecione seu cluster.
  2. Clique na guia Descoberta e balanceamento de carga.
  3. Localize o serviço LoadBalancer afetado e clique no nome dele.
  4. No painel Detalhes do serviço, encontre o campo Balanceador de carga. Esse é o recurso do balanceador de carga do GCP anexado ao cluster.
  5. Clique em Nome do balanceador de carga.
  6. No painel Balanceamento de carga, clique no link Menu avançado.
  7. No Menu avançado, clique em Pools de segmentação.
  8. 1. Observe o nome da verificação de integridade, k8s-XXX-node, em que XXX é o ID de hash do seu cluster. Você precisará disso mais tarde para restaurar a verificação de integridade, se quiser.
  9. Edite o pool de segmentação correspondente para o balanceador de carga para "sem verificação de integridade". Essa é uma atualização in-loco que não deve causar inatividade no seu serviço.

Repita as etapas acima para cada balanceador de carga afetado no cluster.

Depois de remover as verificações de integridade, você poderá fazer upgrade dos nós com segurança para a versão 1.7.2 sem o risco de um desequilíbrio de tráfego para os nós. O balanceador de carga do GCP continuará a encaminhar o tráfego para os nós sem verificações de segurança independentemente do status. Esse comportamento é idêntico ao dos clusters que executam as versões 1.6.x e anteriores do Kubernetes.

Após fazer upgrade

Depois de fazer upgrade, você poderá substituir as verificações de integridade do nó nos balanceadores de carga do cluster da seguinte maneira:

  1. No Console do Google Cloud, vá para o cluster.
  2. Clique na guia Descoberta e balanceamento de carga.
  3. Localize o serviço LoadBalancer afetado e clique no nome dele.
  4. No painel Detalhes do serviço, encontre o campo Balanceador de carga. Esse é o recurso do balanceador de carga do GCP anexado ao cluster.
  5. Clique em Nome do balanceador de carga.
  6. No painel Balanceamento de carga, clique no link Menu avançado.
  7. No Menu avançado, clique em Pools de segmentação.
  8. Edite o pool de segmentação correspondente do balanceador de carga para o mesmo valor do formato k8s-XXX-node que você anotou anteriormente ao remover as verificações de integridade antes do upgrade. Esse é um upgrade no local que não causará inatividade no serviço.

Repita as etapas acima para cada balanceador de carga afetado no cluster.