Os clusters do Anthos em bare metal agora são o Google Distributed Cloud (somente software) em bare metal. Para mais informações, consulte a visão geral do produto.
Problemas conhecidos do Google Distributed Cloud para bare metal
Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
formatação de comentário no início e no final de cada linha. #}
vinculação, torna muito mais fácil manter esta página atualizada. #}
Esta página lista todos os problemas conhecidos do Google Distributed Cloud (somente software) para APIs
metal, antes conhecido como Google Distributed Cloud Virtual. Para filtrar os problemas
conhecidos por uma versão ou categoria do produto, selecione os filtros nos
menus suspensos a seguir.
Selecione sua versão do Google Distributed Cloud:
Selecione a categoria do seu problema:
Ou pesquise seu problema:
Categoria
Versões identificadas
Problema e solução alternativa
Instalação, upgrades e atualizações
1.28.0 para 1.28.600 e 1.29.0 para 1.29.200
Falhas na verificação de simulação da máquina nas configurações de check_inotify_max_user_instances e check_inotify_max_user_watches
Durante a instalação ou upgrade do cluster, a simulação da máquina verifica
relacionadas às configurações do kernel do fs.inotify podem falhar. Se você estiver
afetada por esse problema, o registro de verificação de simulação da máquina contém um erro
como estes:
Minimum kernel setting required for fs.inotify.max_user_instances is 8192. Current fs.inotify.max_user_instances value is 128. Please run "echo "fs.inotify.max_user_instances=8192" | sudo tee --append /etc/sysctl.conf" to set the correct value.
Esse problema ocorre porque fs.inotify max_user_instances e
Os valores max_user_watches são lidos incorretamente no controle
e hosts de inicialização, em vez das máquinas de nós pretendidas.
Alternativa:
Para contornar esse problema, ajuste o fs.inotify.max_user_instances.
e fs.inotify.max_user_watches aos valores recomendados na
todas as máquinas de plano de controle e bootstrap:
echo fs.inotify.max_user_watches=524288 | sudo tee --append /etc/sysctl.conf
echo fs.inotify.max_user_instances=8192 | sudo tee --append /etc/sysctl.conf
sudo sysctl -p
Após a conclusão da instalação ou atualização, esses valores podem ser
e pode ser revertida, se necessário.
Configuração, instalação, upgrades e atualizações, rede, segurança
1.15, 1.16, 1.28, 1.29
A instalação e o upgrade do cluster falham quando o ipam-controller-manager é necessário
A instalação e o upgrade do cluster falham quando
ipam-controller-manager é obrigatório, e seu cluster é
com o Red Hat Enterprise Linux (RHEL) 8.9 ou posterior (dependendo da
alterações upstream do RHEL) com o SELinux em execução no modo de aplicação. Esta
se aplica especificamente quando a versão container-selinux é
superior a 2.225.0.
Seu cluster exige ipam-controller-manager em qualquer um
as seguintes situações:
O cluster está configurado para rede de pilha dupla IPv4/IPv6
Seu cluster está configurado com clusterNetwork.flatIPv4
Definir como true
Seu cluster é configurado com
preview.baremetal.cluster.gke.io/multi-networking: enable
anotação
A instalação e o upgrade do cluster não funcionam quando o
O app ipam-controller-manager está instalado.
Alternativa
Definir o contexto padrão para o diretório /etc/kubernetes
em cada nó do plano de controle para o tipo etc_t:
O upgrade do cluster falha com um erro de verificação de acessibilidade do Google Cloud
Quando você usa bmctl para fazer upgrade de um cluster,
falhar com um erro GCP reachability check failed mesmo que o
o URL de destino pode ser acessado na estação de trabalho do administrador. Esse problema é causado por
um bug nas versões 1.28.0 a 1.28.500 do bmctl.
Alternativa:
Antes de executar o comando bmctl upgrade, defina o
variável de ambiente GOOGLE_APPLICATION_CREDENTIALS para apontar
um arquivo de chave da conta de serviço válido:
Definir o Application Default Credentials (ADC) dessa forma garante que
bmctl tem as credenciais necessárias para acessar a API do Google
endpoint de API.
Configuração, instalação, upgrades e atualizações, rede, segurança
1.15, 1.16, 1.28, 1.29
A instalação e o upgrade do cluster falham quando o ipam-controller-manager é necessário
A instalação e o upgrade do cluster falham quando
ipam-controller-manager é obrigatório, e seu cluster é
com o Red Hat Enterprise Linux (RHEL) 8.9 ou posterior (dependendo da
alterações upstream do RHEL) com o SELinux em execução no modo de aplicação. Esta
se aplica especificamente quando a versão container-selinux é
superior a 2.225.0.
Seu cluster exige ipam-controller-manager em qualquer um
as seguintes situações:
O cluster está configurado para rede de pilha dupla IPv4/IPv6
Seu cluster está configurado com clusterNetwork.flatIPv4
Definir como true
Seu cluster é configurado com
preview.baremetal.cluster.gke.io/multi-networking: enable
anotação
A instalação e o upgrade do cluster não funcionam quando o
O app ipam-controller-manager está instalado.
Alternativa
Definir o contexto padrão para o diretório /etc/kubernetes
em cada nó do plano de controle para o tipo etc_t:
O upgrade do cluster falha com um erro de verificação de acessibilidade do Google Cloud
Quando você usa bmctl para fazer upgrade de um cluster,
falhar com um erro GCP reachability check failed mesmo que o
o URL de destino pode ser acessado na estação de trabalho do administrador. Esse problema é causado por
um bug nas versões 1.28.0 a 1.28.500 do bmctl.
Alternativa:
Antes de executar o comando bmctl upgrade, defina o
variável de ambiente GOOGLE_APPLICATION_CREDENTIALS para apontar
um arquivo de chave da conta de serviço válido:
Definir o Application Default Credentials (ADC) dessa forma garante que
bmctl tem as credenciais necessárias para acessar a API do Google
endpoint de API.
Instalação
1.29
Problema de autorização binária no cluster com pool de nós separado do balanceador de carga
A instalação de um cluster com um pool de nós separado do balanceador de carga pode falhar
se você
ativar
política de autorização binária durante a criação do cluster.
Esse problema acontece porque a criação do serviço de identidade do GKE
O pod e outros pods críticos estão bloqueados pela autorização binária
webhook.
Para determinar se esse problema está afetando você, complete as seguintes etapas:
Identifique quais pods estão com falha:
kubectl get pods \
-n anthos-identity-service \
--kubeconfig CLUSTER_KUBECONFIG
Descreva o pod com falha.
Procure a seguinte mensagem na saída:
admission webhook "binaryauthorization.googleapis.com" denied the
request: failed to post request to endpoint: Post
"https://binaryauthorization.googleapis.com/internal/projects/PROJECT_NUMBER/policy/locations/LOCATION/clusters/CLUSTER_NAME:admissionReview":
oauth2/google: status code 400:
{"error":"invalid_target","error_description":"The
target service indicated by the \"audience\" parameters is invalid.
This might either be because the pool or provider is disabled or deleted
or because it doesn't exist."}
Se você receber a mensagem anterior, seu cluster está com esse problema.
Alternativa:
Para resolver esse problema, siga estas etapas:
Cancelar a operação de criação do cluster.
Remova o bloco spec.binaryAuthorization da
de configuração do cluster.
Crie o cluster com a autorização binária desativada.
Pontos de montagem com o SELinux ativado estão causando problemas
Se você tiver o SELinux ativado e montar sistemas de arquivos no Kubernetes
diretórios relacionados, poderá ter problemas como a criação de clusters
falha, arquivos ilegíveis ou problemas de permissão.
Para saber se você foi afetado por esse problema, execute o seguinte comando:
ls -Z /var/lib/containerd
:
Se aparecer
system_u:object_r:unlabeled_t:s0, em que se espera
ver outro rótulo, como
system_u:object_r:container_var_lib_t:s0, isso afeta você.
Alternativa:
Se você montou recentemente sistemas de arquivos em diretórios, verifique se esses
estão atualizados de acordo com sua configuração do SELinux.
Execute os seguintes comandos em cada máquina antes
executando bmctl create cluster:
restorecon -R -v /var
restorecon -R -v /etc
Essa correção única persistirá após a reinicialização, mas será necessária a cada
vez que um novo nó com os mesmos pontos de montagem é adicionado. Para saber mais, consulte
Montar sistemas de arquivos na documentação do Red Hat.
Redefinir/excluir
1.29.0
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 excluirá os
namespace do cluster de usuário. O namespace do cluster de usuário está preso na
Terminating. Com o tempo, a redefinição do cluster expira
e retorna um erro.
Alternativa:
Para remover o namespace e concluir a redefinição do cluster de usuário, use o
seguintes etapas:
Exclua o pod metrics-server do cluster de administrador:
Depois que o finalizador é removido, o namespace do cluster é removido e o
a redefinição do cluster foi concluída.
configuração, instalação, segurança
1.16.0 para 1.16.7 e 1.28.0 para 1.28.400
A implantação da autorização binária não tem um nodeSeletor
Se você ativou
Autorização binária
para o GKE em Bare Metal e estão usando a versão 1.16.0 para
das versões 1.16.7 ou 1.28.0 a 1.28.400,
os pods do recurso são programados. Nessas versões, a
A implantação da autorização binária não tem um nodeSelector, então a
É possível programar pods para o atributo em nós de trabalho em vez de controlar
nós do plano de controle. Esse comportamento não faz com que nada falhe, mas não é
pretendido.
Alternativa:
Para todos os clusters afetados, siga estas etapas:
Abra o arquivo de implantação da autorização binária:
Depois que a alteração é salva, os pods são reimplantados apenas no controle
nós do plano de controle. Essa correção precisa ser aplicada após cada upgrade.
Upgrades e atualizações
1.28.0, 1.28.100, 1.28.200, 1.28.300
Erro ao fazer upgrade de um cluster para 1.28.0-1.28.300
Upgrade de clusters criados antes da versão 1.11.0 para as versões 1.28.0-1.28.300
pode fazer com que o pod do implantador do controlador do ciclo de vida entre em um estado de erro
durante o upgrade. Quando isso acontece, os registros do controlador de ciclo de vida
o pod do implantador tem uma mensagem de erro semelhante a esta:
"inventorymachines.baremetal.cluster.gke.io\" is invalid: status.storedVersions[0]: Invalid value: \"v1alpha1\": must appear in spec.versions
Alternativa:
Esse problema foi corrigido na versão 1.28.400. Fazer upgrade para a versão 1.28.400 ou
para resolver o problema depois.
Se você não conseguir fazer upgrade, execute os comandos a seguir para resolver o
problema:
ID do projeto incorreto exibido na Análise de registros
Às vezes, os registros de clusters ou contêineres são marcados com um ID de projeto diferente
em resource.labels.project_id na Análise de registros.
Isso pode acontecer quando o cluster está configurado para usar a observabilidade
PROJECT_ONE, que é definido nos
clusterOperations.projectID na configuração do cluster.
No entanto, o cloudOperationsServiceAccountKeyPath no
A configuração tem uma chave de conta de serviço do projeto
PROJECT_TWO.
Nesses casos, todos os registros são roteados para PROJECT_ONE,
mas resource.labels.project_id é rotulado como
PROJECT_TWO:
Alternativa:
Use uma das seguintes opções para resolver o problema:
Use uma conta de serviço do mesmo projeto de destino.
Altere project_id no arquivo JSON da chave da conta de serviço para o projeto atual.
Altere o project_id diretamente no filtro de registro da Análise de registros.
Rede
1.29.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 poderá
degradar-se conforme o número total de serviços
tipo LoadBalancer for de 2.000. Com a queda do desempenho,
Serviços recém-criados levam muito tempo para se conectar ou
que um cliente não pode acessar. os serviços atuais continuam funcionando,
sem lidar com modos de falha, como a perda de um nó do balanceador de carga,
de forma eficaz. Esses problemas de serviço acontecem quando
A implantação do ang-controller-manager foi encerrada devido a
sem memória.
Se o cluster for afetado por esse problema, os serviços no cluster
inacessível e inacessível e o ang-controller-manager
A implantação está em um CrashLoopBackOff. A resposta quando
listar as implantações de ang-controller-manager é semelhante a
o seguinte:
Como solução alternativa, você pode aumentar o limite de recursos de memória da implantação ang-controller-manager em 100 MiB e remover a
Limite de CPU:
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 bootstrap
cluster especificado. Antes de criar um cluster de inicialização, bmctl
executa uma verificação de acessibilidade do Google Cloud na estação de trabalho do administrador.
Esta verificação pode falhar devido a problemas de conectividade com o
endpoint do Container Registry, gcr.io, e talvez um
como esta:
system checks failed for bootstrap machine: GCP reachability check failed: failed to reach url https://gcr.io: Get "https://cloud.google.com/artifact-registry/": net/http: request canceled (Client.Timeout exceeded while awaiting headers)
Alternativa
Para contornar esse problema, tente realizar a operação novamente com a sinalização.
--ignore-validation-errors:
Rede
1.15, 1.16
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. Você pode enfrentar
problemas com volumes ou pods NFS travados. Isso é bastante provável se
há cargas de trabalho que usam ReadWriteMany volumes com suporte
drivers de armazenamento suscetíveis a esse problema:
Robin.io
Portworx (sharedv4 de volumes de serviço)
csi-nfs
Esta não é uma lista completa.
Alternativa
Uma correção para esse problema está disponível para as seguintes versões do Ubuntu:
20.04 LTS: use uma imagem do kernel 5.4.0 posterior a
linux-image-5.4.0-166-generic
22.04 LTS: use uma imagem do kernel 5.15.0 posterior a
linux-image-5.15.0-88-generic ou use o kernel 6.5 HWE.
Se você não usa uma dessas versões, entre em contato
Suporte do Google
Geração de registros e monitoramento
1.15, 1.16, 1.28
kube-state-metrics OOM em cluster grande
Você pode notar que kube-state-metrics ou o
Pod gke-metrics-agent que existe no mesmo nó que
kube-state-metrics está sem memória (OOM, na sigla em inglês).
Isso pode acontecer em clusters com mais de 50 nós
objetos do Kubernetes.
Alternativa
Para resolver esse problema, atualize o stackdriver personalizado
definição de recurso para usar o ksmNodePodMetricsOnly
portão de recurso. Essa porta de recursos garante que apenas um pequeno número
e as métricas críticas serão expostas.
Para usar essa solução alternativa, siga estas etapas:
Verifique a definição do recurso personalizado stackdriver para
portões de recursos disponíveis:
A verificação de simulação falha no RHEL 9.2 devido à ausência de iptables
Ao instalar um cluster no Red Hat Enterprise Linux (RHEL) 9.2
sistema operacional, pode ocorrer uma falha devido à
pacote iptables. A falha ocorre durante a simulação
verifica e aciona uma mensagem de erro semelhante a esta:
'check_package_availability_pass': "The following packages are not available: ['iptables']"
O RHEL 9.2 está em Pré-lançamento
para a versão 1.28 do Google Distributed Cloud.
Alternativa
Para ignorar o erro de verificação de simulação, defina
spec.bypassPreflightCheck para true no seu
recurso de cluster.
Operação
1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16
Failover lento do MetalLB em alta escala
Quando o MetalLB lida com um grande número de serviços (mais de 10.000),
e o failover pode levar mais de uma hora. Isso acontece porque o MetalLB usa uma taxa
fila limitada que, quando em alta escala, pode demorar um pouco para
do serviço que precisa fazer failover.
Alternativa
Faça upgrade do cluster para a versão 1.28 ou posterior. Se você não conseguir
fazer upgrade, editar manualmente o serviço (por exemplo, adicionar um
) faz com que o serviço faça failover mais rapidamente.
Operação
1.16.0-1.16.6, 1.28.0-1.28.200
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 o exemplo a seguir:
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 em
nós do plano de controle têm a propriedade do grupo e do usuário definida como root.
Esta configuração de propriedade de arquivo causa falhas de upgrade no plano de controle
nós ao fazer upgrade de um cluster da versão 1.16.x para a versão 1.28.0-gke.435.
Esse problema só se aplica a clusters criados antes da versão
1.11 com os Registros de auditoria do Cloud desativados. Os Registros de auditoria do Cloud estão ativados
por padrão para clusters na versão 1.9 e superior.
Alternativa
Se não for possível fazer upgrade do cluster para a versão 1.28.100-gke.146,
use as etapas a seguir como solução alternativa para concluir o upgrade do cluster
para a versão 1.28.0-gke.435:
Se os Registros de auditoria do Cloud estiverem ativados, remova o arquivo /var/log/apiserver/audit.log.
Se os Registros de auditoria do Cloud estiverem desativados, mude a propriedade de /var/log/apiserver/audit.log para a mesma do diretório pai, /var/log/apiserver.
Rede, upgrades e atualizações
1.28.0-gke.435
O MetalLB não atribui endereços IP a serviços VIP
O Google Distributed Cloud usa o MetalLB para balanceamento de carga em pacote. No Google Distributed Cloud
versão 1.28.0-gke.435, será feito o upgrade do MetalLB empacotado para a versão 0.13,
que passa a oferecer suporte à CRD para IPAddressPools. No entanto,
como ConfigMaps permite qualquer nome para IPAddressPool,
os nomes dos pools precisavam ser convertidos para um nome compatível com o Kubernetes
anexando um hash ao final do nome do IPAddressPool.
Por exemplo, uma IPAddressPool com o nome default.
é convertido em um nome como default-qpvpd quando você faz o upgrade.
do cluster para a versão 1.28.0-gke.435.
Como o MetalLB requer um nome específico de IPPool para
seleção, a conversão de nome impede que o MetalLB crie um pool
seleção e atribuição de endereços IP. Portanto, os Serviços que usam
metallb.universe.tf/address-pool como uma anotação para selecionar
o pool de endereços de um endereço IP não recebe mais um endereço IP
o controlador do MetalLB.
Esse problema foi corrigido na versão 1.28.100-gke.146 do Google Distributed Cloud.
Alternativa
Se não for possível fazer upgrade do cluster para a versão 1.28.100-gke.146, use o
como solução alternativa:
Consiga o nome convertido do IPAddressPool:
kubectl get IPAddressPools -n kube-system
Atualize o serviço afetado para definir o metallb.universe.tf/address-pool
para o nome convertido com o hash.
Por exemplo, se o nome IPAddressPool foi convertido de
default para um nome como default-qpvpd, mude
a anotação metallb.universe.tf/address-pool: default
no serviço para metallb.universe.tf/address-pool: default-qpvpd.
O hash usado na conversão do nome é determinístico, ou seja,
alternativa é persistente.
Upgrades e atualizações
1.14, 1.15, 1.16, 1.28, 1.29
Pods órfãos após o upgrade para a versão 1.14.x
Ao fazer upgrade dos clusters do Google Distributed Cloud para a versão 1.14.x, alguns
os recursos da versão anterior não são excluídos. Especificamente, você
poderá encontrar um conjunto de pods órfãos como este:
Esse problema foi corrigido na versão 1.15.0 e mais recentes do Google Distributed Cloud.
Instalação
1,14
A criação do cluster travou no job machine-init
Se você tentar instalar o Google Distributed Cloud versão 1.14.x,
falha devido aos jobs machine-init, semelhante a
o seguinte exemplo de saída:
"kubeadm join" task failed due to:
error execution phase control-plane-join/etcd: error creating local etcd static pod manifest file: etcdserver: re-configuration failed due to not enough started members
"kubeadm reset" task failed due to:
panic: runtime error: invalid memory address or nil pointer dereference
Alternativa:
Remove o membro obsoleto do etcd que faz com que o
falha do job machine-init. Conclua as etapas a seguir
nó do plano de controle em funcionamento:
Liste os membros atuais do etcd:
etcdctl --key=/etc/kubernetes/pki/etcd/peer.key \
--cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/peer.crt \
member list
Procure os membros com o status unstarted, como mostrado em
o seguinte exemplo de saída:
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 da falha
Membro do etcd. No exemplo de saída anterior, esse ID é
bd1949bcb70e2cb5: e
O exemplo de saída a seguir mostra que o membro foi removido:
Member bd1949bcb70e2cb5 removed from cluster 9d70e2a69debf2f
Rede
1.28.0
Cilium-operator nó ausentes list e
permissões watch
No Cilium 1.13, o ClusterRole cilium-operator
estão incorretas. Os nós list e
watch permissões estão ausentes. O
cilium-operator falha ao iniciar coletores de lixo, que
resulta nos seguintes problemas:
Vazamento de recursos do Cilium.
Identidades desatualizadas não são removidas dos mapas de política do Filestore.
Os mapas de políticas podem atingir o limite de 16 mil.
Não é possível adicionar novas entradas.
Aplicação incorreta da NetworkPolicy.
As identidades podem atingir o limite de 64 mil.
Não será possível criar pods.
Um operador sem as permissões de nó informa o seguinte
exemplo de mensagem de registro:
2024-01-02T20:41:37.742276761Z level=error msg=k8sError error="github.com/cilium/cilium/operator/watchers/node.go:83: Failed to watch *v1.Node: failed to list *v1.Node: nodes is forbidden: User \"system:serviceaccount:kube-system:cilium-operator\" cannot list resource \"nodes\" in API group \"\" at the cluster scope" subsys=k8s
O agente Cilium relata uma mensagem de erro quando não consegue inserir um
entrada em um mapa de política, como o exemplo a seguir:
level=error msg="Failed to add PolicyMap key" bpfMapKey="{6572100 0 0 0}" containerID= datapathPolicyRevision=0 desiredPolicyRevision=7 endpointID=1313 error="Unable to update element for Cilium_policy_01313 map with file descriptor 190: the map is full, please consider resizing it. argument list too long" identity=128 ipv4= ipv6= k8sPodName=/ port=0 subsys=endpoint
Alternativa:
Remova as identidades do Cilium e adicione o ClusterRole que está faltando
permissões ao operador:
Remova os objetos CiliumIdentity atuais:
kubectl delete ciliumid –-all
Edite o objeto ClusterRole cilium-operator:
kubectl edit clusterrole cilium-operator
Adicione uma seção para nodes que inclua
, conforme mostrado no exemplo a seguir:
- apiGroups:
- ""
resources:
- nodes
verbs:
- get
- list
- watch
Salve e feche o editor. O operador detecta dinamicamente
mudança de permissão. Não é necessário reiniciar manualmente o operador.
Upgrades e atualizações
1.15.0-1.15.7, 1.16.0-1.16.3
Problema temporário encontrado durante a verificação de simulação.
Uma das tarefas de verificação de integridade do kubeadm executadas durante o upgrade
a verificação de simulação pode falhar com a seguinte mensagem de erro:
[ERROR CreateJob]: could not delete Job \"upgrade-health-check\" in the namespace \"kube-system\": jobs.batch \"upgrade-health-check\" not found
Esse erro pode ser ignorado com segurança. Se você encontrar esse erro que
bloqueia o upgrade, e execute novamente o comando de upgrade.
Se você observar esse erro ao executar a simulação usando o
bmctl preflightcheck, nada é bloqueado por este
falha. É possível executar a verificação de simulação novamente para
informações de simulação.
Alternativa:
Execute novamente o comando de upgrade ou, se encontrado durante
bmctl preflightcheck, executar novamente preflightcheck
comando.
Operação
1.14, 1.15.0-1.15.7, 1.16.0-1.16.3, 1.28.0
A verificação periódica de integridade da rede falha quando um nó é substituído ou removido
Esse problema afeta clusters que realizam verificações periódicas de integridade da rede
depois que um nó for substituído ou removido. Se o cluster passa por períodos
verificações de integridade, a verificação periódica de integridade da rede resulta em falha após
na substituição ou remoção de um nó, porque o ConfigMap do inventário de rede
não é atualizado depois de criado.
Alternativa:
A solução alternativa recomendada é excluir o ConfigMap do inventário e o
verificações periódicas de integridade da rede. O operador de cluster automaticamente
recria-as com as informações mais atualizadas.
Para clusters 1.14.x, execute os seguintes comandos:
O gateway de rede para GDC não pode aplicar sua configuração quando o dispositivo
nome contém um ponto
Se você tiver um dispositivo de rede com um caractere de ponto
(.) no nome, como bond0.2,
O gateway de rede para a GDC trata o período como um caminho no
diretório quando ele executa sysctl para fazer mudanças. Quando
O gateway de rede para GDC verifica se há detecção de endereço duplicado
(DAD) estiver ativado, a verificação poderá falhar e, portanto, não realizará a reconciliação.
O comportamento é diferente entre as versões do cluster:
1.14 e 1.15: esse erro só existe quando você usa IPv6.
endereços IP flutuantes. Se você não usar endereços IP flutuantes IPv6,
não notará esse problema quando os nomes dos dispositivos contiverem um ponto.
1.16.0 a 1.16.2: esse erro sempre existe quando o dispositivo
contêm um ponto.
Alternativa:
Faça upgrade do cluster para a versão 1.16.3 ou posterior.
Como solução alternativa, até que seja possível fazer upgrade dos clusters, remova o período
(.) do nome do dispositivo.
Upgrades e atualizações, rede, segurança
1.16.0
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 Google Distributed Cloud versão 1.16 usa o Kubernetes versão 1.27.
Na versão 1.27.0 e mais recentes do Kubernetes, o recurso de configuração
seccomp perfis estão em disponibilidade geral e não usam mais uma
porta de recursos (em inglês).
Essa mudança do Kubernetes faz com que os upgrades para a versão 1.16.0 falhem quando
seccomp está desativado na configuração do cluster. Este problema
foi corrigido na versão 1.16.1 e nos clusters mais recentes. Se você
definir o campo cluster.spec.clusterSecurity.enableSeccomp;
para false, é possível fazer upgrade para a versão 1.16.1 ou superior.
Clusters com spec.clusterSecurity.enableSeccomp não definido ou
definidas como true não são afetadas.
Os metadados de containerd podem ser corrompidos após a reinicialização quando
O dispositivo /var/lib/containerd foi ativado
Se você ativou o /var/lib/containerd, a
Os metadados de containerd podem ser corrompidos após uma reinicialização. Metadados corrompidos
pode causar falhas nos pods, incluindo pods essenciais ao sistema.
Para verificar se esse problema afeta você, confira se uma montagem opcional foi definida
em /etc/fstab para /var/lib/containerd/ e tem
nofail nas opções de montagem.
Alternativa:
Remova a opção de montagem nofail em /etc/fstab.
ou faça upgrade do cluster para a versão 1.15.6 ou mais recente.
Operação
1.13, 1.14, 1.15, 1.16, 1.28
Limpar pods desatualizados no cluster
É possível encontrar pods gerenciados por uma implantação (ReplicaSet) em um
Failed e com o status de
TaintToleration. Esses pods não usam recursos de cluster,
deve ser excluída.
É possível usar o seguinte comando kubectl para listar os
Pods que podem ser limpos:
kubectl get pods –A | grep TaintToleration
O exemplo de saída a seguir mostra um pod com o
Status de TaintToleration:
Para cada pod com os sintomas descritos, verifique o ReplicaSet
do pod. Se o ReplicaSet for atendido, é possível excluir os pods:
Acessar o ReplicaSet que gerencia o pod e encontrar o
Valor de ownerRef.Kind:
kubectl get pod POD_NAME -n NAMESPACE -o yaml
Acessar o ReplicaSet e verificar se o status.replicas
é igual a spec.replicas:
kubectl get replicaset REPLICA_NAME -n NAMESPACE -o yaml
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 ao fazer 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
relacionados a eventos do etcd podem
interromper a operação. Especificamente, é possível
o job de upgrade-node falha para o
TASK [etcd_events_install : Run etcdevents] etapa.
Se você for afetado por esse problema, vai encontrar falhas no pod, como
seguindo:
O pod kube-apiserver falha ao iniciar com o
seguinte erro:
Esses erros indicam eventos de remoção ou impossibilidade de programar pods
devido a recursos de nó. Como gateway de rede para pods do GDC,
prioridadeClass, elas têm a mesma prioridade padrão que outras cargas de trabalho.
Quando os nós têm recursos restritos, os pods do gateway de rede podem ser
removidos. Esse comportamento é especialmente ruim para o DaemonSet ang-node,
porque esses pods precisam ser programados em um nó específico e não podem ser
migrados.
Alternativa:
Faça upgrade para a versão 1.15 ou posterior.
Como uma correção de curto prazo, você pode atribuir
PriorityClass
aos componentes de gateway de rede para GDC. O controlador do Google Distributed Cloud
substitui essas alterações manuais durante um processo de reconciliação, como
durante um upgrade de cluster.
Atribua a PriorityClass system-cluster-critical às
implantações do controlador de
cluster ang-controller-manager e autoscaler.
Atribua a PriorityClass system-node-critical ao
DaemonSet do nó ang-daemon.
Instalação, upgrades e atualizações
1.15.0, 1.15.1, 1.15.2
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 a criação do cluster e as operações de upgrade,
O Google Distributed Cloud cria um recurso de verificação de integridade com um nome
incorpora o nome e a versão do cluster:
Para clusters da versão 1.15.0, o nome do recurso de verificação de integridade é
CLUSTER_NAME-add-ons-CLUSTER_VER.
Para os clusters da versão 1.15.1 ou 1.15.2, o nome do recurso de verificação de integridade é
CLUSTER_NAME-kubernetes-CLUSTER_VER.
Para nomes de cluster longos, o nome do recurso de verificação de integridade excede a
restrição de tamanho de 63 caracteres do Kubernetes para nomes de
rótulos, o que impede a criação do recurso de verificação de integridade.
Sem uma verificação de integridade bem-sucedida, a operação do cluster falha.
Para saber se esse problema está afetando você, use kubectl describe
para verificar o recurso com falha:
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})
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:
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 NetworkGatewayGroup
recursos personalizados que contêm endereços IP em spec.floatingIPs
que já são usados nas NetworkGatewayGroup personalizadas
do Google Cloud. Esta regra é aplicada por um webhook nos clusters do Google Distributed Cloud
versão 1.15.0 e superior. Endereços IP flutuantes duplicados preexistentes
não causam erros. O webhook impede apenas a criação de novos
recursos personalizados NetworkGatewayGroups que contêm endereços IP
duplicados.
A mensagem de erro do webhook identifica o endereço IP conflitante e o
recurso personalizado existente que já o utiliza:
IP address exists in other gateway with name default
A documentação inicial para recursos de rede avançados, como o
gateway NAT de saída, não adverte sobre endereços IP duplicados.
Inicialmente, apenas o recurso NetworkGatewayGroup chamado
default foi reconhecido pelo reconciliador. Gateway de rede para GDC
agora reconhece todos os NetworkGatewayGroup personalizados
recursos no namespace do sistema. Os recursos personalizados NetworkGatewayGroup
atuais são mantidos.
Alternativa:
Ocorrem erros apenas na criação de um novo
recurso personalizado NetworkGatewayGroup.
Para resolver o erro:
Use o seguinte comando para listar NetworkGatewayGroups
recursos personalizados:
kubectl get NetworkGatewayGroups --kubeconfig ADMIN_KUBECONFIG \
-n kube-system -o yaml
Abra os recursos personalizados do NetworkGatewayGroup atuais e
remova todos os endereços IP flutuantes conflitantes (spec.floatingIPs):
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 no GDC em uma versão nova ou atualizada
1.13.7 Cluster que usa um registro particular, VMs que se conectam ao nó
ou usar uma GPU podem não iniciar corretamente. Esse problema ocorre porque alguns pods do sistema no namespace vm-system estão recebendo erros de extração de imagem. Por exemplo, se a VM usar a rede de nós, alguns pods poderão relatar erros de extração de imagem, como nos exemplos a seguir:
macvtap-4x9zp 0/1 Init:ImagePullBackOff 0 70m
Esse problema foi corrigido na versão 1.14.0 e mais recentes dos clusters do Google Distributed Cloud.
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:
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 o objetivo do pod gke-metrics-agent no cluster de tipo é facilitar a taxa de sucesso de criação do cluster e o rastreamento e monitoramento internos.
Portanto, você pode ignorar esse erro.
Alternativa
Apesar dos erros, o processo de criação do cluster não está bloqueado porque o objetivo do pod gke-metrics-agent no cluster de tipo é facilitar a taxa de sucesso de criação do cluster e o rastreamento e monitoramento internos.
Portanto, você pode ignorar esse erro.
Operação, rede
1.12, 1.13, 1.14, 1.15, 1.16, 1.28
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. Este problema é
corrigido para as versões de cluster 1.14.1 e mais recentes.
Para verificar se esse problema afeta você, observe as regras de
encaminhamento iptables nos nós em que o pod de back-end do Serviço afetado está
em execução:
sudo iptables -L FORWARD
Se você vir a regra KUBE-FORWARD antes da
regra CILIUM_FORWARD em iptables, talvez esse problema
esteja afetando você. O exemplo de saída a seguir mostra um nó em que
o problema existe:
Chain FORWARD (policy ACCEPT)
target prot opt source destination
KUBE-FORWARD all -- anywhere anywhere /* kubernetes forwarding rules */
KUBE-SERVICES all -- anywhere anywhere ctstate NEW /* kubernetes service portals */
KUBE-EXTERNAL-SERVICES all -- anywhere anywhere ctstate NEW /* kubernetes externally-visible service portals */
CILIUM_FORWARD all -- anywhere anywhere /* cilium-feeder: CILIUM_FORWARD */
Alternativa:
Reinicie o pod anetd no nó que está configurado incorretamente. Depois de
reiniciar o pod anetd, a regra de encaminhamento em iptables será
configurada corretamente.
O exemplo de saída a seguir mostra que a regra CILIUM_FORWARD
agora está configurada corretamente antes da regra
KUBE-FORWARD:
Chain FORWARD (policy ACCEPT)
target prot opt source destination
CILIUM_FORWARD all -- anywhere anywhere /* cilium-feeder: CILIUM_FORWARD */
KUBE-FORWARD all -- anywhere anywhere /* kubernetes forwarding rules */
KUBE-SERVICES all -- anywhere anywhere ctstate NEW /* kubernetes service portals */
KUBE-EXTERNAL-SERVICES all -- anywhere anywhere ctstate NEW /* kubernetes externally-visible service portals */
Upgrades e atualizações
1.9, 1.10
O recurso em fase de pré-lançamento 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. As versões anteriores do cluster,
como 1.14.0 e 1.14.1, não são afetadas. Esse problema foi corrigido na
versão 1.14.3 e em todas as versões subsequentes, incluindo 1.15.0 e posteriores.
Alternativa:
Como solução alternativa, é possível corrigir a implantação clientconfig-operator
para adicionar mais contexto de segurança e garantir que a implantação
esteja pronta.
Use o comando a seguir para corrigir clientconfig-operator no
cluster de destino:
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")
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:
Os clusters que executam o etcd versão 3.4.13 ou anterior podem apresentar privação do relógio e relógios de recursos não operacionais, que podem causar os seguintes problemas:
A programação do pod é interrompida
Não é possível registrar nós
O kubelet não observa mudanças no pod
Esses problemas podem tornar o cluster não funcional.
Esse problema foi corrigido nas versões 1.12.9 e 1.13.6 do Google Distributed Cloud.
1.14.3 e versões subsequentes. Essas versões mais recentes usam o etcd versão 3.4.21. Todas as versões anteriores do Google Distributed Cloud são afetadas pela
problema.
Alternativa
Se não for possível fazer upgrade imediatamente, reduza o risco de falha do cluster diminuindo seu número de nós. Remova os nós até que a métrica etcd_network_client_grpc_sent_bytes_total seja inferior a 300 MBps.
Para visualizar essa métrica no Metrics Explorer:
Acesse o Metrics Explorer no Console do Google Cloud:
Expanda Selecionar uma métrica, insira Kubernetes Container na barra de filtros e use os submenus para selecionar a métrica:
No menu Recursos ativos, selecione Contêiner do Kubernetes.
No menu Categorias de métricas ativas, selecione Anthos.
No menu Métricas ativas, selecione etcd_network_client_grpc_sent_bytes_total.
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",
fazer upgrade do cluster para a versão 1.11.7 ou posterior, a versão 1.12.4 ou
mais tarde.
Upgrades e atualizações
1.10, 1.11, 1.12, 1.13, 1.14.0, 1.14.1
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
estão em um cluster com mais de 180 dias ou mais e nunca reiniciou o anthos-cluster-operator;
Se você tiver emitido um cert-manager manualmente
rotações de certificados em um cluster com mais de 90 dias ou mais e nunca
reiniciou o anthos-cluster-operator.
Alternativa
Reinicie o pod encerrando o anthos-cluster-operator.
Upgrades e atualizações
1.14.0
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
de upgrade, mas elas podem ser encontradas em um estado inesperado. Recomendamos
que você remova os pods desatualizados.
Esse problema foi corrigido na versão 1.14.1.
Alternativa:
Para remover os pods do implantador do controlador de ciclo de vida desatualizados:
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.
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:
O estado BGPSession muda constantemente devido ao grande número de rotas recebidas.
A rede avançada do Google Distributed Cloud falha ao gerenciar as sessões do BGP
corretamente quando pares externos anunciam um grande número de rotas (cerca de 100
ou mais). Com um grande número de rotas de entrada, o controlador do BGP local do nó
leva muito tempo para reconciliar as sessões do BGP e falha ao atualizar o
status. A falta de atualizações de status ou de uma verificação de integridade faz com que a sessão
seja excluída por estar desatualizada.
Comportamento indesejável em sessões do BGP que você pode perceber e indicar
um problema:
Exclusão e recriação contínuas do bgpsession.
bgpsession.status.state nunca se torna Established.
Rotas que não anunciam ou são repetidas e anunciadas.
Os problemas de balanceamento de carga do BGP podem ser notados com problemas de
conectividade com os serviços de LoadBalancer.
O problema FlatIP do BGP pode ser perceptível com problemas de conectividade
nos pods.
Para determinar se os problemas do BGP são causados pelos pares remotos que anunciam muitas rotas, use os seguintes comandos para analisar os status e a saída associados:
Use kubectl get bgpsessions no cluster afetado.
A saída mostra bgpsessions com o estado "Não estabelecido"
e o tempo do último relatório é contabilizado continuamente de cerca de 10 a 12 segundos
antes de parecer zerado.
A saída de kubectl get bgpsessions mostra que as
sessões afetadas estão sendo recriadas repetidamente:
kubectl get bgpsessions \
-o jsonpath="{.items[*]['metadata.name', 'metadata.creationTimestamp']}"
As mensagens de registro indicam que as sessões do BGP desatualizadas estão sendo excluídas:
kubectl logs ang-controller-manager-POD_NUMBER
Substitua POD_NUMBER pelo pod
líder no cluster.
Alternativa:
Reduza ou elimine o número de rotas anunciadas do peering remoto para o cluster com uma política de exportação.
No cluster do Google Distributed Cloud versão 1.14.2 e posterior, também é possível desativar o
que processa as rotas recebidas usando um
AddOnConfiguration: Adicione o
argumento --disable-received-routes ao contêiner bgpd
do daemonset ang-daemon.
Rede
1.14, 1.15, 1.16, 1.28
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:
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:
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.
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:
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 clusters do Google Distributed Cloud com muitos nós,
poderá receber uma mensagem de erro kubeadmin join semelhante à
exemplo a seguir:
TASK [kubeadm : kubeadm join --config /dev/stdin --ignore-preflight-errors=all] ***
fatal: [10.200.0.138]: FAILED! => {"changed": true, "cmd": "kubeadm join
--config /dev/stdin --ignore-preflight-errors=all", "delta": "0:05:00.140669", "end": "2022-11-01 21:53:15.195648", "msg": "non-zero return code", "rc": 1,
"start": "2022-11-01 21:48:15.054979", "stderr": "W1101 21:48:15.082440 99570 initconfiguration.go:119]
Usage of CRI endpoints without URL scheme is deprecated and can cause kubelet errors in the future.
Automatically prepending scheme \"unix\" to the \"criSocket\" with value \"/run/containerd/containerd.sock\". Please update your configuration!\nerror
execution phase preflight: couldn't validate the identity of the API Server: could not find a JWS signature in the cluster-info ConfigMap for token ID \"yjcik0\"\n
To see the stack trace of this error execute with --v=5 or higher", "stderr_lines":
["W1101 21:48:15.082440 99570 initconfiguration.go:119] Usage of CRI endpoints without URL scheme is deprecated and can cause kubelet errors in the future.
Automatically prepending scheme \"unix\" to the \"criSocket\" with value \"/run/containerd/containerd.sock\".
Please update your configuration!", "error execution phase preflight: couldn't validate the identity of the API Server:
could not find a JWS signature in the cluster-info ConfigMap for token ID \"yjcik0\"",
"To see the stack trace of this error execute with --v=5 or higher"], "stdout": "[preflight]
Running pre-flight checks", "stdout_lines": ["[preflight] Running pre-flight checks"]}
Alternativa:
Esse problema foi resolvido no Google Distributed Cloud versão 1.13.4 e mais recentes.
Se você precisar usar uma versão afetada, primeiro crie um cluster com
menos de 20 nós e, em seguida, redimensione o cluster para adicionar outros nós
após a conclusão da instalação.
Geração de registros e monitoramento
1.10, 1.11, 1.12 e 1.13.0
Limite de CPU baixo para metrics-server em clusters de borda
Nos clusters do Google Distributed Cloud Edge, os limites baixos de CPU para
metrics-server pode causar reinicializações frequentes do
metrics-server: O escalonamento automático horizontal de pods (HPA, na sigla em inglês) não funciona
porque metrics-server não está íntegro.
Se o limite de CPU de metrics-server for menor que 40m,
os clusters poderão ser afetados. Para verificar os limites de CPU de metrics-server, consulte um dos seguintes arquivos:
Clusters do Google Distributed Cloud versão 1.x-1.12:
Esse problema é resolvido nos clusters do Google Distributed Cloud 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:
Reduzir a escala vertical metrics-server-operator:
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
[...]
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 via serviço NodePort falha quando o pod de back-end está no mesmo nó que o NodePort segmentado. Isso afeta os serviços LoadBalancer quando usado com pods hospedados pela rede de rede. Com vários back-ends, pode ocorrer uma falha esporádica de conexão.
Esse problema é causado por um bug no programa eBPF.
Alternativa:
Ao usar um serviço do Nodeport, não segmente o nó em que algum
dos pods de back-end é executado. Ao usar o serviço LoadBalancer, verifique se os
pods hospedados pela rede não são executados nos nós do LoadBalancer.
Upgrades e atualizações
1.12.3, 1.13.0
Os clusters de administrador 1.13.0 não podem gerenciar os 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 estiver interrompido, verifique
o seguinte erro no arquivo upgrade-cluster.log dentro da pasta bmctl-workspace para confirmar se
os pools de nós de trabalho são a causa:
Operation failed, retrying with backoff. Cause: error creating "baremetal.cluster.gke.io/v1, Kind=NodePool" cluster-test-cluster-2023-06-06-140654/np1: admission webhook "vnodepool.kb.io" denied the request: Adding worker nodepool to Admin cluster is disallowed.
Alternativa:
Antes de fazer upgrade, mova todos os pools de nós de trabalho para clusters de usuário. Para
instruções sobre como adicionar e remover pools de nós, consulte
Gerenciar pools de nós em um cluster.
Upgrades e atualizações
1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28
Erros ao atualizar recursos usando kubectl apply
Se você atualizar recursos, como os recursos personalizados ClientConfig ou
Stackdriver usando kubectl apply,
o controlador poderá retornar um erro ou reverter a entrada e as mudanças
planejadas.
Por exemplo, tente editar o recurso personalizado Stackdriver da seguinte maneira: primeiro acesse o recurso e, em seguida, aplique uma versão atualizada:
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:
Identificar os pedaços de backlog corrompidos. Confira o exemplo a seguir
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/ está em
falha. Todos os arquivos *.flb com falha na verificação do formato precisam ser
removidos.
Encerre os pods em execução para stackdriver-log-forwarder:
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 a recorrência do
faça o upgrade do cluster para a versão 1.14.1 ou posterior.
Operação
1.13, 1.14.0, 1.14.1
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
Clusters de perfil do Google Distributed Cloud 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 clusters de administrador versão 1.11.0, 1.11.1 ou 1.11.2
gerenciar clusters de usuário 1.10.x. Quando o detector de problemas do nó falha, o registro é atualizado
com a seguinte mensagem de erro:
Error - NPD not supported for anthos baremetal version 1.10.4:
anthos version 1.10.4 not supported.
Alternativa
Faça upgrade do cluster de administrador para 1.11.3 para resolver o problema.
Operação
1.14
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 um tamanho de máscara CIDR de pod de 22, Cada nó
receberá uma máscara CIDR de pod de 24, e o cluster será
compatível com até quatro nós. Seu cluster também pode ter instabilidade de rede
em um período de alto desligamento de pods quando maxPodsPerNode estiver definido como 129
ou mais e não houver sobrecarga suficiente no CIDR do pod para cada nó.
Se o cluster for afetado, o pod anetd informará o seguinte erro quando você adicionar um novo nó ao cluster e não houver podCIDR disponível:
error="required IPv4 PodCIDR not available"
Alternativa
Siga estas etapas para resolver o problema:
Faça upgrade para a versão 1.14.1 ou posterior.
Remova os nós de trabalho e adicione-os novamente.
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
Uma reversão de upgrade pode falhar para clusters da versão 1.14.0 ou 1.14.1.
Se você fizer upgrade de um cluster de 1.14.0 para 1.14.1 e tentar reverter para 1.14.0
usando o comando bmctl restore cluster, um erro
como o exemplo a seguir poderá ser retornado:
I0119 22:11:49.705596 107905 client.go:48] Operation failed, retrying with backoff.
Cause: error updating "baremetal.cluster.gke.io/v1, Kind=HealthCheck" cluster-user-ci-f3a04dc1b0d2ac8/user-ci-f3a04dc1b0d2ac8-network: admission webhook "vhealthcheck.kb.io"
denied the request: HealthCheck.baremetal.cluster.gke.io "user-ci-f3a04dc1b0d2ac8-network" is invalid:
Spec: Invalid value: v1.HealthCheckSpec{ClusterName:(*string)(0xc0003096e0), AnthosBareMetalVersion:(*string)(0xc000309690),
Type:(*v1.CheckType)(0xc000309710), NodePoolNames:[]string(nil), NodeAddresses:[]string(nil), ConfigYAML:(*string)(nil),
CheckImageVersion:(*string)(nil), IntervalInSeconds:(*int64)(0xc0015c29f8)}: Field is immutable
Alternativa:
Exclua todos os recursos healthchecks.baremetal.cluster.gke.io
no namespace do cluster e execute novamente o comando bmctl restore
cluster:
Listar todos os recursos
healthchecks.baremetal.cluster.gke.io
kubectl get healthchecks.baremetal.cluster.gke.io \
--namespace=CLUSTER_NAMESPACE \
--kubeconfig=ADMIN_KUBECONFIG
Substitua:
CLUSTER_NAMESPACE: o namespace do cluster.
ADMIN_KUBECONFIG: o caminho até o arquivo kubeconfig
do cluster de administrador.
Excluir todos os healthchecks.baremetal.cluster.gke.io
recursos listados na etapa anterior:
Substituir HEALTHCHECK_RESOURCE_NAME por
o nome dos recursos de verificação de integridade.
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
Encontre os nós do plano de controle usando o seguinte comando:
kubectl get node -l 'node-role.kubernetes.io/control-plane' \
-o name --kubeconfig KUBECONFIG_PATH
Para verificar a lista de taints em um nó, use o seguinte comando:
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.
Encontre pods sem a tolerância node-role.kubernetes.io/master:NoSchedule:
kubectl get pods -A --field-selector spec.nodeName="NODE_NAME" \
-o=custom-columns='Name:metadata.name,Toleration:spec.tolerations[*].key' \
--kubeconfig KUBECONFIG_PATH | \
grep -v "node-role.kubernetes.io/master" | uniq
Exclua os pods que não têm a tolerância node-role.kubernetes.io/master:NoSchedule:
kubectl delete pod POD_NAME –-kubeconfig KUBECONFIG_PATH
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ê implantou manualmente componentes de coleta gerenciada no namespace gmp-system dos
clusters da versão 1.11, os recursos associados não serão
preservados quando você fizer upgrade para a versão 1.12.
A partir da versão 1.12.0 de clusters, o serviço gerenciado
para componentes do Prometheus no namespace gmp-system e
as definições personalizadas de recursos são gerenciadas
stackdriver-operator com enableGMPForApplications
. O campo enableGMPForApplications
é true por padrão, portanto, se você implantar manualmente os componentes
do Serviço gerenciado para Prometheus no namespace antes de atualizar
para a versão 1.12, os recursos serão excluídos por stackdriver-operator.
Alternativa
Para preservar os recursos de coleta gerenciados manualmente, faça o seguinte:
faça o backup de todos os recursos personalizados atuais do PodMonitoring.
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:
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 na versão 1.11.0 do Google Distributed Cloud
Esse problema foi corrigido na versão 1.11.1 do Google Distributed Cloud. Em alguns casos, o comando bmctl create cluster sai antecipadamente e grava erros como este nos registros:
Error creating cluster: error waiting for applied resources: provider cluster-api watching namespace USER_CLUSTER_NAME not found in the target cluster
Alternativa
A operação com falha produz artefatos, mas o cluster não está operacional. Se esse problema afetar você, use as etapas a seguir para limpar os artefatos e criar um cluster:
Ver etapas de solução alternativa
Para excluir os artefatos do cluster e redefinir a máquina do nó, execute o seguinte comando:
bmctl reset -c USER_CLUSTER_NAME
Para iniciar a operação de criação do cluster, execute o seguinte comando:
A sinalização --keep-bootstrap-cluster é importante se essa
falha do comando.
Se o comando de criação do cluster for bem-sucedido, pule para as etapas restantes. Caso contrário, continue.
Execute o seguinte comando para ver a versão do cluster de inicialização:
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 valor
para o Google Distributed Cloud versão 1.13 e mais recentes).
O cluster é configurado para fornecer várias interfaces de rede, multi-NIC, para pods (clusterNetwork.multipleNetworkInterfaces definido como true no arquivo de
configuração do cluster).
O cluster é configurado para usar um proxy, em que spec.proxy.url é especificado no arquivo de configuração do cluster. Mesmo que a criação do cluster falhe, essa configuração é propagada quando você tenta criar um cluster. É possível ver essa configuração de proxy
como uma variável de ambiente HTTPS_PROXY ou na configuração containerd (/etc/systemd/system/containerd.service.d/09-proxy.conf).
Alternativa
Anexe CIDRs de serviço (clusterNetwork.services.cidrBlocks)
à variável de ambiente NO_PROXY em todas as máquinas de nó.
Instalação
1.10, 1.11, 1.12
Falha nos sistemas com a configuração umask restritiva
O Google Distributed Cloud versão 1.10.0 introduz um controle sem raiz
plano de controle que executa todos os componentes do plano de controle como um ambiente
usuário. A execução dos componentes como um usuário não raiz pode causar falhas de instalação ou de upgrade em
sistemas com uma configuração umask mais restritiva de 0077.
Alternativa
Redefina os nós do plano de controle e altere a configuração umask
para 0022 em todas as máquinas do plano de controle. Após a atualização das máquinas, tente instalar
novamente.
Também é possível alterar as permissões de diretório e de arquivo de
/etc/kubernetes nas máquinas do plano de controle para que a instalação
ou upgrade continue.
Torne /etc/kubernetes e todos os subdiretórios globalmente legíveis:
chmod o+rx.
Transfira todos os arquivos do usuário root no diretório (recursivamente)
/etc/kubernetes legível (chmod o+r). Exclua os arquivos de chave privada
(.key) dessas alterações, porque eles já foram criados com as permissões e a
propriedade corretas.
O grupo de controle v2 (cgroup v2) não é compatível com os clusters do Google Distributed Cloud versões 1.13 e
antes do Google Distributed Cloud. No entanto, a versão 1.14 é compatível com o cgroup
v2 como um recurso de pré-lançamento
. A presença
de /sys/fs/cgroup/cgroup.controllers indica que seu
sistema usa o cgroup v2.
Alternativa
Se o sistema usa o cgroup v2, faça upgrade do cluster para a versão 1.14.
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.
Ao instalar os clusters do Google Distributed Cloud em VMs do vSphere, defina o
tx-udp_tnl-segmentation e
desativar as sinalizações tx-udp_tnl-csum-segmentation. Essas sinalizações são
relacionadas à descarga da segmentação de hardware feita pelo driver do vSphere
VMXNET3 e não funcionam com o túnel GENEVE do
clusters do Google Distributed Cloud.
Alternativa
Execute o comando a seguir em cada nó para verificar os valores atuais dessas sinalizações.
ethtool -k NET_INTFC | grep segm
Substitua NET_INTFC pela interface de rede associada
ao endereço IP do nó.
A resposta terá entradas como estas:
...
tx-udp_tnl-segmentation: on
tx-udp_tnl-csum-segmentation: on
...
No RHEL 8.4, ethtool às vezes mostra que essas flags estão desativadas,
mas na realidade não estão. Para ter certeza de que estão desativadas, ative-as e depois desative-as com os comandos a seguir.
ethtool -K ens192 tx-udp_tnl-segmentation on ethtool -K ens192 \
tx-udp_tnl-csum-segmentation on
ethtool -K ens192 tx-udp_tnl-segmentation off ethtool -K ens192 \
tx-udp_tnl-csum-segmentation off
Essa alteração de sinalização não permanece nas reinicializações. Configure os scripts de inicialização para definir explicitamente esses sinalizadores quando o sistema for inicializado.
Upgrades e atualizações
1.10
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):
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:
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
O upgrade de clusters para a versão 1.12.0 ou superior falha quando
Nos clusters do Google Distributed Cloud 1.12.0, todos os recursos
O ambiente de execução de VMs na GDC é migrado para o vm-system
namespace para oferecer melhor suporte ao ambiente de execução da VM na versão GA do GDC. Se
você tem o ambiente de execução de VM no GDC ativado em uma versão 1.11.x ou inferior
cluster, o upgrade para a versão 1.12.0 ou superior vai falhar, a menos que
desativar o ambiente de execução da VM na GDC. Quando você é afetado por esse problema, a operação de upgrade informa o seguinte erro:
Failed to upgrade cluster: cluster isn't upgradable with vmruntime enabled from
version 1.11.x to version 1.12.0: please disable VMruntime before upgrade to
1.12.0 and higher version
Alternativa
Para desativar o ambiente de execução da VM no GDC:
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:
Use kubectl edit para remover a anotação kubectl.kubernetes.io/last-applied-configuration do recurso contido na mensagem de registro.
Salve e aplique as alterações no recurso.
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. Esses recursos usam o gateway de rede para GDC. Os upgrades de cluster ficam travados na mensagem de linha de comando Waiting for upgrade to complete... e os erros anthos-cluster-operator registram o seguinte:
apply run failed ... MatchExpressions:[]v1.LabelSelectorRequirement(nil)}: field
is immutable...
Alternativa
Para desbloquear o upgrade, execute os seguintes comandos no cluster que você está fazendo upgrade:
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 inferior e use manualmente
kubectl cordon em um nó, o Google Distributed Cloud pode remover a restrição
antes de estar pronto, em um esforço para reconciliar o estado esperado.
Alternativa
Para a versão 1.12.0 e clusters anteriores, use
modo de manutenção para
delimitar e drenar nós com segurança.
Na versão 1.12.1 (anthosBareMetalVersion: 1.12.1) ou
superior, o Google Distributed Cloud não vai desvincular os nós inesperadamente quando
use 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. Este problema se aplica às versões 1.11.1 do cluster do Google Distributed Cloud
e antes.
Para determinar se esse problema afeta um cluster de usuário, execute o seguinte comando:
ADMIN_KUBECONFIG: o caminho até o arquivo kubeconfig do cluster de administrador.
USER_CLUSTER_NAMESPACE: o namespace do cluster. Por padrão, os namespaces do cluster para
Os clusters do Google Distributed Cloud são o nome do cluster que inclui
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.
As etapas a seguir restauram a função em um cluster de usuário afetado (USER_CLUSTER_NAME):
Localizar o arquivo kubeconfig do cluster de usuário. Nuvem distribuída do Google
gera o arquivo kubeconfig na estação de trabalho do administrador quando você cria um
cluster especificado. Por padrão, o arquivo está no diretório bmctl-workspace/USER_CLUSTER_NAME.
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 pela
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.
Execute o seguinte comando para excluir o arquivo kubeconfig corrompido no cluster de administrador:
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
[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:
Ver etapas de solução alternativa
Faça upgrade do cluster para a versão 1.11.0 ou posterior.
Se não for possível fazer upgrade dos clusters imediatamente, siga estas etapas para atualizar o regex de análise de CRI:
Para evitar que as mudanças a seguir sejam revertidas, reduza a escala vertical de stackdriver-operator:
[PARSER]
# https://rubular.com/r/Vn30bO78GlkvyB
Name cri
Format regex
# The timestamp is described in
https://www.rfc-editor.org/rfc/rfc3339#section-5.6
Regex ^(?<time>[0-9]{4}-[0-9]{2}-[0-9]{2}[Tt ][0-9]
{2}:[0-9]{2}:[0-9]{2}(?:\.[0-9]+)?(?:[Zz]|[+-][0-9]
{2}:[0-9]{2})) (?<stream>stdout|stderr)
(?<logtag>[^ ]*) (?<log>.*)$
Time_Key time
Time_Format %Y-%m-%dT%H:%M:%S.%L%z
Time_Keep off
Para as versões 1.10 a 1.15 do cluster do Google Distributed Cloud, alguns clientes têm
encontramos uma cobrança alta inesperada para Metrics volume no
Faturamento. Esse problema afeta você apenas quando ambas as circunstâncias a seguir se aplicarem:
O monitoramento de aplicativos está ativado (enableStackdriverForApplications=true)
Os pods do aplicativo têm a anotação prometheus.io/scrap=true.
Para confirmar se você foi afetado por esse problema,
liste as métricas definidas pelo usuário. Se você vir faturamento para métricas indesejadas, esse problema se aplica a você.
Alternativa
Se você for afetado por esse problema, recomendamos que faça upgrade dos
clusters para a versão 1.12 e mude para a nova solução de monitoramento de aplicativos managed-service-for-prometheus que resolve esse problema:
Sinalizações separadas para controlar a coleta de registros do aplicativo em comparação com as métricas do aplicativo
Pacote de serviço gerenciado do Google Cloud Managed Service para Prometheus
Se não for possível fazer upgrade para a versão 1.12, siga estas etapas:
Encontre os pods e os Serviços de origem que têm o faturamento indesejado:
kubectl --kubeconfig KUBECONFIG \
get pods -A -o yaml | grep 'prometheus.io/scrape: "true"'
kubectl --kubeconfig KUBECONFIG get \
services -A -o yaml | grep 'prometheus.io/scrape: "true"'
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, começando com
Google Distributed Cloud versão 1.11, os dados não são mais coletados para
métricas descontinuadas. Se você usar essas métricas em qualquer uma das políticas de alertas,
não haverá dados para acionar a condição de alerta.
A tabela a seguir lista as métricas individuais que estão obsoletas e as métricas que as substituem.
Nas versões do cluster do Google Distributed Cloud anteriores à 1.11, a definição da política
arquivo do 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:
No console do Google Cloud, selecione Monitoring ou clique no botão a seguir: Acessar o Monitoring
No painel de navegação, selecione Painéis e exclua o painel Status do nó do cluster do Anthos.
Clique na guia Biblioteca de amostra e reinstale o painel Status do nó do
cluster do Anthos.
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.
Esses registros de erros podem ser ignorados com segurança porque as métricas a que se referem são
não são compatíveis nem são essenciais para fins de monitoramento.
Geração de registros e monitoramento
1.10, 1.11
Interrupções intermitentes da exportação de métricas
Os clusters do Google Distributed Cloud podem sofrer interrupções
exportação contínua de métricas ou métricas ausentes em alguns nós. Se esse problema afetar os clusters, você poderá ver lacunas nos dados das seguintes métricas (no mínimo):
O comando encontrará cpu: 50m se as edições tiverem sido concluídas
efeito.
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
Os clusters do Google Distributed Cloud versão 1.12.x não impedem que você
editar redes
recursos personalizados
no cluster de usuário. O Google Distributed Cloud reconcilia recursos personalizados
nos clusters de usuário com os recursos personalizados no cluster de administrador
durante upgrades de cluster. Essa reconciliação substitui todas as edições feitas diretamente nos
recursos personalizados de rede no cluster de usuário. O
os recursos personalizados de rede devem ser modificados apenas no cluster de administrador,
mas os clusters da versão 1.12.x não impõem esse requisito.
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. Versões de clusters do Google Distributed Cloud
As versões 1.13.0 e superiores impedem que você modifique a personalização da rede
recursos nos clusters de usuário diretamente.
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 Google Distributed Cloud configura a filtragem de caminho reverso em nós para desativar
a validação de origem (net.ipv4.conf.all.rp_filter=0). Se a configuração
rp_filter for alterada para 1 ou 2, os pods vão falhar devido aos tempos limite de comunicação
fora do nó.
A filtragem de caminho reverso é definida com arquivos rp_filter na pasta de configuração IPv4 (net/ipv4/conf/all). Este valor também pode ser modificado por sysctl, que armazena as configurações de filtragem de caminho reverso em um arquivo de configuração de segurança de rede, como /etc/sysctl.d/60-gce-network-security.conf.
Alternativa
A conectividade do pod pode ser restaurada realizando uma das seguintes ações
soluções alternativas:
Defina o valor de net.ipv4.conf.all.rp_filter novamente como
0 manualmente e, em seguida, execute sudo sysctl -p para aplicar.
a mudança.
Ou
Reinicie o pod anetd para definir
net.ipv4.conf.all.rp_filter de volta para 0. Para reiniciar o pod anetd, use os seguintes comandos para localizar
e excluir o pod anetd, e um novo pod anetd será iniciado no lugar:
Depois de executar uma das soluções alternativas, verifique se o
O valor de net.ipv4.conf.all.rp_filter é definido como 0 por
executando sysctl net.ipv4.conf.all.rp_filter em cada nó.
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 dos clusters do Google Distributed Cloud.
Alternativa
Ver etapas de solução alternativa
Como solução alternativa, execute os seguintes comandos para que seu CentOS use um feed
de arquivo:
sed -i 's/mirrorlist/#mirrorlist/g' /etc/yum.repos.d/CentOS-Linux-*
sed -i 's|#baseurl=http://mirror.centos.org|baseurl=http://vault.centos.org|g' \
/etc/yum.repos.d/CentOS-Linux-*
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:
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 os upgrades do cluster
Quando você faz upgrade de clusters do Google Distributed Cloud, 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:
Verifique se o serviço node-problem-detector systemd está em execução no nó.
Use o comando SSh e conecte-se ao nó.
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 exibir inactive, o node-problem-detector não está sendo executado no nó.
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 na versão 1.10.2 e posterior.
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:
Executar em nós de trabalho (não em nós do plano de controle).
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 devido à disputa de anthos-cluster-operator gets
foi atualizado e não afetará os recursos normais do cluster.
O bug não aparece depois da versão 1.13 ou mais recente.
Alternativa:
Exclua o job do dynamic-version-installer por
kubectl delete job anthos-version-$version$ -n kube-system
Upgrades e atualizações
1.13
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.
Há um problema em stackdriver-operator que faz com que ele
consomem mais tempo de CPU do que o normal. O uso normal da CPU for menor que 50
milliCPU (50m) para stackdriver-operator em inatividade
estado. A causa é uma incompatibilidade de recursos de certificado que
stackdriver-operator se aplica com as expectativas
cert-manager. Essa incompatibilidade causa uma disputa entre
cert-manager e stackdriver-operator pol.
atualizar esses recursos.
Esse problema pode resultar em desempenho reduzido em clusters com limitações
Disponibilidade da CPU
Alternativa:
Até que você possa fazer upgrade para uma versão que corrigiu o bug, use
a seguinte solução alternativa:
Para reduzir temporariamente stackdriver-operator para 0
réplicas, aplique um recurso personalizado AddonConfiguration:
A extração de métricas com base em anotações não funciona
Na versão secundária do Google Distributed Cloud 1.16, a
Campo enableStackdriverForApplications no
A especificação de recurso personalizado stackdriver foi descontinuada. Este campo é
substituído por dois campos, enableCloudLoggingForApplications e
enableGMPForApplications, no recurso personalizado do Stackdriver.
Recomendamos que você use o Google Cloud Managed Service para Prometheus para monitoramento
das cargas de trabalho. Use o campo enableGMPForApplications para
ativar esse recurso.
Se você confiar na coleta de métricas acionada
prometheus.io/scrape anotação na sua
cargas de trabalho, use o método annotationBasedApplicationMetrics
uma flag de entrada de recurso para manter o comportamento antigo. No entanto, há um problema que
impede que o annotationBasedApplicationMetrics funcione
corretamente, impedindo a coleta de métricas dos aplicativos em
o Cloud Monitoring.
Alternativa:
Para resolver esse problema, faça upgrade do cluster para a versão 1.16.2 ou mais recente.
A coleta de métricas de carga de trabalho com base em anotações ativada pelo
Coleta de annotationBasedApplicationMetrics atributo
para objetos que têm o campo prometheus.io/scrape
. Muitos sistemas de software com origem de código aberto usam esse
. Se você continuar usando esse método de métricas
, esteja ciente dessa dependência para não se surpreender com
no Cloud Monitoring.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2024-07-04 UTC."],[],[]]
Painéis e exclua o painel Status do nó do cluster do Anthos.