Nesta página, listamos os problemas conhecidos selecionados do GKE na AWS e as etapas que você pode seguir para reduzir o impacto deles.
Se precisar de mais ajuda, entre em contato com o Cloud Customer Care.Operações
O escalonador automático de clusters pode escalonar verticalmente incorretamente o escalonamento vertical de zero nó
As versões afetadas por esse problema são as seguintes:
- Todas as versões anteriores à 1.27
- Versões da 1.27 de 1.27.0-gke.0 até 1.27.12-gke.800, mas não incluindo
- Versões de 1.28 a partir de 1.28.0-gke.0 até 1.28.8-gke.800, mas não incluindo
O escalonador automático de clusters não faz o escalonar verticalmente corretamente de zero nós para pools de nós com rótulos ou taints personalizados.
Esse problema ocorre porque o escalonador automático de clusters do GKE na AWS não configurou os rótulos do pool de nós e as tags de taint no pool de nós correspondente ao grupo de escalonamento automático durante o provisionamento do pool de nós. Nos pools de nós sem nós, o escalonador automático de cluster não consegue criar os modelos de nó corretamente devido a essas tags ausentes. Isso pode levar a decisões incorretas de escalonamento, como os pods não serem programados para os nós aplicáveis ou o provisionamento de nós que não são realmente necessários. Para mais informações, consulte Configuração da descoberta automática.
Rede
Tempo limite do aplicativo causados por falhas de inserção da tabela de conntrack
As versões afetadas por esse problema são as seguintes:
- Todas as versões de 1.23 a partir de 1.23.8-gke.1700.
- Todas as versões de 1.24 a partir de 1.24.0-gke.0.
- Versões de 1.25 que variam de 1.25.0-gke.0 até, mas não incluem, 1.25.10-gke.1200.
- Versões de 1.26.0-gke.0 até 1.26.4-gke.2200, mas sem incluir esta última.
Os clusters em execução em um SO Ubuntu que usa o kernel 5.15 ou posterior são suscetíveis a falhas na inserção de tabela do rastreamento de conexão de rede (conntrack). As falhas de inserção podem ocorrer mesmo quando a tabela de conntrack tiver espaço para novas entradas. As falhas são causadas por alterações no kernel 5.15 e mais recentes que restringem as inserções de tabelas com base no comprimento da cadeia.
Para ver se você foi afetado por esse problema, verifique as estatísticas do sistema de rastreamento de conexão no kernel com o seguinte comando:
sudo conntrack -S
A resposta será assim:
cpu=0 found=0 invalid=4 insert=0 insert_failed=0 drop=0 early_drop=0
error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=1 found=0 invalid=0 insert=0 insert_failed=0 drop=0 early_drop=0
error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=2 found=0 invalid=16 insert=0 insert_failed=0 drop=0 early_drop=0
error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=3 found=0 invalid=13 insert=0 insert_failed=0 drop=0 early_drop=0
error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=4 found=0 invalid=9 insert=0 insert_failed=0 drop=0 early_drop=0
error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=5 found=0 invalid=1 insert=0 insert_failed=0 drop=0 early_drop=0
error=519 search_restart=0 clash_resolve=126 chaintoolong=0
Se um valor chaintoolong na resposta for um número diferente de zero, você enfrentará esse problema.
Solução
Se você estiver executando a versão 1.26.2-gke.1001, faça um upgrade para a versão 1.26.4-gke.2200 ou posterior.
Usabilidade
Erro de clusters inacessíveis na IU
As versões afetadas por esse problema são 1.25.5-gke.1500 e 1.25.4-gke.1300.
Algumas superfícies de IU no console do Google Cloud não podem autorizar o cluster e podem exibi-lo como inacessível.
Solução
Faça upgrade do cluster para o patch mais recente disponível da versão 1.25. Esse problema foi corrigido na versão 1.25.5-gke.2000.
Erros da API
O Kubernetes 1.22 suspende o uso e substitui várias APIs. Se você tiver feito upgrade do cluster para a versão 1.22 ou posterior, as chamadas feitas pelo aplicativo para uma das APIs descontinuadas vão falhar.
Solução
Faça upgrade do seu aplicativo para substituir as chamadas de API obsoletas pelos correspondentes mais recentes.