En esta página, se enumeran los problemas conocidos de Anthos en modo privado, junto con las formas en que puedes evitarlos o solucionarlos.
La creación de clústeres de administrador permanece en waiting for node update jobs
La creación de un clúster de administrador suele tardar unos 30 minutos. Si el clúster se atasca en la fase de “esperando trabajos de actualización de nodos” durante mucho tiempo, puedes finalizar el proceso con Ctrl + C. Esta fase es el último paso de la instalación.
Finalizar este proceso no afecta la instalación.
La creación de clústeres de usuarios está atascada
Por lo general, la creación de un clúster de usuario tarda entre 10 y 30 minutos. Si el clúster aparece bloqueado en curso, puedes usar los comandos a continuación para verificar el progreso de la creación del clúster.
kubectl get pods -n cluster-USER_CLUSTER --kubeconfig=ADMIN_KUBECONFIG
kubectl get Cluster -n cluster-USER_CLUSTER -o yaml --kubeconfig=ADMIN_KUBECONFIG
La actualización del clúster de administrador con múltiples nodos del plano de control está atascada
La actualización del clúster de administrador puede detenerse en la actualización de los nodos del plano de control.
El comando de actualización permanece en Waiting for upgrade to complete... Upgrading <control plane node IP>.
El problema solo afecta al clúster de administrador si está configurado con todas las condiciones siguientes:
El registro privado configurado usa un certificado firmado por una autoridad certificadora privada.
El clúster de administrador está configurado con múltiples nodos del plano de control. Por ejemplo, si se configura para alta disponibilidad.
Los nodos del plano de control tienen
dockerinstalado.
El problema se debe a una configuración incorrecta en la que se intenta obtener el archivo de autoridad certificadora del registro en una ubicación incorrecta. Para solucionar el problema, debes distribuir de forma manual el archivo de autoridad certificadora en cada nodo. Por ejemplo, ejecuta la siguiente secuencia de comandos desde la estación de trabajo de administrador:
#!/bin/bash
# Docker login to generate the $HOME/.docker/config.json file
docker login REGISTRY_HOST
# List the IP addresses for all the control plane nodes, separated by whitespace.
IPs=( NODE_IPS_SEPARATED_BY_SPACE )
for ip in "${IPs[@]}"; do
# Copy the docker config over to the nodes.
scp $HOME/.docker/config.json USER_NAME@${ip}:docker-config.json
# Fix the image pull credentials issue
ssh USER_NAME@${ip} "sudo mkdir -p /root/.docker && sudo cp docker-config.json /root/.docker/config.json"
# Fix the cert issue, only needed for private registry with self-signed certs.
ssh USER_NAME@${ip} "sudo mkdir -p /etc/docker/certs.d && sudo cp -r /etc/containerd/certs.d/REGISTRY_HOST /etc/docker/certs.d/"
done
Reemplaza USER_NAME y REGISTRY_HOST por los valores configurados en la configuración del clúster de administrador.
Error de autorización 400 para el acceso a la IP privada
Después de configurar la autenticación de Open ID Connect (OIDC), si todavía usas una dirección IP para acceder al centro de administración, se te redireccionará a la página de autenticación y verás un error relacionado con la autorización del acceso a la IP privada. Por ejemplo:
Usa el nombre de dominio configurado en lugar de la IP a fin de acceder a la plataforma, ejecuta actl platform management-center describe para recuperar la dirección completa. El dominio es obligatorio para la devolución de llamada de redireccionamiento. Tu dominio puede apuntar a la dirección privada.
Respuesta de error HTTP 500 cuando se crea un administrador de plataforma inicial
Cuando aplicas un perfil de OIDC a clústeres, es posible que recibas una respuesta de error HTTP 500 después de hacer clic en Enviar si el nombre de usuario o el prefijo de grupo de tu perfil contienen el carácter “/”.
Para resolver este problema, borra el perfil y crea uno nuevo sin el carácter “/” en el nombre de usuario y el prefijo de grupo. Luego, intenta aplicar el perfil nuevo a los clústeres.
RBAC: Acceso denegado
Si ves un mensaje RBAC: access denied después de acceder con una cuenta de administrador de la plataforma, es posible que haya un error en la configuración de OIDC. Consulta Restablecer la configuración de autenticación.
Usa imágenes del registro privado cuando se usa la configuración de duplicación de registros
Si el clúster se configura con la configuración de duplicación de registros, toma nota de la ruta de acceso de la imagen cuando uses una imagen directamente desde el registro privado.
Por ejemplo, si el clúster de administrador se crea con la configuración de duplicación:
registryMirrors:
- endpoint: https://10.200.0.2/v2/library
docker push 10.200.0.2/library/test-image:test-tag sube una imagen al registro privado. Cuando creas un Deployment o Pod, la imagen 10.200.0.2/library/test-image:test-tag no se puede usar tal como está. Esto se debe a que la configuración containerd del nodo (/etc/containerd/config.toml) se estableció para duplicar todas las extracciones de imágenes desde 10.200.0.2/library. Luego, containerd intenta extraer la imagen desde 10.200.0.2/library/library/test-image:test-tag.
Para solucionar este problema, prueba uno de los siguientes pasos:
- Envía la imagen al extremo
docker push 10.200.0.2/library/library/test-image:test-tag. - Usa la ruta de acceso de la imagen
10.200.0.2/test-image:test-tag
No se puede actualizar el centro de administración de 0.8 a 0.9 cuando se configura OIDC.
La actualización del centro de administración de 0.8 a 0.9 cuando se configura OIDC falla con el siguiente mensaje de error:
level=fatal msg="Unable to initialize options: unable to resolve management center cluster: The given \"management center\" cluster \"admin-admin@admin\" does not appear to be a valid management center cluster. Did you choose the right cluster?\nunable to list DomainIDPMapping objects: the server could not find the requested resource"
Para solucionar este problema, crea un archivo con la CRD de DomainIDPMapping.
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
annotations:
controller-gen.kubebuilder.io/version: v0.4.0
creationTimestamp: null
name: domainidpmappings.managementcenter.anthos.cloud.google.com
spec:
group: managementcenter.anthos.cloud.google.com
names:
kind: DomainIDPMapping
listKind: DomainIDPMappingList
plural: domainidpmappings
singular: domainidpmapping
scope: Cluster
versions:
- name: v1alpha1
schema:
openAPIV3Schema:
description: DomainIDPMapping is the Schema for the domainidpmappings API
properties:
apiVersion:
description: 'APIVersion defines the versioned schema of this representation
of an object. Servers should convert recognized schemas to the latest
internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources'
type: string
kind:
description: 'Kind is a string value representing the REST resource this
object represents. Servers may infer this from the endpoint the client
submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds'
type: string
metadata:
type: object
spec:
description: DomainIDPMappingSpec is the struct that contains the mapping
from the domain to the authentication method name specified in the AIS
ClientConfig.
properties:
authMethodName:
description: AuthMethodName is the name of the authentication method
configured in the AIS ClientConfig.
type: string
domainName:
description: DomainName is the domain used to serve the Anthos web
endpoints. The domain should not include the protocol such as http
or https. Wild cards are not supported in the domain name.
type: string
required:
- authMethodName
- domainName
type: object
type: object
served: true
storage: true
status:
acceptedNames:
kind: ""
plural: ""
conditions: []
storedVersions: []
Aplica la CRD.
kubectl --kubeconfig=ADMIN_KUBECONFIG apply -f domainIDPMappingCRD.yaml
Borra el espacio de nombres de oauth2-proxy y EnvoyFilter.
kubectl --kubeconfig=ADMIN_KUBECONFIG delete envoyfilter istio-ingressgateway -n istio-system
kubectl --kubeconfig=ADMIN_KUBECONFIG delete namespace oauth2-proxy
Se produjo un error cuando se extraía la imagen de los pods con el prefijo anthos-log-forwarder.
Si --private-registry se habilita cuando se instala el clúster, la ruta de imagen que usó initContainer en la ruta de anthos-log-forwarder no se reemplazará por la ruta de acceso especificada en --private-registry. Esto solo ocurrirá en el clúster de administrador.
Por ejemplo, si observas el siguiente error en el clúster de administrador:
kubectl -n kube-system get pods --selector=app=anthos-log-forwarder
anthos-log-forwarder-2n96b 0/1 Init:ErrImagePull 0 16s
anthos-log-forwarder-8fxm8 0/1 Init:ErrImagePull 0 16s
anthos-log-forwarder-bh7rb 0/1 Init:ImagePullBackOff 0 16s
Solo el clúster de administrador con --private-registry configurado se verá afectado por este problema, que se corregirá en la próxima actualización.
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.
En la página de máquinas, no aparece ninguna máquina después de la actualización.
Reinicia el Pod anthos-cluster-operator.
kubectl --kubeconfig ADMIN_KUBECONFIG delete pods -l control-plane=anthos-cluster-operator -n kube-system
No se pueden editar los clústeres de usuario después de la actualización
Reinicia el Pod anthos-cluster-operator.
kubectl --kubeconfig ADMIN_KUBECONFIG delete pods -l control-plane=anthos-cluster-operator -n kube-system