Problemas conhecidos do GKE em Bare Metal

Nesta página, listamos todos os problemas conhecidos do Google Distributed Cloud Virtual for Bare Metal. Para filtrar os problemas conhecidos por versão ou categoria do produto, selecione os filtros nos menus suspensos a seguir.

Selecione a versão do GDCV para Bare Metal:

Selecione a categoria do problema:

Ou pesquise seu problema:

Categoria Versões identificadas Problema e solução alternativa
Redefinir/excluir 1.29.0

Falha ao redefinir o cluster de usuário ao tentar excluir o namespace

Ao executar bmctl reset cluster -c ${USER_CLUSTER}, após a conclusão de todos os jobs relacionados, o comando não vai excluir o namespace do cluster de usuário. O namespace do cluster de usuário está preso no estado Terminating. Depois, 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, siga estas 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 for removido, o namespace do cluster será removido e a redefinição do cluster será concluída.
configuração, instalação, segurança 1.16.0 a 1.16.7 e 1.28.0 a 1.28.400

A implantação da autorização binária não tem um nodeSeletor

Se você ativou a autorização binária para o GKE em Bare Metal e está usando uma versão de 1.16.0 a 1.16.7 ou 1.28.0 a 1.28.400, pode ter um problema com onde os pods do recurso estão programados. Nessas versões, a implantação da autorização binária não tem um nodeSelector. Portanto, os pods do recurso podem ser programados em nós de trabalho em vez de nós do plano de controle. Esse comportamento não faz com que nada falhe, mas não é o esperado.

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 bloco spec.template.spec:
  3.       nodeSelector:
            node-role.kubernetes.io/control-plane: ""
    
  4. Salve as alterações.

Depois que a alteração for salva, os pods serão reimplantados apenas nos 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

Erro ao fazer upgrade de um cluster para 1.28.0-1.28.300

O 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 implantador do controlador do ciclo de vida entre em um estado de erro durante o upgrade. Quando isso acontece, os registros do pod do implantador do controlador de ciclo de vida têm 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. Faça upgrade para a versão 1.28.400 ou mais recente para resolver o problema.

Se você não conseguir fazer upgrade, execute os seguintes comandos 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

ID do projeto incorreto exibido na Análise de registros

Às vezes, os registros de cluster ou contêiner são marcados com um ID do 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 é definida no campo clusterOperations.projectID na configuração do cluster. No entanto, o cloudOperationsServiceAccountKeyPath na 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.0

Degradação do desempenho de clusters que usam balanceamento de carga em pacote com o BGP

Para clusters da versão 1.29.0 que usam balanceamento de carga em pacote com BGP, o desempenho do balanceamento de carga pode cair à medida que o número total de Serviços do tipo LoadBalancer se aproxima de 2.000. Com a degradação do desempenho, os serviços recém-criados levam muito tempo para se conectar ou não podem ser conectados por um cliente. Os serviços atuais continuam funcionando, mas não processam modos de falha, como a perda de um nó do balanceador de carga, de maneira eficaz. Esses problemas de serviço acontecem quando a implantação ang-controller-manager é encerrada devido à falta de memória.

Se o cluster for afetado por esse problema, os Serviços no cluster vão ficar inacessíveis e não íntegros e a implantação ang-controller-manager estará em um CrashLoopBackOff. A resposta ao listar as implantações de ang-controller-manager é semelhante a esta:

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 o limite de CPU:

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

Depois de 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

Os problemas de conectividade gcr.io do endpoint do Container Registry podem bloquear operações do cluster

Várias operações de cluster para clusters de administrador criam um cluster de inicialização. Antes de criar um cluster de inicialização, bmctl realiza uma verificação de acessibilidade do Google Cloud na estação de trabalho do administrador. Essa verificação pode falhar devido a problemas de conectividade com o endpoint do Container Registry, gcr.io, e é possível que você veja uma mensagem de erro 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

GKE Dataplane V2 incompatível com alguns drivers de armazenamento

Os clusters do GKE em Bare Metal usam o GKE Dataplane V2, que é incompatível com alguns provedores de armazenamento. É possível que você tenha problemas com volumes ou pods NFS travados. Isso pode acontecer quando você tem cargas de trabalho que usam volumes ReadWriteMany com 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 mais recente que linux-image-5.4.0-166-generic.
  • 22.04 LTS: use uma imagem do kernel 5.15.0 mais recente que linux-image-5.15.0-88-generic ou use o kernel HWE 6.5.

Se você não estiver usando uma dessas versões, entre em contato com o Suporte do Google.

Geração de registros e monitoramento 1,15, 1,16, 1,28

kube-state-metrics OOM em cluster grande

É possível 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 ou com muitos objetos do Kubernetes.

Alternativa

Para resolver esse problema, atualize a definição do recurso personalizado stackdriver para usar o portão de recursos ksmNodePodMetricsOnly. Esse portão de recursos garante que apenas um pequeno número de métricas críticas seja exposto.

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

  1. Verifique a definição de recurso personalizado stackdriver para conferir os 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

A verificação de simulação falha no RHEL 9.2 devido à ausência de iptables

Ao instalar um cluster no sistema operacional Red Hat Enterprise Linux (RHEL) 9.2, talvez haja uma falha devido ao pacote iptables ausente. A falha ocorre durante essas verificações 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 o GKE em Bare Metal versão 1.28.

Alternativa

Para ignorar o erro de verificação de simulação, defina spec.bypassPreflightCheck como true no recurso de cluster.

Operação 1,10, 1,11, 1,12, 1,13, 1,14, 1,15, 1,16

Failover lento do MetalLB em alta escala

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

Alternativa

Faça upgrade do cluster para a versão 1.28 ou mais recente. Se não for possível fazer upgrade, editar manualmente o serviço (por exemplo, adicionar uma anotação) vai fazer com que ele faça failover mais rapidamente.

Operação 1.16.0-1.16.6, 1.28.0-1.28.200

As variáveis de ambiente precisarão ser definidas na estação de trabalho do administrador se o proxy estiver ativado

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 no 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

Os upgrades para a versão 1.28.0-gke.435 podem falhar se audit.log tiver a propriedade incorreta

Em alguns casos, o arquivo /var/log/apiserver/audit.log nos nós do plano de controle tem a propriedade do grupo e do usuário definida como root. Essa configuração de propriedade de arquivo causa falhas de upgrade para os nós do plano de controle 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 e que tiveram os Registros de auditoria do Cloud desativados. Os registros de auditoria do Cloud são ativados por padrão para clusters na versão 1.9 e posteriores.

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 MetalLB não atribui endereços IP a serviços VIP

O GKE em Bare Metal usa o MetalLB para balanceamento de carga em pacote. Na versão 1.28.0-gke.435 do GKE em Bare Metal, o MetalLB empacotado é atualizado para a versão 0.13, que introduz a compatibilidade com CRD para IPAddressPools. No entanto, como ConfigMaps permite qualquer nome para um IPAddressPool, os nomes dos pools precisaram ser convertidos em um nome compatível com o Kubernetes, anexando um hash ao final do nome do IPAddressPool. Por exemplo, um IPAddressPool com o nome default é convertido em um nome como default-qpvpd quando você faz upgrade do cluster para a versão 1.28.0-gke.435.

Como o MetalLB exige um nome específico de um IPPool para seleção, a conversão de nome impede que o MetalLB faça uma seleção de pool e atribua 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 recebem mais um endereço IP do controlador do MetalLB.

Esse problema foi corrigido no GKE em Bare Metal versão 1.28.100-gke.146.

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:

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

    Por exemplo, se o nome IPAddressPool foi convertido de default para um nome como default-qpvpd, altere 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. Portanto, a solução alternativa é persistente.

Upgrades e atualizações 1,14, 1,15, 1,16, 1,28, 1,29

Pods órfãos após o upgrade para a versão 1.14.x

Quando você faz upgrade de clusters Bare Metal do GKE para a versão 1.14.x, alguns recursos da versão anterior não são excluídos. Especificamente, você verá um conjunto de pods órfãos como o seguinte:

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 recomendamos que você os remova.

  • Execute os seguintes comandos 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 no GKE em Bare Metal versão 1.15.0 e mais recentes.

Instalação 1,14

A criação do cluster travou no job machine-init

Se você tentar instalar o Google Distributed Cloud Virtual para Bare Metal versão 1.14.x, poderá encontrar uma falha devido aos jobs machine-init, semelhante ao exemplo de saída a seguir:

"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:

Remova o membro obsoleto do etcd que causa a falha do job machine-init. Conclua as etapas a seguir em um nó do plano de controle que funcione:

  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 membros com um status de unstarted, conforme mostrado no exemplo de saída abaixo:
    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 do etcd com falha. No exemplo de saída anterior, esse ID é bd1949bcb70e2cb5.

    O exemplo de saída a seguir mostra que o membro foi removido:
    Member bd1949bcb70e2cb5 removed from cluster  9d70e2a69debf2f
    
Rede 1.28.0

Cilium-operatorlist e watch permissões ausentes

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

  • Vazamento de recursos 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ó relata a seguinte mensagem de registro de exemplo:

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 uma entrada em um mapa de políticas, como no 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 ao operador as permissões do ClusterRole que estão faltando:

  1. Remova os objetos CiliumIdentity existentes:
    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 as permissões ausentes, conforme mostrado no exemplo a seguir:
    - apiGroups:
      - ""
      resources:
      - nodes
      verbs:
      - get
      - list
      - watch
    
    .
  4. Salve e feche o editor. O operador detecta dinamicamente a mudança na 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

Problema temporário encontrado durante a verificação de simulação.

Uma das tarefas de verificação de integridade do kubeadm executadas durante a verificação de simulação de upgrade pode falhar e mostrar 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, execute o comando de upgrade novamente.

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


Alternativa:

Execute novamente o comando de upgrade ou, se encontrado durante bmctl preflightcheck, execute novamente o comando preflightcheck.

Operação 1.14, 1.15.0-1.15.7, 1.16.0-1.16.3, 1.28.0

A verificação periódica de integridade da rede falha quando um nó é substituído ou removido

Esse problema afeta os clusters que realizam verificações periódicas de integridade da rede após a substituição ou remoção de um nó. Se o cluster passar por verificações de integridade periódicas, essa verificação de integridade resultará em falha após a substituição ou remoção de um nó. Isso acontece porque o ConfigMap do inventário de rede não é atualizado depois que ele é criado.


Alternativa:

A solução alternativa recomendada é excluir o ConfigMap de inventário e a verificação periódica de integridade da rede. O operador de cluster os recria automaticamente 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

O gateway de rede para GDC não pode aplicar sua configuração quando o nome do dispositivo contém um ponto

Se você tiver um dispositivo de rede que inclua um caractere de ponto (.) no nome, como bond0.2, o Gateway de rede para GDC tratará o ponto como um caminho no diretório quando executar sysctl para fazer alterações. Quando o Gateway de rede para GDC verifica se a detecção de endereço duplicado (DAD, na sigla em inglês) está ativada, a verificação pode falhar e, portanto, não será reconciliada.

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

  • 1.14 e 1.15: esse erro só existe quando você usa endereços IP flutuantes IPv6. 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 - 1.16.2: este erro sempre existe quando os nomes dos dispositivos contêm um ponto.

Alternativa:

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

Como solução alternativa, até que seja possível fazer upgrade dos clusters, remova o ponto (.) do nome do dispositivo.

Upgrades e atualizações, rede, segurança 1.16.0

Os upgrades para a versão 1.16.0 falham quando o seccomp está desativado.

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 GKE em Bare Metal versão 1.16 usa o Kubernetes versão 1.27. Nas versões 1.27.0 e mais recentes do Kubernetes, o recurso para definir perfis de seccomp está em disponibilidade geral e não usa mais um gate de recurso. Essa alteração do Kubernetes faz com que os upgrades para a versão 1.16.0 falhem quando seccomp for desativado na configuração do cluster. Esse problema foi corrigido na versão 1.16.1 e nos clusters mais recentes. Se o campo cluster.spec.clusterSecurity.enableSeccomp estiver definido como false, você poderá fazer upgrade para a versão 1.16.1 ou posterior.

Clusters com spec.clusterSecurity.enableSeccomp indefinido ou definido como true não são afetados.

Instalação, operação 1.11, 1.12, 1.13, 1.14, 1.15.0-1.15.5, 1.16.0-1.16.1

Os metadados de containerd podem ser corrompidos após a reinicialização quando o /var/lib/containerd for ativado.

Se você tiver ativado /var/lib/containerd, os metadados do containerd poderão ficar corrompidos após uma reinicialização. Metadados corrompidos podem causar falhas nos pods, incluindo pods essenciais ao sistema.

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


Alternativa:

Remova a opção de ativação 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

Limpar pods desatualizados no cluster

É possível ver pods gerenciados por um Deployment (ReplicaSet) no estado Failed e com o status TaintToleration. Esses pods não usam recursos de cluster, mas precisam ser excluídos.

Use 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 TaintToleration:

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

Alternativa:

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

  1. Receba o ReplicaSet que gerencia o pod e encontre o valor ownerRef.Kind:
    kubectl get pod POD_NAME -n NAMESPACE -o yaml
    
    .
  2. Conseguir 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

O etcd-events pode ser interrompido no upgrade para a versão 1.16.0

Quando você faz upgrade de um cluster atual para a versão 1.16.0, as falhas do pod relacionadas a eventos do etcd podem interromper a operação. Especificamente, o job de upgrade do nó falha para a etapa TASK [etcd_events_install : Run etcdevents].

Se você for afetado por esse problema, terá falhas no pod como estas:

  • 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 falha ao iniciar 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 a correção, use a seguinte solução alternativa temporária para resolver 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 do CoreDNS não foi reconhecido

OrderPolicy não é reconhecido como um parâmetro e não é usado. Em vez disso, o GKE em Bare Metal 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 atual:
    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

Gateway de rede para componentes do GDC removidos ou pendentes devido à classe de prioridade ausente

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 o gateway de rede para pods do GDC não têm classe prioritária, eles 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, é possível atribuir manualmente uma PriorityClass ao gateway de rede para componentes GDC. O controlador do GKE em Bare Metal 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

Falha na criação e no upgrade dos clusters devido ao tamanho do nome do cluster

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 as operações de criação e upgrade de clusters, o GKE em Bare Metal cria um recurso de verificação de integridade com um nome que 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

Os clusters das versões 1.14.0 e 1.14.1 com recursos em fase de pré-lançamento não podem ser atualizados para a versão 1.15.x

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

Os clusters da versão 1.15 não aceitam endereços IP flutuantes duplicados

O gateway de rede para GDC não permite criar novos recursos personalizados NetworkGatewayGroup que contêm endereços IP em spec.floatingIPs que já são usados em recursos personalizados NetworkGatewayGroup atuais. Essa regra é aplicada por um webhook no GKE em clusters Bare Metal versão 1.15.0 e mais recentes. 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. O gateway de rede para GDC agora reconhece todos os recursos personalizados NetworkGatewayGroup 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 NetworkGatewayGroups:
    kubectl get NetworkGatewayGroups --kubeconfig ADMIN_KUBECONFIG \
        -n kube-system -o yaml
    
  2. Abra os recursos personalizados NetworkGatewayGroup existentes 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

As VMs podem não começar em clusters 1.13.7 que usam um registro particular

Quando você ativa o ambiente de execução de VM na GDC em um cluster da versão 1.13.7 novo ou atualizado que usa um registro particular, as VMs que se conectam à rede do nó ou usam uma GPU podem não ser iniciadas 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 mais recentes de clusters do GKE em bare metal.

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-metric-agent falha ao iniciar

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 a finalidade do pod gke-metrics-agent no cluster de tipo é facilitar a taxa de sucesso da criação do cluster e para 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 a finalidade do pod gke-metrics-agent no cluster de tipo é facilitar a taxa de sucesso da criação do cluster e para 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

Acessar um endpoint de serviço IPv6 causa falha no nó LoadBalancer no CentOS ou RHEL

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

Problemas de conectividade intermitente após a reinicialização do nó

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. Esse problema foi 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 não retém as informações do proprietário e permissões originais

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

clientconfig-operator preso no estado pendente com CreateContainerConfigError

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. Versões de cluster anteriores, como 1.14.0 e 1.14.1, não foram 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

A rotação da autoridade de certificação falha para clusters sem balanceamento de carga em pacote

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

ipam-controller-manager loops de falhas em clusters de pilha dupla

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

privação do relógio no etcd

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 no GDCV para as versões do Bare Metal 1.12.9, 1.13.6, 1.14.3 e posteriores. Essas versões mais recentes usam o etcd versão 3.4.21. Todas as versões anteriores do GDCV para Bare Metal foram afetadas por esse 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 do 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

Operador SR-IOV vfio-pci modo "com falha"

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", faça upgrade do cluster para a versão 1.11.7, posterior ou 1.12.4 ou posterior.

Upgrades e atualizações 1.10, 1.11, 1.12, 1.13, 1.14.0, 1.14.1

Alguns nós de trabalho não ficam no estado Pronto após o upgrade

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

Várias rotações de certificado do gerenciador de certificado resultam em inconsistência

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 em um cluster com mais de 180 dias ou mais e nunca reiniciou o anthos-cluster-operator.
  • Se você fez rotações manuais de certificados emitidos por cert-manager em um cluster com mais de 90 dias e nunca reiniciou o anthos-cluster-operator.

Alternativa

Reinicie o pod encerrando o anthos-cluster-operator.

Upgrades e atualizações 1.14.0

Pods do implantador do controlador de ciclo de vida desatualizados criados durante o upgrade do cluster de usuário

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 as operações de upgrade, mas podem ser encontrados 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

O estado BGPSession muda constantemente devido ao grande número de rotas recebidas.

O GKE na rede avançada Bare Metal não gerencia as sessões do BGP corretamente quando pares externos anunciam um alto 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 sessões desatualizadas do BGP 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.

No cluster bare metal do GKE versão 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 e 1,28

Tempos limite do aplicativo causados por falhas de inserção da tabela de conexão

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

Não é possível restaurar backups de clusters com bmctl em algumas versões

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

O NetworkGatewayGroup falhará se não houver um endereço IP na interface

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

Loop de falhas anthos-cluster-operator ao remover um nó do plano de controle

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

kubeadm join falha em clusters grandes devido a incompatibilidade de token.

Ao instalar o GKE em clusters Bare Metal com um grande número de nós, talvez você veja uma mensagem de erro kubeadmin join semelhante ao 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 é resolvido no GDCV para a versão 1.13.4 do Bare Metal 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

Limite de CPU baixo para metrics-server em clusters de borda

Nos clusters do GKE em Bare Metal Edge, limites baixos de CPU para metrics-server podem causar reinicializações frequentes de 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:

  • Clusters do GKE em Bare Metal versão 1.x-1.12:
    kubectl get deployment metrics-server -n kube-system \
        -o yaml > metrics-server.yaml
    
  • Clusters do GKE em Bare Metal versão 1.13 ou mais recente:
    kubectl get deployment metrics-server -n gke-managed-metrics-server \
        -o yaml > metrics-server.yaml
    

Alternativa:

Esse problema é resolvido no GKE em clusters Bare Metal versão 1.13.1 ou mais recente. 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. Reduzir metrics-server-operator:
    kubectl scale deploy metrics-server-operator --replicas=0
  2. Atualize a configuração e aumente os limites de CPU:
    • Clusters do GKE em Bare Metal versão 1.x-1.12:
      kubectl -n kube-system edit deployment metrics-server
    • Clusters do GKE em Bare Metal versão 1.13:
      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 NodePort direta ao pod hostNetwork não funciona

A conexão com um pod ativado com hostNetwork usando o serviço NodePort falha quando o pod de back-end está no mesmo nó que o NodePort de destino. 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 1.13.0 não podem gerenciar clusters de usuário 1.12.3

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

O upgrade para a versão 1.13.x está bloqueado para clusters de administrador com pools de nós de trabalho

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 for interrompido, verifique se os pools de nós de trabalho são a causa verificando 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=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

Erros ao atualizar recursos usando kubectl apply

Se você atualizar os recursos atuais, como os recursos personalizados ClientConfig ou Stackdriver, usando kubectl apply, o controlador poderá retornar um erro ou reverter sua entrada e as alterações 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. Consiga a definição atual do YAML:
    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 de volta:
    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. Consiga a definição atual do YAML:
    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 de volta:
    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

Os fragmentos de backlog corrompidos causam falha no stackdriver-log-forwarder

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. Confira os seguintes exemplos de mensagens de erro:
    [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/ tem falha. Todos os arquivos *.flb com falha na verificação de 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 stackdriver-log-forwarder foram excluídos antes de passar 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

Reiniciar o Dataplane V2 (anetd) em clusters pode fazer com que as VMs atuais não sejam anexadas a uma rede que não seja do pod

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 que o problema se repita, faça upgrade do cluster para a versão 1.14.1 ou posterior.

Operação 1.13, 1.14.0, 1.14.1

gke-metrics-agent não tem limite de memória em clusters de perfil do Edge

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 o GKE em clusters de perfil do 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

A criação do cluster pode falhar devido às disputas

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

Os endereços IP reservados não são liberados ao usar o plug-in de onde está com o recurso de várias NICs

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 de nó falha no cluster de usuário 1.10.4

O Detector de problemas do nó pode falhar nos clusters de usuário da versão 1.10.x quando os clusters de administrador das versões 1.11.0, 1.11.1 ou 1.11.2 gerenciam clusters de usuário da versão 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

Os nós de cluster IPv4 no modo 1.14 da ilha têm um tamanho de máscara CIDR de pod de 24

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 uma máscara CIDR de pod de 22, cada nó receberá uma máscara CIDR de pod de 24 e o cluster só vai poder aceitar 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

Falha na reversão do upgrade do cluster

A reversão de um upgrade pode falhar para os 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. Liste todos os healthchecks.baremetal.cluster.gke.io recursos:
    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 recursos healthchecks.baremetal.cluster.gke.io 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

O endereço IP externo do serviço não funciona no modo plano

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

Os upgrades de 1.13.0 para 1.14.x feitos no local não são concluídos

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 clusters atualizados para a versão 1.14.0 perdem os taints mestres

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 do GKE 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 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

A criação da VM falha intermitentemente com erros de upload

À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 em clusters 1.11 não são preservados nos upgrades para a versão 1.12.

Os componentes da coleção gerenciada fazem parte do Serviço gerenciado para Prometheus. Se você tiver implantado manualmente os componentes da 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 dos clusters da versão 1.12.0, os componentes do Managed Service para Prometheus no namespace gmp-system e as definições de recursos personalizados relacionados são gerenciados por stackdriver-operator com o campo 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 Managed Service para Prometheus.
  3. reimplante os recursos personalizados do PodMonitoring no cluster atualizado.
Upgrades e atualizações 1.13

Não é possível fazer upgrade de alguns clusters da versão 1.12 com o ambiente de execução de contêiner do Docker para a versão 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

bmctl sai antes de a criação do cluster ser concluída

A criação de clusters pode falhar para o GDCV na versão 1.11.0 do Bare Metal . Esse problema foi corrigido no GDCV para a versão 1.11.1 do Bare Metal. 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 instalação informa erro de reconciliação do ambiente de execução da VM

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 ao usar proxy multi-NIC, containerd e HTTPS

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 padrão para GDCV para Bare Metal 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

Falha nos sistemas com a configuração umask restritiva

A GDCV para Bare Metal 1.10.0 introduziu um recurso de plano de controle sem raiz que executa todos os componentes do plano de controle como um usuário não raiz. 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

Incompatibilidade com o grupo de controle v2

O grupo de controle v2 (cgroup v2) não tem suporte no GKE em clusters Bare Metal versões 1.13 e anteriores do GDCV para Bare Metal. 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

Verificações de simulação e credenciais da conta de serviço

Para instalações acionadas por clusters administrativos ou de clusters 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 suas permissões associadas.

Instalação 1,10, 1,11, 1,12, 1,13, 1,14, 1,15, 1,16, 1,28, 1,29

Como instalar no vSphere

Ao instalar clusters do GKE em Bare Metal em VMs do vSphere, defina as sinalizações tx-udp_tnl-segmentation e tx-udp_tnl-csum-segmentation como desativadas. Essas sinalizações estão relacionadas à descarga de segmentação de hardware feita pelo driver VMXNET3 do vSphere e não funcionam com o túnel GENEVE do GKE em 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
...
Às vezes, no RHEL 8.4, ethtool mostra que essas sinalizações estão desativadas enquanto não estão. Para desativar essas sinalizações, ative e desative as flags com os seguintes comandos:
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

O bmctl não pode criar, atualizar ou redefinir clusters de usuário de versão anterior

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

Os upgrades de cluster para a versão 1.12.1 podem parar

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

A atualização de clusters para a versão 1.12.0 ou mais recente falha quando o ambiente de execução de VMs no GDC está ativado

Na versão 1.12.0 dos clusters do GKE em Bare Metal, todos os recursos relacionados ao ambiente de execução da VM no GDC são migrados para o namespace vm-system para oferecer melhor suporte ao ambiente de execução da VM na versão GA do GDC. Se você tiver o ambiente de execução de VM na GDC ativado em um cluster da versão 1.11.x ou anterior, o upgrade para a versão 1.12.0 ou mais recente falhará, a menos que você primeiro desative o ambiente de execução de 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 na 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 o ambiente de execução da VM no GDC.

Para mais informações, consulte Como trabalhar com cargas de trabalho baseadas em VM.

Upgrades e atualizações 1.10, 1.11, 1.12

O upgrade parou em error during manifests operations

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 são bloqueados para clusters com recursos que usam o gateway de rede para GDC

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. Ambos os 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

bmctl update não remove bloqueios de manutenção

O comando bmctl update não pode remover ou modificar a seção maintenanceBlocks da configuração do recurso 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

Os nós não são restritos se você não usar o procedimento do modo de manutenção

Se você executar clusters da versão 1.12.0 (anthosBareMetalVersion: 1.12.0) ou anterior e usar manualmente kubectl cordon em um nó, o GKE em Bare Metal poderá desvincular o nó antes que esteja tudo pronto para reconciliar o estado esperado.


Alternativa

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

Na versão 1.12.1 (anthosBareMetalVersion: 1.12.1) ou mais recente, o GKE em Bare Metal não desassociará seus nós inesperadamente quando usar kubectl cordon.

Operação 1.11

Os clusters de administrador da versão 11 que usam um espelho de registro não podem gerenciar os clusters da versão 1.10

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

Secret do kubeconfig substituído

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 ao GKE em clusters Bare Metal 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 namespaces dos clusters do GKE em bare metal 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 GKE em 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 é o kubeconfig correto do cluster de usuário:
    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

Como tirar um snapshot como um usuário de login não raiz

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

stackdriver-log-forwarder tem [parser:cri] invalid time format registros de aviso

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

Faturamento inesperado de monitoramento

Para as versões 1.10 a 1.15 do cluster bare metal do GKE, alguns clientes encontraram um faturamento alto inesperado para Metrics volume na página Faturamento. Esse problema afeta você apenas quando ambas as circunstâncias a seguir se aplicarem:

  • O monitoramento de aplicativos está ativado (enableStackdriverForApplications=true)
  • O 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 fazer upgrade dos clusters para a versão 1.12 e mudar para a nova solução de monitoramento de aplicativos managed-service-for-prometheus que resolva o 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 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

    As edições em metrics-server-config não são mantidas

    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

    Métricas com uso suspenso afetam o painel do Cloud Monitoring

    Várias métricas do GKE em Bare Metal foram descontinuadas e, a partir da GDCV para Bare Metal versão 1.11, os dados não são mais coletados para essas 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

    Nas versões do cluster bare metal do GKE anteriores à 1.11, o arquivo de definição da 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

    stackdriver-log-forwarder contém erros CrashloopBackOff

    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 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 passar para a próxima etapa.
    2. Implante o DaemonSet a seguir para limpar todos os dados corrompidos em buffers de 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 no seu 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

    Erro de métrica desconhecido no registro do gke-metrics-agent

    gke-metrics-agent é um daemonset que coleta métricas em cada nó e as encaminha para o Cloud Monitoring. Ele pode produzir registros como os seguintes:

    Unknown metric: kubernetes.io/anthos/go_gc_duration_seconds_summary_percentile
    

    Erros semelhantes podem ocorrer com outros tipos de métricas, incluindo, entre outras:

    • 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, já que as métricas a que se referem não são compatíveis nem essenciais para fins de monitoramento.

    Geração de registros e monitoramento 1.10, 1.11

    Interrupções intermitentes da exportação de métricas

    Os clusters do GKE em bare metal podem apresentar interrupções na exportação normal e contínua de métricas ou perder métricas 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 seu recurso stackdriver para edição:
      kubectl -n kube-system edit stackdriver stackdriver
      
    2. Para aumentar a solicitação de CPU para 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 vai ficar assim:
      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 encontra cpu: 50m se as edições entraram em vigor.
    Rede 1.10

    Vários gateways padrão apresentam falha de conectividade com endpoints externos

    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

    As edições personalizadas de recursos de rede em clusters de usuários são substituídas

    A versão 1.12.x dos clusters do GKE em Bare Metal não impede que você edite manualmente os recursos personalizados de rede no cluster de usuário. O GKE em Bare Metal reconcilia recursos personalizados nos clusters de usuário com os recursos personalizados no cluster de administrador durante os upgrades do cluster. Essa reconciliação substitui todas as edições feitas diretamente nos recursos personalizados de rede no cluster de usuário. Os recursos personalizados de rede precisam 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 1.13.0 e mais recentes do cluster do GKE em Bare Metal 1.13.0 e mais recentes impedem que você modifique os recursos personalizados de rede diretamente nos clusters de usuário.

    Rede 1,10, 1,11, 1,12, 1,13, 1,14, 1,15, 1,16, 1,28

    Falhas de conectividade dos pods e filtragem de caminho reverso

    O GKE em Bare Metal configura a filtragem de caminho reverso nos nós para desativar a validação da origem (net.ipv4.conf.all.rp_filter=0). Se a configuração rp_filter for alterada para 1 ou 2, os pods falharão 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 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 alteração.

    Ou

    Reinicie o pod anetd para definir net.ipv4.conf.all.rp_filter novamente como 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 valor net.ipv4.conf.all.rp_filter está definido como 0 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

    Endereços IP do cluster de inicialização (tipo) e endereços IP dos nós do cluster sobrepostos

    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

    Falha na criação ou atualização do cluster no CentOS

    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 de clusters do GKE em Bare Metal.


    Alternativa

    Segurança 1,10, 1,11, 1,12, 1,13, 1,14, 1,15, 1,16, 1,28

    O contêiner não pode gravar em VOLUME definido no Dockerfile com containerd e SELinux

    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

    O Detector de problemas do nó não é ativado por padrão após upgrades do cluster

    Quando você faz upgrade do GKE em clusters Bare Metal, 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, isso significa que o node-problem-detector não está em execução 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 backup de clusters falha ao usar o login não raiz

    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 nas versões 1.10.2 e posteriores.

    Rede 1.10, 1.11, 1.12

    Os serviços do balanceador de carga não funcionam com contêineres na rede do host do plano de controle

    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

    Pod órfão de anthos-version-$version$ com falha ao extrair imagem

    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 porque a disputa de anthos-cluster-operator recebe upgrade e não afeta 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

    1.12 clusters atualizados da 1.11 não podem atualizar para 1.13.0

    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 do 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

    Uso elevado da CPU em stackdriver-operator

    Há um problema em stackdriver-operator que faz com que ele consuma mais tempo de CPU do que o normal. O uso normal da CPU é inferior a 50 miliCPU (50m) para stackdriver-operator no estado inativo. O motivo é uma incompatibilidade de recursos de certificado que stackdriver-operator aplica com as expectativas de cert-manager. Essa incompatibilidade causa uma disputa entre cert-manager e stackdriver-operator na atualização desses recursos.

    Esse problema pode resultar em desempenho reduzido em clusters com disponibilidade limitada de CPU.


    Alternativa:

    Até que seja possível fazer upgrade para uma versão que corrija esse bug, use a seguinte solução alternativa:

    1. Para reduzir escala vertical temporariamente stackdriver-operator a 0 réplica, 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, escalone stackdriver-operator novamente:
      kubectl scale deploy stackdriver-operator --replicas=1
      
    Geração de registros e monitoramento 1.16.0, 1.16.1

    A extração de métricas com base em anotações não está funcionando

    Na versão secundária do GDCV para Bare Metal 1.16, o campo enableStackdriverForApplications na especificação de recurso personalizado stackdriver foi descontinuado. Esse campo será substituído por dois campos, enableCloudLoggingForApplications e enableGMPForApplications, no recurso personalizado do Stackdriver.

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

    Se você depende da coleta de métricas acionada por anotações prometheus.io/scrape nas suas cargas de trabalho, é possível usar a sinalização de bloqueio de recursos annotationBasedApplicationMetrics para manter o comportamento antigo. No entanto, há um problema que impede que o annotationBasedApplicationMetrics funcione corretamente, impedindo a coleta de métricas dos seus aplicativos no Cloud Monitoring.


    Alternativa:

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

    A coleta de métricas de carga de trabalho com base em anotações, ativada pelo portão de recursos annotationBasedApplicationMetrics, coleta métricas de objetos que têm a anotação prometheus.io/scrape. Muitos sistemas de software com origem de código aberto podem usar essa anotação. Se você continuar usando esse método de coleta de métricas, esteja ciente dessa dependência para não se surpreender com as cobranças de métricas no Cloud Monitoring.

    Se precisar de mais ajuda, entre em contato com o Cloud Customer Care.