Solucionar problemas habituales

En esta página se explica cómo resolver problemas habituales con GKE en AWS.

Si necesitas más ayuda, ponte en contacto con el servicio de atención al cliente de Cloud.

Mensajes de error habituales

En las siguientes secciones se explican las causas y las soluciones de algunos mensajes de error habituales.

El servidor no tiene un recurso

Pueden producirse errores como error: the server doesn't have a resource type "services" cuando un clúster no tiene grupos de nodos en ejecución o cuando la pasarela Connect no puede conectarse a un grupo de nodos. Para comprobar el estado de tus grupos de nodos, ejecuta el siguiente comando:

gcloud container aws node-pools list \
    --cluster-name CLUSTER_NAME \
    --location LOCATION

Haz los cambios siguientes:

  • CLUSTER_NAME: el nombre de tu clúster
  • LOCATION: la Google Cloud ubicación que gestiona tu clúster

El resultado incluye el estado de los grupos de nodos del clúster. Si no aparece ningún grupo de nodos, crea uno.

Usuario prohibido

Se produce el siguiente error 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

Puedes configurar usuarios adicionales pasando la marca --admin-users al crear un clúster.

Si usas la pasarela Connect y no puedes conectarte a tu clúster, prueba a seguir estos pasos:

  1. Obtén los usuarios autorizados de tu clúster.

    gcloud container aws clusters describe CLUSTER_NAME \
    --format 'value(authorization.admin_users)'

    Sustituye CLUSTER_NAME por el nombre de tu clúster.

    El resultado incluye los nombres de usuario con acceso de administrador al clúster. Por ejemplo:

    {'username': 'administrator@example.com'}

  2. Obtiene el nombre de usuario autenticado actualmente con la CLI de Google Cloud.

    gcloud config get-value account

    El resultado incluye la cuenta autenticada con la CLI de Google Cloud. Si la salida de gcloud containers aws clusters describe y gcloud config get-value account no coincide, ejecuta gcloud auth login y autentícate como el nombre de usuario con acceso de administrador al clúster.

Problemas con los comandos de kubectl

En las siguientes secciones se explica cómo resolver problemas con comandos de kubectl que no responden o fallan.

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, lo más probable es que aún no hayas creado un pool de nodos. De forma predeterminada, GKE on AWS genera archivos kubeconfig que usan la pasarela de Connect como endpoint accesible a través de Internet. Para que esto funcione, la implementación de gke-connect-agent debe ejecutarse en un grupo de nodos del 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, las solicitudes a connectgateway.googleapis.com fallarán con un error 404.cannot find active connections for cluster

En 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 necesita un pool de nodos. Si el comando kubectl no responde, consulta los registros del componente 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 y mostrar el mensaje error: unable to upgrade connection al usar Conectar pasarela. Esta es una limitación al usar la pasarela Connect como endpoint del servidor de la API de Kubernetes.

Para solucionar este problema, usa un kubeconfig que especifique el endpoint privado del clúster. Para obtener instrucciones sobre cómo acceder al clúster a través de su endpoint privado, consulta el artículo Configurar el acceso a clústeres para kubectl.

kubectl logs falla con el error remoto: tls: internal error

Este problema puede producirse si falta un permiso en el rol de la API Control Plane. Por ejemplo, esto puede ocurrir si a tu rol de AWS le falta el permiso ec2:DescribeDhcpOptions. En este caso, no se pueden aprobar las solicitudes de firma de certificados de los nodos y el nodo de trabajo no tiene un certificado válido.

Para determinar si este es el problema, puedes comprobar si hay solicitudes de firma de certificados pendientes que no se hayan aprobado con este comando:

kubectl get csr

Para resolver este problema, verifica que tu rol de AWS cumpla los requisitos.

Solución de problemas genéricos de kubectl

Si usas la pasarela de conexión:

  • Asegúrate de que has habilitado Connect Gateway en tu Google Cloud proyecto:

    gcloud services enable connectgateway.googleapis.com

  • En los clústeres con una versión de Kubernetes anterior a la 1.25, asegúrate de que haya al menos un grupo de nodos de Linux en ejecución y de que gke-connect-agent esté en funcionamiento. Para obtener más información, consulta el artículo Solucionar problemas de conexión de clústeres.

  • En los clústeres con una versión de Kubernetes 1.25 o posterior, consulta los gke-connect-agentregistros con Cloud Logging.

El servicio de Kubernetes (LoadBalancer) o el Ingress de Kubernetes no funcionan

Si has creado balanceadores de carga elásticos (ELB, NLB o ALB) de AWS, pero no funcionan como esperabas, puede deberse a problemas con el etiquetado de subredes. Para obtener más información, consulta Subredes de balanceador de carga.

Los pods de los nodos Arm fallan

El problema siguiente se produce cuando se despliega un pod en un nodo Arm, pero la imagen de contenedor no se ha compilado para la arquitectura Arm.

Para identificar el problema, sigue estos pasos:

  1. Obtén el estado de tus pods:

    kubectl get pods

  2. Obtén los registros del pod que falla:

    kubectl logs POD_NAME

    Sustituye POD_NAME por el nombre del pod que falla.

    El mensaje de error de los registros de tu pod es similar al siguiente:

    exec ./hello-app: exec format error

Para solucionar este problema, asegúrese de que su imagen de contenedor sea compatible con la arquitectura Arm. Te recomendamos que crees imágenes de varias arquitecturas.

No se puede eliminar el clúster

Si recibes un error similar al siguiente al intentar eliminar un clúster, es posible que tu rol de API de GKE Multi-Cloud 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 que se indican en Crear un rol de API de GKE Multi-Cloud. Cuando vuelvas a crear el rol con el mismo nombre y permisos, podrás volver a probar el comando.

Siguientes pasos