En esta página, se enumeran los problemas conocidos de Anthos en modo privado, junto con las formas en que puedes evitarlos o solucionarlos.
No se pudo vincular una cuenta de servicio al ClusterRole anthos-platform-admin predeterminado
No puedes vincular correctamente una cuenta de servicio al ClusterRole predeterminado anthos-platform-admin o anthos-platform-admin-read-only. El controlador debe otorgar de forma dinámica algunos permisos a los sujetos, pero actualmente solo admite usuarios y grupos.
Fallas de conectividad del Pod y filtrado de la ruta de acceso inversa
El modo privado de Anthos configura el filtrado de ruta de acceso inversa en los nodos para inhabilitar la validación de origen (net.ipv4.conf.all.rp_filter=0). Si la configuración rp_filter se cambia a 1 o 2, los pods fallarán debido a que se agotaron los tiempos de espera de la comunicación fuera de los nodos.
El filtrado de ruta de acceso inversa se establece con los archivos rp_filter en la carpeta de configuración de IPv4 (net/ipv4/conf/all). También es posible que sysctl anule este valor, que almacena la configuración del filtrado de la ruta de acceso inversa en un archivo de configuración de seguridad de red, como /etc/sysctl.d/60-gce-network-security.conf.
Para restablecer la conectividad del Pod, vuelve a establecer net.ipv4.conf.all.rp_filter en 0 de forma manual o reinicia el Pod anetd para volver a configurar net.ipv4.conf.all.rp_filter en 0. A fin de reiniciar el Pod anetd, usa los siguientes comandos para ubicar y borrar el pod anetd, y se iniciará un nuevo Pod anetd en su lugar:
kubectl get pods -n kube-system
kubectl delete pods -n kube-system ANETD_XYZ
Reemplaza ANETD_XYZ con el nombre del pod anetd.
Bucle de redireccionamiento cuando se accede a la consola del centro de administración de Anthos
Si el navegador se encuentra en un bucle de redireccionamiento cuando accedes a la consola del centro de administración después de configurar los proveedores de identidad y acceder con el proveedor de identidad, es posible que haya un error en la configuración de OIDC. Consulta Restablece la configuración de la autenticación.
Esto suele ocurrir cuando la reclamación del nombre de usuario o la reclamación del grupo no existen en los alcances de OIDC solicitados. Verifica el JWT del proveedor de OIDC para verificar que se use la reclamación de nombre de usuario o la reclamación de grupo correcta cuando se configuran proveedores de identidad.
Los ID de cliente deben ser únicos cuando se configura OIDC
Este problema puede manifestarse en un bucle de redireccionamiento después de autenticarse de forma correcta mediante el proveedor de OIDC. Verifica la configuración del proveedor de identidad para ver si hay otros proveedores que usen el mismo ID de cliente:
KUBECONFIG=${ADMIN_KUBECONFIG} kubectl get clientconfig -n kube-public default -oyaml
Si hay ID de cliente duplicados, pídele a tu proveedor de identidad que cree un ID de cliente nuevo.
Actualiza manualmente las páginas web después de que venza el token de autorización
Si ves una página web en la que se muestran errores y ha pasado al menos una hora (o menos, según la configuración del proveedor de OIDC) desde el último acceso, haz clic en el botón de actualización del navegador para actualizar la página web con un nuevo token de autorización. Es posible que tu proveedor de OIDC te solicite acceder de nuevo.
Falla cuando se crea el clúster de administrador
Si tienes problemas para crear el clúster de administrador en el que el pod kube-proxy en el clúster kind no se inicia, intenta configurar nf_conntrack_max de forma manual en la estación de trabajo de administrador. Por ejemplo:
sudo sysctl -w net.netfilter.nf_conntrack_max=131072