Nesta página, você encontrará uma lista dos problemas conhecidos do modo privado do Anthos, além de maneiras de evitá-los e corrigi-los.
Falhas de conectividade dos pods e filtragem de caminho reverso
O modo particular do Anthos 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 falharão devido aos tempos limite de comunicação
fora do nó.
A filtragem de caminho reverso é definida com arquivos rp_filter na pasta de configuração
IPv4 (net/ipv4/conf/all). Este valor também pode ser modificado por sysctl,
que armazena as configurações de filtragem de caminho reverso em um arquivo de configuração de segurança de
rede, como /etc/sysctl.d/60-gce-network-security.conf.
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:
kubectl get pods -n kube-system
kubectl delete pods -n kube-system ANETD_XYZ
Substitua ANETD_XYZ pelo nome do pod anetd.
Redirecionar loop ao acessar o Console do Anthos Management Center
Se o navegador estiver em um loop de redirecionamento ao acessar o console do Centro de gerenciamento após configurar os provedores de identidade e fazer login com o provedor de identidade, talvez haja um erro nas configurações do OIDC. Veja Redefinir configuração de autenticação.
Isso geralmente ocorre quando a declaração de nome de usuário ou do grupo não existe nos escopos do OIDC solicitados. Verifique o JWT do provedor de OIDC para verificar se a declaração de nome de usuário ou a declaração de grupo correta é usada ao configurar provedores de identidade.
Os IDs do cliente precisam ser exclusivos ao configurar o OIDC
Esse problema pode se manifestar em um loop de redirecionamento após a autenticação com o provedor OIDC. Verifique a configuração do provedor de identidade para ver se há outros provedores de identidade que usam o mesmo ID do cliente:
KUBECONFIG=${ADMIN_KUBECONFIG} kubectl get clientconfig -n kube-public default -oyaml
Se houver IDs do cliente duplicados, peça ao provedor de identidade para criar um novo.
Atualizar manualmente as páginas da Web após a expiração do token de autorização
Se houver uma página da Web com erros e se passou pelo menos uma hora (ou menos, dependendo das configurações do provedor OIDC) desde o último login, clique no botão de atualização do navegador com um novo token de autorização. Talvez o provedor OIDC receba uma solicitação para fazer login novamente.
Falha ao criar o cluster de administrador
Se você tiver um problema ao criar o cluster de administrador em que o pod kube-proxy no
cluster kind não é iniciado, tente definir manualmente nf_conntrack_max na
estação de trabalho de administrador. Exemplo:
sudo sysctl -w net.netfilter.nf_conntrack_max=131072