Selecione os clusters do Anthos em versão bare metal:
Selecione a categoria do seu problema:
Ou pesquise seu problema:
Categoria
Versões identificadas
Problema e solução alternativa
Rede
1.11.6, 1.12.3
Operador SR-IOVvfio-pci modo "com falha"
O syncStatus do objeto SriovNetworkNodeState pode informar o valor "Falha" em um nó configurado. Para ver 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 "Falha",
atualize para os clusters do Anthos na versão bare metal 1.11.7 ou posterior ou 1.12.4 ou
posterior.
Upgrades e atualizações
1.10, 1.11, 1.12, 1.13, 1.14.0, 1.14.1
Alguns nós de trabalho não ficam no estado Pronto após o upgrade
Quando o upgrade for concluído, alguns nós de trabalho poderão ter a condição "Pronto" definida como false. No recurso de nó, você vai ver um erro ao lado da condição "Pronto", como no exemplo a seguir:
container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:Network plugin returns error: cni plugin not initialized
Quando você faz login na máquina parada, a configuração CNI na máquina está vazia:
sudo ls /etc/cni/net.d/
Alternativa
Reinicie o pod anetd do nó excluindo-o.
Upgrades e atualizações, segurança
1.10
Várias rotações de certificado do gerenciador de certificado resultam em inconsistência
Após várias rotações manuais ou de certificado automático, o pod do webhook, como
anthos-cluster-operator, não é atualizado com os novos certificados
emitidos por cert-manager. Qualquer atualização do recurso personalizado de cluster falhará e resultará em um erro semelhante a este:
Internal error occurred: failed
calling webhook "vcluster.kb.io": failed to call webhook: Post
"https://webhook-service.kube-system.svc:443/validate-baremetal-cluster-gke-io-v1-cluster?timeout=10s": x509: certificate signed by unknown authority (possibly because of "x509: invalid signature: parent certificate cannot sign this kind of certificate" while trying to verify candidate authority certificate
"webhook-service.kube-system.svc")
Esse problema pode ocorrer nas seguintes circunstâncias:
Se você fez duas rotações de certificado manuais emitidas pelo gerenciador de certificados em um cluster com mais de 180 dias e nunca reiniciou o operador anthos-cluster.
Se você fez uma rotação manual de certificados cert-manager emitida em um cluster com mais de 90 dias ou mais e nunca reiniciou o operador anthos-cluster.
Alternativa
Reinicie o pod encerrando o operador anthos-cluster.
Upgrades e atualizações
1.14.0
Pods do implantador do controlador de ciclo de vida desatualizados criados durante o upgrade do cluster de usuário
Nos clusters de administrador da versão 1.14.0, um ou mais pods do implantador do controlador de ciclo de vida desatualizados podem ser criados durante os upgrades de clusters de usuários.
Esse problema se aplica a clusters de usuários criados inicialmente em
versões anteriores à 1.12. Os pods criados acidentalmente não impedem as
operações de upgrade, mas podem ser encontrados em um estado anormal. 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.
Os clusters do Anthos em rede avançada bare metal falham ao gerenciar sessões do BGP
corretamente quando pares externos anunciam um número alto 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.
Nos clusters do Anthos em bare metal versão 1.14.2 e posterior, também é possível desativar o
recurso que processa rotas recebidas usando um
AddOnConfiguration. Adicione o
argumento --disable-received-routes ao contêiner bgpd
do daemonset ang-daemon.
Rede
1.14
Tempos limite do aplicativo causados por falhas de inserção da tabela de conexão
Os clusters da versão 1.14 em execução em um SO Ubuntu que usa o kernel 5.15 ou
mais recente são suscetíveis a falhas na inserção de tabelas do rastreamento de conexão (net) do netfilter. 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
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á.
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 Anthos em bare metal com um grande número de nós, talvez você receba uma mensagem de erro kubeadmin join semelhante ao
exemplo a seguir:
TASK [kubeadm : kubeadm join --config /dev/stdin --ignore-preflight-errors=all] ***
fatal: [10.200.0.138]: FAILED! => {"changed": true, "cmd": "kubeadm join
--config /dev/stdin --ignore-preflight-errors=all", "delta": "0:05:00.140669",
"end": "2022-11-01 21:53:15.195648", "msg": "non-zero return code", "rc": 1,
"start": "2022-11-01 21:48:15.054979", "stderr": "W1101 21:48:15.082440 99570 initconfiguration.go:119]
Usage of CRI endpoints without URL scheme is deprecated and can cause kubelet errors in the future.
Automatically prepending scheme \"unix\" to the \"criSocket\" with
value \"/run/containerd/containerd.sock\". Please update your configuration!\nerror
execution phase preflight: couldn't validate the identity of the API Server:
could not find a JWS signature in the cluster-info ConfigMap for token ID \"yjcik0\"\n
To see the stack trace of this error execute with --v=5 or higher", "stderr_lines":
["W1101 21:48:15.082440 99570 initconfiguration.go:119]
Usage of CRI endpoints without URL scheme is deprecated and can cause kubelet errors in the future.
Automatically prepending scheme \"unix\" to the \"criSocket\" with value \"/run/containerd/containerd.sock\".
Please update your configuration!", "error execution phase preflight: couldn't validate the identity of the API Server:
could not find a JWS signature in the cluster-info ConfigMap for token ID \"yjcik0\"",
"To see the stack trace of this error execute with --v=5 or higher"], "stdout": "[preflight]
Running pre-flight checks", "stdout_lines": ["[preflight] Running pre-flight checks"]}
Alternativa:
Esse problema foi resolvido nos clusters do Anthos na versão bare metal 1.13.4 e posterior.
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
Em clusters do Anthos em clusters bare metal Edge, os limites baixos de CPU para
metrics-server podem causar reinicializações frequentes de
metrics-server. O escalonamento automático horizontal de pods (HPA, na sigla em inglês) não funciona
porque metrics-server não está íntegro.
Se o limite de CPU de metrics-server for menor que 40m,
os clusters poderão ser afetados. Para verificar os limites de CPU de metrics-server, consulte um dos seguintes arquivos:
Esse problema foi resolvido nos clusters do Anthos na versão bare metal 1.13.1 ou posterior. 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:
Reduza o escalonamento vertical de 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><--- CPU,
[...] Increase 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
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.10, 1.11, 1.12, 1.13, 1.14
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
desejadas.
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. Veja os exemplos de
mensagens de erro abaixo:
[2022/09/16 02:05:01] [error] [storage] format check failed: tail.1/1-1659339894.252926599.flb
[2022/09/16 02:05:01] [error] [engine] could not segregate backlog chunks
Nesse exemplo, o arquivo tail.1/1-1659339894.252926599.flb,
armazenado em var/log/fluent-bit-buffers/tail.1/, está com
falha. Todos os arquivos *.flb com falha na verificação do formato precisam ser
removidos.
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 uma recorrência do
problema, faça upgrade para os clusters do Anthos em bare metal 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
os clusters do Anthos em clusters de perfil bare metal Edge. Os clusters de perfil padrão não são
afetados.
Alternativa:
Faça upgrade do cluster para a versão 1.14.2 ou posterior.
Instalação
1.12, 1.13
A criação do cluster pode falhar devido às disputas
Quando você cria clusters usando kubectl, devido às condições de corrida, a verificação de simulação nunca será concluída. Como resultado, a criação do cluster pode falhar em alguns casos.
O reconciliador de verificação de simulação cria um SecretForwarder para copiar o secret ssh-key padrão para o namespace de destino. Normalmente, a verificação de simulação é usada nas referências do proprietário e é reconciliada quando a SecretForwarder é concluída. Em casos raros, as referências do proprietário de SecretForwarder podem perder a referência à verificação de simulação, fazendo com que ela fique travada. Como resultado, a criação do cluster falha. Para continuar a reconciliação da verificação de simulação orientada pelo controlador, exclua o pod do operador de cluster ou o recurso de verificação de simulação. Quando você exclui o recurso de verificação de simulação, ele
cria outro e continua a reconciliação. Como alternativa, é possível fazer upgrade dos clusters (que foram criados com uma versão anterior) para uma versão fixa.
Rede
1.9, 1.10, 1.11, 1.12, 1.13, 1.14, 1.15
Os endereços IP reservados não são liberados ao usar o plug-in de onde está com o recurso de várias NICs
No recurso multi-Nic, se você estiver usando o plug-in CNI whereabouts e usar a operação CNI DEL para excluir uma interface de rede de um pod, é possível que alguns endereços IP reservados não sejam liberados corretamente. Isso acontece quando a operação CNI DEL é interrompida.
É possível verificar as reservas de endereços IP não utilizados dos pods executando o seguinte comando:
kubectl get ippools -A --kubeconfig KUBECONFIG_PATH
Alternativa:
Exclua manualmente os endereços IP (ippools) que não são usados.
Instalação
1.10, 1.11.0, 1.11.1, 1.11.2
O detector de problemas de nó falha no cluster de usuário 1.10.4
O detector de problemas do nó pode falhar nos clusters do Anthos em clusters de usuários bare metal
1.10.x, quando clusters de Anthos nos clusters bare metal 1.11.0, 1.11.1 ou clusters de administradores 1.11.2
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, a configuração maxPodsPerNode não é considerada
para
clusters do modo 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
A reversão de upgrade pode falhar para clusters do Anthos em bare metal 1.14.0 a 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.
Exclua todos os healthchecks.baremetal.cluster.gke.io
recursos listados na etapa anterior:
Substitua HEALTHCHECK_RESOURCE_NAME pelo
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 2.38.0.
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 Anthos 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 da VM do Anthos
1.11, 1.12, 1.13 e 1.14
A criação da VM falha intermitentemente com erros de upload
A criação de uma nova máquina virtual (VM) com o comando "kubectl virt create vm"
não ocorre com frequência 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 do Anthos versão 1.11, os recursos associados não serão
preservados quando você fizer upgrade para a versão 1.12.
A partir dos clusters do Anthos na versão bare metal 1.12.0, o Serviço gerenciado
para componentes do Prometheus no namespace gmp-system e as definições de recursos personalizados
relacionados são gerenciados pelo stackdriver-operator com o
campo enableGMPForApplications. O campo enableGMPForApplications
é true por padrão, portanto, se você implantar manualmente os componentes
do Serviço gerenciado para Prometheus no namespace antes de atualizar
para a versão 1.12, os recursos serão excluídos por stackdriver-operator.
Alternativa
Para preservar os recursos de coleta gerenciados manualmente, faça o seguinte:
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 do cluster pode falhar para clusters do Anthos na versão bare metal 1.11.0. Esse problema está corrigido nos clusters do Anthos na versão bare metal 1.11.1. 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 será importante se esse comando falhar.
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 descobrir 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 é configurado para usar containerd como
ambiente de execução do contêiner. nodeConfig.containerRuntime é definido como
containerd no arquivo de configuração do cluster, o padrão
para Clusters do Anthos em bare metal na versão 1.14.
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
Os clusters do Anthos na versão bare metal 1.10.0 apresentaram um recurso de plano de controle
sem raiz que executa todos os componentes do plano de controle como um usuário não raiz. A execução dos componentes como um usuário não raiz pode causar falhas de instalação ou de upgrade em
sistemas com uma configuração umask mais restritiva de 0077.
Alternativa
Redefina os nós do plano de controle e altere a configuração umask
para 0022 em todas as máquinas do plano de controle. Após a atualização das máquinas, tente instalar
novamente.
Também é possível alterar as permissões de diretório e de arquivo de
/etc/kubernetes nas máquinas do plano de controle para que a instalação
ou upgrade continue.
Torne /etc/kubernetes e todos os subdiretórios globalmente legíveis:
chmod o+rx.
Transfira todos os arquivos do usuário root no diretório (recursivamente)
/etc/kubernetes legível (chmod o+r). Exclua os arquivos de chave privada
(.key) dessas alterações, porque eles já foram criados com as permissões e a
propriedade corretas.
O
grupo de controle v2 (cgroup v2) não é compatível com as versões 1.13 e
anteriores dos clusters do Anthos em bare metal. No entanto, a versão 1.14 é compatível com o cgroup
v2 como um recurso de pré-lançamento
. A presença
de /sys/fs/cgroup/cgroup.controllers indica que seu
sistema usa o cgroup v2.
Alternativa
Se o sistema usar o cgroup v2, faça upgrade para a versão 1.14 dos
clusters do Anthos em Bare Metal.
Instalação
1.10, 1.11, 1.12, 1.13, 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.
Para que as ADCs funcionem, você precisa apontar a variável de ambiente
GOOGLE_APPLICATION_CREDENTIALS para um arquivo de credencial de conta de serviço ou executar
gcloud auth application-default login.
Instalação
1.10, 1.11, 1.12, 1.13, 1.14
Serviço do Docker
Em máquinas de nó de cluster, se o executável do Docker estiver presente na variável de ambiente
do PATH, mas o serviço do Docker não estiver ativo, a verificação de simulação
falhará e informará que o Docker service
is not active.
Alternativa
Removao Docker ou ative o serviço do Docker.
Instalação
1.10, 1.11, 1.12, 1.13, 1.14
Como instalar no vSphere
Ao instalar clusters do Anthos em Bare Metal em VMs do vSphere, é preciso desativar as
sinalizações tx-udp_tnl-segmentation e tx-udp_tnl-csum-segmentation.
Essas sinalizações são relacionadas à descarga de segmentação de hardware feita pelo vSphere
driver VMXNET3 e não funcionam com o túnel GENEVE de
clusters Anthos no ambiente Bare Metal.
Alternativa
Execute o comando a seguir em cada nó para verificar os valores atuais dessas sinalizações.
ethtool -k NET_INTFC |grep segm
...
tx-udp_tnl-segmentation: on
tx-udp_tnl-csum-segmentation: on
...
Substitua NET_INTFC pela interface de rede associada
ao endereço IP do nó.
No RHEL 8.4, ethtool às vezes mostra que essas sinalizações 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 is not 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ção.
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 VMs do Anthos
1.11, 1.12
O upgrade de clusters para a versão 1.12.0 ou superior falha quando o Anthos VM Runtime está ativado
Nos clusters do Anthos na versão bare metal 1.12.0, todos os recursos relacionados ao
ambiente de execução da VM do Anthos são migrados para o namespace vm-system para oferecer melhor
suporte à versão do GA VM do Anthos. Se você
tiver o Anthos VM Runtime ativado em um cluster da versão 1.11.x ou anterior,
o upgrade para a versão 1.12.0 ou mais recente falhará a menos que você desative
o Anthos VM Runtime. Quando você é afetado por esse problema, a operação de upgrade informa o seguinte erro:
Failed to upgrade cluster: cluster is not 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
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 Anthos Network Gateway
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 Anthos Network Gateway. 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:
Não é possível iniciar a diminuição do nó quando ele está fora de alcance
O processo de drenagem para nós não será iniciado se o nó estiver fora de alcance dos clusters do Anthos em bare metal. Por exemplo, se um nó ficar off-line durante um processo de upgrade de cluster, ele poderá fazer com que o upgrade pare de responder. Isso é raro.
Alternativa
Para minimizar a probabilidade de encontrar esse problema, verifique se os nós estão funcionando corretamente antes de iniciar um upgrade.
Upgrades e atualizações
1.12
O containerd 1.5.13 requer o libseccomp 2.5 ou mais recente
Os clusters do Anthos em bare metal versão 1.12.1 são enviados com o containerd versão 1.5.13, e essa versão do containerd requer o libseccomp versão 2.5 ou mais recente.
Se o sistema não tiver o libseccomp versão 2.5 ou mais recente instalado, atualize-o antes de fazer upgrade dos clusters atuais para a versão 1.12.1. Caso contrário, é possível ver erros nos pods cplb-update para nós do balanceador de carga, como o seguinte:
runc did not terminate successfully: runc: symbol lookup error: runc: undefined symbol: seccomp_notify_respond
Alternativa
Para instalar a versão mais recente do libseccomp no Ubuntu, execute o seguinte comando:
sudo apt-get install libseccomp-dev
Para instalar a versão mais recente do libseccomp no CentOS ou no RHEL, execute o seguinte comando:
sudo dnf -y install libseccomp-devel
Operação
1.10, 1.11, 1.12
Os nós não são restritos se você não usar o procedimento do modo de manutenção
Se você executar Clusters do Anthos em bare metal versão 1.12.0 (anthosBareMetalVersion: 1.12.0) ou
anterior e usar manualmente kubectl cordon em um nó, os Clusters do Anthos em bare metal podem
desvincular o nó antes de estar tudo pronto para tentar reconciliar o estado esperado.
Alternativa
Para Clusters do Anthos em bare metal versão 1.12.0 e anterior, use o
modo de manutenção para restringir e drenar nós com segurança.
Na versão 1.12.1 (anthosBareMetalVersion: 1.12.1) ou mais recente,
os Clusters do Anthos em bare metal não cancelam os nós inesperadamente quando você usa
kubectl cordon.
Operação
1.11
Os clusters de administrador da versão 11 que usam um espelho de registro não podem gerenciar os clusters da versão 1.10
Se o cluster de administrador estiver na versão 1.11 e usar um espelho de registro, não será possível gerenciar clusters de usuário que estão em uma versão secundária menor. Esse problema afeta as operações de redefinição, atualização e upgrade no cluster de usuários.
Para determinar se esse problema afeta você, verifique se há operações de cluster nos registros, como criar, fazer upgrade ou redefinir. Por padrão, esses registros ficam localizados na pasta bmctl-workspace/CLUSTER_NAME/. Se você for afetado pelo problema, os registros contêm a seguinte mensagem de erro:
flag provided but not defined: -registry-mirror-host-to-endpoints
Operação
1.10, 1.11
Secret do kubeconfig substituído
O comando bmctl check cluster, quando executado em clusters de usuários, substitui a chave secreta kubeconfig do cluster de usuário pelo kubeconfig do cluster de administrador. A substituição do arquivo causa falhas nas operações padrão do cluster, como atualização e upgrade, para os clusters de usuário afetados. Esse problema se aplica aos clusters do Anthos na versão bare metal 1.11.1 e anteriores.
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 Anthos em bare metal são
o nome do cluster precedido por cluster-. Por exemplo, se você der o nome de test ao cluster, o namespace será cluster-test.
USER_CLUSTER_NAME: o nome do cluster de usuário a ser verificado.
Se o nome do cluster na saída (consulte contexts.context.cluster no exemplo de saída a seguir) for o nome do cluster de administrador, o cluster de usuário especificado será afetado.
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. Os clusters do Anthos em bare metal geram o arquivo kubeconfig na estação de trabalho de administrador quando você cria um cluster. Por padrão, o arquivo está no diretório bmctl-workspace/USER_CLUSTER_NAME.
Verifique se o kubeconfig está correto no cluster de usuário kubeconfig:
kubectl get nodes \
--kubeconfig PATH_TO_GENERATED_FILE
Substitua PATH_TO_GENERATED_FILE pelo caminho para o
arquivo Kubeconfig do cluster de usuário. A resposta retorna detalhes sobre os nós do cluster de usuário. Confirme se os nomes de máquina estão corretos para o cluster.
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.
Operação, ambiente de execução da VM do Anthos
1.10, 1.11, 1.12, 1.13, 1.14
Ambiente de execução de VM do Anthos: a reinicialização de um pod faz com que as VMs no pod alterem os endereços IP ou percam o endereço IP inteiro.
Se o endereço IP de uma VM for alterado, isso não afetará
a acessibilidade dos aplicativos de VM expostos como um serviço do Kubernetes.
Alternativa
Se o endereço IP for perdido, execute dhclient a partir da VM para adquirir um endereço
IP para a VM.
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
Upgrade dos clusters do Anthos em Bare Metal para a versão 1.11.0 ou mais recente.
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_Key time
Time_Format %Y-%m-%dT%H:%M:%S.%L%z
Time_Keep off
Para clusters do Anthos em versões bare metal 1.10 e mais recentes, alguns clientes encontraram
um faturamento alto inesperado para Metrics volume na
página Faturamento. Esse problema afeta você apenas quando ambas as circunstâncias a seguir se aplicarem:
O monitoramento de aplicativos está ativado (enableStackdriverForApplications=true)
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 as faturadas indesejadas.
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
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 as versões 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 Anthos estão obsoletas. A partir dos
clusters do Anthos na versão Bare Metal 1.11, os dados não são mais coletados para essas
métricas obsoletas. 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.
Nos clusters do Anthos em versões bare metal anteriores à 1.11, o arquivo de definição de política para
o alerta Anthos on baremetal node cpu usage exceeds
80 percent (critical) recomendado usa as métricas obsoletas. 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.
Encerre todos os pods de stackdriver-log-forwarder:
Embora essas métricas de tipo de resumo estejam na lista de métricas, elas não são compatíveis com gke-metrics-agent no momento.
Geração de registros e monitoramento
1.10, 1.11
Interrupções intermitentes da exportação de métricas
Os clusters do Anthos em bare metal podem sofrer interrupções em exportações
contínuas normais 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 entrado em vigor.
Rede
1.10
Vários gateways padrão apresentam falha de conectividade com endpoints externos
Ter vários gateways padrão em um nó pode levar a uma falha de conectividade entre um pod e endpoints externos, como google.com.
Para saber se esse problema está ocorrendo, execute o seguinte comando no nó:
ip route show
Várias instâncias de default na resposta indicam que o problema está ocorrendo.
Rede
1.12
As edições personalizadas de recursos de rede em clusters de usuários são substituídas
Os clusters do Anthos em bare metal versão 1.12.x não impedem que você edite
manualmente
recursos personalizados
de rede no cluster de usuário. Os clusters do Anthos em bare metal reconciliam 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. Os recursos personalizados da rede
devem ser modificados apenas no cluster de administrador, mas os clusters do Anthos em bare metal versão
1.12.x não impõe 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. Os clusters do Anthos em versões bare metal 1.13.0 e mais recentes impedem que você
modifique os recursos personalizados da rede diretamente nos clusters de usuários.
Rede
1.11, 1.12, 1.13, 1.14
Falha NAT com muitas conexões paralelas
Para um determinado nó no cluster, o endereço IP do nó fornece conversão de endereços de rede (NAT, na sigla em inglês) para pacotes roteados para um endereço fora do cluster. Da mesma forma, quando pacotes de entrada inserem um nó de balanceamento de carga configurado para usar o balanceamento de carga em pacote (spec.loadBalancer.mode:
bundled), a conversão de endereços de rede de origem (SNAT, na sigla em inglês) encaminha os pacotes para o endereço IP do nó antes de serem encaminhados para um pod de back-end.
O intervalo de portas para NAT usado por clusters do Anthos em bare metal é 32768–65535.
Esse intervalo limita o número de conexões paralelas a 32.767 por protocolo nesse nó. Cada conexão precisa de uma entrada na tabela conntrack. Se você tiver muitas conexões de curta duração, a tabela conntrack ficará sem portas para NAT.
Um coletor de lixo limpa as entradas desatualizadas, mas a limpeza não é imediata.
Quando o número de conexões no nó se aproximar 32.767,
você começará a ver quedas de pacotes para conexões que precisam de NAT.
Para identificar esse problema, execute o seguinte comando no pod anetd do nó problemático:
IP de origem do cliente com balanceamento de carga em pacote de camada 2
Definir a
política de tráfego externo
como Local pode causar erros de roteamento, como No route to
host, para balanceamento de
carga em pacote de camada 2. A política de tráfego externo é definida como Cluster
(externalTrafficPolicy:
Cluster), por padrão. Com essa configuração, o Kubernetes
processa o tráfego em todo o cluster. Serviços do tipo LoadBalancer ou NodePort podem usar externalTrafficPolicy: Local para preservar o endereço IP da origem do cliente. No entanto, com essa configuração, o Kubernetes processa apenas o tráfego local do nó.
Alternativa
Se você quiser preservar o endereço IP da origem do cliente, será necessário fazer outras configurações
para garantir que os IPs de serviço estejam acessíveis. Para detalhes de configuração,
consulte
Como preservar o endereço IP da origem do cliente
em Configurar o balanceamento de carga em pacote.
Rede
1.10, 1.11, 1.12, 1.13, 1.14
Modificar firewalld apagará as cadeias de políticas do Cilium iptable
Ao executar clusters do Anthos em Bare Metal com firewalld ativado no CentOS ou
no Red Had Enterprise Linux (RHEL), as alterações em firewalld podem remover as cadeias
iptables do Cilium na rede do host. As cadeias iptables são adicionadas pelo pod anetd quando ele é iniciado. A perda das cadeias do iptables do Cilium faz com que
o pod no nó perca a conectividade de rede fora do nó.
As alterações em firewalld que removerão as cadeias de iptables incluem, mas não estão limitadas a:
Reiniciando firewalld, usando systemctl
Como atualizar o firewalld com o cliente da linha de comando (firewall-cmd --reload)
Alternativa
Reinicie o anetd no nó. Localize
e exclua o pod anetd com os seguintes comandos para reiniciar anetd:
Ao usar a visualização do recurso Gateway NAT de saída, é possível definir regras de seleção de tráfego que especificam um endereço
egressSourceIP que já está sendo usado por outro objeto EgressNATPolicy. Isso pode causar conflitos de roteamento do tráfego de saída.
Alternativa
Coordene com sua equipe de desenvolvimento para determinar quais endereços IP flutuantes estão disponíveis para uso antes de especificar o endereço egressSourceIP no recurso EgressNATPolicy personalizado.
Rede
1.10, 1.11, 1.12, 1.13, 1.14
Falhas de conectividade dos pods e filtragem de caminho reverso
Os clusters do Anthos no bare metal configuram o filtro de caminho reverso nos 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 falharão devido a 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
Para restaurar a conectividade do pod, defina net.ipv4.conf.all.rp_filter de volta para
0 manualmente ou reinicie o pod de anetd para definir net.ipv4.conf.all.rp_filter
novamente 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:
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.11
Incompatibilidade com o Ubuntu 18.04.6 no kernel do GA
Os clusters do Anthos em versões bare metal 1.11.0 e 1.11.1 não são compatíveis
com o Ubuntu 18.04.6 no kernel do GA (de 4.15.0-144-generic
a 4.15.0-176-generic). A incompatibilidade faz com que o
agente da rede não configure a rede do cluster com um
erro "O programa BPF é muito grande" nos registros anetd. É possível ver pods travados no status ContainerCreating com um erro networkPlugin cni failed to set up pod no log de eventos dos pods. Esse problema não se aplica aos kernels de ativação de hardware do Ubuntu (HWE).
Alternativa
Recomendamos que você instale o kernel do HWE e faça upgrade para a última versão do HWE compatível com o Ubuntu 18.04.
Sistema operacional
1.10, 1.11, 1.12, 1.13, 1.14
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
compatíveis do CentOS e afeta todas as versões dos clusters do Anthos em bare metal.
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-*
No RHEL e no CentOS, há uma limitação no nível do cluster de 100.000 endpoints. Serviço do Kubernetes. Se dois serviços fizerem referência ao mesmo conjunto de pods, isso conta como dois conjuntos separados de endpoints. A implementação nftable subjacente no
RHEL e no CentOS causa essa limitação. A limitação não é intrínseca dos
clusters do Anthos em bare metal.
Segurança
1.10, 1.11, 1.12, 1.13, 1.14
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.
Segurança
1.10, 1.11, 1.12, 1.13, 1.14
Erros do SELinux durante a criação do pod
A criação do pod às vezes falha quando o SELinux impede o ambiente de execução do contêiner de configurar rótulos em montagens tmpfs. Essa falha é rara, mas pode acontecer quando o SELinux está no modo Enforcing e em alguns kernels.
Para verificar se o SELinux é a causa das falhas na criação de pods, use o seguinte
comando para verificar se há erros nos registros kubelet:
journalctl -u kubelet
Se o SELinux estiver causando falha na criação do pod, a resposta do comando conterá um erro semelhante ao seguinte:
error setting label on mount source '/var/lib/kubelet/pods/6d9466f7-d818-4658-b27c-3474bfd48c79/volumes/kubernetes.io~secret/localpv-token-bpw5x': failed to set file label on /var/lib/kubelet/pods/6d9466f7-d818-4658-b27c-3474bfd48c79/volumes/kubernetes.io~secret/localpv-token-bpw5x: permission denied
Para verificar se esse problema está relacionado à aplicação do SELinux, execute o seguinte comando:
ausearch -m avc
Esse comando pesquisa nos registros de auditoria erros de permissão de cache de vetor
de acesso (AVC). O avc: denied no exemplo de resposta a seguir confirma que as falhas de criação do pod estão relacionadas à aplicação do SELinux.
A causa raiz desse problema de criação de pods com o SELinux é um bug do kernel encontrado nas seguintes imagens do Linux:
Red Hat Enterprise Linux (RHEL) versões anteriores à 8.3
Versões do CentOS anteriores à 8.3
Alternativa
A reinicialização da máquina ajuda a recuperar o problema.
Para evitar erros de criação de pods, use o RHEL 8.3 ou posterior ou o CentOS 8.3 ou posterior, porque essas versões corrigiram o bug do kernel.
Redefinir/excluir
1.10, 1.11, 1.12
Exclusão de namespaces
A exclusão de um namespace impedirá a criação de novos recursos nesse
namespace, incluindo jobs para redefinir máquinas.
Alternativa
Ao excluir um cluster de usuário, você
precisa excluir o objeto de cluster antes de excluir o namespace dele. Caso contrário,
os jobs para redefinir as máquinas não poderão ser criados, e o processo de exclusão ignorará a etapa de limpeza da máquina.
Redefinir/excluir
1.10, 1.11, 1.12, 1.13, 1.14
serviço containerd
O comando bmctl reset não exclui arquivos de configuração containerd ou
binários. O serviço containerd systemd está ativo e em execução. O comando exclui os contêineres que estão executando pods programados para o nó.
Upgrades e atualizações
1.10, 1.11, 1.12
O detector de problemas de nós não é ativado por padrão após os upgrades de cluster
Ao fazer upgrade de clusters do Anthos em bare metal, o detector de problemas de nós 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 mostrar inactive, o 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 aos clusters do Anthos em bare metal 1.9.x, 1.10.0 e 1.10.1 e é 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 ao upgrade da disputa de anthos-cluster-operador e
não afeta nenhuma funcionalidade de cluster regular.
O bug não está presente depois da versão 1.13 ou mais recente.
Alternativa:
Exclua o job do dynamic-version-installer por
kubectl delete job anthos-version-$version$ -n kube-system
Upgrades e atualizações
1.13
1.12 clusters atualizados da 1.11 não podem atualizar para 1.13.0
Não é possível fazer upgrade dos clusters da versão 1.12 da versão 1.11 para a 1.13.0. Esse problema de upgrade não se aplica a clusters criados na
versão 1.12.
Para determinar se você foi afetado, verifique os registros do job de upgrade que contém a string upgrade-first-no* no cluster de administrador.
Se a mensagem de erro abaixo aparecer, você será afetado.
TASK [kubeadm_upgrade_apply : Run kubeadm upgrade apply] *******
...
[upgrade/config] FATAL: featureGates: Invalid value: map[string]bool{\"IPv6DualStack\":false}: IPv6DualStack is not a valid feature name.
...
Alternativa:
Para contornar esse problema:
Execute os seguintes comandos na estação de trabalho de administrador: