View a markdown version of this page

Solución de problemas de los clústeres locales de Amazon EKS en AWS Outposts configurados con el almacén de instancias de EC2 - Amazon EKS

Ayude a mejorar esta página

Para contribuir a esta guía del usuario, elija el enlace Edit this page on GitHub que se encuentra en el panel derecho de cada página.

Solución de problemas de los clústeres locales de Amazon EKS en AWS Outposts configurados con el almacén de instancias de EC2

En este tema, se tratan los errores habituales que pueden aparecer al usar clústeres locales de Amazon EKS en AWS Outposts configurados con el almacén de instancias de EC2 y cómo solucionarlos.

Si aparece el siguiente error después de ejecutar aws eks update-kubeconfig:

Either parameter --cluster-name or --cluster-id must be specified.

O bien:

couldn't get current server API group list: getting credentials: exec: executable aws failed with exit code 1

Verifique que kubeconfig (~/.kube/config) especifique --cluster-name en los argumentos exec, en lugar de --cluster-id:

      args:
        - --region
        - region-code
        - eks
        - get-token
        - --cluster-name
        - my-cluster
        - --output
        - json
      command: aws

Si los nodos no aparecen al ejecutar kubectl get nodes:

  1. Compruebe los registros kubelet en el nodo. Acceda al nodo con SSM o SSH y ejecute:

    systemctl status kubelet -l

  2. Compruebe si hay errores no autorizados. Los errores no autorizados pueden indicar la falta de permisos de rol de nodo o problemas con el ConfigMap de aws-auth. Verifique que el rol de instancia del nodo esté correctamente asignado en el ConfigMap de aws-auth.

  3. Compruebe el estado de la CSR. Compruebe que se haya aprobado la solicitud de firma del certificado del nodo:

    kubectl get csr

    Si el estado de la CSR es Pending, apruébela:

    kubectl certificate approve node-csr-EXAMPLE

Si el clúster pasa al estado ERROR:

  • Capacidad insuficiente: verifique que el Outpost tenga suficiente capacidad virtualizada para 6 instancias del plano de control (3 etcd + 3 servidores de la API) de los tipos de instancias especificados. Los tipos de instancias deben estar establecidos en su Outpost.

  • No se puede cumplir con la topología de distribución: si especificó un spreadLevel de host, verifique que al menos 3 hosts estén configurados con el tipo de instancia elegido. Si especificó rack, verifique que al menos 3 bastidores tengan hosts con el tipo de instancia elegido.

  • Problemas con las subredes: verifique que las subredes que especificó se encuentren en la zona de disponibilidad a la que está destinado el Outpost y que cada subred tenga al menos 3 direcciones IP disponibles. Consulte Creación de una VPC y subredes para clústeres locales de Amazon EKS en AWS Outposts configurados con el almacén de instancias de EC2.

Si el clúster permanece en el estado UPDATING durante una actualización de la versión de Kubernetes o de la versión de la plataforma:

  • Capacidad insuficiente: durante las actualizaciones, las instancias del plano de control se eliminan antes de la reinstanciación. Si otra carga de trabajo consume la capacidad liberada antes de poder aprovisionar la instancia de reemplazo, la actualización se detiene. Verifique que el Outpost tenga capacidad disponible para los tipos de instancias del plano de control.

Si pierde la capacidad de efectuar las operaciones de la API de Kubernetes y el Outpost se desconecta:

  • etcd puede haber perdido cuórum. Esto ocurre si más de una instancia de etcd deja de estar disponible durante una desconexión.

  • Las cargas de trabajo que ya están en ejecución continúan funcionando, pero las operaciones de la API de Kubernetes no están disponibles.

  • Cuando se restablezca la conectividad, Amazon EKS recuperará el estado del clúster a partir de la instantánea etcd más reciente.

Contacte con AWS Support Center.