s <0x0 Problemas conhecidos do Google Distributed Cloud para bare metal

Esta página lista todos os problemas conhecidos do Google Distributed Cloud (somente software) para bare metal (antes conhecido como Google Distributed Cloud Virtual, anteriormente conhecido como clusters do Anthos em bare metal).

Esta página é destinada a administradores, arquitetos e operadores que gerenciam o ciclo de vida da infraestrutura tecnológica e responder a alertas e páginas quando os objetivos de nível de serviço (SLOs) não são atendidos ou os aplicativos falham. Para saber mais sobre papéis comuns e tarefas de exemplo referenciados no conteúdo do Google Cloud, consulte Tarefas e funções de usuário comuns do GKE.

Se você faz parte do Programa para desenvolvedores do Google, salve esta página para receber notificações quando uma nota da versão relacionada a ela for publicada. Para saber mais, consulte Páginas salvas.

Para filtrar os problemas conhecidos por uma versão ou categoria do produto, selecione os filtros nos menus suspensos a seguir.

Selecione sua versão do Google Distributed Cloud:

Selecione a categoria do seu problema:

Ou pesquise seu problema:

Categoria Versões identificadas Problema e solução alternativa
Rede, upgrades e atualizações 1.30 e versões mais recentes

O recurso de entrada incluído no Google Distributed Cloud usa istiod. Esse recurso não usa definições de recursos personalizados definidas pelo Istio. No entanto, como o código usado é de código aberto, os pods são sensíveis a instalações do Istio que você possa ter para seus próprios casos de uso.

Se não houver definições de recursos personalizados do Istio nos clusters, o Istiod se declara pronto sem esperar pelas definições de recursos personalizados. No entanto, se houver v1beta definições de recursos personalizados no cluster, o Istiod vai aguardar v1 definições de recursos personalizados antes de declarar a prontidão. Como resultado, o pod do Istiod pode não atingir o estado de prontidão, causando falha nos upgrades do cluster.

Verificação:

Para confirmar se o cluster foi afetado, verifique o status do pod Istiod no namespace gke-system:

kubectl get pods -n gke-system -l app=istiod

Se o status do pod for Running, mas a verificação de prontidão falhar (por exemplo, 0/1 pronto), é provável que o cluster seja afetado.


Alternativa:

Para resolver esse problema, use um dos métodos a seguir.

  • Implante manualmente as definições de recursos personalizados v1 do Istio no cluster.

  • Desative o recurso de entrada em pacote se não estiver usando.
Instalação, upgrades e atualizações 1.30.400 e versões anteriores

Clusters na versão 1.30.400 ou anterior podem apresentar falhas no pod lifecycle-controllers-manager ao validar recursos personalizados PreflightCheck. Esses erros travam o provisionamento e os upgrades de cluster.

Esse problema ocorre devido a uma desreferência de ponteiro nulo durante a validação de recursos PreflightCheck.


Alternativa:

Para permitir o provisionamento ou upgrades de cluster, ignore as verificações de simulação. Defina o campo bypassPreflightCheck como true no arquivo de configuração do cluster:

spec:
  bypassPreflightCheck: true

Para mais informações, consulte Ignorar verificações de simulação ao aplicar recursos do Kubernetes.
Operação, redefinição/exclusão 1.33 e versões anteriores

Quando você restaura um cluster usando bmctl restore cluster, o serviço systemd do Detector de problemas do nó (NPD) não é iniciado nos nós após a conclusão da operação de restauração.

Para verificar se você foi afetado, execute systemctl is-active node-problem-detector nos nós do cluster após uma operação de restauração. Se o comando retornar inactive, você será afetado por esse problema.


Alternativa:

Para restaurar o NPD, faça o seguinte:

  1. Desative o NPD de acordo com o processo em Como ativar e desativar o detector de problemas do nó.
  2. Ative o NPD de acordo com o processo em Como ativar e desativar o detector de problemas do nó.

Desativar e ativar o NPD aciona explicitamente os jobs do implantador do NPD, que instalam o serviço NPD em todos os nós.
Rede, operação 1.28 e versões anteriores, 1.29.0-1.29.700, 1.30.0-1.30.300

Em clusters que usam o balanceador de carga de camada 2 agrupado, podem ocorrer erros de "Conexão recusada" ou uma breve indisponibilidade do servidor da API (aproximadamente 1 minuto) a cada sete dias.

Esse comportamento ocorre porque os pods haproxy e keepalived nos nós do plano de controle são reiniciados devido a uma configuração de tempo de vida do job. Esse problema afeta clusters nas versões 1.29.0 a 1.29.700, 1.30.0 a 1.30.300 e 1.28 e anteriores.


Verificação:

Para confirmar se o cluster está afetado por esse problema específico, verifique a configuração do job de atualização do balanceador de carga seguindo estas etapas:

  1. Encontre o nome do job de atualização:

    kubectl get jobs -n kube-system | grep bm-system-cplb-update

  2. Verifique a configuração de tempo de vida do job:

    kubectl get job JOB_NAME -n kube-system -o jsonpath='{.spec.ttlSecondsAfterFinished}'

    Substitua JOB_NAME pelo nome retornado na etapa anterior.

  3. Se a saída for 604800 (que é 7 dias em segundos), o cluster será afetado por esse problema.


Alternativa:

Para evitar as reinicializações semanais, adicione manualmente um patch ao campo ttlSecondsAfterFinished nos jobs de atualização do balanceador de carga atuais com um valor maior. Para isso, siga estas etapas:

  1. Edite o job de atualização do balanceador de carga:

    kubectl edit job JOB_NAME -n kube-system

  2. No editor, encontre o campo ttlSecondsAfterFinished e mude o valor para 7776000 (aproximadamente 90 dias).

  3. Salve e saia do editor para aplicar as mudanças.
Operação 1.32.0-1.32.700, 1.33.0-1.33.300, 1.34.0

O pod cluster-operator pode falhar ou entrar em um loop de falha devido a um pânico: assignment to entry in nil map em um controlador. Isso pode acontecer quando o controlador tenta atualizar anotações em um recurso personalizado, como um NodePool, que não tem nenhuma anotação (mapa nulo).


Alternativa:

Para evitar o pânico, verifique se o recurso personalizado (por exemplo, NodePool) tem pelo menos uma anotação. É possível adicionar uma anotação fictícia usando o seguinte comando:

kubectl annotate nodepool NODEPOOL_NAME \
    -n CLUSTER_NAMESPACE dummy-annotation="added-manually" --overwrite \
    --kubeconfig=ADMIN_KUBECONFIG

Substitua:

  • NODEPOOL_NAME: o nome do recurso personalizado NodePool.
  • CLUSTER_NAMESPACE: o namespace do cluster.
  • ADMIN_KUBECONFIG: o caminho até o arquivo kubeconfig do cluster de administrador.
Upgrades e atualizações 1.34.0

Falha no upgrade do nó de trabalho devido a uma incompatibilidade de nome do host

As atualizações de nós de trabalho falham devido a uma regressão (kubernetes/kubeadm#3244) em kubeadm. A regressão ocorre quando o nome do host do Linux não corresponde ao valor do rótulo kubernetes.io/hostname nos nós correspondentes do Kubernetes.

Para confirmar que o nó afetado falhou, use journalctl semelhante a este:

[root@vm-lb-0--40b1a328a3448f5-112eaaafe1beedad ~]# journalctl -t kubeadm

A resposta será semelhante a este exemplo:

Dec 09 20:09:50 vm-lb-0--40b1a328a3448f5-112eaaafe1beedad kubeadm[3684235]: error: error execution phase kubelet-config: could not remove the CRI socket annotation from Node "vm-lb-0--40b1a328a3448f5-112eaaafe1beedad": nodes "vm-lb-0--40b1a328a3448f5-112eaaafe1beedad" not found

Neste exemplo, o nome do host do Linux informado na resposta journalctl não corresponde ao rótulo kubernetes.io/hostname do nó, confirmando que o upgrade é afetado por esse problema:

kubectl get nodes lb-0--40b1a328a3448f5-112eaaafe1beedad.lab.anthos \
  -ojsonpath='{.metadata.labels.kubernetes\.io\/hostname}'

A resposta:

lb-0--40b1a328a3448f5-112eaaafe1beedad.lab.anthos

Alternativa:

Para que o nó afetado conclua o upgrade, tente mudar temporariamente o nome do host para corresponder ao valor do rótulo kubernetes.io/hostname nos nós correspondentes do Kubernetes, semelhante ao seguinte:

[root@vm-lb-0--40b1a328a3448f5-112eaaafe1beedad ~]# hostname lb-0--40b1a328a3448f5-112eaaafe1beedad.lab.anthos
Rede 1.34.0

Quando você ativa o failover rápido do NAT de saída, o isolamento de um nó de gateway com kubectl cordon <NODE_NAME> inicia uma migração normal que mantém as conexões de saída atuais. No entanto, na versão 1.34.0 somente de software do Google Distributed Cloud, o recurso de migração gradual não funciona como esperado.

Se um administrador isolar um nó de gateway de saída ativo em um cluster da versão 1.34.0 que usa failover rápido, o isolamento vai se comportar como uma falha não planejada de nó e encerrar imediatamente todas as conexões com estado nesse nó.


Alternativa:

Não há solução alternativa para esse problema.
Rede 1.32.0

Os serviços ClusterIP podem ter conexões intermitentes ou com falha quando o tráfego é encaminhado para pods de back-end em nós diferentes. Essa falha de comunicação é causada por uma regressão no Cilium v1.15 que resultou na remoção das regras CILIUM_POST_nat de iptables. As regras CILIUM_POST_nat são necessárias para a conversão de endereços de rede de origem (SNAT, na sigla em inglês), e a remoção delas leva a um mascaramento não confiável pelo kube-proxy, o que resulta em falhas de comunicação do serviço ClusterIP.

Por exemplo, se você estiver fazendo upgrade de um cluster e a operação ficar paralisada, poderá ver mensagens de registro como a seguinte, que indica que o handshake TLS expirou enquanto o serviço ClusterIP tentava se conectar ao servidor da API no pool de nós np1:

      I0527 15:42:39.261368  372146 upgrade.go:994] Error trying to connect to api server: Get "https://10.200.0.108:443/apis/baremetal.cluster.gke.io/v1/namespaces/cluster-baremetal-test/nodepools/np1": net/http: TLS handshake timeout
      E0527 15:42:39.264789  372146 exec.go:207] command "/root/bmctl-upgrade upgrade cluster --kubeconfig /root/bmctl-workspace/baremetal-test/baremetal-test-kubeconfig --quiet --cluster baremetal-test --manifest-profile-env staging" times out

Esse problema foi corrigido na versão 1.32.100 e mais recentes.

Alternativa:

Se não for possível fazer upgrade para uma versão com a correção, recomendamos que você faça upgrade manual da imagem do Cilium para a versão v1.15.6-anthos1.32.50 ou mais recente. Essa atualização resolve o problema ao reintroduzir as regras CILIUM_POST_nat necessárias.

Para fazer upgrade da imagem do Cilium, siga estas etapas:

  1. Edite o DaemonSet anetd no namespace kube-system: 
    kubectl edit ds anetd -n kube-system
  2. Replace all occurrences of the Cilium image tag with version v1.15.6-anthos1.32.50 or a later version.

    Example old image:

    image: gcr.io/anthos-baremetal-staging/anthos-networking/cilium/cilium:v1.15.6-anthos1.32-gke.41@sha256:1940fccc...

    Exemplo de nova imagem:

    image: gcr.io/anthos-baremetal-staging/anthos-networking/cilium/cilium:v1.15.6-anthos1.32-gke.50
  3. Salve as mudanças e feche o editor.
Instalação, upgrades e atualizações 1,33

Ao tentar usar o comando bmctl configure projects para configurar a federação de identidade da carga de trabalho para um novo projeto Google Cloud , o comando falha com a seguinte mensagem de erro:

Error ((retry 1) error adding iam policy bindings: failed to add project binding: failed to set project "<>" iam policy: googleapi: Error 400: Identity Pool does not exist (projectID.svc.id.goog). Please check that you specified a valid resource name as returned in the `name` attribute in the configuration API., badRequest) ensuring iam policy binding: project-Id

Isso ocorre porque o pool de identidades de carga de trabalho padrão necessário chamado projectID.svc.id.goog não é provisionado automaticamente no novo projeto.

Alternativa:

Siga estas etapas para configurar a federação de identidade da carga de trabalho no seu projeto:

  1. Crie manualmente o pool de identidades da carga de trabalho padrão ausente: 
    gcloud iam workload-identity-pools create PROJECT_ID.svc.id.goog \
    --location=global \
    --project=PROJECT_ID

    Substitua PROJECT_ID pela ID do seu projeto.

  2. Na estação de trabalho do administrador, atualize a variável de ambiente GCP_ACCESS_TOKEN com um token de acesso recém-recuperado: 
    export GCP_ACCESS_TOKEN=$(gcloud auth application-default print-access-token)

    Por padrão, o token de acesso tem uma vida útil de 3.600 segundos (1 hora). Ao usar a autenticação de cluster da Identidade da carga de trabalho, o bmctl verifica o tempo de expiração do token. Se a expiração do token for em até 1.800 segundos (30 minutos), bmctl vai informar um erro e sair.

  3. Execute bmctl configure projects novamente.
Upgrades e atualizações, Logging e monitoramento 1.29, 1.30, 1.31, 1.32

O playbook do Ansible cal-update contém erros lógicos que fazem com que ele falhe ao tentar mudar a flag disableCloudAuditLogging. Isso impede a ativação ou desativação adequada dos registros de auditoria.

Quando disableCloudAuditLogging é alterado de true para false, não é possível ativar os registros de auditoria porque o script falha antes de aplicar a mudança de configuração a kube-apiserver. Quando disableCloudAuditLogging muda de false para true, os registros de auditoria podem ser desativados, mas o job cal-update falha continuamente, impedindo que o playbook alcance as verificações de integridade. A mensagem de erro observada é: 

The task includes an option with an undefined variable. The error was: 'dict object' has no attribute 'stdout_lines'

Alternativa:

Não há uma solução alternativa para esse problema. Faça upgrade do cluster para uma versão que tenha a correção. Ao fazer upgrade, siga estas etapas:

  1. Desative a geração de registros de auditoria definindo disableCloudAuditLogging como true.
  2. Quando o patch estiver disponível, faça upgrade do cluster para uma das seguintes versões de patch de lançamento secundário (ou mais recentes), que têm a correção:
    • 1.30.1200
    • 1.31.800
    • 1.32.400
  3. Para reativar os registros de auditoria do Cloud, defina disableCloudAuditLogging de volta para false.
Upgrades e atualizações 1.32+

Os upgrades para clusters de administrador de alta disponibilidade (HA) falham após uma operação de reparo

Em clusters de administrador de alta disponibilidade, o comando gkectl upgrade admin falha e fica travado quando você o executa depois do comando gkectl repair admin-master.

O comando gkectl repair admin-master adiciona uma anotação machine.onprem.gke.io/managed=false às máquinas reparadas. Essa anotação faz com que o controlador cluster-api fique preso em um estado de reconciliação quando você executa o comando gkectl upgrade admin. Os upgrades para clusters não HA incluem uma lógica de pivô que remove essa anotação, mas ela não está presente nos upgrades para clusters de alta disponibilidade.

Alternativa:

Remova manualmente a anotação machine.onprem.gke.io/managed dos recursos de máquina no cluster de administrador antes de iniciar o upgrade.
Upgrades, configuração 1.32.0 - 1.32.200

Os clusters configurados com um espelho de registro falham na verificação de simulação check_gcr_pass durante um upgrade para a versão 1.32.0 ou mais recente. Essa falha ocorre devido a uma mudança na forma como o recurso personalizado PreflightCheck é construído, omitindo as configurações de espelho de registro da especificação do cluster usada na verificação.

Esse problema foi descoberto durante testes internos em clusters com configurações de proxy e espelho de registro.

Alternativa:

Use uma das seguintes opções como solução alternativa para esse problema:

  • Use a flag --force ao acionar o upgrade.
  • Obtenha a configuração atual do cluster usando bmctl get config e use esse arquivo de configuração recém-gerado para acionar o upgrade.
Configuração, atualizações 1.15 a 1.30, 1.31.0 a 1.31.800, 1.32.0 a 1.32.300

Em versões específicas do cluster, os CronJobs de verificação de integridade periódica podem não atualizar as especificações quando houver mudanças na configuração do recurso do cluster. Essas falhas de atualização levam a verificações de integridade desatualizadas e possíveis falhas de jobs.

Esse problema foi corrigido nas versões 1.31.900, 1.32.400 e 1.33.0 e mais recentes do Google Distributed Cloud.

Alternativa:

Para as versões 1.30 e anteriores, siga estas etapas como solução alternativa:

  1. Desative as verificações de integridade periódicas.

    Isso exclui o recurso HealthCheck atual.

  2. Reative as verificações de integridade periódicas.

    Isso cria novos recursos HealthCheck, que consideram a configuração mais recente do cluster.
Rede 1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28, 1.29, 1.30, 1.31

O Keepalived é usado para mover o VIP do plano de controle de uma máquina para outra e alcançar alta disponibilidade. Quando o VIP do plano de controle é processado pelo balanceador de carga de camada 2 agrupado, é possível que failovers da instância do Keepalived causem intervalos breves (menos de um segundo) de tempo em que ARPs sem custo financeiro com endereços MAC diferentes são intercalados. A infraestrutura de rede de comutação pode interpretar esse intercalamento como anormal e negar outras mensagens ARP por períodos de até 30 minutos. As mensagens ARP bloqueadas podem resultar na indisponibilidade do VIP do plano de controle durante esse período.

O entrelaçamento de ARPs sem custo financeiro é causado pelas configurações do Keepalived usadas na versão 1.31 e anteriores. Especificamente, todos os nós foram configurados para usar a mesma prioridade. Mudanças na configuração do Keepalived na versão 1.32 resolvem esse problema configurando prioridades diferentes para cada instância do Keepalived e fornecendo uma configuração de cluster, controlPlane.loadBalancer.keepalivedVRRPGARPMasterRepeat, para reduzir o número de ARPs desnecessários.

Alternativa:

Para as versões 1.31 e anteriores, é possível reduzir o intercalamento dos ARPs sem custo financeiro editando diretamente o arquivo de configuração do Keepalived, /usr/local/etc/keepalived/keepalived.conf. Para cada um dos nós que executam o balanceador de carga do plano de controle, edite o arquivo de configuração para mudar as seguintes configurações:

  • priority: defina um valor priority distinto para cada nó. Os valores válidos estão entre 1 e 254.
  • weight: mude o valor de weight de -2 para -253 para garantir que um failover do Keepalived seja acionado quando uma verificação de integridade falhar.
Geração de registros e monitoramento 1.30, 1.31, 1.32, 1.33

Devido a um erro de definição interna, a métrica kubernetes.io/anthos/custom_resurce_watchers pode mostrar dados imprecisos. Se você for afetado por isso, poderá encontrar erros nos registros semelhantes a estes:

One or more TimeSeries could not be written: timeSeries[42]: Value type for metric kubernetes.io/anthos/custom_resurce_watchers must be INT64, but is DOUBLE.

Você pode ignorar esses erros com segurança. Essa métrica não é usada para alertas críticos do sistema, e os erros não afetam a função do seu projeto ou clusters.
Operação 1.30, 1.31, 1.32, 1.33

Se o diretório .manifests estiver ausente na estação de trabalho do administrador ao executar bmctl check cluster --snapshot, o comando vai falhar com um erro semelhante a este:

Error message: failing while capturing snapshot failed to parse cluster config
file
failed to get CRD file

Essa falha ocorre porque o comando bmctl check cluster --snapshot exige os arquivos de definição de recurso personalizado no diretório .manifests para validar a configuração do cluster. Esse diretório geralmente é criado durante a configuração do cluster. Se você excluir o diretório por engano ou executar bmctl de um local diferente, o comando não poderá continuar com a operação de snapshot.

Alternativas:

Para resolver esse problema, gere novamente o diretório .manifests manualmente usando um dos seguintes métodos:

  • Execute o comando bmctl check cluster: 
    bmctl check cluster --cluster CLUSTER_NAME \
    --kubeconfig ADMIN_KUBECONFIG

    Como parte das verificações iniciais, esse comando cria automaticamente o diretório .manifests no diretório de trabalho atual, independente de o comando ser concluído ou não.

  • No diretório que contém o arquivo de configuração do cluster atual, execute o comando bmctl create cluster: 
    bmctl create cluster --cluster TEST_CLUSTER

    Embora esse comando provavelmente resulte em um erro, como Não foi possível analisar o arquivo de configuração do cluster, o diretório .manifests ainda é criado no seu diretório de trabalho atual.

    O diretório temporário bmctl-workspace/TEST_CLUSTER gerado pode ser excluído com segurança depois.

Depois de realizar uma das soluções alternativas anteriores, tente executar o comando bmctl check cluster --snapshot novamente.
Instalação, upgrades e atualizações 1.32.0, 1.32.100

Se a instância do HAProxy não estiver disponível em um nó que hospeda o VIP do plano de controle, a configuração nopreempt na instância do Keepalived impedirá que o VIP do plano de controle seja movido para um nó com um HAProxy íntegro. Esse problema está relacionado a um recurso que configura automaticamente as prioridades do protocolo de redundância de roteador virtual (VRRP) do Keepalived, que é incompatível com a configuração nopreempt.


Alternativa:

Como solução alternativa, siga estas etapas para desativar o recurso Keepalived:

  1. Adicione a anotação preview.baremetal.cluster.gke.io/keepalived-different-priorities: "disable" ao cluster: 
    kubectl annotate --kubeconfig ADMIN_KUBECONFIG \
    -n CLUSTER_NAMESPACE \
    clusters.baremetal.cluster.gke.io/CLUSTER_NAME \
    preview.baremetal.cluster.gke.io/keepalived-different-priorities="disable"
  2. Remova nopreempt de /usr/local/etc/keepalived/keepalived.conf nos nós que executam o balanceador de carga do plano de controle.

    Dependendo da configuração do balanceador de carga, esses são os nós do plano de controle ou os nós em um pool de nós do balanceador de carga.

  3. Depois que o nopreempt for removido, os pods estáticos do keepalived precisarão ser reiniciados para selecionar as mudanças dos arquivos de configuração. Para fazer isso, em cada nó, use o seguinte comando para reiniciar os pods keepalived: 
    crictl rmp -f \
    $(crictl pods --namespace=kube-system --name='keepalived-*' -q)
Instalação, upgrades e atualizações 1.30, 1.31, 1.32.0

Os jobs de verificação de simulação e de integridade com falha podem deixar artefatos em pastas abm-tools-* com carimbo de data/hora em /usr/local/bin. Se você for afetado por isso, poderá ver várias pastas como esta: /usr/local/bin/abm-tools-preflight-20250410T114317. Falhas repetidas podem aumentar o uso do disco.

Alternativa

Remova essas pastas manualmente se encontrar esse problema: 

rm -rf  /usr/local/bin/abm-tools-*
Rede 1.28.0-1.28.200

Em clusters com o gateway NAT de saída ativado, se um balanceador de carga escolher back-ends que correspondam às regras de seleção de tráfego especificadas por um recurso personalizado EgressNATPolicy desatualizado, o tráfego do balanceador de carga será descartado.

Esse problema ocorre na criação e exclusão de pods que correspondem a uma política de saída. As políticas de saída não são limpas como deveriam quando os pods são excluídos, e as políticas de saída desatualizadas fazem com que os pods do LoadBalancer tentem enviar tráfego para uma conexão que não existe mais.

Esse problema foi corrigido nas versões 1.28.300 e mais recentes do Google Distributed Cloud.

Alternativa

Para limpar os recursos da política de saída de NAT, reinicie cada nó que hospeda um backend com falha.
Upgrades e atualizações, redefinição/exclusão 1.28

Ao substituir (remover, adicionar) um nó do plano de controle no Google Distributed Cloud 1.28, o novo nó pode não conseguir entrar no cluster. Isso acontece porque o processo responsável por configurar o novo nó (bm-system-machine-init) encontra o seguinte erro:

Failed to add etcd member: etcdserver: unhealthy cluster

Esse erro ocorre quando um nó de plano de controle antigo é removido e a associação dele ao etcd-events não é limpa corretamente, deixando para trás um membro desatualizado. O membro desatualizado impede que novos nós entrem no cluster etcd-events, fazendo com que o processo machine-init falhe e o novo nó seja recriado continuamente.

As consequências desse problema incluem:

  • Não foi possível iniciar o novo nó do plano de controle corretamente.
  • O cluster pode ficar preso em um estado RECONCILING.
  • O nó do plano de controle é excluído e recriado continuamente devido à falha machine-init.

Esse problema foi corrigido nas versões 1.29 e mais recentes.

Alternativa:

Se não for possível fazer upgrade para a versão 1.29, limpe manualmente o membro etcd-events com falha do cluster usando as instruções a seguir:

  1. Use o SSH para acessar um nó do plano de controle em funcionamento.
  2. Execute o seguinte comando: 
    ETCDCTL_API=3 etcdctl \
    --cacert=/etc/kubernetes/pki/etcd/ca.crt \
    --cert=/etc/kubernetes/pki/etcd/server.crt \
    --key=/etc/kubernetes/pki/etcd/server.key \
    --endpoints=localhost:2382 \
    member list
  3. Se a resposta incluir o nó removido na lista de membros, encontre o ID do membro na primeira coluna do nó e execute o seguinte comando: 
    ETCDCTL_API=3 etcdctl \
    --cacert=/etc/kubernetes/pki/etcd/ca.crt \
    --cert=/etc/kubernetes/pki/etcd/server.crt \
    --key=/etc/kubernetes/pki/etcd/server.key \
    --endpoints=localhost:2382 \
    member remove MEMBER_ID
     Substitua MEMBER_ID pelo ID do membro do nó removido.

O novo nó do plano de controle vai entrar automaticamente no cluster após alguns minutos.
Upgrades e atualizações 1.30.500-gke.126, 1.30.600-gke.68, 1.31.100-gke.136, 1.31.200-gke.58

Durante um upgrade do cluster, o processo pode falhar no primeiro nó do plano de controle com uma mensagem de erro no job do Ansible que indica que o arquivo super-admin.conf está faltando.

Esse problema ocorre porque o primeiro nó do plano de controle a ser atualizado pode não ser o primeiro nó provisionado durante a criação do cluster. O processo de upgrade pressupõe que o primeiro nó a ser atualizado é aquele que contém o arquivo super-admin.conf.

Esse problema foi corrigido nas seguintes atualizações de patch: 1.30.500-gke.127, 1.30.600-gke.69 e 1.31.200-gke.59

Alternativa:

Para atenuar o problema, siga esta etapa no nó com falha:

  • Copie o arquivo /etc/kubernetes/admin.conf para /etc/kubernetes/super-admin.conf: 
    cp /etc/kubernetes/admin.conf /etc/kubernetes/super-admin.conf

    O processo de upgrade é repetido automaticamente e deve ser concluído.
Upgrades e atualizações 1.29.0 - 1.29.1100, 1.30.0 - 1.30.400

Os pods com uma tolerância NoSchedule são considerados para remoção durante upgrades. No entanto, devido à tolerância NoSchedule, o controlador de implantação ou DaemonSet pode programar o pod novamente no nó em manutenção, o que pode atrasar o upgrade.

Para saber se você foi afetado por esse problema, siga estas etapas:

  1. Verifique os registros do pod anthos-cluster-operator para identificar os pods que estão impedindo a drenagem do nó.

    No snippet de registro de exemplo a seguir, o pod node-problem-detector-mgmt-ydhc2 ainda não foi drenado:

    nodepool_controller.go:720] controllers/NodePool "msg"="Pods yet to drain for 10.0.0.3 machine are 1 : [node-problem-detector-mgmt-ydhc2]" "nodepool"={"Namespace":"test-cluster","Name":"test-cluster"}
  2. Para cada pod que está impedindo o esgotamento do nó, execute o comando a seguir para verificar as tolerâncias: 
    kubectl get po POD_NAME -n kube-system \
    -o json | jq '.spec.tolerations'

    Substitua POD_NAME pelo nome do pod que está impedindo a drenagem do nó.

    Você vai encontrar uma das seguintes combinações:

    • Tolerância com efeito NoSchedule e operador Exists
    • Tolerância com efeito NoSchedule e chave "baremetal.cluster.gke.io/maintenance"
    • Tolerância com um efeito vazio e chave "baremetal.cluster.gke.io/maintenance"

    Por exemplo, a resposta pode ser assim:

    {
  "effect": "NoSchedule",
  "operator": "Exists"
},

Alternativa:

Para desbloquear a remoção do nó, faça o seguinte:

  • Adicione a tolerância baremetal.cluster.gke.io/maintenance:NoExecute aos pods que têm uma tolerância baremetal.cluster.gke.io/maintenance:Schedule e não exigem encerramento normal.
  • Remova as combinações de tolerância identificadas dos pods que precisam ser desalojados durante a drenagem de nós.
Rede 1.28, 1.29 e 1.30

As chamadas de rede para pods com o hostPort ativado falham e descartam pacotes se a solicitação for originada do mesmo nó em que o pod está em execução. Isso se aplica a todos os tipos de cluster e de nó. Os clusters criados sem kube-proxy não são afetados.

Verifique se você foi afetado por esse problema:

  1. Consiga os nomes dos pods anetd:

    Os pods anetd são responsáveis por controlar o tráfego de rede.

    kubectl get pods -l k8s-app=cilium -n kube-system
  2. Verifique o status dos pods anetd: 
    kubectl -n kube-system exec -it ANETD_POD_NAME -- cilium status --all-clusters

    Substitua ANETD_POD_NAME pelo nome de um dos pods anetd no cluster.

    Se a resposta incluir KubeProxyReplacement: Partial ..., você será afetado por esse problema.

Alternativa

Se você tiver um caso de uso para enviar solicitações a pods que usam hostPort do mesmo nó em que estão sendo executados, crie um cluster sem kube-proxy. Como alternativa, é possível configurar pods para usar um portmap plug-in de interface de rede de contêiner (CNI).
Geração de registros e monitoramento Identificado na versão 1.29.100. Também pode acontecer em outras versões.

E/S de disco alta devido à perda de conectividade de rede ou a uma conta de serviço inválida

Os pods stackdriver-log-forwarder podem perder a conectividade ou ter uma conta de serviço expirada, o que causa falha no envio desses registros para logging.googleapis.com, levando a um acúmulo de registros no buffer e resultando em alta E/S de disco. O agente do Cloud Logging (Fluent Bit), um daemonset chamado stackdriver-log-forwarder, usa um buffer baseado em sistema de arquivos com um limite de 4 GB. Quando está cheio, o agente tenta girar ou liberar o buffer, o que pode causar E/S alta.


O que verificar:

Verifique se as chaves da conta de serviço (SA) expiraram. Se for o caso, gire-os para resolver o problema.

Confirme a conta de serviço usada com o seguinte comando e valide-a no IAM:

kubectl get secret google-cloud-credentials -n CLUSTER_NAMESPACE -o jsonpath='{.data.credentials\.json}' | base64 --decode

Alternativa:

Aviso:a remoção do buffer resulta na perda permanente de todos os registros armazenados nele, incluindo registros de nós, pods e contêineres do Kubernetes.
Se o acúmulo de buffer for causado pela perda de conectividade de rede com o serviço de geração de registros do Google Cloud, esses registros serão perdidos permanentemente quando o buffer for excluído ou se ele estiver cheio e o agente não conseguir enviar os registros.

  1. Remova o pod daemonset stackdriver-log-forwarder do cluster adicionando um seletor de nós. Isso mantém o DaemonSet stackdriver-log-forwarder, mas o cancela dos nós:

    kubectl --kubeconfig KUBECONFIG -n kube-system \
    patch daemonset stackdriver-log-forwarder \
    -p '{"spec": {"template": {"spec": {"nodeSelector": {"non-existing": "true"}}}}}'

    Substitua KUBECONFIG pelo caminho para o arquivo kubeconfig do cluster de usuário.

    Verifique se os pods de stackdriver-log-forwarder foram excluídos antes de ir para a próxima etapa.

  2. Se isso estiver acontecendo com apenas um ou alguns nós:

    • Conecte-se ao nó usando SSH em que stackdriver-log-forwarder estava em execução (verifique se o stackdriver-log-forwarder não está mais em execução nesses nós).
    • No nó, exclua todos os arquivos de buffer usando rm -rf /var/log/fluent-bit-buffers/ e siga a etapa 6.

  3. Se houver muitos nós com esses arquivos e você quiser aplicar um script para limpar todos os nós com esses blocos de backlog, use os seguintes scripts:

    Implante um DaemonSet para limpar todos os dados em buffers em fluent-bit:

    kubectl --kubeconfig KUBECONFIG -n kube-system apply -f - << EOF
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluent-bit-cleanup
  namespace: kube-system
spec:
  selector:
    matchLabels:
      app: fluent-bit-cleanup
  template:
    metadata:
      labels:
        app: fluent-bit-cleanup
    spec:
      containers:
      - name: fluent-bit-cleanup
        image: debian:10-slim
        command: ["bash", "-c"]
        args:
        - |
          rm -rf /var/log/fluent-bit-buffers/
          echo "Fluent Bit local buffer is cleaned up."
          sleep 3600
        volumeMounts:
        - name: varlog
          mountPath: /var/log
        securityContext:
          privileged: true
      tolerations:
      - key: "CriticalAddonsOnly"
        operator: "Exists"
      - key: node-role.kubernetes.io/master
        effect: NoSchedule
      - key: node-role.gke.io/observability
        effect: NoSchedule
      volumes:
      - name: varlog
        hostPath:
          path: /var/log
EOF

  4. Verifique se o DaemonSet limpou todos os nós. A saída dos dois comandos a seguir precisa ser igual ao número de nós no cluster:

    kubectl --kubeconfig KUBECONFIG logs \
    -n kube-system -l app=fluent-bit-cleanup | grep "cleaned up" | wc -l
kubectl --kubeconfig KUBECONFIG \
    -n kube-system get pods -l app=fluent-bit-cleanup --no-headers | wc -l

  5. Exclua o DaemonSet de limpeza.

    kubectl --kubeconfig KUBECONFIG -n kube-system delete ds \
    fluent-bit-cleanup

  6. Reinicie os pods stackdriver-log-forwarder:

    kubectl --kubeconfig KUBECONFIG \
    -n kube-system patch daemonset stackdriver-log-forwarder --type json \
    -p='[{"op": "remove", "path": "/spec/template/spec/nodeSelector/non-existing"}]'
Upgrades e atualizações, operação 1.28, 1.29, 1.30.0 e 1.30.100

Os pods podem ficar presos durante a finalização quando os nós estão sendo reduzidos. Pods presos podem bloquear operações, como upgrades, que esgotam os nós. Os pods podem ficar presos quando o contêiner aparece como em execução, mesmo que o processo principal do contêiner já tenha sido encerrado. Nesse caso, o comando crictl stop também não interrompe o contêiner.

Para confirmar se você foi afetado pelo problema, siga estas etapas:

  1. Verifique se o cluster tem pods presos com o status Terminating: 
    kubectl get pods --kubeconfig CLUSTER_KUBECONFIG -A \
    -o wide | grep Terminating
  2. Para pods presos em encerramento, use kubectl describe para verificar eventos: 
    kubectl describe pod POD_NAME \
    --kubeconfig CLUSTER_KUBECONFIG \
    -n NAMESPACE

    Se você encontrar avisos como este com Unhealthy e FailedKillPod como motivos, isso significa que você está sendo afetado por esse problema:

    Events:
  Type     Reason         Age                      From     Message
  ----     ------         ----                     ----     -------
  Warning  FailedKillPod  19m (x592 over 46h)      kubelet  error killing pod: [failed to "KillContainer" for "dnsmasq" with KillContainerError: "rpc error: code = DeadlineExceeded desc = context deadline exceeded", failed to "KillPodSandbox" for "0843f660-461e-458e-8f07-efe052deae23" with KillPodSandboxError: "rpc error: code = DeadlineExceeded desc = context deadline exceeded"]
  Warning  Unhealthy      4m37s (x16870 over 46h)  kubelet  (combined from similar events): Readiness probe errored: rpc error: code = Unknown desc = failed to exec in container: failed to start exec "c1ea4ffe7e4f1bacaab4f312bcc45c879785f6e22e7dc2d94abc3a019e20e1a9": OCI runtime exec failed: exec failed: cannot exec in a stopped container: unknown

Esse problema é causado por um problema upstream do containerd, que foi corrigido nas versões 1.28.1000, 1.29.600, 1.30.200, 1.31 e mais recentes do Google Distributed Cloud.

Alternativa

Para desbloquear a operação do cluster:

  1. Forçar a exclusão de pods presos: 
    kubectl delete pod POD_NAME -n POD_NAMESPACE --force
  2. Quando os pods forem reiniciados, tente fazer a operação do cluster novamente.
Upgrades e atualizações, operação 1.28, 1.29 e 1.30.0-1.30.100

Os pods podem ficar presos durante a finalização quando os nós estão sendo reduzidos. Pods presos podem bloquear operações de cluster, como upgrades, que drenam nós. Os pods podem ficar presos quando o processo runc init é congelado, o que impede que o containerd exclua o cgroups associado a esse pod.

Para confirmar se você foi afetado pelo problema, siga estas etapas:

  1. Verifique se o cluster tem pods presos com o status Terminating: 
    kubectl get pods --kubeconfig CLUSTER_KUBECONFIG -A \
    -o wide | grep Terminating
  2. Verifique os registros do kubelet nos nós que têm pods presos em encerramento:

    O comando a seguir retorna entradas de registro que contêm o texto Failed to remove cgroup.

    journalctl -u kubelet --no-pager -f | grep "Failed to remove cgroup"

    Se a resposta contiver avisos como este, você será afetado por esse problema:

    May 22 23:08:00 control-1--f1c6edcdeaa9e08-e387c07294a9d3ab.lab.anthos kubelet[3751]: time="2024-05-22T23:08:00Z" level=warning msg="Failed to remove cgroup (will retry)" error="rmdir /sys/fs/cgroup/freezer/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-podea876418628af89ec2a74ea73d4a6023.slice/cri-containerd-d06aacfec2b399fcf05a187883341db1207c04be3698ec058214a6392cfc6148.scope: device or resource busy"
...
May 22 23:09:04 control-1 kubelet[3751]: time="2024-05-22T23:09:04Z" level=warning msg="Failed to remove cgroup (will retry)" error="rmdir /sys/fs/cgroup/net_cls,net_prio/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-podea876418628af89ec2a74ea73d4a6023.slice/cri-containerd-d06aacfec2b399fcf05a187883341db1207c04be3698ec058214a6392cfc6148.scope: device or resource busy"
...

Alternativa

Para descongelar o processo runc init e desbloquear as operações do cluster:

  1. Usando o caminho cgroup dos registros do kubelet, verifique se o cgroup está congelado conferindo o conteúdo do arquivo freezer.state: 
    cat CGROUP_PATH_FROM_KUBELET_LOGS/freezer.state

    O conteúdo do freezer.state indica o estado do cgroup.

    Com um caminho das entradas de registro de exemplo anteriores, o comando seria assim:

    cat /sys/fs/cgroup/freezer/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-podea876418628af89ec2a74ea73d4a6023.slice/cri-containerd-d06aacfec2b399fcf05a187883341db1207c04be3698ec058214a6392cfc6148.scope/freezer.state
  2. Descongele os cgroups que estão no estado FREEZING ou FROZEN: 
    echo "THAWED" > CGROUP_PATH_FROM_KUBELET_LOGS/freezer.state

    Quando os cgroups forem THAWED, os processos runc init correspondentes serão encerrados automaticamente e os cgroups serão removidos automaticamente. Isso evita que outros avisos de Failed to remove cgroup apareçam nos registros do kubelet. Os pods presos no estado Terminating também são removidos automaticamente pouco tempo depois da limpeza.

  3. Depois que os cgroups congelados forem limpos e os pods presos forem removidos, tente fazer a operação do cluster novamente.
Configuração, rede 1.28.0 a 1.28.1000, 1.29.0 a 1.29.500 e 1.30.0 a 1.30.200

Nas versões identificadas do Google Distributed Cloud, o kubelet pode não atualizar os contratos de locação de nós por mais de 40 segundos, resultando em eventos NodeNotReady.

O problema é intermitente e ocorre aproximadamente a cada sete dias. O failover do VIP do plano de controle pode ocorrer por volta da hora dos eventos NodeNotReady.

Esse problema foi corrigido nas versões 1.28.1100, 1.29.600, 1.30.300 e mais recentes.

Alternativa:

Para atenuar o problema, configure o kubelet seguindo estas etapas:

  1. Crie /etc/default/kubelet e adicione as seguintes variáveis de ambiente:
    2. HTTP2_READ_IDLE_TIMEOUT_SECONDS=10
HTTP2_PING_TIMEOUT_SECONDS=5
  2. Reinicie o kubelet: 
    systemctl restart kubelet
  3. Receba o novo ID do processo (PID) do kubelet: 
    pgrep kubelet
  4. Verifique se as variáveis de ambiente entram em vigor após a reinicialização do kubelet no nó: 
    cat /proc/KUBELET_PID/environ | tr '\0' '\n' | grep -e HTTP2_READ_IDLE_TIMEOUT_SECONDS -e HTTP2_PING_TIMEOUT_SECONDS

    Substitua KUBELET_PID pela saída do comando na etapa anterior.

    A resposta ao comando cat deve listar as duas variáveis de ambiente adicionadas nas últimas linhas.
Atualizações 1,30

Quando você cria um cluster de usuário usando o comando bmctl create cluster e transmite o campo cloudOperationsServiceAccountKeyPath no cabeçalho, o campo spec.clusterOperations.serviceAccountSecret é adicionado ao recurso de cluster criado. Esse campo não está no arquivo de configuração do cluster e é imutável. O comando bmctl update cluster não preenche esse campo do cabeçalho. Portanto, as tentativas de atualizar o cluster com o comando bmctl update cluster e o arquivo de configuração original do cluster falham com o seguinte erro: 

[2025-01-15 16:38:46+0000] Failed to calculate diff:
---
E000090: Unable to calculate diff

An error occurred while calculating diff between live configuration and cluster.yaml file



Wrapped error: error in dryRunClient.Update for {map[apiVersion:baremetal.cluster.gke.io/v1 kind:Cluster metadata:map[annotations:map[baremetal.cluster.gke.io/enable-kubelet-read-only-port:false baremetal.cluster.gke.io/maintenance-mode-deadline-seconds:180 preview.baremetal.cluster.gke.io/add-on-configuration:enable] creationTimestamp: name:user-test namespace:cluster-user-test resourceVersion:1171702] spec:map[anthosBareMetalVersion:0.0.0-gke.0 bypassPreflightCheck:false clusterNetwork:map[multipleNetworkInterfaces:false pods:map[cidrBlocks:[10.240.0.0/13]] services:map[cidrBlocks:[172.26.0.0/16]]] clusterOperations:map[location:us-west1 projectID:baremetal-test] controlPlane:map[nodePoolSpec:map[nodes:[map[address:10.200.0.15]]]] gkeConnect:map[projectID:baremetal-test] loadBalancer:map[addressPools:[map[addresses:[10.200.0.20/32 10.200.0.21/32 10.200.0.22/32 10.200.0.23/32 10.200.0.24/32 fd00:1::15/128 fd00:1::16/128 fd00:1::17/128 fd00:1::18/128] name:pool1]] mode:bundled ports:map[controlPlaneLBPort:443] vips:map[controlPlaneVIP:10.200.0.19 ingressVIP:10.200.0.20]] nodeAccess:map[loginUser:root] nodeConfig:map[podDensity:map[maxPodsPerNode:250]] profile:default storage:map[lvpNodeMounts:map[path:/mnt/localpv-disk storageClassName:local-disks] lvpShare:map[numPVUnderSharedPath:5 path:/mnt/localpv-share storageClassName:local-shared]] type:user] status:map[]]}: admission webhook "vcluster.kb.io" denied the request: Cluster.baremetal.cluster.gke.io "user-test" is invalid: spec: Forbidden: Fields should be immutable.
(A in old)
(B in new)

{"clusterNetwork":{"multipleNetworkInterfaces":false,"services":{"cidrBlocks":["172.26.0.0/16"]},"pods":{"cidrBlocks":["10.240.0.0/13"]},"bundledIngress":true},"controlPlane":{"nodePoolSpec":{"nodes":[{"address":"10.200.0.15"}],"operatingSystem":"linux"}},"credentials":{"sshKeySecret":{"name":"ssh-key","namespace":"cluster-user-test"},"imagePullSecret":{"name":"private-registry-creds","namespace":"cluster-user-test"}},"loadBalancer":{"mode":"bundled","ports":{"controlPlaneLBPort":443},"vips":{"controlPlaneVIP":"10.200.0.19","ingressVIP":"10.200.0.20"},"addressPools":[{"name":"pool1","addresses":["10.200.0.20/32","10.200.0.21/32","10.200.0.22/32","10.200.0.23/32","10.200.0.24/32","fd00:1::15/128","fd00:1::16/128","fd00:1::17/128","fd00:1::18/128"]}]},"gkeConnect":{"projectID":"baremetal-test","location":"global","connectServiceAccountSecret":{"name":"gke-connect","namespace":"cluster-user-test"},"registerServiceAccountSecret":{"name":"gke-register","namespace":"cluster-user-test"}},"storage":{"lvpShare":{"path":"/mnt/localpv-share","storageClassName":"local-shared","numPVUnderSharedPath":5},"lvpNodeMounts":{"path":"/mnt/localpv-disk","storageClassName":"local-disks"}},"clusterOperations":{"projectID":"baremetal-test","location":"us-west1"

A: ,"serviceAccountSecret":{"name":"google-cloud-credentials","namespace":"cluster-user-test"}},"type":"user","nodeAccess":{"loginUser":"root"},"anthosBareMetalVersion":"0.0.0-gke.0","bypassPreflightCheck":false,"nodeConfig":{"podDensity":{"maxPodsPerNode":250},"containerRuntime":"containerd"},"profile":"default"}

B: },"type":"user","nodeAccess":{"loginUser":"root"},"anthosBareMetalVersion":"0.0.0-gke.0","bypassPreflightCheck":false,"nodeConfig":{"podDensity":{"maxPodsPerNode":250},"containerRuntime":"containerd"},"profile":"default"}



For more information, see https://cloud.google.com/distributed-cloud/docs/reference/gke-error-ref#E000090

Esse problema só ocorre quando você usa uma versão 1.30.x do bmctl para fazer atualizações.

Alternativa:

Como solução alternativa, é possível receber a configuração do cluster do recurso Cluster real antes de fazer as atualizações:

  1. Recupere o arquivo de configuração do cluster de usuário com base no recurso Cluster implantado: 
    bmctl get config --cluster CLUSTER_NAME \
    --kubeconfig ADMIN_KUBECONFIG_PATH

    O recurso personalizado recuperado é gravado em um arquivo YAML chamado: bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME-TIMESTAMP.yaml. Esse novo arquivo de configuração inclui spec.clusterOperations.serviceAccountSecret, que é necessário para o funcionamento do comando de atualização. O TIMESTAMP no nome do arquivo indica a data e a hora em que ele foi criado.

  2. Substitua o arquivo de configuração do cluster atual pelo arquivo recuperado. Salve o backup do arquivo atual.
  3. Edite o novo arquivo de configuração do cluster e use bmctl update para atualizar o cluster de usuário: 
    bmctl update cluster --cluster CLUSTER_NAME \
    --kubeconfig ADMIN_KUBECONFIG_PATH
Upgrades e atualizações, segurança 1.29, 1.30 e 1.31

A rotação de certificados do Kubelet falha quando kubelet-client-current.pem e kubelet-server-current.pem são arquivos reais, em vez de links simbólicos (symlinks).

Esse problema pode ocorrer depois de usar bmctl restore para restaurar um cluster de um backup.

Alternativa:

Se você for afetado por esse problema, use as seguintes etapas como uma solução alternativa:
  1. Faça backup dos arquivos de certificado atuais: 
    mkdir -p ~/kubelet-backup/
cp -r /var/lib/kubelet/pki/ ~/kubelet-backup/
  2. Se quiser, exclua os arquivos de certificado acumulados: 
    ls | grep -E "^kubelet-server-20*" | xargs rm -rf
ls | grep -E "^kubelet-client-20*" | xargs rm -rf
  3. Renomeie os arquivos kubelet-client-current.pem e kubelet-server-current.pem:

    Usar um carimbo de data/hora é um esquema de renomeação comum.

    datetime=$(date +%Y-%m-%d-%H-%M-%S)
mv kubelet-server-current.pem kubelet-server-${datetime}.pem
mv kubelet-client-current.pem kubelet-client-${datetime}.pem
  4. Na mesma sessão do comando anterior, crie links simbólicos que apontem para os certificados válidos mais recentes (renomeados): 
    ln -s kubelet-server-${datetime}.pem kubelet-server-current.pem
ln -s kubelet-client-${datetime}.pem kubelet-client-current.pem
  5. Defina as permissões como 777 para os links simbólicos: 
    chmod 777 kubelet-server-current.pem
chmod 777 kubelet-client-current.pem
  6. Se os certificados forem substituídos, exclua o diretório de backup: 
    rm -rf ~/kubelet-backup/
Instalação, upgrades e atualizações 1.31

Na versão 1.31 do Google Distributed Cloud, você pode receber erros ao tentar criar recursos personalizados, como clusters (todos os tipos) e cargas de trabalho. O problema é causado por uma mudança incompatível introduzida no Kubernetes 1.31 que impede que o campo caBundle em uma definição de recurso personalizada faça a transição de um estado válido para um inválido. Para mais informações sobre a mudança, consulte o registro de alterações do Kubernetes 1.31.

Antes do Kubernetes 1.31, o campo caBundle era geralmente definido com um valor improvisado de \n, porque em versões anteriores do Kubernetes o servidor da API não permitia conteúdo vazio do pacote de CA. Usar \n era uma solução alternativa razoável para evitar confusão, já que o cert-manager geralmente atualiza o caBundle mais tarde.

Se o caBundle tiver sido corrigido uma vez de um estado inválido para um válido, não haverá problemas. No entanto, se a definição de recurso personalizado for reconciliada de volta para \n (ou outro valor inválido), você poderá encontrar o seguinte erro:

...Invalid value: []byte{0x5c, 0x6e}: unable to load root certificates: unable to parse bytes as PEM block]

Alternativa

Se você tiver uma definição de recurso personalizada em que caBundle está definido como um valor inválido, remova o campo caBundle por completo. Isso deve resolver o problema.
Instalação, upgrades e atualizações 1.28, 1.29 e 1.30

Em um upgrade de cluster, cada nó é esvaziado e atualizado. Nas versões 1.28 e mais recentes, o Google Distributed Cloud mudou de drenagem de nós baseada em taint para drenagem baseada em remoção. Além disso, para resolver as interdependências de pods, a remoção baseada em despejo segue uma ordem de remoção em várias etapas. Em cada estágio de drenagem, os pods têm um período de carência de 20 minutos para serem encerrados, enquanto a drenagem anterior baseada em taint tinha um único tempo limite de 20 minutos. Se cada estágio exigir os 20 minutos completos para desalojar todos os pods, o tempo para drenar um nó poderá ser significativamente maior do que a drenagem baseada em taint anterior. Por sua vez, o aumento do tempo de drenagem de nós pode aumentar significativamente o tempo necessário para concluir um upgrade de cluster ou colocar um cluster no modo de manutenção.

Há também um problema upstream do Kubernetes (link em inglês) que afeta a lógica de tempo limite para o esgotamento baseado em remoção. Esse problema também pode aumentar os tempos de drenagem de nós.

Alternativa:

Como solução alternativa, você pode desativar a drenagem de nós baseada em remoção. Isso volta para o esgotamento baseado em taint. Não recomendamos o esgotamento baseado em taint, porque ele não respeita os PodDisruptionBudgets (PDBs), o que pode causar interrupções no serviço.
Instalação, upgrades e atualizações 1.16, 1.28 e 1.29

A reconciliação de cluster é uma fase padrão para a maioria das operações de cluster, incluindo criação e upgrades. Durante a reconciliação do cluster, o controlador de cluster do Google Distributed Cloud aciona uma verificação de simulação. Se essa verificação de simulação falhar, a reconciliação adicional do cluster será bloqueada. Como resultado, as operações de cluster que incluem o ajuste de contas do cluster também são bloqueadas.

Essa verificação de simulação não é executada periodicamente, apenas como parte da reconciliação do cluster. Portanto, mesmo que você corrija o problema que causou a falha inicial de simulação e as verificações de simulação sob demanda sejam executadas com sucesso, a reconciliação do cluster ainda será bloqueada devido a essa verificação de simulação com falha desatualizada.

Se você tiver uma instalação ou um upgrade de cluster travado, siga estas etapas para verificar se você está sendo afetado por esse problema:

  1. Verifique os registros do pod anthos-cluster-operator para entradas como estas: 
    "msg"="Preflight check not ready. Won't reconcile"
  2. Verifique se a verificação de simulação acionada pelo controlador do cluster está em estado de falha: 
    kubectl describe preflightcheck PREFLIGHT_CHECK_NAME \
    -n CLUSTER_NAMESPACE \
    --kubeconfig=ADMIN_KUBECONFIG

    Substitua:

    • PREFLIGHT_CHECK_NAME: o nome da verificação prévia a ser excluída. Nesse caso, o nome é igual ao nome do cluster.
    • CLUSTER_NAMESPACE: o namespace do cluster em que a verificação prévia falhou.
    • ADMIN_KUBECONFIG: o caminho do arquivo kubeconfig do cluster de administrador.

    Se a verificação de simulação falhar (Status.Pass é false), provavelmente você será afetado por esse problema.

Esse problema foi corrigido nas versões 1.30 e posteriores.

Alternativa

Para desbloquear as operações do cluster, exclua manualmente a verificação de simulação com falha do cluster de administrador:

kubectl delete preflightcheck PREFLIGHT_CHECK_NAME \
    -n CLUSTER_NAMESPACE \
    --kubeconfig=ADMIN_KUBECONFIG

Depois que a verificação de simulação com falha desatualizada for excluída, o controlador do cluster poderá criar uma nova verificação de simulação.
Instalação, upgrades e atualizações 1.30.100, 1.30.200 e 1.30.300

A criação ou o upgrade de clusters de usuário para as versões 1.30.100, 1.30.200 ou 1.30.300 pode falhar. Esse problema se aplica apenas quando kubectl ou um cliente da API GKE On-Prem (o console Google Cloud , a CLI gcloud ou o Terraform) é usado para operações de criação e upgrade do cluster de usuário.

Nessa situação, a operação de criação do cluster de usuário fica presa no estado Provisioning, e um upgrade do cluster de usuário fica preso no estado Reconciling.

Para verificar se um cluster foi afetado, siga estas etapas:

  1. Consiga o recurso do cluster: 
    kubectl get cluster CLUSTER_NAME -n USER_CLUSTER_NAMESPACE \
    --kubeconfig ADMIN_KUBECONFIG

    Substitua:

    • CLUSTER_NAME: o nome do cluster de usuário travado.
    • USER_CLUSTER_NAMESPACE: o nome do namespace do cluster de usuário.
    • ADMIN_KUBECONFIG: o caminho do arquivo kubeconfig do cluster gerenciado.

    Se o valor CLUSTER STATE for Provisioning ou Reconciling, talvez você esteja enfrentando esse problema. O exemplo de resposta a seguir é um indicador de que um upgrade está travado:

    NAME            ABM VERSION      DESIRED ABM VERSION  CLUSTER STATE
some-cluster    1.30.0-gke.1930  1.30.100-gke.96      Reconciling

    As versões incompatíveis também indicam que o upgrade do cluster não foi concluído.

  2. Encontre o nome completo do pod anthos-cluster-operator: 
    kubectl get pods -n kube-system -o=name \
    -l baremetal.cluster.gke.io/lifecycle-controller-component=true \
    --kubeconfig ADMIN_KUBECONFIG

    Como mostrado no exemplo a seguir, a saída é uma lista de pods que inclui o pod anthos-cluster-operator:

    pod/anthos-cluster-operator-1.30.100-gke.96-d96cf6765-lqbsg
pod/cap-controller-manager-1.30.100-gke.96-fcb5b5797-xzmb7
  3. Transmita os registros do pod anthos-cluster-operator para uma mensagem repetida, indicando que o cluster está preso no provisionamento ou na reconciliação: 
    kubectl logs POD_NAME -n kube-system -f --since=15s \
    --kubeconfig ADMIN_KUBECONFIG | \
    grep "Waiting for configMapForwarder to forward kube-system/metadata-image-digests to the cluster namespace, requeuing"

    Substitua POD_NAME pelo nome completo do pod anthos-cluster-operator da etapa anterior.

    Enquanto o comando é executado, observe um fluxo contínuo de linhas de registro correspondentes, o que indica que a operação do cluster está travada. A saída de exemplo a seguir é semelhante ao que você vê quando um cluster fica preso na reconciliação:

    ...
I1107 17:06:32.528471       1 reconciler.go:1475]  "msg"="Waiting for configMapForwarder to forward kube-system/metadata-image-digests to the cluster namespace, requeuing" "Cluster"={"name":"user-t05db3f0761d4061-cluster","namespace":"cluster-user-t05db3f0761d4061-cluster"} "controller"="cluster" "controllerGroup"="baremetal.cluster.gke.io" "controllerKind"="Cluster" "name"="user-t05db3f0761d4061-cluster" "namespace"="cluster-user-t05db3f0761d4061-cluster" "reconcileID"="a09c70a6-059f-4e81-b6b2-aaf19fd5f926"
I1107 17:06:37.575174       1 reconciler.go:1475]  "msg"="Waiting for configMapForwarder to forward kube-system/metadata-image-digests to the cluster namespace, requeuing" "Cluster"={"name":"user-t05db3f0761d4061-cluster","namespace":"cluster-user-t05db3f0761d4061-cluster"} "controller"="cluster" "controllerGroup"="baremetal.cluster.gke.io" "controllerKind"="Cluster" "name"="user-t05db3f0761d4061-cluster" "namespace"="cluster-user-t05db3f0761d4061-cluster" "reconcileID"="e1906c8a-cee0-43fd-ad78-88d106d4d30a""Name":"user-test-v2"} "err"="1 error occurred:\n\t* failed to construct the job: ConfigMap \"metadata-image-digests\" not found\n\n"
...

    Pressione Control+C para interromper o streaming dos registros.

  4. Verifique se o ConfigMapForwarder está parado: 
    kubectl get configmapforwarder metadata-image-digests-in-cluster \
    -n USER_CLUSTER_NAMESPACE \
    -o jsonpath='{range .status.conditions[?(@.type=="Ready")]}Reason: {.reason}{"\n"}Message: {.message}{"\n"}{end}' \
    --kubeconfig ADMIN_KUBECONFIG

    A resposta contém motivos e mensagens do recurso ConfigMapForwarder. Quando o ConfigMapForwarder estiver parado, você verá uma saída como esta:

    Reason: Stalled
Message: cannot forward configmap kube-system/metadata-image-digests without "baremetal.cluster.gke.io/mark-source" annotation
  5. Confirme se o ConfigMap metadata-image-digests não está presente no namespace do cluster de usuário: 
    kubectl get configmaps metadata-image-digests \
    -n USER_CLUSTER_NAMESPACE \
    --kubeconfig ADMIN_KUBECONFIG

    A resposta será parecida com esta:

    Error from server (NotFound): configmaps "metadata-image-digests" not found

Alternativa

Como solução alternativa, atualize manualmente o ConfigMap para adicionar a anotação ausente:

  1. Adicione a anotação ausente ao ConfigMap: 
    kubectl annotate configmap metadata-image-digests \
    -n kube-system "baremetal.cluster.gke.io/mark-source"="true" \
    --kubeconfig ADMIN_KUBECONFIG

    Quando ele é anotado corretamente, o ConfigMap metadata-image-digests é criado automaticamente no namespace do cluster de usuário.

  2. Confirme se o ConfigMap foi criado automaticamente no namespace do cluster de usuário: 
    kubectl get configmaps metadata-image-digests \
    -n USER_CLUSTER_NAMESPACE \
    --kubeconfig ADMIN_KUBECONFIG

    Se o ConfigMap for criado, a resposta do comando será semelhante a esta:

    NAME                     DATA   AGE
metadata-image-digests   0      7s

Com a correção e a verificação acima, o operador do cluster será desbloqueado e as operações do cluster vão continuar normalmente.
Operação, redefinição/exclusão 1.30.0 - 1.30.300, 1.29.0 - 1.29.700, 1.28.0 - 1.28.1100

Ao executar bmctl restore --control-plane-node como um usuário não raiz, um problema de chown ocorre ao copiar arquivos do nó do plano de controle para a máquina da estação de trabalho.

Alternativa:

Execute o comando bmctl restore --control-plane-node com sudo para usuários não raiz.
Upgrades 1.30.0-gke.1930

Durante um upgrade, o job upgrade-health-check pode permanecer em um estado ativo devido à falta da imagem pause:3.9.

Esse problema não afeta o sucesso do upgrade.

Alternativa:

Exclua manualmente o job upgrade-health-check com o seguinte comando:

    kubectl delete job upgrade-health-check-JOB_ID --cascade=true
Sistema operacional 1.28, 1.29, 1.30

Downloads lentos em contêineres no RHEL 9.2

Downloads de artefatos com tamanhos que excedem o limite do cgroup memory.max podem ser extremamente lentos. Esse problema é causado por um bug no kernel do Linux para Red Hat Enterprise Linux (RHEL) 9.2. Os kernels com cgroup v2 ativado são afetados. O problema foi corrigido nas versões do kernel 5.14.0-284.40.1.el_9.2 e mais recentes.

Alternativa:

Para os pods afetados, aumente as configurações de limite de memória dos contêineres (spec.containers[].resources.limits.memory) para que os limites sejam maiores que o tamanho dos artefatos baixados.
Upgrades 1.28 a 1.29.200

Durante um upgrade do cluster bare metal, ele pode falhar com uma mensagem de erro indicando que há um conflito na definição de recurso personalizada networks.networking.gke.io. Especificamente, o erro informa que v1alpha1 não está presente em spec.versions.

Esse problema ocorre porque a versão v1alpha1 da definição de recurso personalizada não foi migrada para v1 durante o processo de upgrade.

Alternativa:

Faça patch nos clusters afetados com os seguintes comandos:

kubectl patch customresourcedefinitions/networkinterfaces.networking.gke.io \
    --subresource status --type json \
    --patch='[{ "op": "replace", "path": "/status/storedVersions", "value": ["v1"]}]'
kubectl patch customresourcedefinitions/networks.networking.gke.io \
    --subresource status --type json \
    --patch='[{ "op": "replace", "path": "/status/storedVersions", "value": ["v1"]}]'
Instalação, upgrades e atualizações 1.28.0 para 1.28.600 e 1.29.0 para 1.29.200

Durante a instalação ou upgrade do cluster, a simulação da máquina verifica relacionadas às configurações do kernel do fs.inotify podem falhar. Se você estiver afetada por esse problema, o registro de verificação de simulação da máquina contém um erro como estes: 

Minimum kernel setting required for fs.inotify.max_user_instances is 8192. Current fs.inotify.max_user_instances value is 128. Please run "echo "fs.inotify.max_user_instances=8192" | sudo tee --append /etc/sysctl.conf" to set the correct value.

Esse problema ocorre porque fs.inotify max_user_instances e Os valores max_user_watches são lidos incorretamente no controle e hosts de inicialização, em vez das máquinas de nós pretendidas.

Alternativa:
Para contornar esse problema, ajuste o fs.inotify.max_user_instances. e fs.inotify.max_user_watches aos valores recomendados na todas as máquinas de plano de controle e bootstrap: 

echo fs.inotify.max_user_watches=524288 | sudo tee --append /etc/sysctl.conf
echo fs.inotify.max_user_instances=8192 | sudo tee --append /etc/sysctl.conf
sudo sysctl -p

Após a conclusão da instalação ou atualização, esses valores podem ser e pode ser revertida, se necessário.

Upgrades 1.28.0 - 1.28.500

Quando você usa bmctl para fazer upgrade de um cluster, falhar com um erro GCP reachability check failed mesmo que o o URL de destino pode ser acessado na estação de trabalho do administrador. Esse problema é causado por um bug nas versões 1.28.0 a 1.28.500 do bmctl.

Alternativa:

Antes de executar o comando bmctl upgrade, defina o variável de ambiente GOOGLE_APPLICATION_CREDENTIALS para apontar um arquivo de chave da conta de serviço válido:

export GOOGLE_APPLICATION_CREDENTIALS=JSON_KEY_PATH
bmctl upgrade cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG

Definir o Application Default Credentials (ADC) dessa forma garante que bmctl tem as credenciais necessárias para acessar a API do Google endpoint de API.
Configuração, instalação, upgrades e atualizações, rede, segurança 1.15, 1.16, 1.28, 1.29

A instalação e o upgrade do cluster falham quando ipam-controller-manager é obrigatório, e seu cluster é com o Red Hat Enterprise Linux (RHEL) 8.9 ou posterior (dependendo da alterações upstream do RHEL) com o SELinux em execução no modo de aplicação. Esta se aplica especificamente quando a versão container-selinux é superior a 2.225.0.

Seu cluster exige ipam-controller-manager em qualquer um as seguintes situações:

  • O cluster está configurado para rede de pilha dupla IPv4/IPv6
  • Seu cluster está configurado com clusterNetwork.flatIPv4 Definir como true
  • Seu cluster é configurado com preview.baremetal.cluster.gke.io/multi-networking: enable anotação

A instalação e o upgrade do cluster não funcionam quando o O app ipam-controller-manager está instalado.

Alternativa

Definir o contexto padrão para o diretório /etc/kubernetes em cada nó do plano de controle para o tipo etc_t: 

semanage fcontext /etc/kubernetes --add -t etc_t
semanage fcontext /etc/kubernetes/controller-manager.conf --add -t etc_t
restorecon -R /etc/kubernetes

Esses comandos revertem a mudança de container-selinux no /etc/kubernetes.

Depois que o cluster for atualizado para uma versão com a correção, desfaça o mudança anterior de contexto do arquivo em cada nó do plano de controle: 

semanage fcontext /etc/kubernetes --delete -t etc_t
semanage fcontext /etc/kubernetes/controller-manager.conf --delete -t etc_t
restorecon -R /etc/kubernetes
Upgrades 1.28.0 - 1.28.500

Quando você usa bmctl para fazer upgrade de um cluster, falhar com um erro GCP reachability check failed mesmo que o o URL de destino pode ser acessado na estação de trabalho do administrador. Esse problema é causado por um bug nas versões 1.28.0 a 1.28.500 do bmctl.

Alternativa:

Antes de executar o comando bmctl upgrade, defina o variável de ambiente GOOGLE_APPLICATION_CREDENTIALS para apontar um arquivo de chave da conta de serviço válido:

export GOOGLE_APPLICATION_CREDENTIALS=JSON_KEY_PATH
bmctl upgrade cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG

Definir o Application Default Credentials (ADC) dessa forma garante que bmctl tem as credenciais necessárias para acessar a API do Google endpoint de API.
Instalação 1.29

A instalação de um cluster com um pool de nós separado do balanceador de carga pode falhar se você ativar política de autorização binária durante a criação do cluster.

Esse problema acontece porque a criação do serviço de identidade do GKE O pod e outros pods críticos estão bloqueados pela autorização binária webhook.

Para determinar se esse problema está afetando você, complete as seguintes etapas:

  1. Identifique quais pods estão com falha: 
    kubectl get pods \
    -n anthos-identity-service \
    --kubeconfig CLUSTER_KUBECONFIG
  2. Descreva o pod com falha.
  3. Procure a seguinte mensagem na saída:
    4. admission webhook "binaryauthorization.googleapis.com" denied the
        request: failed to post request to endpoint: Post
"https://binaryauthorization.googleapis.com/internal/projects/PROJECT_NUMBER/policy/locations/LOCATION/clusters/CLUSTER_NAME:admissionReview":
        oauth2/google: status code 400:
{"error":"invalid_target","error_description":"The
        target service indicated by the \"audience\" parameters is invalid.
This might either be because the pool or provider is disabled or deleted
or because it doesn't exist."}

    Se você receber a mensagem anterior, seu cluster está com esse problema.

Alternativa:

Para resolver esse problema, siga estas etapas:

  1. Cancelar a operação de criação do cluster.
  2. Remova o bloco spec.binaryAuthorization da de configuração do cluster.
  3. Crie o cluster com a autorização binária desativada.
  4. Quando a instalação terminar, ativar a política de autorização binária para um cluster atual.
Configuração, instalação 1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28, 1.29, 1.30

Se você tiver o SELinux ativado e montar sistemas de arquivos no Kubernetes diretórios relacionados, poderá ter problemas como a criação de clusters falha, arquivos ilegíveis ou problemas de permissão.

Para saber se esse problema está afetando você, execute o seguinte comando: 

ls -Z /var/lib/containerd
. Se aparecer system_u:object_r:unlabeled_t:s0, em que se espera ver outro rótulo, como system_u:object_r:container_var_lib_t:s0, isso afeta você.

Alternativa:

Se você montou recentemente sistemas de arquivos em diretórios, verifique se esses estão atualizados de acordo com sua configuração do SELinux.

Execute os seguintes comandos em cada máquina antes executando bmctl create cluster:

restorecon -R -v /var
 
restorecon -R -v /etc

Essa correção única persistirá após a reinicialização, mas será necessária a cada vez que um novo nó com os mesmos pontos de montagem é adicionado. Para saber mais, consulte Montar sistemas de arquivos na documentação do Red Hat.
Redefinir/excluir 1.29.0

Ao executar bmctl reset cluster -c ${USER_CLUSTER}, após a conclusão de todos os jobs relacionados, o comando não excluirá os namespace do cluster de usuário. O namespace do cluster de usuário está preso na Terminating. Com o tempo, a redefinição do cluster expira e retorna um erro.

Alternativa:

Para remover o namespace e concluir a redefinição do cluster de usuário, use o seguintes etapas:

  1. Exclua o pod metrics-server do cluster de administrador: 
    kubectl delete pods -l k8s-app=metrics-server \
    -n gke-managed-metrics-server --kubeconfig ADMIN_KUBECONFIG_PATH
     Nessa situação, o pod metrics-server impede a remoção do namespace do cluster.
  2. No cluster de administrador, force a remoção do finalizador no namespace do cluster de usuário: 
    kubectl get ns ${USER_CLUSTER_NAMESPACE} -ojson | \
    jq '.spec.finalizers = []' | \
    kubectl replace --raw "/api/v1/namespaces/${USER_CLUSTER_NAMESPACE}/finalize" -f -
     Depois que o finalizador é removido, o namespace do cluster é removido e a a redefinição do cluster foi concluída.
configuração, instalação, segurança 1.16.0 para 1.16.7 e 1.28.0 para 1.28.400

Se você ativou Autorização binária para o Google Distributed Cloud e está usando uma versão de 1.16.0 a 1.16.7 ou 1.28.0 a 1.28.400, talvez você tenha um problema com o local em que os pods do recurso são programados. Nessas versões, a A implantação da autorização binária não tem um nodeSelector, então a É possível programar pods para o atributo em nós de trabalho em vez de controlar nós do plano de controle. Esse comportamento não faz com que nada falhe, mas não é pretendido.

Alternativa:

Para todos os clusters afetados, siga estas etapas:

  1. Abra o arquivo de implantação da autorização binária: 
    kubectl edit -n binauthz-system deployment binauthz-module-deployment
  2. Adicione o seguinte nodeSelector ao spec.template.spec: bloco:
    3.       nodeSelector:
        node-role.kubernetes.io/control-plane: ""
  3. Salve as alterações.

Depois que a alteração é salva, os pods são reimplantados apenas no controle nós do plano de controle. Essa correção precisa ser aplicada após cada upgrade.
Upgrades e atualizações 1.28.0, 1.28.100, 1.28.200, 1.28.300

Upgrade de clusters criados antes da versão 1.11.0 para as versões 1.28.0-1.28.300 pode fazer com que o pod do implantador do controlador do ciclo de vida entre em um estado de erro durante o upgrade. Quando isso acontece, os registros do controlador de ciclo de vida o pod do implantador tem uma mensagem de erro semelhante a esta: 

"inventorymachines.baremetal.cluster.gke.io\" is invalid: status.storedVersions[0]: Invalid value: \"v1alpha1\": must appear in spec.versions

Alternativa:

Esse problema foi corrigido na versão 1.28.400. Fazer upgrade para a versão 1.28.400 ou para resolver o problema depois.

Se você não conseguir fazer upgrade, execute os comandos a seguir para resolver o problema: 

kubectl patch customresourcedefinitions/nodepoolclaims.baremetal.cluster.gke.io \
    --subresource status --type json \
    --patch='[{ "op": "replace", "path": "/status/storedVersions", "value": ["v1"]}]'

kubectl patch customresourcedefinitions/machineclasses.baremetal.cluster.gke.io \
    --subresource status --type json \
    --patch='[{ "op": "replace", "path": "/status/storedVersions", "value": ["v1"]}]'

kubectl patch customresourcedefinitions/inventorymachines.baremetal.cluster.gke.io \
    --subresource status --type json \
    --patch='[{ "op": "replace", "path": "/status/storedVersions", "value": ["v1"]}]'
Geração de registros e monitoramento 1.13.7, 1.14, 1.15, 1.16, 1.28

Às vezes, os registros de clusters ou contêineres são marcados com um ID de projeto diferente em resource.labels.project_id na Análise de registros.

Isso pode acontecer quando o cluster está configurado para usar a observabilidade PROJECT_ONE, que é definido nos clusterOperations.projectID na configuração do cluster. No entanto, o cloudOperationsServiceAccountKeyPath no A configuração tem uma chave de conta de serviço do projeto PROJECT_TWO.

Nesses casos, todos os registros são roteados para PROJECT_ONE, mas resource.labels.project_id é rotulado como PROJECT_TWO:

Alternativa:

Use uma das seguintes opções para resolver o problema:

  • Use uma conta de serviço do mesmo projeto de destino.
  • Altere project_id no arquivo JSON da chave da conta de serviço para o projeto atual.
  • Altere o project_id diretamente no filtro de registro da Análise de registros.
Rede 1.29, 1.30

Para clusters da versão 1.29.0 que usam balanceamento de carga em pacote com BGP, o desempenho do balanceamento de carga poderá degradar-se conforme o número total de serviços tipo LoadBalancer for de 2.000. Com a queda do desempenho, Serviços recém-criados levam muito tempo para se conectar ou que um cliente não pode acessar. os serviços atuais continuam funcionando, sem lidar com modos de falha, como a perda de um nó do balanceador de carga, de forma eficaz. Esses problemas de serviço acontecem quando A implantação do ang-controller-manager foi encerrada devido a sem memória.

Se o cluster for afetado por esse problema, os serviços no cluster inacessível e inacessível e o ang-controller-manager A implantação está em um CrashLoopBackOff. A resposta ao listar as implantações de ang-controller-manager é semelhante a o seguinte: 

ang-controller-manager-79cdd97b88-9b2rd   0/1    CrashLoopBackOff   639 (59s ago)   2d10h   10.250.210.152   vm-bgplb-centos4-n1-02   <none>   <none>

ang-controller-manager-79cdd97b88-r6tcl   0/1   CrashLoopBackOff   620 (4m6s ago)   2d10h   10.250.202.2     vm-bgplb-centos4-n1-11   <none>   <none>

Alternativa

Como solução alternativa, você pode aumentar o limite de recursos de memória da implantação ang-controller-manager em 100 MiB e remover a Limite de CPU:

kubectl edit deployment ang-controller-manager -n kube-system --kubeconfig ADMIN_KUBECONFIG

Após fazer as mudanças e fechar o editor, você verá a seguinte saída: 

deployment.apps/ang-controller-manager edited

Para verificar se as mudanças foram aplicadas, inspecione o manifesto de ang-controller-manager no cluster: 

kubectl get deployment ang-controller-manager \
   -n kube-system \
   -o custom-columns=NAME:.metadata.name,CPU_LIMITS:.spec.template.spec.containers[*].resources.limits.cpu,MEMORY_LIMITS:.spec.template.spec.containers[*].resources.limits.memory \
   --kubeconfig ADMIN_KUBECONFIG

A resposta será assim: 

NAME                     CPU_LIMITS   MEMORY_LIMITS
ang-controller-manager   <none>       400Mi
Instalação, upgrades, backup e restauração 1.28.0, 1.28.100

Várias operações de cluster para clusters de administrador criam um bootstrap cluster especificado. Antes de criar um cluster de inicialização, o bmctl executa uma verificação de acessibilidade Google Cloud na estação de trabalho do administrador. Essa verificação pode falhar devido a problemas de conectividade com o endpoint do Artifact Registry, gcr.io, e talvez um como esta:

        system checks failed for bootstrap machine: GCP reachability check failed: failed to reach url https://gcr.io: Get "https://cloud.google.com/artifact-registry/": net/http: request canceled (Client.Timeout exceeded while awaiting headers)

Alternativa

Para contornar esse problema, tente realizar a operação novamente com a sinalização. --ignore-validation-errors:
Rede 1.15, 1.16

Os clusters bare metal usam o GKE Dataplane V2, que é incompatível com alguns provedores de armazenamento. Você pode enfrentar problemas com volumes ou pods NFS travados. Isso é bastante provável se há cargas de trabalho que usam ReadWriteMany volumes com suporte drivers de armazenamento suscetíveis a esse problema:

  • Robin.io
  • Portworx (sharedv4 de volumes de serviço)
  • csi-nfs

Esta não é uma lista completa.

Alternativa

Uma correção para esse problema está disponível para as seguintes versões do Ubuntu:

  • 20.04 LTS: use uma imagem do kernel 5.4.0 posterior a linux-image-5.4.0-166-generic
  • 22.04 LTS: use uma imagem do kernel 5.15.0 posterior a linux-image-5.15.0-88-generic ou use o kernel 6.5 HWE.

Se você não usa uma dessas versões, entre em contato Suporte do Google
Geração de registros e monitoramento 1.15, 1.16, 1.28

Você pode notar que kube-state-metrics ou o Pod gke-metrics-agent que existe no mesmo nó que kube-state-metrics está sem memória (OOM, na sigla em inglês).

Isso pode acontecer em clusters com mais de 50 nós objetos do Kubernetes.

Alternativa

Para resolver esse problema, atualize o stackdriver personalizado definição de recurso para usar o ksmNodePodMetricsOnly portão de recurso. Essa porta de recursos garante que apenas um pequeno número e as métricas críticas serão expostas.

Para usar essa solução alternativa, siga estas etapas:

  1. Verifique a definição do recurso personalizado stackdriver para portões de recursos disponíveis: 
    kubectl -n kube-system get crd stackdrivers.addons.gke.io -o yaml | grep ksmNodePodMetricsOnly
  2. Atualize a definição do recurso personalizado stackdriver para ativar ksmNodePodMetricsOnly: 
    kind:stackdriver
spec:
  featureGates:
     ksmNodePodMetricsOnly: true
Instalação 1.28.0-1.28.200

Ao instalar um cluster no Red Hat Enterprise Linux (RHEL) 9.2 sistema operacional, pode ocorrer uma falha devido à pacote iptables. A falha ocorre durante a simulação verifica e aciona uma mensagem de erro semelhante a esta:

'check_package_availability_pass': "The following packages are not available: ['iptables']"

O RHEL 9.2 está em Pré-lançamento para a versão 1.28 do Google Distributed Cloud.

Alternativa

Para ignorar o erro de verificação de simulação, defina spec.bypassPreflightCheck para true no seu recurso de cluster.
Operação 1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16

Quando o MetalLB lida com um grande número de serviços (mais de 10.000), e o failover pode levar mais de uma hora. Isso acontece porque o MetalLB usa uma taxa fila limitada que, quando em alta escala, pode demorar um pouco para do serviço que precisa fazer failover.

Alternativa

Faça upgrade do cluster para a versão 1.28 ou posterior. Se você não conseguir fazer upgrade, editar manualmente o serviço (por exemplo, adicionar um ) faz com que o serviço faça failover mais rapidamente.
Operação 1.16.0-1.16.6, 1.28.0-1.28.200

bmctl check cluster pode falhar devido a falhas de proxy se você não tiver as variáveis de ambiente HTTPS_PROXY e NO_PROXY definidas na estação de trabalho do administrador. O comando bmctl relata uma mensagem de erro sobre a falha ao chamar alguns serviços do Google, como o exemplo a seguir:

[2024-01-29 23:49:03+0000] error validating cluster config: 2 errors occurred:
        * GKERegister check failed: 2 errors occurred:
        * Get "https://gkehub.googleapis.com/v1beta1/projects/baremetal-runqi/locations/global/memberships/ci-ec1a14a903eb1fc": oauth2: cannot fetch token: Post "https://oauth2.googleapis.com/token": dial tcp 108.177.98.95:443: i/o timeout
        * Post "https://cloudresourcemanager.googleapis.com/v1/projects/baremetal-runqi:testIamPermissions?alt=json&prettyPrint=false": oauth2: cannot fetch token: Post "https://oauth2.googleapis.com/token": dial tcp 74.125.199.95:443: i/o timeout

Alternativa

Defina HTTPS_PROXY e NO_PROXY manualmente na estação de trabalho do administrador.
Upgrades e atualizações 1.28.0-gke.435

Em alguns casos, o arquivo /var/log/apiserver/audit.log em nós do plano de controle têm a propriedade do grupo e do usuário definida como root. Esta configuração de propriedade de arquivo causa falhas de upgrade no plano de controle nós ao fazer upgrade de um cluster da versão 1.16.x para a versão 1.28.0-gke.435. Esse problema só se aplica a clusters criados antes da versão 1.11 com os Registros de auditoria do Cloud desativados. Os Registros de auditoria do Cloud estão ativados por padrão para clusters na versão 1.9 e superior.

Alternativa

Se não for possível fazer upgrade do cluster para a versão 1.28.100-gke.146, use as etapas a seguir como solução alternativa para concluir o upgrade do cluster para a versão 1.28.0-gke.435:

  • Se os Registros de auditoria do Cloud estiverem ativados, remova o arquivo /var/log/apiserver/audit.log.
  • Se os Registros de auditoria do Cloud estiverem desativados, mude a propriedade de /var/log/apiserver/audit.log para a mesma do diretório pai, /var/log/apiserver.
Rede, upgrades e atualizações 1.28.0-gke.435

O Google Distributed Cloud usa o MetalLB para balanceamento de carga em pacote. No Google Distributed Cloud versão 1.28.0-gke.435, será feito o upgrade do MetalLB empacotado para a versão 0.13, que passa a oferecer suporte à CRD para IPAddressPools. No entanto, como ConfigMaps permite qualquer nome para IPAddressPool, os nomes dos pools precisavam ser convertidos para um nome compatível com o Kubernetes anexando um hash ao final do nome do IPAddressPool. Por exemplo, uma IPAddressPool com o nome default. é convertido em um nome como default-qpvpd quando você faz o upgrade. do cluster para a versão 1.28.0-gke.435.

Como o MetalLB requer um nome específico de IPPool para seleção, a conversão de nome impede que o MetalLB crie um pool seleção e atribuição de endereços IP. Portanto, os Serviços que usam metallb.universe.tf/address-pool como uma anotação para selecionar o pool de endereços de um endereço IP não recebe mais um endereço IP o controlador do MetalLB.

Esse problema foi corrigido na versão 1.28.100-gke.146 do Google Distributed Cloud.

Alternativa

Se não for possível fazer upgrade do cluster para a versão 1.28.100-gke.146, use o como solução alternativa:

  1. Consiga o nome convertido do IPAddressPool: 
    kubectl get IPAddressPools -n kube-system
  2. Atualize o serviço afetado para definir o metallb.universe.tf/address-pool para o nome convertido com o hash.

    Por exemplo, se o nome IPAddressPool foi convertido de default para um nome como default-qpvpd, mude a anotação metallb.universe.tf/address-pool: default no serviço para metallb.universe.tf/address-pool: default-qpvpd.

O hash usado na conversão do nome é determinístico, ou seja, alternativa é persistente.
Upgrades e atualizações 1.14, 1.15, 1.16, 1.28, 1.29

Ao fazer upgrade dos clusters para a versão 1.14.x, alguns recursos da versão anterior não são excluídos. Especificamente, você poderá encontrar um conjunto de pods órfãos como este:

capi-webhook-system/capi-controller-manager-xxx
capi-webhook-system/capi-kubeadm-bootstrap-controller-manager-xxx

Esses objetos órfãos não afetam diretamente a operação do cluster, mas uma prática recomendada, recomendamos que você os remova.

  • Execute os comandos a seguir para remover os objetos órfãos: 
    kubectl delete ns capi-webhook-system
kubectl delete validatingwebhookconfigurations capi-validating-webhook-configuration
kubectl delete mutatingwebhookconfigurations capi-mutating-webhook-configuration

Esse problema foi corrigido na versão 1.15.0 e mais recentes do Google Distributed Cloud.
Instalação 1,14

Se você tentar instalar o Google Distributed Cloud versão 1.14.x, falha devido aos jobs machine-init, semelhante a o seguinte exemplo de saída:

"kubeadm join" task failed due to:
error execution phase control-plane-join/etcd: error creating local etcd static pod manifest file: etcdserver: re-configuration failed due to not enough started members

"kubeadm reset" task failed due to:
panic: runtime error: invalid memory address or nil pointer dereference

Alternativa:

Remove o membro obsoleto do etcd que faz com que o falha do job machine-init. Conclua as etapas a seguir nó do plano de controle em funcionamento:

  1. Liste os membros atuais do etcd: 
    etcdctl --key=/etc/kubernetes/pki/etcd/peer.key \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/peer.crt \
  member list
     Procure os membros com o status unstarted, como mostrado em o seguinte exemplo de saída: 
    5feb7ac839625038, started, vm-72fed95a, https://203.0.113.11:2380, https://203.0.113.11:2379, false
99f09f145a74cb15, started, vm-8a5bc966, https://203.0.113.12:2380, https://203.0.113.12:2379, false
bd1949bcb70e2cb5, unstarted, , https://203.0.113.10:2380, , false
  2. Remova o membro do etcd com falha: 
    etcdctl --key=/etc/kubernetes/pki/etcd/peer.key \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/peer.crt \
  member remove MEMBER_ID
     Substitua MEMBER_ID pelo ID do membro com falha do etcd. No exemplo de saída anterior, esse ID é bd1949bcb70e2cb5:
    e
    O exemplo de saída a seguir mostra que o membro foi removido: 
    Member bd1949bcb70e2cb5 removed from cluster  9d70e2a69debf2f
Rede 1.28.0

No Cilium 1.13, o ClusterRole cilium-operator estão incorretas. Os nós list e watch permissões estão ausentes. O cilium-operator falha ao iniciar coletores de lixo, que resulta nos seguintes problemas:

  • Vazamento de recursos do Cilium.
  • Identidades desatualizadas não são removidas dos mapas de política do Filestore.
  • Os mapas de políticas podem atingir o limite de 16 mil.
    • Não é possível adicionar novas entradas.
    • Aplicação incorreta da NetworkPolicy.
  • As identidades podem atingir o limite de 64 mil.
    • Não será possível criar pods.

Um operador sem as permissões de nó informa o seguinte exemplo de mensagem de registro:

2024-01-02T20:41:37.742276761Z level=error msg=k8sError error="github.com/cilium/cilium/operator/watchers/node.go:83: Failed to watch *v1.Node: failed to list *v1.Node: nodes is forbidden: User \"system:serviceaccount:kube-system:cilium-operator\" cannot list resource \"nodes\" in API group \"\" at the cluster scope" subsys=k8s

O agente Cilium relata uma mensagem de erro quando não consegue inserir um entrada em um mapa de política, como o exemplo a seguir:

level=error msg="Failed to add PolicyMap key" bpfMapKey="{6572100 0 0 0}" containerID= datapathPolicyRevision=0 desiredPolicyRevision=7 endpointID=1313 error="Unable to update element for Cilium_policy_01313 map with file descriptor 190: the map is full, please consider resizing it. argument list too long" identity=128 ipv4= ipv6= k8sPodName=/ port=0 subsys=endpoint

Alternativa:

Remova as identidades do Cilium e adicione o ClusterRole que está faltando permissões ao operador:

  1. Remova os objetos CiliumIdentity atuais: 
    kubectl delete ciliumid –-all
  2. Edite o objeto ClusterRole cilium-operator: 
    kubectl edit clusterrole cilium-operator
  3. Adicione uma seção para nodes que inclua, conforme mostrado no exemplo a seguir: 
    - apiGroups:
  - ""
  resources:
  - nodes
  verbs:
  - get
  - list
  - watch
  4. Salve e feche o editor. O operador detecta dinamicamente mudança de permissão. Não é necessário reiniciar manualmente o operador.
Upgrades e atualizações 1.15.0-1.15.7, 1.16.0-1.16.3

Uma das tarefas de verificação de integridade do kubeadm executadas durante o upgrade a verificação de simulação pode falhar com a seguinte mensagem de erro:

[ERROR CreateJob]: could not delete Job \"upgrade-health-check\" in the namespace \"kube-system\": jobs.batch \"upgrade-health-check\" not found

Esse erro pode ser ignorado com segurança. Se você encontrar esse erro que bloqueia o upgrade, e execute novamente o comando de upgrade.

Se você observar esse erro ao executar a simulação usando o bmctl preflightcheck, nada é bloqueado por este falha. É possível executar a verificação de simulação novamente para informações de simulação.


Alternativa:

Execute novamente o comando de upgrade ou, se encontrado durante bmctl preflightcheck, executar novamente preflightcheck comando.
Operação 1.14, 1.15.0-1.15.7, 1.16.0-1.16.3, 1.28.0

Esse problema afeta clusters que realizam verificações periódicas de integridade da rede depois que um nó for substituído ou removido. Se o cluster passa por períodos verificações de integridade, a verificação periódica de integridade da rede resulta em falha após na substituição ou remoção de um nó, porque o ConfigMap do inventário de rede não é atualizado depois de criado.


Alternativa:

A solução alternativa recomendada é excluir o ConfigMap do inventário e o verificações periódicas de integridade da rede. O operador de cluster automaticamente recria-as com as informações mais atualizadas.

Para clusters 1.14.x, execute os seguintes comandos:

kubectl delete configmap \
    $(kubectl get cronjob CLUSTER_NAME-network -o=jsonpath='{.spec.jobTemplate.spec.template.spec.volumes[?(@name=="inventory-config-volume")].configMap.name}' \
    -n CLUSTER_NAMESPACE) \
    -n CLUSTER_NAMESPACE \
    --kubeconfig ADMIN_KUBECONFIG
kubectl delete healthchecks.baremetal.cluster.gke.io \
    CLUSTER_NAME-network -n CLUSTER_NAMESPACE \
    --kubeconfig ADMIN_KUBECONFIG

Para clusters 1.15.0 e posteriores, execute os seguintes comandos:

kubectl delete configmap \
    $(kubectl get cronjob bm-system-network -o=jsonpath='{.spec.jobTemplate.spec.template.spec.volumes[?(@.name=="inventory-config-volume")]configMap.name}' \
    -n CLUSTER_NAMESPACE) \
    -n CLUSTER_NAMESPACE \
    --kubeconfig ADMIN_KUBECONFIG
kubectl delete healthchecks.baremetal.cluster.gke.io \
    bm-system-network -n CLUSTER_NAMESPACE \
    --kubeconfig ADMIN_KUBECONFIG
Rede 1.14, 1.15, 1.16.0-1.16.2

Se você tiver um dispositivo de rede com um caractere de ponto (.) no nome, como bond0.2, O gateway de rede para a GDC trata o período como um caminho no diretório quando ele executa sysctl para fazer mudanças. Quando O gateway de rede para GDC verifica se há detecção de endereço duplicado (DAD) estiver ativado, a verificação poderá falhar e, portanto, não realizará a reconciliação.

O comportamento é diferente entre as versões do cluster:

  • 1.14 e 1.15: esse erro só existe quando você usa IPv6. endereços IP flutuantes. Se você não usar endereços IP flutuantes IPv6, não notará esse problema quando os nomes dos dispositivos contiverem um ponto.
  • 1.16.0 a 1.16.2: esse erro sempre existe quando o dispositivo contêm um ponto.

Alternativa:

Faça upgrade do cluster para a versão 1.16.3 ou posterior.

Como solução alternativa, até que seja possível fazer upgrade dos clusters, remova o período (.) do nome do dispositivo.
Upgrades e atualizações, rede, segurança 1.16.0

Se seccomp estiver desativado para o cluster (spec.clusterSecurity.enableSeccomp definido como false), os upgrades para a versão 1.16.0 falharão.

O Google Distributed Cloud versão 1.16 usa o Kubernetes versão 1.27. Na versão 1.27.0 e mais recentes do Kubernetes, o recurso de configuração seccomp perfis estão em disponibilidade geral e não usam mais uma porta de recursos (em inglês). Essa mudança do Kubernetes faz com que os upgrades para a versão 1.16.0 falhem quando seccomp está desativado na configuração do cluster. Este problema foi corrigido na versão 1.16.1 e nos clusters mais recentes. Se você definir o campo cluster.spec.clusterSecurity.enableSeccomp; para false, é possível fazer upgrade para a versão 1.16.1 ou superior.

Clusters com spec.clusterSecurity.enableSeccomp não definido ou definidas como true não são afetadas.
Instalação, operação 1.11, 1.12, 1.13, 1.14, 1.15.0-1.15.5, 1.16.0-1.16.1

Se você ativou o /var/lib/containerd, a Os metadados de containerd podem ser corrompidos após uma reinicialização. Metadados corrompidos pode causar falhas nos pods, incluindo pods essenciais ao sistema.

Para verificar se esse problema afeta você, confira se uma montagem opcional foi definida em /etc/fstab para /var/lib/containerd/ e tem nofail nas opções de montagem.


Alternativa:

Remova a opção de montagem nofail em /etc/fstab. ou faça upgrade do cluster para a versão 1.15.6 ou mais recente.
Operação 1.13, 1.14, 1.15, 1.16, 1.28

É possível encontrar pods gerenciados por uma implantação (ReplicaSet) em um Failed e com o status de TaintToleration. Esses pods não usam recursos de cluster, deve ser excluída.

É possível usar o seguinte comando kubectl para listar os Pods que podem ser limpos:

kubectl get pods –A | grep TaintToleration

O exemplo de saída a seguir mostra um pod com o Status de TaintToleration:

kube-system    stackdriver-metadata-agent-[...]    0/1    TaintToleration    0

Alternativa:

Para cada pod com os sintomas descritos, verifique o ReplicaSet do pod. Se o ReplicaSet for atendido, é possível excluir os pods:

  1. Acessar o ReplicaSet que gerencia o pod e encontrar o valor de ownerRef.Kind: 
    kubectl get pod POD_NAME -n NAMESPACE -o yaml
  2. Acessar o ReplicaSet e verificar se o status.replicas é igual a spec.replicas: 
    kubectl get replicaset REPLICA_NAME -n NAMESPACE -o yaml
  3. Se os nomes forem correspondentes, exclua o pod: 
    kubectl delete pod POD_NAME -n NAMESPACE.
Upgrades 1.16.0

Quando você faz upgrade de um cluster atual para a versão 1.16.0, as falhas do pod relacionados a eventos do etcd podem interromper a operação. Especificamente, é possível o job de upgrade-node falha para o TASK [etcd_events_install : Run etcdevents] etapa.

Se você for afetado por esse problema, vai encontrar falhas no pod, como seguindo:

  • O pod kube-apiserver falha ao iniciar com o seguinte erro: 
    connection error: desc = "transport: Error while dialing dial tcp 127.0.0.1:2382: connect: connection refused"
  • O pod etcd-events não é iniciado com o seguinte erro: 
    Error: error syncing endpoints with etcd: context deadline exceeded

Alternativa:

Se não for possível fazer upgrade do cluster para uma versão com use a seguinte solução temporária para solucionar os erros:

  1. Use SSH para acessar o nó do plano de controle com os erros informados.
  2. Edite o arquivo de manifesto etcd-events, /etc/kubernetes/manifests/etcd-events.yaml. e remova a sinalização initial-cluster-state=existing.
  3. Aplique o manifesto.
  4. O upgrade vai continuar.
Rede 1.15.0-1.15.2

OrderPolicy não é reconhecido como um parâmetro e não é usado. Em vez disso, o Google Distributed Cloud sempre usa Random.

Esse problema ocorre porque o modelo CoreDNS não foi atualizado, o que faz com que orderPolicy seja ignorado.


Alternativa:

Atualize o modelo CoreDNS e aplique a correção. Essa correção persiste até um upgrade.

  1. Edite o modelo: 
    kubectl edit cm -n kube-system coredns-template
     Substitua o conteúdo do modelo pelo seguinte: 
    coredns-template: |-
  .:53 {
    errors
    health {
      lameduck 5s
    }
    ready
    kubernetes cluster.local in-addr.arpa ip6.arpa {
      pods insecure
      fallthrough in-addr.arpa ip6.arpa
    }
{{- if .PrivateGoogleAccess }}
    import zones/private.Corefile
{{- end }}
{{- if .RestrictedGoogleAccess }}
    import zones/restricted.Corefile
{{- end }}
    prometheus :9153
    forward . {{ .UpstreamNameservers }} {
      max_concurrent 1000
      {{- if ne .OrderPolicy "" }}
      policy {{ .OrderPolicy }}
      {{- end }}
    }
    cache 30
{{- if .DefaultDomainQueryLogging }}
    log
{{- end }}
    loop
    reload
    loadbalance
}{{ range $i, $stubdomain := .StubDomains }}
{{ $stubdomain.Domain }}:53 {
  errors
{{- if $stubdomain.QueryLogging }}
  log
{{- end }}
  cache 30
  forward . {{ $stubdomain.Nameservers }} {
    max_concurrent 1000
    {{- if ne $.OrderPolicy "" }}
    policy {{ $.OrderPolicy }}
    {{- end }}
  }
}
{{- end }}
Rede, operação 1.10, 1.11, 1.12, 1.13, 1.14

Os pods do gateway de rede em kube-system podem mostrar um status Pending ou Evicted, conforme o exemplo de saída condensada a seguir:

$ kubectl -n kube-system get pods | grep ang-node
ang-node-bjkkc     2/2     Running     0     5d2h
ang-node-mw8cq     0/2     Evicted     0     6m5s
ang-node-zsmq7     0/2     Pending     0     7h

Esses erros indicam eventos de remoção ou impossibilidade de programar pods devido a recursos de nó. Como gateway de rede para pods do GDC, prioridadeClass, elas têm a mesma prioridade padrão que outras cargas de trabalho. Quando os nós têm recursos restritos, os pods do gateway de rede podem ser removidos. Esse comportamento é especialmente ruim para o DaemonSet ang-node, porque esses pods precisam ser programados em um nó específico e não podem ser migrados.


Alternativa:

Faça upgrade para a versão 1.15 ou posterior.

Como uma correção de curto prazo, você pode atribuir PriorityClass aos componentes de gateway de rede para GDC. O controlador do Google Distributed Cloud substitui essas alterações manuais durante um processo de reconciliação, como durante um upgrade de cluster.

  • Atribua a PriorityClass system-cluster-critical às implantações do controlador de cluster ang-controller-manager e autoscaler.
  • Atribua a PriorityClass system-node-critical ao DaemonSet do nó ang-daemon.
Instalação, upgrades e atualizações 1.15.0, 1.15.1, 1.15.2

A criação de clusters da versão 1.15.0, 1.15.1 ou 1.15.2 ou o upgrade de clusters para a versão 1.15.0, 1.15.1 ou 1.15.2 falha quando o nome do cluster é maior do que 48 caracteres (versão 1.15.0) ou 45 caracteres (versão 1.15.1 ou 1.15.2). Durante a criação do cluster e as operações de upgrade, O Google Distributed Cloud cria um recurso de verificação de integridade com um nome incorpora o nome e a versão do cluster:

  • Para clusters da versão 1.15.0, o nome do recurso de verificação de integridade é CLUSTER_NAME-add-ons-CLUSTER_VER.
  • Para os clusters da versão 1.15.1 ou 1.15.2, o nome do recurso de verificação de integridade é CLUSTER_NAME-kubernetes-CLUSTER_VER.

Para nomes de cluster longos, o nome do recurso de verificação de integridade excede a restrição de tamanho de 63 caracteres do Kubernetes para nomes de rótulos, o que impede a criação do recurso de verificação de integridade. Sem uma verificação de integridade bem-sucedida, a operação do cluster falha.

Para saber se esse problema está afetando você, use kubectl describe para verificar o recurso com falha: 

kubectl describe healthchecks.baremetal.cluster.gke.io \
    HEALTHCHECK_CR_NAME -n CLUSTER_NAMESPACE \
    --kubeconfig ADMIN_KUBECONFIG

Se esse problema estiver afetando você, a resposta conterá um aviso sobre ReconcileError como este: 

...
Events:
  Type     Reason          Age                   From                    Message
  ----     ------          ----                  ----                    -------
  Warning  ReconcileError  77s (x15 over 2m39s)  healthcheck-controller  Reconcile error, retrying: 1 error occurred:
           * failed to create job for health check
db-uat-mfd7-fic-hybrid-cloud-uk-wdc-cluster-02-kubernetes-1.15.1: Job.batch
"bm-system-db-uat-mfd7-fic-hybrid-cloud-u24d5f180362cffa4a743" is invalid: [metadata.labels: Invalid
value: "db-uat-mfd7-fic-hybrid-cloud-uk-wdc-cluster-02-kubernetes-1.15.1": must be no more than 63
characters, spec.template.labels: Invalid value:
"db-uat-mfd7-fic-hybrid-cloud-uk-wdc-cluster-02-kubernetes-1.15.1": must be no more than 63 characters]

Alternativa

Para desbloquear o upgrade ou a criação do cluster, ignore a verificação de integridade. Use o comando a seguir para corrigir o recurso personalizado de verificação de integridade com o status aprovado: (status: {pass: true})

kubectl patch healthchecks.baremetal.cluster.gke.io \
    HEALTHCHECK_CR_NAME -n CLUSTER_NAMESPACE \
    --kubeconfig ADMIN_KUBECONFIG --type=merge \
    --subresource status --patch 'status: {pass: true}'
Upgrades e atualizações 1.14, 1.15

Se os clusters das versões 1.14.0 e 1.14.1 tiverem um recurso em fase de pré-lançamento ativado, eles não poderão fazer upgrade para a versão 1.15.x. Isso se aplica a recursos em fase de pré-lançamento, como a capacidade de criar um cluster sem o kube-proxy, que é ativado com a seguinte anotação no arquivo de configuração do cluster:

preview.baremetal.cluster.gke.io/kube-proxy-free: "enable"

Se esse problema estiver afetando você, haverá um erro durante o upgrade do cluster como este:

[2023-06-20 23:37:47+0000] error judging if the cluster is managing itself:
error to parse the target cluster: error parsing cluster config: 1 error
occurred:

Cluster.baremetal.cluster.gke.io "$cluster-name" is invalid:
Annotations[preview.baremetal.cluster.gke.io/$preview-feature-name]:
Forbidden: preview.baremetal.cluster.gke.io/$preview-feature-name feature
isn't supported in 1.15.1 Anthos Bare Metal version

Esse problema foi corrigido na versão 1.14.2 e nos clusters mais recentes.


Alternativa:

Se não for possível fazer upgrade dos clusters para a versão 1.14.2 ou superior antes do upgrade para a versão 1.15.x, use um cluster bootstrap para fazer upgrade direto para a versão 1.15.x:

bmctl upgrade cluster --use-bootstrap=true
Operação 1.15

O gateway de rede para GDC não permite criar novos NetworkGatewayGroup recursos personalizados que contêm endereços IP em spec.floatingIPs que já são usados nas NetworkGatewayGroup personalizadas do Google Cloud. Essa regra é aplicada por um webhook em clusters bare metal versão 1.15.0 e superior. Endereços IP flutuantes duplicados preexistentes não causam erros. O webhook impede apenas a criação de novos recursos personalizados NetworkGatewayGroups que contêm endereços IP duplicados.

A mensagem de erro do webhook identifica o endereço IP conflitante e o recurso personalizado existente que já o utiliza: 

IP address exists in other gateway with name default

A documentação inicial para recursos de rede avançados, como o gateway NAT de saída, não adverte sobre endereços IP duplicados. Inicialmente, apenas o recurso NetworkGatewayGroup chamado default foi reconhecido pelo reconciliador. Gateway de rede para GDC agora reconhece todos os NetworkGatewayGroup personalizados recursos no namespace do sistema. Os recursos personalizados NetworkGatewayGroup atuais são mantidos.


Alternativa:

Ocorrem erros apenas na criação de um novo recurso personalizado NetworkGatewayGroup.

Para resolver o erro:

  1. Use o seguinte comando para listar recursos personalizados de NetworkGatewayGroups: 
    kubectl get NetworkGatewayGroups --kubeconfig ADMIN_KUBECONFIG \
    -n kube-system -o yaml
  2. Abra os recursos personalizados do NetworkGatewayGroup atuais e remova todos os endereços IP flutuantes conflitantes (spec.floatingIPs): 
    kubectl edit NetworkGatewayGroups --kubeconfig ADMIN_KUBECONFIG \
    -n kube-system RESOURCE_NAME
  3. Para aplicar as alterações, feche e salve os recursos personalizados editados.
Ambiente de execução de VM na GDC 1.13.7

Quando você ativa o ambiente de execução de VM no GDC em uma versão nova ou atualizada 1.13.7 Cluster que usa um registro particular, VMs que se conectam ao nó ou usar uma GPU podem não iniciar corretamente. Esse problema ocorre porque alguns pods do sistema no namespace vm-system estão recebendo erros de extração de imagem. Por exemplo, se a VM usar a rede de nós, alguns pods poderão relatar erros de extração de imagem, como nos exemplos a seguir:

macvtap-4x9zp              0/1   Init:ImagePullBackOff  0     70m

Esse problema foi corrigido na versão 1.14.0 e nos clusters mais recentes.

Alternativa

Se não for possível fazer upgrade dos clusters imediatamente, será possível extrair imagens manualmente. Os seguintes comandos extraem a imagem do plug-in CNI do macvtap para sua VM e a enviam para o registro particular: 

docker pull \
    gcr.io/anthos-baremetal-release/kubevirt/macvtap-cni:v0.5.1-gke.:21
docker tag \
    gcr.io/anthos-baremetal-release/kubevirt/macvtap-cni:v0.5.1-gke.:21 \
    REG_HOST/anthos-baremetal-release/kubevirt/macvtap-cni:v0.5.1-gke.:21
docker push \
    REG_HOST/anthos-baremetal-release/kubevirt/macvtap-cni:v0.5.1-gke.:21

Substitua REG_HOST pelo nome de domínio de um host espelhado localmente.

Instalação 1.11, 1.12

Durante a criação do cluster de tipo, o pod gke-metrics-agent falha ao iniciar devido a um erro de extração de imagem da seguinte maneira:

error="failed to pull and unpack image \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\": failed to resolve reference \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\": pulling from host gcr.io failed with status code [manifests 1.8.3-anthos.2]: 403 Forbidden"

Além disso, no registro containerd do cluster de inicialização, você verá a seguinte entrada:

Sep 13 23:54:20 bmctl-control-plane containerd[198]: time="2022-09-13T23:54:20.378172743Z" level=info msg="PullImage \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\" " Sep 13 23:54:21 bmctl-control-plane containerd[198]: time="2022-09-13T23:54:21.057247258Z" level=error msg="PullImage \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\" failed" error="failed to pull and unpack image \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\": failed to resolve reference \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\": pulling from host gcr.io failed with status code [manifests 1.8.3-anthos.2]: 403 Forbidden"

Você verá o seguinte erro "Falha ao extrair" no pod:

gcr.io/gke-on-prem-staging/gke-metrics-agent

Alternativa

Apesar dos erros, o processo de criação do cluster não está bloqueado porque o objetivo do pod gke-metrics-agent no cluster de tipo é facilitar a taxa de sucesso de criação do cluster e o rastreamento e monitoramento internos. Portanto, você pode ignorar esse erro.

Alternativa

Apesar dos erros, o processo de criação do cluster não está bloqueado porque o objetivo do pod gke-metrics-agent no cluster de tipo é facilitar a taxa de sucesso de criação do cluster e o rastreamento e monitoramento internos. Portanto, você pode ignorar esse erro.
Operação, rede 1.12, 1.13, 1.14, 1.15, 1.16, 1.28

Quando você acessa um serviço de pilha dupla (um serviço que tem endpoints IPv4 e IPv6) e usa o endpoint IPv6, o nó LoadBalancer que disponibiliza o serviço pode falhar. Esse problema afeta clientes que usam serviços de pilha dupla com o CentOS ou RHEL e a versão do kernel anterior a kernel-4.18.0-372.46.1.el8_6.

Se você acredita que esse problema afeta você, verifique a versão do kernel no nó LoadBalancer usando o comando uname -a.


Alternativa:

Atualize o nó do LoadBalancer para a versão kernel-4.18.0-372.46.1.el8_6 ou posterior do kernel. Essa versão do kernel está disponível por padrão no CentOS e RHEL versão 8.6 e posterior.
Rede 1.11, 1.12, 1.13, 1.14.0

Depois de reiniciar um nó, pode haver problemas de conectividade intermitente para um Serviço NodePort ou LoadBalancer. Por exemplo, pode haver erros de redefinição de conexão ou handshake de TLS intermitente. Este problema é corrigido para as versões de cluster 1.14.1 e mais recentes.

Para verificar se esse problema afeta você, observe as regras de encaminhamento iptables nos nós em que o pod de back-end do Serviço afetado está em execução:

sudo iptables -L FORWARD

Se você vir a regra KUBE-FORWARD antes da regra CILIUM_FORWARD em iptables, talvez esse problema esteja afetando você. O exemplo de saída a seguir mostra um nó em que o problema existe:

Chain FORWARD (policy ACCEPT)
target                  prot opt source   destination
KUBE-FORWARD            all  --  anywhere anywhere                /* kubernetes forwarding rules */
KUBE-SERVICES           all  --  anywhere anywhere    ctstate NEW /* kubernetes service portals */
KUBE-EXTERNAL-SERVICES  all  --  anywhere anywhere    ctstate NEW /* kubernetes externally-visible service portals */
CILIUM_FORWARD          all  --  anywhere anywhere                /* cilium-feeder: CILIUM_FORWARD */

Alternativa:

Reinicie o pod anetd no nó que está configurado incorretamente. Depois de reiniciar o pod anetd, a regra de encaminhamento em iptables será configurada corretamente.

O exemplo de saída a seguir mostra que a regra CILIUM_FORWARD agora está configurada corretamente antes da regra KUBE-FORWARD:

Chain FORWARD (policy ACCEPT)
target                  prot opt source   destination
CILIUM_FORWARD          all  --  anywhere anywhere                /* cilium-feeder: CILIUM_FORWARD */
KUBE-FORWARD            all  --  anywhere anywhere                /* kubernetes forwarding rules */
KUBE-SERVICES           all  --  anywhere anywhere    ctstate NEW /* kubernetes service portals */
KUBE-EXTERNAL-SERVICES  all  --  anywhere anywhere    ctstate NEW /* kubernetes externally-visible service portals */
Upgrades e atualizações 1.9, 1.10

O recurso em fase de pré-lançamento do cluster 1.9.x que usa o bmctl 1.9.x não retém as informações do proprietário e permissões originais. Para verificar se esse recurso está afetando você, extraia o arquivo de backup usando o seguinte comando:

tar -xzvf BACKUP_FILE

Alternativa

Verifique se o metadata.json está presente e se a bmctlVersion é 1.9.x. Se o metadata.json não estiver presente, faça upgrade para o cluster 1.10.x e use bmctl 1.10.x para fazer backup/restauração.
Upgrades e criação 1.14.2

Se você tiver criado um cluster da versão 1.14.2 ou feito upgrade com uma configuração OIDC/LDAP, talvez veja o pod clientconfig-operator travado em um estado pendente. Com esse problema, há dois pods clientconfig-operator, um em estado de execução e o outro em estado pendente.

Esse problema se aplica apenas aos clusters da versão 1.14.2. As versões anteriores do cluster, como 1.14.0 e 1.14.1, não são afetadas. Esse problema foi corrigido na versão 1.14.3 e em todas as versões subsequentes, incluindo 1.15.0 e posteriores.


Alternativa:

Como solução alternativa, é possível corrigir a implantação clientconfig-operator para adicionar mais contexto de segurança e garantir que a implantação esteja pronta.

Use o comando a seguir para corrigir clientconfig-operator no cluster de destino: 

kubectl patch deployment clientconfig-operator -n kube-system \
    -p '{"spec":{"template":{"spec":{"containers": [{"name":"oidcproxy","securityContext":{"runAsGroup":2038,"runAsUser":2038}}]}}}}' \
    --kubeconfig CLUSTER_KUBECONFIG

Substitua:

  • CLUSTER_KUBECONFIG: o caminho do arquivo kubeconfig do cluster de destino.
Operação 1.11, 1.12, 1.13, 1.14, 1.15

Para clusters sem balanceamento de carga em pacote (spec.loadBalancer.mode definido como manual), o comando bmctl update credentials certificate-authorities rotate pode parar de responder e falhar com o seguinte erro: x509: certificate signed by unknown authority.

Se você for afetado por esse problema, o comando bmctl poderá gerar a seguinte mensagem antes de não responder:

Signing CA completed in 3/0 control-plane nodes

Nesse caso, o comando falhará em algum momento. O registro de autoridade de certificação em rotação para um cluster com três planos de controle pode incluir entradas como a seguinte: 

[2023-06-14 22:33:17+0000] waiting for all nodes to trust CA bundle OK
[2023-06-14 22:41:27+0000] waiting for first round of pod restart to complete OK
Signing CA completed in 0/0 control-plane nodes
Signing CA completed in 1/0 control-plane nodes
Signing CA completed in 2/0 control-plane nodes
Signing CA completed in 3/0 control-plane nodes
...
Unable to connect to the server: x509: certificate signed by unknown
authority (possibly because of "crypto/rsa: verification error" while
trying to verify candidate authority certificate "kubernetes")

Alternativa

Se precisar de ajuda, fale com o Suporte do Google.
Instalação, rede 1.11, 1.12, 1.13, 1.14.0-1.14.1

Quando você implanta um cluster de pilha dupla (um cluster com endereços IPv4 e IPv6), os pods ipam-controller-manager podem apresentar loop de falhas. Esse comportamento faz os nós alternarem entre os estados Ready e NotReady e pode causar falha na instalação do cluster. Esse problema pode ocorrer quando o servidor da API está sobrecarregado.

Para saber se esse problema afeta você, verifique se os pods ipam-controller-manager estão falhando com erros CrashLoopBackOff:

kubectl -n kube-system get pods | grep  ipam-controller-manager

O exemplo de saída a seguir mostra pods em um estado CrashLoopBackOff:

ipam-controller-manager-h7xb8   0/1  CrashLoopBackOff   3 (19s ago)   2m ipam-controller-manager-vzrrf   0/1  CrashLoopBackOff   3 (19s ago)   2m1s
ipam-controller-manager-z8bdw   0/1  CrashLoopBackOff   3 (31s ago)   2m2s

Saiba detalhes sobre o nó que está no estado NotReady:

kubectl describe node <node-name> | grep PodCIDRs

Em um cluster com esse problema, um nó não tem PodCIDRs atribuídos a ele, conforme mostrado no exemplo de saída a seguir:

PodCIDRs:

Em um cluster íntegro, todos os nós precisam ter PodCIDRs de pilha dupla atribuídos a ele, conforme mostrado no exemplo de saída a seguir:

PodCIDRs:    192.168.6.0/24,222:333:444:555:5:4:7:0/120

Alternativa:

Reinicie os pods ipam-controller-manager:

kubectl -n kube-system rollout restart ds ipam-controller-manager
Operação 1.6, 1.7, 1.8, 1.9, 1.10, 1.11, 1.12, 1.13 e 1.14

Os clusters que executam o etcd versão 3.4.13 ou anterior podem apresentar privação do relógio e relógios de recursos não operacionais, que podem causar os seguintes problemas:

  • A programação do pod é interrompida
  • Não é possível registrar nós
  • O kubelet não observa mudanças no pod

Esses problemas podem tornar o cluster não funcional.

Esse problema foi corrigido nas versões 1.12.9 e 1.13.6 do Google Distributed Cloud. 1.14.3 e versões subsequentes. Essas versões mais recentes usam o etcd versão 3.4.21. Todas as versões anteriores do Google Distributed Cloud são afetadas pela problema.

Alternativa

Se não for possível fazer upgrade imediatamente, reduza o risco de falha do cluster diminuindo seu número de nós. Remova os nós até que a métrica etcd_network_client_grpc_sent_bytes_total seja inferior a 300 MBps.

Para visualizar essa métrica no Metrics Explorer:

  1. Acesse o Metrics Explorer no console Google Cloud :

    Acessar o Metrics Explorer

  2. Selecione a guia Configuração.
  3. Expanda Selecionar uma métrica, insira Kubernetes Container na barra de filtros e use os submenus para selecionar a métrica:
    1. No menu Recursos ativos, selecione Contêiner do Kubernetes.
    2. No menu Categorias de métricas ativas, selecione Anthos.
    3. No menu Métricas ativas, selecione etcd_network_client_grpc_sent_bytes_total.
    4. Clique em Aplicar.
Rede 1.11.6, 1.12.3

O syncStatus do objeto SriovNetworkNodeState pode informar o valor "com falha" em um nó configurado. Para conferir o status de um nó e determinar se o problema afeta você, execute o seguinte comando:

kubectl -n gke-operators get \
    sriovnetworknodestates.sriovnetwork.k8s.cni.cncf.io NODE_NAME \
    -o jsonpath='{.status.syncStatus}'

Substitua NODE_NAME pelo nome do nó a ser verificado.


Alternativa:

Se o status do objeto SriovNetworkNodeState for "Com falha", fazer upgrade do cluster para a versão 1.11.7 ou posterior, a versão 1.12.4 ou mais tarde.
Upgrades e atualizações 1.10, 1.11, 1.12, 1.13, 1.14.0, 1.14.1

Quando o upgrade for concluído, alguns nós de trabalho poderão ter a condição "Pronto" definida como false. No recurso de nó, você vai ver um erro ao lado da condição "Pronto", como no exemplo a seguir:

container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:Network plugin returns error: cni plugin not initialized

Quando você faz login na máquina parada, a configuração CNI na máquina está vazia:

sudo ls /etc/cni/net.d/

Alternativa

Reinicie o pod anetd do nó excluindo-o.
Upgrades e atualizações, segurança 1.10

Após várias rotações manuais ou de certificado automático, o pod do webhook, como anthos-cluster-operator, não é atualizado com os novos certificados emitidos por cert-manager. Qualquer atualização do recurso personalizado de cluster falhará e resultará em um erro semelhante a este: 

Internal error occurred: failed calling
webhook "vcluster.kb.io": failed to call webhook: Post "https://webhook-service.kube-system.svc:443/validate-baremetal-cluster-gke-io-v1-cluster?timeout=10s": x509: certificate signed by unknown authority (possibly because of "x509:
invalid signature: parent certificate cannot sign this kind of certificate"
while trying to verify candidate authority certificate
"webhook-service.kube-system.svc")

Esse problema pode ocorrer nas seguintes circunstâncias:

  • Se você fez duas rotações manuais de certificados emitidos pelo gerenciador de certificados estão em um cluster com mais de 180 dias ou mais e nunca reiniciou o anthos-cluster-operator;
  • Se você tiver emitido um cert-manager manualmente rotações de certificados em um cluster com mais de 90 dias ou mais e nunca reiniciou o anthos-cluster-operator.

Alternativa

Reinicie o pod encerrando o anthos-cluster-operator.
Upgrades e atualizações 1.14.0

Nos clusters de administrador da versão 1.14.0, um ou mais pods do implantador do controlador de ciclo de vida desatualizados podem ser criados durante os upgrades de clusters de usuários. Esse problema se aplica a clusters de usuários criados inicialmente em versões anteriores à 1.12. Os pods criados acidentalmente não impedem de upgrade, mas elas podem ser encontradas em um estado inesperado. Recomendamos que você remova os pods desatualizados.

Esse problema foi corrigido na versão 1.14.1.

Alternativa:

Para remover os pods do implantador do controlador de ciclo de vida desatualizados:

  1. Liste recursos de verificação de simulação: 
    kubectl get preflightchecks --kubeconfig ADMIN_KUBECONFIG -A

    A saída é assim:

    NAMESPACE                    NAME                      PASS   AGE
cluster-ci-87a021b9dcbb31c   ci-87a021b9dcbb31c        true   20d
cluster-ci-87a021b9dcbb31c   ci-87a021b9dcbb31cd6jv6   false  20d

    em que ci-87a021b9dcbb31c é o nome do cluster.

  2. Exclua os recursos em que o valor na coluna PASS seja true ou false.

    Por exemplo, para excluir os recursos na amostra de saída anterior, use os seguintes comandos:

    kubectl delete preflightchecks ci-87a021b9dcbb31c \
    -n cluster-ci-87a021b9dcbb31c \
    --kubeconfig ADMIN_KUBECONFIG 
kubectl delete preflightchecks ci-87a021b9dcbb31cd6jv6 \
    -n cluster-ci-87a021b9dcbb31c \
    --kubeconfig ADMIN_KUBECONFIG
Rede 1.9, 1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28

A rede avançada do Google Distributed Cloud falha ao gerenciar as sessões do BGP corretamente quando pares externos anunciam um grande número de rotas (cerca de 100 ou mais). Com um grande número de rotas de entrada, o controlador do BGP local do nó leva muito tempo para reconciliar as sessões do BGP e falha ao atualizar o status. A falta de atualizações de status ou de uma verificação de integridade faz com que a sessão seja excluída por estar desatualizada.

Comportamento indesejável em sessões do BGP que você pode perceber e indicar um problema:

  • Exclusão e recriação contínuas do bgpsession.
  • bgpsession.status.state nunca se torna Established.
  • Rotas que não anunciam ou são repetidas e anunciadas.

Os problemas de balanceamento de carga do BGP podem ser notados com problemas de conectividade com os serviços de LoadBalancer.

O problema FlatIP do BGP pode ser perceptível com problemas de conectividade nos pods.

Para determinar se os problemas do BGP são causados pelos pares remotos que anunciam muitas rotas, use os seguintes comandos para analisar os status e a saída associados:

  • Use kubectl get bgpsessions no cluster afetado. A saída mostra bgpsessions com o estado "Não estabelecido" e o tempo do último relatório é contabilizado continuamente de cerca de 10 a 12 segundos antes de parecer zerado.
  • A saída de kubectl get bgpsessions mostra que as sessões afetadas estão sendo recriadas repetidamente: 
    kubectl get bgpsessions \
    -o jsonpath="{.items[*]['metadata.name', 'metadata.creationTimestamp']}"
  • As mensagens de registro indicam que as sessões do BGP desatualizadas estão sendo excluídas: 
    kubectl logs ang-controller-manager-POD_NUMBER

    Substitua POD_NUMBER pelo pod líder no cluster.


Alternativa:

Reduza ou elimine o número de rotas anunciadas do peering remoto para o cluster com uma política de exportação.

Nas versões 1.14.2 e mais recentes, também é possível desativar o recurso que processa rotas recebidas usando um AddOnConfiguration. Adicione o argumento --disable-received-routes ao contêiner bgpd do daemonset ang-daemon.
Rede 1.14, 1.15, 1.16, 1.28

Os clusters em execução em um SO Ubuntu que usa o kernel 5.15 ou posterior são suscetíveis a falhas na inserção de tabela do rastreamento de conexão de rede (conntrack). As falhas de inserção podem ocorrer mesmo quando a tabela de conntrack tiver espaço para novas entradas. As falhas são causadas por alterações no kernel 5.15 e mais recentes que restringem as inserções de tabelas com base no comprimento da cadeia.

Para ver se você foi afetado por esse problema, verifique as estatísticas do sistema de rastreamento de conexão no kernel com o seguinte comando:

sudo conntrack -S

A resposta será assim:

cpu=0       found=0 invalid=4 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=1       found=0 invalid=0 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=2       found=0 invalid=16 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=3       found=0 invalid=13 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=4       found=0 invalid=9 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=5       found=0 invalid=1 insert=0 insert_failed=0 drop=0 early_drop=0 error=519 search_restart=0 clash_resolve=126 chaintoolong=0
...

Se o valor chaintoolong na resposta for um número diferente de zero, esse problema afeta você.

Alternativa

A mitigação de curto prazo aumenta o tamanho da tabela de hash netfiler (nf_conntrack_buckets) e da tabela de rastreamento de conexão do netfilter (nf_conntrack_max). Use os seguintes comandos em cada nó de cluster para aumentar o tamanho das tabelas:

sysctl -w net.netfilter.nf_conntrack_buckets=TABLE_SIZE

sysctl -w net.netfilter.nf_conntrack_max=TABLE_SIZE

Substitua TABLE_SIZE pelo novo tamanho em bytes. O valor padrão de tamanho da tabela é 262144. Sugerimos definir um valor igual a 65.536 vezes o número de núcleos no nó. Por exemplo, se o nó tiver oito núcleos, defina o tamanho da tabela como 524288.
Upgrades e atualizações 1.11.3, 1.11.4, 1.11.5, 1.11.6, 1.11.7, 1.11.8, 1.12.4, 1.12.5, 1.12.6, 1.12.7, 1.12.8, 1.13.4, 1.13.5

Recomendamos que você faça backup dos clusters antes de fazer upgrade para restaurar a versão anterior se a atualização não for bem-sucedida. Um problema com o comando bmctl restore cluster faz com que ele não restaure backups de clusters com as versões identificadas. Esse problema é específico para upgrades, em que você está restaurando um backup de uma versão anterior.

Se o cluster for afetado, o registro bmctl restore cluster conterá este erro:

Error: failed to extract image paths from profile: anthos version VERSION not supported

Alternativa:

Até que esse problema seja corrigido, recomendamos usar as instruções em Fazer backup e restaurar clusters para fazer backup manual e restaurar os clusters manualmente, se necessário.
Rede 1.10, 1.11, 1.12, 1.13, 1.14.0-1.14.2

NetworkGatewayGroup falha ao criar daemons para nós que não têm interfaces IPv4 e IPv6. Isso faz com que recursos como o BGP LB e EgressNAT falhem. Se você verificar os registros do pod ang-node com falha no namespace kube-system, erros semelhantes ao exemplo a seguir serão exibidos quando um endereço IPv6 estiver ausente:

ANGd.Setup    Failed to create ANG daemon    {"nodeName": "bm-node-1", "error":
"creating NDP client failed: ndp: address \"linklocal\" not found on interface \"ens192\""}

No exemplo anterior, não há endereço IPv6 na interface ens192. Erros de ARP semelhantes são exibidos se o nó estiver sem um endereço IPv4.

NetworkGatewayGroup tenta estabelecer uma conexão ARP e uma conexão NDP para o endereço IP local do link. Se o endereço IP não existir (IPv4 para ARP, IPv6 para NDP), a conexão falhará e o daemon não continuará.

Esse problema foi corrigido na versão 1.14.3.


Alternativa:

Conecte-se ao nó usando SSH e adicione um endereço IPv4 ou IPv6 ao link que contém o IP do nó. No exemplo de entrada de registro anterior, a interface era ens192:

ip address add dev INTERFACE scope link ADDRESS

Substitua:

  • INTERFACE: a interface do nó, como ens192.
  • ADDRESS: o endereço IP e a máscara de sub-rede a serem aplicados à interface.
Redefinir/excluir 1.10, 1.11, 1.12, 1.13.0-1.13.2

Ao tentar remover um nó do plano de controle removendo o endereço IP de Cluster.Spec, o anthos-cluster-operator entra em um estado de loop de falha que bloqueia outras operações.


Alternativa:

O problema foi corrigido nas versões 1.13.3 e 1.14.0 e posteriores. Todas as outras versões são afetadas. Fazer upgrade para uma das versões fixas

Como solução alternativa, execute o seguinte comando:

kubectl label baremetalmachine IP_ADDRESS \
    -n CLUSTER_NAMESPACE baremetal.cluster.gke.io/upgrade-apply-

Substitua:

  • IP_ADDRESS: o endereço IP do nó em um estado de loop de falha.
  • CLUSTER_NAMESPACE: o namespace do cluster.
Instalação 1.13.1, 1.13.2 e 1.13.3

Ao instalar clusters com muitos nós, poderá receber uma mensagem de erro kubeadmin join semelhante à exemplo a seguir:

TASK [kubeadm : kubeadm join --config /dev/stdin --ignore-preflight-errors=all] ***
fatal: [10.200.0.138]: FAILED! => {"changed": true, "cmd": "kubeadm join
--config /dev/stdin --ignore-preflight-errors=all", "delta": "0:05:00.140669", "end": "2022-11-01 21:53:15.195648", "msg": "non-zero return code", "rc": 1,
"start": "2022-11-01 21:48:15.054979", "stderr": "W1101 21:48:15.082440   99570 initconfiguration.go:119]
Usage of CRI endpoints without URL scheme is deprecated and can cause kubelet errors in the future.
Automatically prepending scheme \"unix\" to the \"criSocket\" with value \"/run/containerd/containerd.sock\". Please update your configuration!\nerror
execution phase preflight: couldn't validate the identity of the API Server: could not find a JWS signature in the cluster-info ConfigMap for token ID \"yjcik0\"\n
To see the stack trace of this error execute with --v=5 or higher", "stderr_lines":
["W1101 21:48:15.082440   99570 initconfiguration.go:119] Usage of CRI endpoints without URL scheme is deprecated and can cause kubelet errors in the future.
Automatically prepending scheme \"unix\" to the \"criSocket\" with value \"/run/containerd/containerd.sock\".
Please update your configuration!", "error execution phase preflight: couldn't validate the identity of the API Server:
could not find a JWS signature in the cluster-info ConfigMap for token ID \"yjcik0\"",
"To see the stack trace of this error execute with --v=5 or higher"], "stdout": "[preflight]
Running pre-flight checks", "stdout_lines": ["[preflight] Running pre-flight checks"]}

Alternativa:

Esse problema foi resolvido no Google Distributed Cloud versão 1.13.4 e mais recentes.

Se você precisar usar uma versão afetada, primeiro crie um cluster com menos de 20 nós e, em seguida, redimensione o cluster para adicionar outros nós após a conclusão da instalação.
Geração de registros e monitoramento 1.10, 1.11, 1.12 e 1.13.0

Nos clusters do Google Distributed Cloud Edge, os limites baixos de CPU para metrics-server pode causar reinicializações frequentes do metrics-server: O escalonamento automático horizontal de pods (HPA, na sigla em inglês) não funciona porque metrics-server não está íntegro.

Se o limite de CPU de metrics-server for menor que 40m, os clusters poderão ser afetados. Para verificar os limites de CPU de metrics-server, consulte um dos seguintes arquivos:

  • Versões do cluster 1.x-1.12: 
    kubectl get deployment metrics-server -n kube-system \
    -o yaml > metrics-server.yaml
  • Versões 1.13 ou mais recentes do cluster: 
    kubectl get deployment metrics-server -n gke-managed-metrics-server \
    -o yaml > metrics-server.yaml

Alternativa:

Esse problema foi resolvido nas versões de cluster 1.13.1 ou mais recentes. Para corrigir esse problema, faça upgrade dos clusters.

Uma solução alternativa de curto prazo até que seja possível fazer upgrade dos clusters é aumentar manualmente os limites da CPU para metrics-server da seguinte maneira:

  1. Reduza o escalonamento vertical de metrics-server-operator: 
    kubectl scale deploy metrics-server-operator --replicas=0
  2. Atualize a configuração e aumente os limites da CPU:
    • Versões de clusters 1.x-1.12: 
      kubectl -n kube-system edit deployment metrics-server
    • Versões 1.13 dos clusters: 
      kubectl -n gke-managed-metrics-server edit deployment metrics-server

    Remova a linha --config-dir=/etc/config e aumente os limites de CPU, conforme mostrado no exemplo a seguir:

    [...]
- command:
- /pod_nanny
# - --config-dir=/etc/config # <--- Remove this line
- --container=metrics-server
- --cpu=50m # <--- Increase CPU, such as to 50m
- --extra-cpu=0.5m
- --memory=35Mi
- --extra-memory=4Mi
- --threshold=5
- --deployment=metrics-server
- --poll-period=30000
- --estimator=exponential
- --scale-down-delay=24h
- --minClusterSize=5
- --use-metrics=true
[...]
  3. Salve e feche a metrics-server para aplicar as mudanças.
Rede 1.14, 1.15, 1.16

A conexão com um pod ativado com hostNetwork via serviço NodePort falha quando o pod de back-end está no mesmo nó que o NodePort segmentado. Isso afeta os serviços LoadBalancer quando usado com pods hospedados pela rede de rede. Com vários back-ends, pode ocorrer uma falha esporádica de conexão.

Esse problema é causado por um bug no programa eBPF.


Alternativa:

Ao usar um serviço do Nodeport, não segmente o nó em que algum dos pods de back-end é executado. Ao usar o serviço LoadBalancer, verifique se os pods hospedados pela rede não são executados nos nós do LoadBalancer.
Upgrades e atualizações 1.12.3, 1.13.0

Os clusters de administrador que executam a versão 1.13.0 não podem gerenciar clusters de usuário que executam a versão 1.12.3. As operações em um cluster de usuário da versão 1.12.3 falham.


Alternativa:

Faça upgrade do cluster de administrador para a versão 1.13.1 ou faça upgrade para a mesma versão do cluster de administrador.
Upgrades e atualizações 1.12

Os clusters de administrador da versão 1.13.0 e superior não podem conter pools de nós de trabalho. Os upgrades para a versão 1.13.0 ou posterior para clusters de administrador com pools de nós de trabalho estão bloqueados. Se o upgrade do cluster de administrador estiver interrompido, verifique o seguinte erro no arquivo upgrade-cluster.log dentro da pasta bmctl-workspace para confirmar se os pools de nós de trabalho são a causa:

Operation failed, retrying with backoff. Cause: error creating "baremetal.cluster.gke.io/v1, Kind=NodePool" cluster-test-cluster-2023-06-06-140654/np1: admission webhook "vnodepool.kb.io" denied the request: Adding worker nodepool to Admin cluster is disallowed.

Alternativa:

Antes de fazer upgrade, mova todos os pools de nós de trabalho para clusters de usuário. Para instruções sobre como adicionar e remover pools de nós, consulte Gerenciar pools de nós em um cluster.

Upgrades e atualizações 1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28

Se você atualizar recursos, como os recursos personalizados ClientConfig ou Stackdriver usando kubectl apply, o controlador poderá retornar um erro ou reverter a entrada e as mudanças planejadas.

Por exemplo, tente editar o recurso personalizado Stackdriver da seguinte maneira: primeiro acesse o recurso e, em seguida, aplique uma versão atualizada:

  1. Encontre a definição YAML atual: 
    kubectl get stackdriver -n kube-system stackdriver \
    -o yaml > stackdriver.yaml
  2. Ative os recursos ou atualize a configuração no arquivo YAML.
  3. Aplique o arquivo YAML atualizado: 
    kubectl apply -f stackdriver.yaml

A etapa final para kubectl apply é onde você pode encontrar problemas.


Alternativa:

Não use kubectl apply para fazer alterações nos recursos. Em vez disso, use kubectl edit ou kubectl patch, conforme mostrado nos exemplos a seguir:

  1. Edite o recurso personalizado Stackdriver: 
    kubectl edit stackdriver -n kube-system stackdriver
  2. Ative os recursos ou atualize a configuração no arquivo YAML.
  3. Salvar e sair do editor

Abordagem alternativa usando kubectl patch:

  1. Encontre a definição YAML atual: 
    kubectl get stackdriver -n kube-system stackdriver \
    -o yaml > stackdriver.yaml
  2. Ative os recursos ou atualize a configuração no arquivo YAML.
  3. Aplique o arquivo YAML atualizado: 
    kubectl patch stackdriver stackdriver --type merge \
    -n kube-system --patch-file stackdriver.yaml
Geração de registros e monitoramento 1.12, 1.13, 1.14, 1.15, 1.16

O loop de falhas stackdriver-log-forwarder se tentar processar um bloco de backlog corrompido. Os seguintes erros de exemplo são mostrados nos registros do contêiner:

[2022/09/16 02:05:01] [error] [storage] format check failed: tail.1/1-1659339894.252926599.flb
[2022/09/16 02:05:01] [error] [engine] could not segregate backlog chunks

Quando esse loop de falhas ocorre, não é possível ver registros no Cloud Logging.


Alternativa:

Para resolver esses erros, siga estas etapas:

  1. Identificar os pedaços de backlog corrompidos. Veja os exemplos de mensagens de erro abaixo: 
    [2022/09/16 02:05:01] [error] [storage] format check failed: tail.1/1-1659339894.252926599.flb
[2022/09/16 02:05:01] [error] [engine] could not segregate backlog chunks
    Neste exemplo, o arquivo tail.1/1-1659339894.252926599.flb armazenado em var/log/fluent-bit-buffers/tail.1/ está com falha. Todos os arquivos *.flb com falha na verificação do formato precisam ser removidos.
  2. Encerre os pods em execução para stackdriver-log-forwarder: 
    kubectl --kubeconfig KUBECONFIG -n kube-system \
    patch daemonset stackdriver-log-forwarder \
    -p '{"spec": {"template": {"spec": {"nodeSelector": {"non-existing": "true"}}}}}'
     Substitua KUBECONFIG pelo caminho para o arquivo kubeconfig do cluster de usuário.

    Verifique se os pods de stackdriver-log-forwarder foram excluídos antes de ir para a próxima etapa.
  3. Conecte-se ao nó usando SSH em que stackdriver-log-forwarder esteja em execução.
  4. No nó, exclua todos os arquivos *.flb corrompidos em var/log/fluent-bit-buffers/tail.1/.

    Se houver muitos arquivos corrompidos e você quiser aplicar um script para limpar todos os blocos de backlog, use os seguintes scripts:
    1. Implante um DaemonSet para limpar todos os dados sujos em buffers em fluent-bit: 
      kubectl --kubeconfig KUBECONFIG -n kube-system apply -f - << EOF
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluent-bit-cleanup
  namespace: kube-system
spec:
  selector:
    matchLabels:
      app: fluent-bit-cleanup
  template:
    metadata:
      labels:
        app: fluent-bit-cleanup
    spec:
      containers:
      - name: fluent-bit-cleanup
        image: debian:10-slim
        command: ["bash", "-c"]
        args:
        - |
          rm -rf /var/log/fluent-bit-buffers/
          echo "Fluent Bit local buffer is cleaned up."
          sleep 3600
        volumeMounts:
        - name: varlog
          mountPath: /var/log
        securityContext:
          privileged: true
      tolerations:
      - key: "CriticalAddonsOnly"
        operator: "Exists"
      - key: node-role.kubernetes.io/master
        effect: NoSchedule
      - key: node-role.gke.io/observability
        effect: NoSchedule
      volumes:
      - name: varlog
        hostPath:
          path: /var/log
EOF
    2. Verifique se o DaemonSet limpou todos os nós. A saída dos dois comandos a seguir precisa ser igual ao número de nós no cluster: 
      kubectl --kubeconfig KUBECONFIG logs \
    -n kube-system -l app=fluent-bit-cleanup | grep "cleaned up" | wc -l
kubectl --kubeconfig KUBECONFIG \
    -n kube-system get pods -l app=fluent-bit-cleanup --no-headers | wc -l
    3. Exclua o DaemonSet de limpeza. 
      kubectl --kubeconfig KUBECONFIG -n kube-system delete ds \
    fluent-bit-cleanup
    4. Reinicie os pods stackdriver-log-forwarder: 
      kubectl --kubeconfig KUBECONFIG \
    -n kube-system patch daemonset stackdriver-log-forwarder --type json \
    -p='[{"op": "remove", "path": "/spec/template/spec/nodeSelector/non-existing"}]'
Rede, ambiente de execução de VM no GDC 1.14.0

Em clusters multi-nic, a reinicialização do Dataplane V2 (anetd) pode impedir que máquinas virtuais sejam anexadas a redes. Um erro semelhante ao seguinte pode ser observado nos registros de pods anetd:

could not find an allocator to allocate the IP of the multi-nic endpoint

Alternativa:

É possível reiniciar a VM para corrigir rapidamente. Para evitar a recorrência do faça o upgrade do cluster para a versão 1.14.1 ou posterior.
Operação 1.13, 1.14.0, 1.14.1

Dependendo da carga de trabalho do cluster, o gke-metrics-agent pode usar mais de 4.608 MiB de memória. Esse problema afeta apenas os clusters de perfil do Google Distributed Cloud para bare metal Edge. Os clusters de perfil padrão não são afetados.


Alternativa:

Faça upgrade do cluster para a versão 1.14.2 ou posterior.
Instalação 1.12, 1.13

Quando você cria clusters usando kubectl, devido às condições de corrida, a verificação de simulação nunca será concluída. Como resultado, a criação do cluster pode falhar em alguns casos.

O reconciliador de verificação de simulação cria um SecretForwarder para copiar o secret ssh-key padrão para o namespace de destino. Normalmente, a verificação de simulação é usada nas referências do proprietário e é reconciliada quando a SecretForwarder é concluída. Em casos raros, as referências do proprietário de SecretForwarder podem perder a referência à verificação de simulação, fazendo com que ela fique travada. Como resultado, a criação do cluster falha. Para continuar a reconciliação da verificação de simulação orientada pelo controlador, exclua o pod do operador de cluster ou o recurso de verificação de simulação. Quando você exclui o recurso de verificação de simulação, ele cria outro e continua a reconciliação. Como alternativa, é possível fazer upgrade dos clusters (que foram criados com uma versão anterior) para uma versão fixa.

Rede 1.9, 1.10, 1.11, 1.12, 1.13, 1.14, 1.15

No recurso multi-Nic, se você estiver usando o plug-in CNI whereabouts e usar a operação CNI DEL para excluir uma interface de rede de um pod, é possível que alguns endereços IP reservados não sejam liberados corretamente. Isso acontece quando a operação CNI DEL é interrompida.

É possível verificar as reservas de endereços IP não utilizados dos pods executando o seguinte comando:

kubectl get ippools -A --kubeconfig KUBECONFIG_PATH

Alternativa:

Exclua manualmente os endereços IP (ippools) que não são usados.
Instalação 1.10, 1.11.0, 1.11.1, 1.11.2

O Detector de problemas do nó pode falhar nos clusters de usuário da versão 1.10.x, quando clusters de administrador versão 1.11.0, 1.11.1 ou 1.11.2 gerenciar clusters de usuário 1.10.x. Quando o detector de problemas do nó falha, o registro é atualizado com a seguinte mensagem de erro:

Error - NPD not supported for anthos baremetal version 1.10.4:
anthos version 1.10.4 not supported.

Alternativa

Faça upgrade do cluster de administrador para 1.11.3 para resolver o problema.
Operação 1.14

Na versão 1.14, amaxPodsPerNode não é considerada paraclusters no modo de ilha , portanto, os nós recebem um tamanho de máscara CIDR de pod de 24 (256 endereços IP).Isso pode fazer com que o cluster fique sem endereços IP do pod antes do esperado. Por exemplo, se o cluster tiver um tamanho de máscara CIDR de pod de 22, Cada nó receberá uma máscara CIDR de pod de 24, e o cluster será compatível com até quatro nós. Seu cluster também pode ter instabilidade de rede em um período de alto desligamento de pods quando maxPodsPerNode estiver definido como 129 ou mais e não houver sobrecarga suficiente no CIDR do pod para cada nó.

Se o cluster for afetado, o pod anetd informará o seguinte erro quando você adicionar um novo nó ao cluster e não houver podCIDR disponível:

error="required IPv4 PodCIDR not available"

Alternativa

Siga estas etapas para resolver o problema:

  1. Faça upgrade para a versão 1.14.1 ou posterior.
  2. Remova os nós de trabalho e adicione-os novamente.
  3. Remova os nós do plano de controle e adicione-os novamente, de preferência um a um para evitar a inatividade do cluster.
Upgrades e atualizações 1.14.0, 1.14.1

Uma reversão de upgrade pode falhar para clusters da versão 1.14.0 ou 1.14.1. Se você fizer upgrade de um cluster de 1.14.0 para 1.14.1 e tentar reverter para 1.14.0 usando o comando bmctl restore cluster, um erro como o exemplo a seguir poderá ser retornado:

I0119 22:11:49.705596  107905 client.go:48] Operation failed, retrying with backoff.
Cause: error updating "baremetal.cluster.gke.io/v1, Kind=HealthCheck" cluster-user-ci-f3a04dc1b0d2ac8/user-ci-f3a04dc1b0d2ac8-network: admission webhook "vhealthcheck.kb.io"
denied the request: HealthCheck.baremetal.cluster.gke.io "user-ci-f3a04dc1b0d2ac8-network" is invalid:
Spec: Invalid value: v1.HealthCheckSpec{ClusterName:(*string)(0xc0003096e0), AnthosBareMetalVersion:(*string)(0xc000309690),
Type:(*v1.CheckType)(0xc000309710), NodePoolNames:[]string(nil), NodeAddresses:[]string(nil), ConfigYAML:(*string)(nil),
CheckImageVersion:(*string)(nil), IntervalInSeconds:(*int64)(0xc0015c29f8)}: Field is immutable

Alternativa:

Exclua todos os recursos healthchecks.baremetal.cluster.gke.io no namespace do cluster e execute novamente o comando bmctl restore cluster:

  1. Listar todos os recursos healthchecks.baremetal.cluster.gke.io 
    kubectl get healthchecks.baremetal.cluster.gke.io \
    --namespace=CLUSTER_NAMESPACE \
    --kubeconfig=ADMIN_KUBECONFIG

    Substitua:

    • CLUSTER_NAMESPACE: o namespace do cluster.
    • ADMIN_KUBECONFIG: o caminho até o arquivo kubeconfig do cluster de administrador.
  2. Exclua todos os healthchecks.baremetal.cluster.gke.io recursos listados na etapa anterior: 
    kubectl delete healthchecks.baremetal.cluster.gke.io \
    HEALTHCHECK_RESOURCE_NAME \
    --namespace=CLUSTER_NAMESPACE \
    --kubeconfig=ADMIN_KUBECONFIG
     Substitua HEALTHCHECK_RESOURCE_NAME pelo nome dos recursos de verificação de integridade.
  3. Execute novamente o comando bmctl restore cluster.
Rede 1.12.0

Em um cluster com flatIPv4 definido como true, os serviços do tipo LoadBalancer não podem ser acessados pelos endereços IP externos.

Esse problema foi corrigido na versão 1.12.1.


Alternativa:

No ConfigMap cilium-config, defina enable-415 como "true" e reinicie os pods anetd.
Upgrades e atualizações 1.13.0, 1.14

Quando você tenta fazer um upgrade de 1.13.0 para 1.14.x no local usando bmctl 1.14.0 e a flag --use-bootstrap=false, o upgrade não é concluído.

Um erro com o operador preflight-check faz com que o cluster nunca programe as verificações necessárias, o que significa que a verificação de simulação nunca termina.


Alternativa:

Faça um upgrade para a versão 1.13.1 antes de fazer upgrade para a versão 1.14.x. Um upgrade de 1.13.0 para 1.13.1 no local deve funcionar. Ou faça upgrade da versão 1.13.0 para 1.14.x sem a flag --use-bootstrap=false.
Upgrades e atualizações, segurança 1.13 e 1.14

Os nós do plano de controle exigem um de dois taints específicos para evitar que os pods de carga de trabalho sejam programados neles. Quando você faz upgrade dos clusters da versão 1.13 para a versão 1.14.0, os nós do plano de controle perdem os seguintes taints necessários:

  • node-role.kubernetes.io/master:NoSchedule
  • node-role.kubernetes.io/master:PreferNoSchedule

Esse problema não causa falhas de upgrade, mas pods que não podem ser executados nos nós do plano de controle podem começar a fazer isso. Esses pods de carga de trabalho podem sobrecarregar os nós do plano de controle e causar instabilidade no cluster.

Determine se você será afetado

  1. Encontre os nós do plano de controle usando o seguinte comando: 
    kubectl get node -l 'node-role.kubernetes.io/control-plane' \
    -o name --kubeconfig KUBECONFIG_PATH
  2. Para verificar a lista de taints em um nó, use o seguinte comando: 
    kubectl describe node NODE_NAME \
    --kubeconfig KUBECONFIG_PATH

    Se nenhum dos taints necessários estiver listado, isso vai afetar você.

Alternativa

Siga as etapas a seguir para cada nó do plano de controle do cluster afetado da versão 1.14.0 para restaurar a função adequada. Estas etapas são para o taint node-role.kubernetes.io/master:NoSchedule e os pods relacionados. Se você pretende que os nós do plano de controle usem o taint PreferNoSchedule, ajuste as etapas de acordo.
Operação, ambiente de execução de VM no GDC 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28, 1.29, 1.30, 1.31

Às vezes, criar uma nova máquina virtual (VM) com o comando kubectl virt create vm falha durante o upload da imagem. Esse problema se aplica a VMs do Linux e do Windows. O erro será semelhante ao exemplo abaixo: 

PVC default/heritage-linux-vm-boot-dv not found DataVolume default/heritage-linux-vm-boot-dv created
Waiting for PVC heritage-linux-vm-boot-dv upload pod to be ready... Pod now ready
Uploading data to https://10.200.0.51

 2.38 MiB / 570.75 MiB [>----------------------------------------------------------------------------------]   0.42% 0s

fail to upload image: unexpected return value 500,  ...

Alternativa

Repita o comando kubectl virt create vm para criar a VM.
Upgrades e atualizações, Logging e monitoramento 1.11

Os componentes da coleção gerenciada fazem parte do Serviço gerenciado para Prometheus. Se você implantou manualmente componentes de coleta gerenciada no namespace gmp-system dos clusters da versão 1.11, os recursos associados não serão preservados quando você fizer upgrade para a versão 1.12.

A partir da versão 1.12.0 de clusters, o serviço gerenciado para componentes do Prometheus no namespace gmp-system e as definições personalizadas de recursos são gerenciadas stackdriver-operator com enableGMPForApplications . O campo enableGMPForApplications é true por padrão, portanto, se você implantar manualmente os componentes do Serviço gerenciado para Prometheus no namespace antes de atualizar para a versão 1.12, os recursos serão excluídos por stackdriver-operator.

Alternativa

Para preservar os recursos de coleta gerenciados manualmente, faça o seguinte:

  1. faça o backup de todos os recursos personalizados atuais do PodMonitoring.
  2. faça upgrade do cluster para a versão 1.12 e ative o Serviço gerenciado para Prometheus.
  3. reimplante os recursos personalizados do PodMonitoring no cluster atualizado.
Upgrades e atualizações 1.13

Se um cluster da versão 1.12 que usa o ambiente de execução de contêiner do Docker não tiver a seguinte anotação, ele não poderá fazer upgrade para a versão 1.13:

baremetal.cluster.gke.io/allow-docker-container-runtime:  "true"

Se esse problema afetar você, bmctl gravará o seguinte erro no arquivo upgrade-cluster.log dentro da pasta bmctl-workspace:

Operation failed, retrying with backoff. Cause: error creating "baremetal.cluster.gke.io/v1, Kind=Cluster": admission webhook
"vcluster.kb.io" denied the request: Spec.NodeConfig.ContainerRuntime: Forbidden: Starting with Anthos Bare Metal version 1.13 Docker container
runtime will not be supported. Before 1.13 please set the containerRuntime to containerd in your cluster resources.

Although highly discouraged, you can create a cluster with Docker node pools until 1.13 by passing the flag "--allow-docker-container-runtime" to bmctl
create cluster or add the annotation "baremetal.cluster.gke.io/allow-docker- container-runtime: true" to the cluster configuration file.

É mais provável que isso ocorra com os clusters do Docker da versão 1.12 que passaram por upgrade da versão 1.11, já que esse upgrade não exige a anotação para manter o ambiente de execução do contêiner do Docker. Nesse caso, os clusters não têm a anotação ao fazer upgrade para a versão 1.13. A partir da versão 1.13, containerd é o único ambiente de execução de contêiner permitido.

Alternativa:

Se você for afetado por esse problema, atualize o recurso do cluster com a anotação ausente. É possível adicionar a anotação enquanto o upgrade está em execução ou após o cancelamento e antes de tentar fazer upgrade novamente.
Instalação 1.11

A criação de clusters pode falhar na versão 1.11.0 do Google Distributed Cloud Esse problema foi corrigido na versão 1.11.1 do Google Distributed Cloud. Em alguns casos, o comando bmctl create cluster sai antecipadamente e grava erros como este nos registros:

Error creating cluster: error waiting for applied resources: provider cluster-api watching namespace USER_CLUSTER_NAME not found in the target cluster

Alternativa

A operação com falha produz artefatos, mas o cluster não está operacional. Se esse problema afetar você, use as etapas a seguir para limpar os artefatos e criar um cluster:
Instalação, VM Runtime no GDC 1.11, 1.12

A operação de criação do cluster pode informar um erro semelhante a este:

I0423 01:17:20.895640 3935589 logs.go:82]  "msg"="Cluster reconciling:" "message"="Internal error occurred: failed calling webhook \"vvmruntime.kb.io\": failed to call webhook: Post \"https://vmruntime-webhook-service.kube-system.svc:443/validate-vm-cluster-gke-io-v1vmruntime?timeout=10s\": dial tcp 10.95.5.151:443: connect: connection refused" "name"="xxx" "reason"="ReconciliationError"

Alternativa

Esse erro é benigno e pode ser ignorado com segurança.
Instalação 1.10, 1.11, 1.12

A criação de cluster falha quando você tem a seguinte combinação de condições:

  • O cluster está configurado para usar containerd como o ambiente de execução do contêiner (nodeConfig.containerRuntime definido como containerd no arquivo de configuração do cluster, o valor para o Google Distributed Cloud versão 1.13 e mais recentes).
  • O cluster é configurado para fornecer várias interfaces de rede, multi-NIC, para pods (clusterNetwork.multipleNetworkInterfaces definido como true no arquivo de configuração do cluster).
  • O cluster é configurado para usar um proxy, em que spec.proxy.url é especificado no arquivo de configuração do cluster. Mesmo que a criação do cluster falhe, essa configuração é propagada quando você tenta criar um cluster. É possível ver essa configuração de proxy como uma variável de ambiente HTTPS_PROXY ou na configuração containerd (/etc/systemd/system/containerd.service.d/09-proxy.conf).

Alternativa

Anexe CIDRs de serviço (clusterNetwork.services.cidrBlocks) à variável de ambiente NO_PROXY em todas as máquinas de nó.
Instalação 1.10, 1.11, 1.12

O Google Distributed Cloud versão 1.10.0 introduz um controle sem raiz plano de controle que executa todos os componentes do plano de controle como um ambiente usuário. A execução dos componentes como um usuário não raiz pode causar falhas de instalação ou de upgrade em sistemas com uma configuração umask mais restritiva de 0077.


Alternativa

Redefina os nós do plano de controle e altere a configuração umask para 0022 em todas as máquinas do plano de controle. Após a atualização das máquinas, tente instalar novamente.

Também é possível alterar as permissões de diretório e de arquivo de /etc/kubernetes nas máquinas do plano de controle para que a instalação ou upgrade continue.

  • Torne /etc/kubernetes e todos os subdiretórios globalmente legíveis: chmod o+rx.
  • Transfira todos os arquivos do usuário root no diretório (recursivamente) /etc/kubernetes legível (chmod o+r). Exclua os arquivos de chave privada (.key) dessas alterações, porque eles já foram criados com as permissões e a propriedade corretas.
  • Torne /usr/local/etc/haproxy/haproxy.cfg legível.
  • Torne /usr/local/etc/bgpadvertiser/bgpadvertiser-cfg.yaml legível.
Instalação 1.10, 1.11, 1.12, 1.13

O grupo de controle v2 (cgroup v2) não é compatível com as versões 1.13 e anteriores do Google Distributed Cloud. No entanto, a versão 1.14 é compatível com o cgroup v2 como um recurso de pré-lançamento . A presença de /sys/fs/cgroup/cgroup.controllers indica que seu sistema usa o cgroup v2.


Alternativa

Se o sistema usa o cgroup v2, faça upgrade do cluster para a versão 1.14.
Instalação 1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28, 1.29

Para instalações acionadas por clusters administrativos ou híbridos (em outras palavras, clusters não criados com bmctl, como clusters de usuários), a verificação de simulação não verifica as credenciais da conta de serviço do Google Cloud ou as permissões associadas.
Instalação 1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28, 1.29, 1.30

Ao instalar clusters bare metal em VMs do vSphere, é preciso desativar as flags tx-udp_tnl-segmentation e tx-udp_tnl-csum-segmentation. Essas flags estão relacionadas à descarga de segmentação de hardware feita pelo driver do vSphere VMXNET3 e não funcionam com o túnel GENEVE de clusters bare metal.


Alternativa

Execute o comando a seguir em cada nó para verificar os valores atuais dessas sinalizações.

ethtool -k NET_INTFC | grep segm

Substitua NET_INTFC pela interface de rede associada ao endereço IP do nó.

A resposta terá entradas como estas:

...
tx-udp_tnl-segmentation: on
tx-udp_tnl-csum-segmentation: on
...
 No RHEL 8.4, ethtool às vezes mostra que essas flags estão desativadas, mas na realidade não estão. Para ter certeza de que estão desativadas, ative-as e depois desative-as com os comandos a seguir. 
ethtool -K ens192 tx-udp_tnl-segmentation on ethtool -K ens192 \
    tx-udp_tnl-csum-segmentation on
ethtool -K ens192 tx-udp_tnl-segmentation off ethtool -K ens192 \
    tx-udp_tnl-csum-segmentation off

Essa alteração de sinalização não permanece nas reinicializações. Configure os scripts de inicialização para definir explicitamente esses sinalizadores quando o sistema for inicializado.
Upgrades e atualizações 1.10

A CLI bmctl não pode criar, atualizar ou redefinir um cluster de usuário com uma versão secundária inferior, independentemente da versão do cluster de administrador. Por exemplo, não é possível usar bmctl com uma versão de 1.N.X para redefinir um cluster de usuário da versão 1.N-1.Y, mesmo que o cluster de administrador também esteja na versão 1.N.X.

Se você for afetado por esse problema, verá os registros semelhantes ao seguinte ao usar bmctl:

[2022-06-02 05:36:03-0500] error judging if the cluster is managing itself: error to parse the target cluster: error parsing cluster config: 1 error occurred:

*   cluster version 1.8.1 isn't supported in bmctl version 1.9.5, only cluster version 1.9.5 is supported

Alternativa:

Use kubectl para criar, editar ou excluir o recurso personalizado do cluster de usuário no cluster de administrador.

A capacidade de fazer upgrade dos clusters de usuário não é afetada.
Upgrades e atualizações 1.12

O upgrade de clusters para a versão 1.12.1 pode demorar devido à indisponibilidade do servidor de API. Esse problema afeta todos os tipos de clusters e todos os sistemas operacionais compatíveis. Quando esse problema ocorre, o comando bmctl upgrade cluster pode falhar em vários pontos, inclusive durante a segunda fase das verificações de simulaçãos


Alternativa

Verifique seus registros de upgrade para saber se você foi afetado por esse problema. Os registros de upgrade estão localizados em /baremetal/bmctl-workspace/CLUSTER_NAME/log/upgrade-cluster-TIMESTAMP por padrão.

O upgrade-cluster.log pode conter erros como os seguintes:

Failed to upgrade cluster: preflight checks failed: preflight check failed
 O registro da máquina pode conter erros como os seguintes (falhas repetidas indicam que você foi afetado por esse problema): 
FAILED - RETRYING: Query CNI health endpoint (30 retries left). FAILED - RETRYING: Query CNI health endpoint (29 retries left).
FAILED - RETRYING: Query CNI health endpoint (28 retries left). ...

O HAProxy e o Keepalived precisam ser executados em cada nó do plano de controle antes de tentar fazer upgrade do cluster para a versão 1.12.1. Use a interface de linha de comando crictl em cada nó para verificar se os contêineres haproxy e keepalived estão em execução:

docker/crictl ps | grep haproxy docker/crictl ps | grep keepalived

Se o HAProxy ou o KeepaLived não estiver em execução em um nó, reinicie o kubelet no nó:

systemctl restart kubelet
Upgrades e atualizações, ambiente de execução de VM no GDC 1.11, 1.12

Nos clusters da versão 1.12.0, todos os recursos relacionados ao O ambiente de execução de VMs na GDC é migrado para o vm-system namespace para oferecer melhor suporte ao ambiente de execução da VM na versão GA do GDC. Se você tem o ambiente de execução de VM no GDC ativado em uma versão 1.11.x ou inferior cluster, o upgrade para a versão 1.12.0 ou superior vai falhar, a menos que desativar o ambiente de execução da VM na GDC. Quando você é afetado por esse problema, a operação de upgrade informa o seguinte erro:

Failed to upgrade cluster: cluster isn't upgradable with vmruntime enabled from
version 1.11.x to version 1.12.0: please disable VMruntime before upgrade to
1.12.0 and higher version

Alternativa

Para desativar o ambiente de execução da VM no GDC:

  1. Edite o recurso personalizado VMRuntime: 
    kubectl edit vmruntime
  2. Defina enabled como false na especificação: 
    apiVersion: vm.cluster.gke.io/v1
kind: VMRuntime
metadata:
  name: vmruntime
spec:
  enabled: false
  ...
  3. Salve o recurso personalizado no seu editor.
  4. Quando o upgrade do cluster for concluído, reative Ambiente de execução de VM na GDC.

Para mais informações, consulte Ativar ou desativar o ambiente de execução de VM no GDC.

Upgrades e atualizações 1.10, 1.11, 1.12

Em algumas situações, os upgrades de cluster não são concluídos e a CLI bmctl não responde. Esse problema pode ser causado por um recurso atualizado incorretamente. Para determinar se você está com esse problema e corrigi-lo, verifique os registros anthos-cluster-operator e procure erros semelhantes às seguintes entradas:

controllers/Cluster "msg"="error during manifests operations" "error"="1 error occurred: ... {RESOURCE_NAME} is invalid: metadata.resourceVersion: Invalid value: 0x0: must be specified for an update

Essas entradas são um sintoma de um recurso atualizado incorretamente, em que {RESOURCE_NAME} é o nome do recurso com problema.


Alternativa

Se você encontrar esses erros nos registros, siga estas etapas:

  1. Use kubectl edit para remover a anotação kubectl.kubernetes.io/last-applied-configuration do recurso contido na mensagem de registro.
  2. Salve e aplique as alterações no recurso.
  3. Tente fazer o upgrade do cluster novamente.
Upgrades e atualizações 1.10, 1.11, 1.12

Os upgrades de cluster da 1.10.x para 1.11.x falham para clusters que usam o gateway NAT de saída ou o balanceamento de carga em pacote com o BGP. Esses recursos usam o gateway de rede para GDC. Os upgrades de cluster ficam travados na mensagem de linha de comando Waiting for upgrade to complete... e os erros anthos-cluster-operator registram o seguinte:

apply run failed ... MatchExpressions:[]v1.LabelSelectorRequirement(nil)}: field
is immutable...

Alternativa

Para desbloquear o upgrade, execute os seguintes comandos no cluster que você está fazendo upgrade:

kubectl -n kube-system delete deployment \
    ang-controller-manager-autoscaler
kubectl -n kube-system delete deployment \
    ang-controller-manager
kubectl -n kube-system delete ds ang-node
Upgrades e atualizações 1.10, 1.11, 1.12, 1.13, 1.14, 1.15

O comando bmctl update não pode remover nem modificar a seção maintenanceBlocks da configuração de recursos do cluster.


Alternativa

Veja mais informações, incluindo instruções sobre a remoção de nós do modo de manutenção em Colocar nós no modo de manutenção.
Operação 1.10, 1.11, 1.12

Se você executar clusters da versão 1.12.0 (anthosBareMetalVersion: 1.12.0) ou inferior e use manualmente kubectl cordon em um nó, o Google Distributed Cloud para bare metal pode remover a restrição antes de estar pronto, em um esforço para reconciliar o estado esperado.


Alternativa

Para a versão 1.12.0 e clusters anteriores, use modo de manutenção para delimitar e drenar nós com segurança.

Na versão 1.12.1 (anthosBareMetalVersion: 1.12.1) ou superior, o Google Distributed Cloud para bare metal não vai desvincular os nós inesperadamente quando use kubectl cordon.
Operação 1.11

Se o cluster de administrador estiver na versão 1.11 e usar um espelho de registro, não será possível gerenciar clusters de usuário que estão em uma versão secundária menor. Esse problema afeta as operações de redefinição, atualização e upgrade no cluster de usuários.

Para determinar se esse problema afeta você, verifique se há operações de cluster nos registros, como criar, fazer upgrade ou redefinir. Por padrão, esses registros ficam localizados na pasta bmctl-workspace/CLUSTER_NAME/. Se você for afetado pelo problema, os registros contêm a seguinte mensagem de erro:

flag provided but not defined: -registry-mirror-host-to-endpoints
Operação 1.10, 1.11

O comando bmctl check cluster, quando executado em clusters de usuários, substitui a chave secreta kubeconfig do cluster de usuário pelo kubeconfig do cluster de administrador. A substituição do arquivo causa falhas nas operações padrão do cluster, como atualização e upgrade, para os clusters de usuário afetados. Esse problema se aplica às versões 1.11.1 e anteriores.

Para determinar se esse problema afeta um cluster de usuário, execute o seguinte comando:

kubectl --kubeconfig ADMIN_KUBECONFIG \
    get secret -n USER_CLUSTER_NAMESPACE \
    USER_CLUSTER_NAME -kubeconfig \
    -o json  | jq -r '.data.value'  | base64 -d

Substitua:

  • ADMIN_KUBECONFIG: o caminho até o arquivo kubeconfig do cluster de administrador.
  • USER_CLUSTER_NAMESPACE: o namespace do cluster. Por padrão, os nomes dos namespaces do cluster são o nome do cluster precedido por cluster-. Por exemplo, se você der o nome de test ao cluster, o namespace será cluster-test.
  • USER_CLUSTER_NAME: o nome do cluster de usuário a ser verificado.

Se o nome do cluster na saída (consulte contexts.context.cluster no exemplo de saída a seguir) for o nome do cluster de administrador, o cluster de usuário especificado será afetado.

apiVersion: v1
clusters:
- cluster:
    certificate-authority-data:LS0tLS1CRU...UtLS0tLQo=
    server: https://10.200.0.6:443
  name: ci-aed78cdeca81874
contexts:
- context:
    cluster: ci-aed78cdeca81
    user: ci-aed78cdeca81-admin
  name: ci-aed78cdeca81-admin@ci-aed78cdeca81
current-context: ci-aed78cdeca81-admin@ci-aed78cdeca81
kind: Config
preferences: {}
users:
- name: ci-aed78cdeca81-admin
  user:
    client-certificate-data: LS0tLS1CRU...UtLS0tLQo=
    client-key-data: LS0tLS1CRU...0tLS0tCg==

Alternativa

As etapas a seguir restauram a função em um cluster de usuário afetado (USER_CLUSTER_NAME):

  1. Localizar o arquivo kubeconfig do cluster de usuário. O Google Distributed Cloud para bare metal gera o arquivo kubeconfig na estação de trabalho do administrador quando você cria um cluster. Por padrão, o arquivo está no diretório bmctl-workspace/USER_CLUSTER_NAME.
  2. Verifique se o kubeconfig está correto no cluster de usuário kubeconfig: 
    kubectl get nodes \
    --kubeconfig PATH_TO_GENERATED_FILE
     Substitua PATH_TO_GENERATED_FILE pelo caminho para o arquivo kubeconfig do cluster de usuário. A resposta retorna detalhes sobre os nós do cluster de usuário. Confirme se os nomes de máquina estão corretos para o cluster.
  3. Execute o seguinte comando para excluir o arquivo kubeconfig corrompido no cluster de administrador: 
    kubectl delete secret \
    -n USER_CLUSTER_NAMESPACE \
    USER_CLUSTER_NAME-kubeconfig
  4. Execute o seguinte comando para salvar o secret kubeconfig correto de volta no cluster de administrador: 
    kubectl create secret generic \
    -n USER_CLUSTER_NAMESPACE \
    USER_CLUSTER_NAME-kubeconfig \
    --from-file=value=PATH_TO_GENERATED_FILE
Operação 1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28, 1.29, 1.30

Se você usar o containerd como ambiente de execução de contêiner, a execução do snapshot como usuário não raiz exigirá que /usr/local/bin esteja no PATH do usuário. Caso contrário, ocorrerá uma falha com crictl: command not found.

Quando você não estiver conectado como o usuário raiz, sudo será usado para executar os comandos de snapshot. O CAMINHO sudo pode ser diferente do perfil raiz e pode não conter /usr/local/bin.


Alternativa

Atualize o secure_path em /etc/sudoers para incluir /usr/local/bin. Como alternativa, crie um link simbólico para crictl em outro diretório /bin.
Geração de registros e monitoramento 1.10

Se o analisador de interface de ambiente de execução do contêiner (CRI, na sigla em inglês) usar uma expressão regular incorreta para analisar o tempo, os registros do pod stackdriver-log-forwarder contêm erros e avisos como os seguintes:

[2022/03/04 17:47:54] [error] [parser] time string length is too long [2022/03/04 20:16:43] [ warn] [parser:cri] invalid time format %Y-%m-%dT%H:%M:%S.%L%z for '2022-03-04T20:16:43.680484387Z'

Alternativa:
Geração de registros e monitoramento 1.10, 1.11, 1.12, 1.13, 1.14, 1.15

Para as versões 1.10 a 1.15 do cluster, alguns clientes têm encontrado uma cobrança alta inesperada para Metrics volume no Faturamento. Esse problema afeta você apenas quando ambas as circunstâncias a seguir se aplicarem:

  • O monitoramento de aplicativos está ativado (enableStackdriverForApplications=true)
  • Managed Service para Prometheus não está ativado (enableGMPForApplications)
  • Os pods do aplicativo têm a anotação prometheus.io/scrap=true.

Para confirmar se você foi afetado por esse problema, liste as métricas definidas pelo usuário. Se você vir faturamento para métricas indesejadas, esse problema se aplica a você.


Alternativa

Se você for afetado por esse problema, recomendamos que faça upgrade dos clusters para a versão 1.12 e mude para a nova solução de monitoramento de aplicativos managed-service-for-prometheus que resolve esse problema:

  • Sinalizações separadas para controlar a coleta de registros do aplicativo em comparação com as métricas do aplicativo
  • Pacote de serviço gerenciado do Google Cloud Managed Service para Prometheus

    • Se não for possível fazer upgrade para a versão 1.12, siga estas etapas:

    1. Encontre os pods e os serviços de origem que têm o faturamento indesejado: 
      kubectl --kubeconfig KUBECONFIG \
    get pods -A -o yaml | grep 'prometheus.io/scrape: "true"'
kubectl --kubeconfig KUBECONFIG get \
    services -A -o yaml | grep 'prometheus.io/scrape: "true"'
    2. Remova a anotação prometheus.io/scrap=true do pod ou do serviço.
    Geração de registros e monitoramento 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28

    Uma alta densidade de pods pode, em casos extremos, criar uma sobrecarga excessiva de geração de registros e monitoramento, o que pode fazer com que o servidor de métricas seja interrompido e reiniciado. É possível editar o ConfigMap metrics-server-config para alocar mais recursos para manter o Metrics Server em execução. No entanto, devido à reconciliação, as edições feitas em metrics-server-config poderão ser revertidas para o valor padrão durante uma atualização de cluster ou operação de upgrade. O Metrics Server não é afetado imediatamente, mas na próxima vez que for reiniciado, ele capta o ConfigMap revertido e está vulnerável a sobrecargas excessivas.


    Alternativa

    Para a versão 1.11.x, é possível criar um script para a edição do ConfigMap e executá-la com atualizações ou upgrades no cluster. Para a versão 1.12 e posteriores, entre em contato com o suporte.
    Geração de registros e monitoramento 1.11, 1.12

    Várias métricas somente de software do Google Distributed Cloud foram descontinuadas e, começando com Google Distributed Cloud versão 1.11, os dados não são mais coletados para métricas descontinuadas. Se você usar essas métricas em qualquer uma das políticas de alertas, não haverá dados para acionar a condição de alerta.

    A tabela a seguir lista as métricas individuais que estão obsoletas e as métricas que as substituem.

    Métricas descontinuadas Métrica de substituição
    kube_daemonset_updated_number_scheduled kube_daemonset_status_updated_number_scheduled
    kube_node_status_allocatable_cpu_cores
    kube_node_status_allocatable_memory_bytes
    kube_node_status_allocatable_pods    		 kube_node_status_allocatable
    kube_node_status_capacity_cpu_cores
    kube_node_status_capacity_memory_bytes
    kube_node_status_capacity_pods    		 kube_node_status_capacity

    Em versões do cluster anteriores à 1.11, o arquivo de definição de política para o alerta Anthos on baremetal node cpu usage exceeds 80 percent (critical) recomendado usa as métricas descontinuadas. O arquivo de definição JSON node-cpu-usage-high.json foi atualizado para as versões 1.11.0 e posteriores.


    Alternativa

    Siga as etapas abaixo para migrar para as métricas de substituição:

    1. No console do Google Cloud , selecione Monitoring ou clique no botão a seguir:
      Acessar o Monitoring
    2. No painel de navegação, selecione Painéis e exclua o painel Status do nó do cluster do Anthos.
    3. Clique na guia Biblioteca de amostra e reinstale o painel Status do nó do cluster do Anthos.
    4. Siga as instruções em Como criar políticas de alerta para criar uma política usando o arquivo de definição de política node-cpu-usage-high.json atualizado.
    Geração de registros e monitoramento 1.10, 1.11

    Em algumas situações, o agente do Logging fluent-bit pode ficar travado no processamento de blocos corrompidos. Quando o agente do Logging não conseguir ignorar blocos corrompidos, talvez você observe que stackdriver-log-forwarder continua falhando com um erro CrashloopBackOff. Se você tiver esse problema, seus registros terão entradas como as seguintes

    [2022/03/09 02:18:44] [engine] caught signal (SIGSEGV) #0  0x5590aa24bdd5
in  validate_insert_id() at plugins/out_stackdriver/stackdriver.c:1232
#1  0x5590aa24c502      in  stackdriver_format() at plugins/out_stackdriver/stackdriver.c:1523
#2  0x5590aa24e509      in  cb_stackdriver_flush() at plugins/out_stackdriver/stackdriver.c:2105
#3  0x5590aa19c0de      in  output_pre_cb_flush() at include/fluent-bit/flb_output.h:490
#4  0x5590aa6889a6      in  co_init() at lib/monkey/deps/flb_libco/amd64.c:117 #5  0xffffffffffffffff  in  ???() at ???:0

    Alternativa:

    Limpe os blocos de buffer para o encaminhador de registros do Stackdriver.

    Observação: nos comandos a seguir, substitua KUBECONFIG pelo caminho para o arquivo kubeconfig do cluster de administrador.

    1. Encerre todos os pods de stackdriver-log-forwarder: 
      kubectl --kubeconfig KUBECONFIG -n kube-system patch daemonset \
    stackdriver-log-forwarder -p \
    '{"spec": {"template": {"spec": {"nodeSelector": {"non-existing": "true"}}}}}'
       Verifique se os pods stackdriver-log-forwarder foram excluídos antes de ir para a próxima etapa.
    2. Implante o seguinte DaemonSet para limpar todos os dados corrompidos nos buffers fluent-bit: 
      kubectl --kubeconfig KUBECONFIG -n kube-system apply -f - << EOF
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluent-bit-cleanup
  namespace: kube-system
spec:
  selector:
    matchLabels:
      app: fluent-bit-cleanup
  template:
    metadata:
      labels:
        app: fluent-bit-cleanup
    spec:
      containers:
      - name: fluent-bit-cleanup
        image: debian:10-slim
        command: ["bash", "-c"]
        args:
        - |
          rm -rf /var/log/fluent-bit-buffers/
          echo "Fluent Bit local buffer is cleaned up."
          sleep 3600
        volumeMounts:
        - name: varlog
          mountPath: /var/log
        securityContext:
          privileged: true
      tolerations:
      - key: "CriticalAddonsOnly"
        operator: "Exists"
      - key: node-role.kubernetes.io/master
        effect: NoSchedule
      - key: node-role.gke.io/observability
        effect: NoSchedule
      volumes:
      - name: varlog
        hostPath:
          path: /var/log
EOF
    3. Use os seguintes comandos para verificar se o DaemonSet limpou todos os nós: 
      kubectl --kubeconfig KUBECONFIG logs \
    -n kube-system -l \
    app=fluent-bit-cleanup | grep "cleaned up" | wc -l
kubectl --kubeconfig KUBECONFIG -n \
    kube-system get pods -l \
    app=fluent-bit-cleanup --no-headers | wc -l
       A saída dos dois comandos precisa ser igual ao número de nós do cluster.
    4. Exclua o DaemonSet de limpeza. 
      kubectl --kubeconfig KUBECONFIG -n \
    kube-system delete ds fluent-bit-cleanup
    5. Reinicie os pods do encaminhador de registros: 
      kubectl --kubeconfig KUBECONFIG \
    -n kube-system patch daemonset \
    stackdriver-log-forwarder --type json \
    -p='[{"op": "remove", "path": "/spec/template/spec/nodeSelector/non-existing"}]'
    Geração de registros e monitoramento 1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28

    gke-metrics-agent é um daemonset que coleta métricas em cada nó e encaminhá-los ao Cloud Monitoring. Ele pode produzir registros como o seguinte:

    Unknown metric: kubernetes.io/anthos/go_gc_duration_seconds_summary_percentile

    Erros semelhantes podem ocorrer com outros tipos de métricas, incluindo (mas não limitado a):

    • apiserver_admission_step_admission_duration_seconds_summary
    • go_gc_duration_seconds
    • scheduler_scheduling_duration_seconds
    • gkeconnect_http_request_duration_seconds_summary
    • alertmanager_nflog_snapshot_duration_seconds_summary

    Esses registros de erros podem ser ignorados com segurança porque as métricas a que se referem são não são compatíveis nem são essenciais para fins de monitoramento.
    Geração de registros e monitoramento 1.10, 1.11

    Os clusters podem sofrer interrupções na exportação contínua normal de métricas ou métricas ausentes em alguns nós. Se esse problema afetar os clusters, você poderá ver lacunas nos dados das seguintes métricas (no mínimo):

    • kubernetes.io/anthos/container_memory_working_set_bytes
    • kubernetes.io/anthos/container_cpu_usage_seconds_total
    • kubernetes.io/anthos/container_network_receive_bytes_total

    Alternativa

    Faça upgrade dos clusters para a versão 1.11.1 ou mais recente.

    Se não for possível fazer upgrade, execute as seguintes etapas como uma solução alternativa:

    1. Abra o recurso stackdriver para edição: 
      kubectl -n kube-system edit stackdriver stackdriver
    2. Para aumentar a solicitação de CPU de gke-metrics-agent de 10m para 50m, adicione a seguinte seção resourceAttrOverride ao manifesto stackdriver: 
      spec:
  resourceAttrOverride:
    gke-metrics-agent/gke-metrics-agent:
      limits:
        cpu: 100m
        memory: 4608Mi
      requests:
        cpu: 50m
        memory: 200Mi
       O recurso editado ficará semelhante ao seguinte: 
      spec:
  anthosDistribution: baremetal
  clusterLocation: us-west1-a
  clusterName: my-cluster
  enableStackdriverForApplications: true
  gcpServiceAccountSecretName: ...
  optimizedMetrics: true
  portable: true
  projectID: my-project-191923
  proxyConfigSecretName: ...
  resourceAttrOverride:
    gke-metrics-agent/gke-metrics-agent:
      limits:
        cpu: 100m
        memory: 4608Mi
      requests:
        cpu: 50m
        memory: 200Mi
    3. Salve as alterações e feche o editor de texto.
    4. Para verificar se as mudanças entraram em vigor, execute o seguinte comando: 
      kubectl -n kube-system get daemonset \
    gke-metrics-agent -o yaml | grep "cpu: 50m"
       O comando vai encontrar cpu: 50m se as edições tiverem entrado em vigor.
    Rede 1.10

    Ter vários gateways padrão em um nó pode levar a uma falha de conectividade entre um pod e endpoints externos, como google.com.

    Para saber se esse problema está ocorrendo, execute o seguinte comando no nó:

    ip route show

    Várias instâncias de default na resposta indicam que o problema está ocorrendo.
    Rede 1.12

    Os clusters da versão 1.12.x não impedem que você edite manualmente redes recursos personalizados no cluster de usuário. O Google Distributed Cloud reconcilia recursos personalizados nos clusters de usuário com os recursos personalizados no cluster de administrador durante upgrades de cluster. Essa reconciliação substitui todas as edições feitas diretamente nos recursos personalizados de rede no cluster de usuário. O os recursos personalizados de rede devem ser modificados apenas no cluster de administrador, mas os clusters da versão 1.12.x não impõem esse requisito.

    Recursos de rede avançados, como balanceador de carga em pacote com BGP, gateway NAT de saída, rede SR-IOV, flat-mode com BGP e multi-NIC para pods, use os seguintes recursos personalizados:

    • BGPLoadBalancer
    • BGPPeer
    • NetworkGatewayGroup
    • NetworkAttachmentDefinition
    • ClusterCIDRConfig
    • FlatIPMode

    Você edita esses recursos personalizados no cluster de administrador e a etapa de reconciliação aplica as alterações aos clusters de usuário.


    Alternativa

    Se você tiver modificado qualquer um dos recursos personalizados mencionados anteriormente em um cluster de usuário, modifique os recursos personalizados correspondentes no cluster de administrador para que correspondam aos resultados antes do upgrade. Esta etapa garante que as alterações de configuração sejam preservadas. As versões de cluster 1.13.0 e mais recentes impedem que você modifique os recursos personalizados de rede diretamente nos clusters de usuários.
    Rede 1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28

    O Google Distributed Cloud configura a filtragem de caminho reverso em nós para desativar a validação de origem (net.ipv4.conf.all.rp_filter=0). Se a configuração rp_filter for alterada para 1 ou 2, os pods vão falhar devido aos tempos limite de comunicação fora do nó.

    A filtragem de caminho reverso é definida com arquivos rp_filter na pasta de configuração IPv4 (net/ipv4/conf/all). Este valor também pode ser modificado por sysctl, que armazena as configurações de filtragem de caminho reverso em um arquivo de configuração de segurança de rede, como /etc/sysctl.d/60-gce-network-security.conf.


    Alternativa

    A conectividade do pod pode ser restaurada realizando uma das seguintes ações soluções alternativas:

    Defina o valor de net.ipv4.conf.all.rp_filter novamente como 0 manualmente e, em seguida, execute sudo sysctl -p para aplicar. a mudança.

    Ou

    Reinicie o pod anetd para definir net.ipv4.conf.all.rp_filter de volta para 0. Para reiniciar o pod anetd, use os seguintes comandos para localizar e excluir o pod anetd, e um novo pod anetd será iniciado no lugar:

    kubectl get pods -n kube-system kubectl delete pods -n kube-system ANETD_XYZ

    Substitua ANETD_XYZ pelo nome do pod anetd.

    Depois de executar uma das soluções alternativas, verifique se o O valor de net.ipv4.conf.all.rp_filter é definido como 0 por executando sysctl net.ipv4.conf.all.rp_filter em cada nó.
    Rede 1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28, 1.29, 1.30, 1.31, 1.32, 1.33, 1.34

    192.168.122.0/24 e 10.96.0.0/27 são as CIDRs padrão do pod e do serviço usadas pelo cluster de inicialização (tipo). As verificações de simulação falharão se houver sobreposição com os endereços IP da máquina do nó do cluster.


    Alternativa

    Para evitar o conflito, passe as sinalizações --bootstrap-cluster-pod-cidr e --bootstrap-cluster-service-cidr para bmctl para especificar valores diferentes.
    Sistema operacional 1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28

    Em dezembro de 2020, a comunidade do CentOS e a Red Hat anunciaram o fim do CentOS. Em 31 de janeiro de 2022, o CentOS 8 chegou ao fim da vida útil (EOL). Como resultado do EOL, os repositórios yum pararam de funcionar com o CentOS, o que causa falha nas operações de criação e atualização dos clusters. Isso se aplica a todas as versões com suporte do CentOS e afeta todas as versões dos clusters.


    Alternativa
    Segurança 1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28

    Se você usa o containerd como o ambiente de execução do contêiner e o sistema operacional está com o SELinux ativado, o VOLUME definido no Dockerfile do aplicativo pode não ser gravável. Por exemplo, os contêineres criados com o Dockerfile a seguir não podem gravar na pasta /tmp.

    FROM ubuntu:20.04 RUN chmod -R 777 /tmp VOLUME /tmp

    Para verificar se você será afetado por esse problema, execute o seguinte comando no nó que hospeda o contêiner problemático:

    ausearch -m avc

    Se você for afetado por esse problema, verá um erro denied como este:

    time->Mon Apr  4 21:01:32 2022 type=PROCTITLE msg=audit(1649106092.768:10979): proctitle="bash" type=SYSCALL msg=audit(1649106092.768:10979): arch=c000003e syscall=257 success=no exit=-13 a0=ffffff9c a1=55eeba72b320 a2=241 a3=1b6 items=0 ppid=75712 pid=76042 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=4294967295 comm="bash" exe="/usr/bin/bash" subj=system_u:system_r:container_t:s0:c701,c935 key=(null) type=AVC msg=audit(1649106092.768:10979): avc:  denied { write } for  pid=76042 comm="bash" name="aca03d7bb8de23c725a86cb9f50945664cb338dfe6ac19ed0036c" dev="sda2" ino=369501097 scontext=system_u:system_r: container_t:s0:c701,c935 tcontext=system_u:object_r: container_ro_file_t:s0 tclass=dir permissive=0

    Alternativa

    Para contornar esse problema, faça uma das seguintes alterações:

    • Desative o SELinux.
    • Não use o recurso VOLUME dentro do Dockerfile.
    Upgrades e atualizações 1.10, 1.11, 1.12

    Quando você faz upgrade de clusters, o Detector de problemas do nó não é ativado por padrão. O problema é relevante para upgrades das versões 1.10 à 1.12.1 e foi corrigido na versão 1.12.2.


    Alternativa:

    Para ativar o detector de problemas de nós:

    1. Verifique se o serviço node-problem-detector systemd está em execução no nó.
      1. Use o comando SSh e conecte-se ao nó.
      2. Verifique se o serviço node-problem-detector systemd está em execução no nó. 
        systemctl is-active node-problem-detector
         Se o resultado do comando mostrar inactive, o detector não está sendo executado no nó.
    2. Para ativar o detector de problemas de nós, use o comando kubectl edit e edite o ConfigMap node-problem-detector-config. Para saber mais, consulte Detector de problemas de nós.
    Operação 1.9, 1.10

    O comando bmctl backup cluster falhará se nodeAccess.loginUser estiver definido como um nome de usuário não raiz.


    Alternativa:

    Esse problema se aplica às versões 1.9.x, 1.10.0 e 1.10.1. e foi corrigido na versão 1.10.2 e posterior.
    Rede 1.10, 1.11, 1.12

    Há um bug em anetd em que os pacotes são descartados para os serviços LoadBalancer se os pods de back-end estão em execução no nó do plano de controle e usando o campo hostNetwork: true na especificação do contêiner.

    O bug não está presente na versão 1.13 ou mais recente.


    Alternativa:

    As soluções alternativas a seguir podem ajudar se você usar um serviço LoadBalancer com suporte de pods hostNetwork:

    1. Executar em nós de trabalho (não em nós do plano de controle).
    2. Usar externalTrafficPolicy: local na especificação do serviço e verificar se as cargas de trabalho são executadas nos nós do balanceador de carga
    Upgrades e atualizações 1.12, 1.13

    O upgrade do cluster de 1.12.x para 1.13.x pode observar um pod anthos-version-$version$ com falha com o erro ImagePullBackOff. Isso acontece devido à disputa de anthos-cluster-operator gets foi atualizado e não afetará os recursos normais do cluster.

    O bug não aparece depois da versão 1.13 ou mais recente.


    Alternativa:

    Exclua o job do dynamic-version-installer por kubectl delete job anthos-version-$version$ -n kube-system

    Upgrades e atualizações 1.13

    Não é possível fazer upgrade dos clusters da versão 1.12 da versão 1.11 para a 1.13.0. Esse problema de upgrade não se aplica a clusters criados na versão 1.12.

    Para determinar se você foi afetado, verifique os registros do job de upgrade que contém a string upgrade-first-no* no cluster de administrador. Se a mensagem de erro abaixo aparecer, você será afetado.

    TASK [kubeadm_upgrade_apply : Run kubeadm upgrade apply] *******
...
[upgrade/config] FATAL: featureGates: Invalid value: map[string]bool{\"IPv6DualStack\":false}: IPv6DualStack isn't a valid feature name.
...

    Alternativa:

    Para contornar esse problema:

    1. Execute os seguintes comandos na estação de trabalho de administrador: 
      echo '[{ "op": "remove", "path": \
    "/spec/clusterConfiguration/featureGates" }]' \
    > remove-feature-gates.patch
export KUBECONFIG=$ADMIN_KUBECONFIG
kubectl get kubeadmconfig -A --no-headers | xargs -L1 bash -c \
    'kubectl patch kubeadmconfig $1 -n $0 --type json \
    --patch-file remove-feature-gates.patch'
    2. Tente fazer o upgrade do cluster novamente.
    Geração de registros e monitoramento 1.16.2, 1.16.3

    Há um problema em stackdriver-operator que faz com que ele consomem mais tempo de CPU do que o normal. O uso normal da CPU for menor que 50 milliCPU (50m) para stackdriver-operator em inatividade estado. A causa é uma incompatibilidade de recursos de certificado que stackdriver-operator se aplica com as expectativas cert-manager. Essa incompatibilidade causa uma disputa entre cert-manager e stackdriver-operator pol. atualizar esses recursos.

    Esse problema pode resultar em desempenho reduzido em clusters com limitações Disponibilidade da CPU


    Alternativa:

    Até que você possa fazer upgrade para uma versão que corrigiu o bug, use a seguinte solução alternativa:

    1. Para reduzir escala vertical temporariamente stackdriver-operator para 0 réplicas, aplique um recurso personalizado AddonConfiguration: 
      kubectl scale deploy stackdriver-operator --replicas=0
    2. Depois de fazer upgrade para uma versão que corrija esse problema, dimensione O backup de stackdriver-operator foi feito novamente: 
      kubectl scale deploy stackdriver-operator --replicas=1
    Geração de registros e monitoramento 1.16.0, 1.16.1

    Na versão secundária do Google Distributed Cloud 1.16, a Campo enableStackdriverForApplications no A especificação de recurso personalizado stackdriver foi descontinuada. Este campo é substituído por dois campos, enableCloudLoggingForApplications e enableGMPForApplications, no recurso personalizado do Stackdriver.

    Recomendamos que você use o Google Cloud Managed Service para Prometheus para monitoramento das cargas de trabalho. Use o campo enableGMPForApplications para ativar esse recurso.

    Se você confiar na coleta de métricas acionada prometheus.io/scrape anotação na sua cargas de trabalho, use o método annotationBasedApplicationMetrics uma flag de entrada de recurso para manter o comportamento antigo. No entanto, há um problema que impede que o annotationBasedApplicationMetrics funcione corretamente, impedindo a coleta de métricas dos aplicativos em o Cloud Monitoring.


    Alternativa:

    Para resolver esse problema, faça upgrade do cluster para a versão 1.16.2 ou mais recente.

    A coleta de métricas de carga de trabalho com base em anotações ativada pelo Coleta de annotationBasedApplicationMetrics atributo para objetos que têm o campo prometheus.io/scrape . Muitos sistemas de software com origem de código aberto usam esse . Se você continuar usando esse método de métricas , esteja ciente dessa dependência para não se surpreender com no Cloud Monitoring.
    Geração de registros e monitoramento 1.15, 1.16, 1.28.0-1.28.900, 1.29.0-1.29.400, 1.30.0, 1.30.100

    Os Registros de auditoria do Cloud precisam de uma configuração de permissão especial que é executada automaticamente pelo cluster-operator no GKE Hub.

    No entanto, nos casos em que um cluster de administrador gerenciava vários clusters com IDs de projeto diferentes, um bug no cluster-operator fazia com que a mesma conta de serviço fosse anexada à lista de permissões repetidamente e falhasse na solicitação devido à limitação de tamanho. Isso faria com que os registros de auditoria de alguns ou todos esses clusters não fossem injetados no Google Cloud.

    O sintoma é uma série de erros Permission Denied no pod audit-proxy no cluster afetado.

    Outro sintoma é o status de erro e uma longa lista de conta de serviço duplicadas ao verificar a lista de permissões de registros de auditoria do Cloud pelo GKE Hub:

    curl -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    https://gkehub.googleapis.com/v1alpha/projects/PROJECT_ID/locations/global/features/cloudauditlogging

{
  "name": "projects/PROJECT_ID/locations/global/features/cloudauditlogging",
  "spec": {
    "cloudauditlogging": {
      "allowlistedServiceAccounts": [
        "SERVICE-ACCOUNT-EMAIL",
        ...
        ... multiple lines of the same service account
      ]
    }
  },
  "state": {
    "state": {
      "code": "ERROR"
    }
  }
}

    Para resolver o problema, faça upgrade do cluster para pelo menos 1.28.1000, 1.29.500 ou 1.30.200, em que o problema foi corrigido. Ou aplique a solução alternativa a seguir:
    Configuração Todas as versões de patch em 1.29 e anteriores, 1.30.400 e anteriores e 1.31.0

    A configuração de espelhamento do registro em nós não é atualizada quando apenas o campo hosts é alterado.

    Quando você atualiza o campo containerRuntime.registryMirrors.hosts para um endpoint de espelho de registro na especificação do cluster, as mudanças não são aplicadas automaticamente aos nós do cluster. Isso acontece porque a lógica de reconciliação não detecta mudanças feitas exclusivamente no campo hosts e, consequentemente, os jobs de atualização da máquina responsáveis por atualizar a configuração do containerd nos nós não são acionados.

    Verificação:

    Para verificar esse problema, modifique apenas o campo hosts de um espelho de registro e inspecione o arquivo de configuração do containerd (o caminho pode ser /etc/containerd/config.toml ou outros caminhos, como /etc/containerd/config.d/01-containerd.conf, dependendo da versão e da configuração) em um nó de trabalho. O arquivo não mostra a lista hosts atualizada para o endpoint de espelho.

    Alternativa:

    Escolha uma destas opções:

    1. Faça upgrade para uma versão com a correção:faça upgrade dos clusters para 1.30.500-gke.126 ou mais recente, 1.31.100-gke.136 ou mais recente ou 1.32.0.
    2. Acione uma atualização com uma mudança no NodePool:faça uma mudança trivial na especificação do NodePool para os nós afetados. Por exemplo, adicione um rótulo ou uma anotação temporária. Isso aciona o processo de atualização da máquina, que coleta as mudanças do espelho do registro. Você pode remover a mudança trivial depois.

    A seguir

    Se precisar de mais ajuda, entre em contato com o Cloud Customer Care. Consulte também Receber suporte para mais informações sobre recursos de suporte, incluindo:

    • Requisitos para abrir um caso de suporte.
    • Ferramentas para ajudar na solução de problemas, como configuração do ambiente, registros e métricas.
    • Componentes compatíveis.