Cette page répertorie les problèmes connus d'Anthos en mode déconnecté, ainsi que les moyens de les éviter ou de les résoudre.
Échecs de connectivité du pod et filtrage du chemin d'accès inverse
Le mode déconnecté d'Anthos configure le filtrage du chemin d'accès inverse sur les nœuds pour désactiver la validation de la source (net.ipv4.conf.all.rp_filter=0). Si le paramètre rp_filter est défini sur 1 ou 2, les pods échouent en raison de délais de communication hors nœud.
Le filtrage du chemin d'accès inverse est défini par les fichiers rp_filter dans le dossier de configuration IPv4 (net/ipv4/conf/all). Cette valeur peut également être remplacée par sysctl, qui stocke les paramètres de filtrage du chemin d'accès inverse dans un fichier de configuration de sécurité réseau, tel que /etc/sysctl.d/60-gce-network-security.conf.
Pour restaurer la connectivité du pod, redéfinissez net.ipv4.conf.all.rp_filter manuellement sur 0 ou redémarrez le pod anetd pour redéfinir net.ipv4.conf.all.rp_filter sur 0. Pour redémarrer le pod anetd, exécutez les commandes suivantes afin de localiser et de supprimer le pod anetd, et un nouveau pod anetd démarrera à sa place :
kubectl get pods -n kube-system
kubectl delete pods -n kube-system ANETD_XYZ
Remplacez ANETD_XYZ par le nom du pod anetd.
Boucle de redirection lors de l'accès à la console du centre de gestion Anthos.
Si le navigateur se trouve dans une boucle de redirection lors de l'accès à la console du centre de gestion après la configuration des fournisseurs d'identité et la connexion avec le fournisseur d'identité, il peut y avoir une erreur dans les paramètres OIDC. Consultez la section Réinitialiser la configuration d'authentification.
Cela se produit généralement lorsque la revendication de nom d'utilisateur ou la revendication de groupe n'existe pas dans les champs d'application OIDC demandés. Consultez le JWT du fournisseur OIDC pour vérifier que la revendication de nom d'utilisateur ou de groupe correcte est utilisée lors de la configuration des fournisseurs d'identité.
Les ID client doivent être uniques lors de la configuration d'OIDC
Ce problème peut se produire dans une boucle de redirection après une authentification réussie avec le fournisseur OIDC. Vérifiez la configuration du fournisseur d'identité pour voir si d'autres fournisseurs d'identité utilisent le même ID client :
KUBECONFIG=${ADMIN_KUBECONFIG} kubectl get clientconfig -n kube-public default -oyaml
S'il existe des ID clients en double, demandez à votre fournisseur d'identité de créer un ID client.
Actualiser manuellement les pages Web après expiration du jeton d'autorisation
Si une page Web affiche des erreurs et qu'il s'est écoulé au moins une heure (ou moins selon les paramètres de votre fournisseur OIDC) depuis votre dernière connexion, cliquez sur le bouton d'actualisation de votre navigateur pour actualiser la page Web avec un nouveau jeton d'autorisation. Il se peut que votre fournisseur OIDC vous invite à vous reconnecter.
Échec lors de la création du cluster d'administrateur
Si, lors de la création du cluster d'administrateur, le pod kube-proxy du cluster kind ne démarre pas, essayez de définir manuellement nf_conntrack_max sur le poste de travail d'administrateur. Exemple :
sudo sysctl -w net.netfilter.nf_conntrack_max=131072