En esta página, se muestra cómo resolver problemas habituales con GKE on AWS.
Si necesitas asistencia adicional, comunícate con Atención al cliente de Cloud.Mensajes de error comunes:
En las siguientes secciones, se explican las causas y las soluciones de algunos mensajes de error comunes.
El servidor no tiene un recurso
Los errores como error: the server doesn't have a resource type "services" pueden ocurrir cuando un clúster no tiene grupos de nodos en ejecución o la puerta de enlace de Connect no puede conectarse a un grupo de nodos. Para verificar el estado de los grupos de nodos, ejecuta el siguiente comando:
gcloud container aws node-pools list \
--cluster-name CLUSTER_NAME \
--location LOCATION
Reemplaza lo siguiente:
CLUSTER_NAME: Es el nombre del clústerLOCATION: la región de Google Cloud que administra tu clúster
El resultado incluye el estado de los grupos de nodos del clúster. Si no tienes un grupo de nodos, crea uno.
Usuario prohibido
El siguiente error ocurre cuando tu nombre de usuario no tiene acceso de administrador a tu clúster:
Error from server (Forbidden): users "administrator@example.com" is forbidden:
User "system:serviceaccount:gke-connect:connect-agent-sa" cannot impersonate
resource "users" in API group "" at the cluster scope
Para configurar usuarios adicionales, pasa la marca --admin-users cuando crees un clúster.
Si usas la puerta de enlace de Connect y no puedes conectarte a tu clúster, prueba los siguientes pasos:
Obtén los usuarios autorizados de tu clúster.
gcloud container aws clusters describe CLUSTER_NAME \ --format 'value(authorization.admin_users)'Reemplaza
CLUSTER_NAMEpor el nombre del clúster.El resultado incluye los nombres de usuario con acceso de administrador al clúster. Por ejemplo:
{'username': 'administrator@example.com'}Obtén el nombre de usuario autenticado actualmente con Google Cloud CLI.
gcloud config get-value accountEl resultado incluye la cuenta autenticada con Google Cloud CLI. Si los resultados de
gcloud containers aws clusters describeygcloud config get-value accountno coinciden, ejecutagcloud auth loginy autentícate con el nombre de usuario que tiene acceso de administrador al clúster.
Problemas con los comandos de kubectl
En las siguientes secciones, se proporciona orientación para resolver problemas con los comandos kubectl que no responden o con errores.
Los comandos de kubectl dejan de responder
Si tu clúster ejecuta una versión de Kubernetes anterior a la 1.25 y los comandos kubectl no responden o se agota el tiempo de espera, el motivo más común es que aún no creaste un grupo de nodos. De forma predeterminada, GKE on AWS genera archivos kubeconfig que usan la puerta de enlace de Connect como un extremo accesible en Internet.
Para que esto funcione, la implementación gke-connect-agent debe ejecutarse en un grupo de nodos en el clúster.
Para obtener más información de diagnóstico, ejecuta el siguiente comando:
kubectl cluster-info -v=9
Si no hay grupos de nodos en ejecución, verás que las solicitudes a connectgateway.googleapis.com fallan con un error 404 cannot find active connections for cluster.
Para los clústeres con una versión de Kubernetes 1.25 o posterior, gke-connect-agent se ejecuta en el plano de control y no se requiere un grupo de nodos. Si el comando kubectl no responde, verifica los registros de componentes del plano de control con Cloud Logging.
Los comandos kubectl exec, attach y port-forward fallan
Los comandos kubectl exec, kubectl attach y kubectl port-forward pueden fallar con el mensaje error: unable to upgrade connection cuando se usa la puerta de enlace de Connect. Esta es una limitación cuando se usa la puerta de enlace de Connect como el extremo del servidor de la API de Kubernetes.
Para solucionar este problema, usa un kubeconfig que especifique el extremo privado del clúster. Si deseas obtener instrucciones para acceder al clúster a través de su extremo privado, consulta Configura el acceso al clúster para kubectl.
Los registros de kubectl fallan con el error remoto: tls: internal error
Esto puede ocurrir cuando al rol de la API del plano de control le falta un permiso. Por ejemplo, esto puede suceder si a tu rol de AWS le falta el permiso ec2:DescribeDhcpOptions. En este caso, las solicitudes de firma de certificados de los nodos no se pueden aprobar y el nodo trabajador no tendrá un certificado válido.
Para determinar si este es el problema, puedes verificar si hay solicitudes de firma de certificados pendientes que no se aprobaron con este comando:
kubectl get csr
Para resolver esto, verifica que tu rol de AWS coincida con los requisitos.
Solución de problemas de kubectl genérico
Si usas la puerta de enlace Connect, haz lo siguiente:
Asegúrate de haber habilitado la puerta de enlace de Connect en tu proyecto de Google Cloud:
gcloud services enable connectgateway.googleapis.comPara los clústeres con una versión de Kubernetes anterior a la 1.25, asegúrate de tener al menos un grupo de nodos de Linux en ejecución y que
gke-connect-agentse esté ejecutando. Para obtener más información, consulta Soluciona problemas de conexiones de clústeres.Para los clústeres con la versión 1.25 de Kubernetes o posterior, verifica los registros
gke-connect-agentcon Cloud Logging.
Kubernetes Service (LoadBalancer) o Kubernetes Ingress no funcionan
Si tus balanceadores de cargas de AWS Elastic (ELB/NLB/ALB) se crearon, pero no funcionan como se esperaba, esto puede deberse a problemas con el etiquetado de la subred. Para obtener más información, consulta Subredes del balanceador de cargas.
Los Pods en nodos Arm fallan
El siguiente problema ocurre cuando implementas un Pod en un nodo Arm, pero la imagen de contenedor no está compilada para la arquitectura Arm.
Para identificar el problema, completa las siguientes tareas:
Obtén el estado de los Pods:
kubectl get podsObtén los registros de un Pod que falla:
kubectl logs POD_NAMEReemplaza
POD_NAMEcon el nombre del Pod que falla.El mensaje de error en los registros de tu Pod es similar al siguiente:
exec ./hello-app: exec format error
Para resolver este problema, asegúrate de que la imagen de contenedor sea compatible con la arquitectura de Arm. Como práctica recomendada, compila varias imágenes de arquitectura.
No se puede borrar el clúster
Si recibes un error similar al siguiente cuando intentas borrar un clúster, es posible que tu rol de API de múltiples nubes de GKE no exista:
ERROR: (gcloud.container.aws.clusters.delete) FAILED_PRECONDITION: Could not
assume role
"arn:aws:iam::ACCOUNT_NUMBER:role/gke123456-anthos-api-role"
through service account
"service-123456789@gcp-sa-gkemulticloud.iam.gserviceaccount.com".
Please make sure the role has a trust policy allowing the GCP service agent to
assume it: WebIdentityErr failed to retrieve credentials
Para solucionar el problema, sigue los pasos en Crea un rol de API de Anthos Multi-Cloud. Cuando vuelvas a crear el rol con el mismo nombre y los mismos permisos, puedes volver a intentar el comando.
¿Qué sigue?
- Si necesitas asistencia adicional, comunícate con Atención al cliente de Cloud.