Solución de problemas con los clústeres y nodos de Amazon EKS

En este capítulo se tratan algunos errores habituales que pueden aparecer al utilizar Amazon EKS y cómo solucionarlos. Si necesita solucionar problemas en áreas específicas de Amazon EKS, consulte los temas aparte Solución de problemas de IAM, Solución de problemas del conector de Amazon EKS y Troubleshooting for ADOT using EKS Add-Ons.

Para obtener más información sobre la solución de problemas, consulte el contenido del Centro de conocimientos sobre Amazon Elastic Kubernetes Service en AWS re:Post.

Capacidad insuficiente

Si aparece el siguiente error al intentar crear un clúster de Amazon EKS, significa que una de las zonas de disponibilidad que ha especificado no tiene capacidad suficiente para admitir un clúster.

Cannot create cluster 'example-cluster' because region-1d, the targeted Availability Zone, does not currently have sufficient capacity to support the cluster. Retry and choose from these Availability Zones: region-1a, region-1b, region-1c

Intente crear de nuevo el clúster con subredes de la VPC de clúster alojadas en las zonas de disponibilidad indicadas en el mensaje de error.

Hay zonas de disponibilidad en las que un clúster no puede residir. Compare las zonas de disponibilidad en las que se encuentran las subredes con la lista de zonas de disponibilidad en Requisitos y consideraciones de subredes.

Los nodos no pueden unirse al clúster

Hay algunos motivos que suelen impedir que los nodos se unan al clúster:

Para identificar y solucionar problemas de causas comunes que impiden que los nodos de trabajo se unan a un clúster, puede usar el manual de procedimientos AWSSupport-TroubleshootEKSWorkerNode. Para obtener más información, consulte AWSSupport-TroubleshootEKSWorkerNode en la Referencia del manual de procedimientos de AWS Systems Manager Automation.

Acceso denegado o no autorizado (kubectl)

Si aparece uno de los siguientes errores al ejecutar los comandos de kubectl, eso significa que su kubectl no está configurado correctamente para Amazon EKS o las credenciales para la entidad principal de IAM (rol u usuario) que utiliza no están asignadas a un nombre de usuario de Kubernetes con suficientes permisos para los objetos de Kubernetes en su clúster de Amazon EKS.

Esto podría deberse a una de las siguientes razones:

Si instala y configura la AWS CLI, puede configurar las credenciales de IAM que utiliza. Para obtener más información, consulte Configurar la AWS CLI, en la Guía del usuario de la interfaz de línea de comandos de AWS. También puede configurar kubectl para utilizar un rol de IAM si asume un rol de IAM para acceder a los objetos de Kubernetes en su clúster. Para obtener más información, consulte Conexión de kubectl a un clúster de EKS mediante la creación de un archivo kubeconfig.

hostname doesn’t match

La versión de Python de su sistema debe ser 2.7.9 o posterior. En caso contrario, se producirán errores hostname doesn’t match en las llamadas de la AWS CLI a Amazon EKS. Para obtener más información, consulte ¿Qué significan los errores “el nombre del host no coincide”? en Preguntas frecuentes sobre las solicitudes de Python.

getsockopt: no route to host

Docker se ejecuta en el rango de CIDR 172.17.0.0/16 en los clústeres de Amazon EKS. Le recomendamos que las subredes de la VPC de su clúster no se superpongan. De lo contrario, recibirá el siguiente error:

Error: : error upgrading connection: error dialing backend: dial tcp 172.17.<nn>.<nn>:10250: getsockopt: no route to host

Instances failed to join the Kubernetes cluster

Si aparece el error Instances failed to join the Kubernetes cluster en la AWS Management Console, asegúrese de que el acceso privado al punto de conexión del clúster esté habilitado o de que haya configurado correctamente los bloques de CIDR para el acceso público al punto de conexión. Para obtener más información, consulte Control del acceso de la red al punto de conexión del servidor de API del clúster.

Códigos de error del grupo de nodos administrado

Si el grupo de nodos administrado encuentra un problema de estado del hardware, Amazon EKS devuelve un código de error para ayudarlo a diagnosticar el problema. Estas comprobaciones de estado no detectan problemas de software porque se basan en comprobaciones de estado de Amazon EC2. En la siguiente lista se describen los códigos de error.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: eks:node-manager
rules:
- apiGroups:
  - ''
  resources:
  - pods
  verbs:
  - get
  - list
  - watch
  - delete
- apiGroups:
  - ''
  resources:
  - nodes
  verbs:
  - get
  - list
  - watch
  - patch
- apiGroups:
  - ''
  resources:
  - pods/eviction
  verbs:
  - create

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: eks:node-manager
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: eks:node-manager
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: eks:node-manager

kubectl describe clusterrole eks:node-manager

kubectl describe clusterrolebinding eks:node-manager

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: eks:node-manager
rules:
- apiGroups:
  - ''
  resources:
  - pods
  verbs:
  - get
  - list
  - watch
  - delete
- apiGroups:
  - ''
  resources:
  - nodes
  verbs:
  - get
  - list
  - watch
  - patch
- apiGroups:
  - ''
  resources:
  - pods/eviction
  verbs:
  - create
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: eks:node-manager
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: eks:node-manager
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: eks:node-manager

kubectl apply -f eks-node-manager-role.yaml

Not authorized for images

Una posible causa de un mensaje de error Not authorized for images es el uso de una AMI privada de Windows de Amazon EKS para lanzar grupos de nodosWindows administrados. Tras lanzar nuevas AMI de Windows, AWS convierte en privadas las AMI de más de cuatro meses de antigüedad, por lo que ya no se puede acceder a ellas. Si el grupo de nodos administrado utiliza una AMI de Windows privada, considere actualizar el grupo de nodos administrados de Windows. Si bien no podemos garantizar que podamos proporcionar acceso a las AMI que se han convertido en privadas, puede solicitar el acceso enviando un ticket a AWS Support. Para obtener más información, consulte Parches en la Guía del usuario de Amazon EC2.

El nodo está en estado NotReady

Si el nodo entra en estado NotReady, es probable que esto indique que el nodo está en mal estado y no está disponible para programar nuevos Pods. Esto puede ocurrir por varios motivos, como que el nodo carezca de recursos suficientes para la CPU, la memoria o el espacio disponible en el disco.

En el caso de las AMI de Windows optimizadas para Amazon EKS, no hay reservas para los recursos de cómputos especificados de forma predeterminada en la configuración de kubelet. Para evitar problemas de recursos, puede reservar recursos de cómputos para los procesos del sistema proporcionando valores de configuración de kube-reserved o system-reserved al kubelet. Para ello, utilice el parámetro de línea de comandos -KubeletExtraArgs del script de arranque. Para obtener más información, consulte Reservar recursos de cómputos para los daemons del sistema en la documentación de Kubernetes y los Parámetros de configuración del script de arranque en esta guía del usuario.

Herramienta de recopilación de registros de CNI

El Amazon VPC CNI plugin for Kubernetes de tiene su propio script de resolución de problemas que está disponible en los nodos en /opt/cni/bin/aws-cni-support.sh. Puede utilizar el script a fin de recopilar registros de diagnóstico para casos de soporte y solución de problemas general.

Utilice el siguiente comando para ejecutar el script en su nodo:

sudo bash /opt/cni/bin/aws-cni-support.sh

curl -O https://raw.githubusercontent.com/awslabs/amazon-eks-ami/master/log-collector-script/linux/eks-log-collector.sh
sudo bash eks-log-collector.sh

El script recopila la siguiente información de diagnóstico: La versión de CNI que ha implementado puede ser anterior a la versión del script.

      This is version 0.6.1. New versions can be found at https://github.com/awslabs/amazon-eks-ami

Trying to collect common operating system logs...
Trying to collect kernel logs...
Trying to collect mount points and volume information...
Trying to collect SELinux status...
Trying to collect iptables information...
Trying to collect installed packages...
Trying to collect active system services...
Trying to collect Docker daemon information...
Trying to collect kubelet information...
Trying to collect L-IPAMD information...
Trying to collect sysctls information...
Trying to collect networking information...
Trying to collect CNI configuration information...
Trying to collect running Docker containers and gather container data...
Trying to collect Docker daemon logs...
Trying to archive gathered information...

	Done... your bundled logs are located in /var/log/eks_i-0717c9d54b6cfaa19_2020-03-24_0103-UTC_0.6.1.tar.gz

La información de diagnóstico se recopila y se almacena en:

/var/log/eks_i-0717c9d54b6cfaa19_2020-03-24_0103-UTC_0.6.1.tar.gz

La red de tiempo de ejecución del contenedor no está lista

Puede recibir un error Container runtime network not ready y errores de autorización similares a los siguientes:

4191 kubelet.go:2130] Container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized
4191 reflector.go:205] k8s.io/kubernetes/pkg/kubelet/kubelet.go:452: Failed to list *v1.Service: Unauthorized
4191 kubelet_node_status.go:106] Unable to register node "ip-10-40-175-122.ec2.internal" with API server: Unauthorized
4191 reflector.go:205] k8s.io/kubernetes/pkg/kubelet/kubelet.go:452: Failed to list *v1.Service: Unauthorized

Esto puede deberse a una de las siguientes razones:

Tiempo de espera de protocolo de enlace TLS

Cuando un nodo no puede establecer una conexión con el punto de conexión del servidor de la API público, podría ver un error similar al siguiente.

server.go:233] failed to run Kubelet: could not init cloud provider "aws": error finding instance i-1111f2222f333e44c: "error listing AWS instances: \"RequestError: send request failed\\ncaused by: Post  net/http: TLS handshake timeout\""

El proceso kubelet reaparecerá continuamente y probará el punto de conexión del servidor de API. El error también puede producirse temporalmente durante cualquier procedimiento que realice una actualización sucesiva del clúster en el plano de control, como un cambio de configuración o una actualización de versión.

Para resolver el problema, verifique la tabla de enrutamiento y los grupos de seguridad para asegurarse de que el tráfico de los nodos puede llegar al punto de conexión público.

InvalidClientTokenId

Si está utilizando roles de IAM para cuentas de servicio de un Pod o DaemonSet implementado en un clúster de la región de China de AWS y no ha establecido la variable de entorno AWS_DEFAULT_REGION en la especificación, el Pod o el DaemonSet pueden recibir el siguiente error:

An error occurred (InvalidClientTokenId) when calling the GetCallerIdentity operation: The security token included in the request is invalid

Para resolver el problema, debe agregar la variable de entorno AWS_DEFAULT_REGION a la especificación del Pod o DaemonSet, tal y como se muestra en el siguiente ejemplo de especificación de un Pod.

apiVersion: v1
kind: Pod
metadata:
  name: envar-demo
  labels:
    purpose: demonstrate-envars
spec:
  containers:
  - name: envar-demo-container
    image: gcr.io/google-samples/node-hello:1.0
    env:
    - name: AWS_DEFAULT_REGION
      value: "region-code"

Los grupos de nodos deben coincidir con la versión de Kubernetes antes de actualizar el plano de control

Antes de actualizar un plano de control con una nueva versión de Kubernetes, la versión secundaria de los nodos administrados y de Fargate en su clúster debe ser la misma que la de la versión actual de su plano de control. La API update-cluster-version de Amazon EKS rechazará las solicitudes hasta que usted actualice todos los nodos administrados de Amazon EKS a la versión del clúster actual. Amazon EKS proporciona las API para actualizar los nodos administrados. Para obtener información sobre la actualización de la versión de Kubernetes del grupo de nodos administrados, consulte Actualización de un grupo de nodos administrados para un clúster. Para actualizar la versión de un nodo de Fargate, elimine el pod que representa el nodo y vuelva a implementar el pod después de actualizar el plano de control. Para obtener más información, consulte Actualización del clúster existente a la nueva versión de Kubernetes.

Al lanzar muchos nodos, hay errores de Too Many Requests

Si lanza muchos nodos al mismo tiempo, es posible que vea un mensaje de error en Datos de usuario de Amazon EC2registros de ejecución que dice Too Many Requests. Esto puede ocurrir porque el plano de control está sobrecargado con llamadas describeCluster. La sobrecarga da como resultado una limitación, es decir, que los nodos no ejecutan el script de arranque ni se unen por completo al clúster.

Asegúrese de que los argumentos --apiserver-endpoint, --b64-cluster-ca y --dns-cluster-ip se estén pasando al script de arranque del nodo. Al incluir estos argumentos, no es necesario que el script de arranque haga una llamada describeCluster, lo que ayuda a evitar que el plano de control se sobrecargue. Para obtener más información, consulte Proporcione datos de usuario a fin de pasar argumentos al archivo bootstrap.sh incluido con una AMI optimizada Linux/Bottlerocket para Amazon EKS.

Respuesta de error no autorizada HTTP 401 en solicitudes del servidor API de Kubernetes

Verá estos errores si el token de cuenta de servicio de un Pod’s ha caducado en un clúster.

El servidor de API de Kubernetes de los clústeres de Amazon EKS rechaza solicitudes con tokens de más de 90 días. En versiones anteriores de Kubernetes, los tokens no tenían caducidad. Esto significa que los clientes que confían en estos tokens deben actualizarlos en una hora. Para evitar que el servidor API de Kubernetes rechace su solicitud debido a un token no válido, la versión del SDK de cliente de Kubernetes utilizada por la carga de trabajo debe ser la misma o posterior a las siguientes versiones:

Puede identificar todos los Pods existentes de tu clúster que utilizan tokens obsoletos. Para obtener más información, consulte Tokens de cuenta de servicio.

La versión de la plataforma Amazon EKS está más de dos versiones por detrás de la versión de plataforma actual

Esto puede ocurrir cuando Amazon EKS no puede actualizar automáticamente la versión de la plataforma del clúster. Aunque hay muchas causas para esto, se presentan algunas de las causas más comunes. Si alguno de estos problemas se aplica a su clúster, es posible que siga funcionando. Amazon EKS no actualizará la versión de la plataforma.

Problema

El rol de IAM de clúster se eliminó: este rol se especificó cuando se creó el clúster. Puede ver qué rol se ha especificado con el siguiente comando. Reemplace my-cluster por el nombre de su clúster.

aws eks describe-cluster --name my-cluster --query cluster.roleArn --output text | cut -d / -f 2

Un ejemplo de salida sería el siguiente.

eksClusterRole

Solución

Cree un nuevo rol de IAM de clúster con el mismo nombre.

Problema

Se eliminó una subred especificada durante la creación del clúster: las subredes que se usarían con el clúster se especificaron durante la creación del clúster. Puede ver qué subredes se especificaron con el siguiente comando. Reemplace my-cluster por el nombre de su clúster.

aws eks describe-cluster --name my-cluster --query cluster.resourcesVpcConfig.subnetIds

Un ejemplo de salida sería el siguiente.

[
"subnet-EXAMPLE1",
"subnet-EXAMPLE2"
]

Solución

Confirme si los ID de subred existen en su cuenta.

vpc_id=$(aws eks describe-cluster --name my-cluster --query cluster.resourcesVpcConfig.vpcId --output text)
aws ec2 describe-subnets --filters "Name=vpc-id,Values=$vpc_id" --query "Subnets[*].SubnetId"

Un ejemplo de salida sería el siguiente.

[
"subnet-EXAMPLE3",
"subnet-EXAMPLE4"
]

Si los ID de subredes devueltos en la salida no coinciden con los ID de subredes que se especificaron cuando se creó el clúster y desea que Amazon EKS actualice el clúster, debe cambiar las subredes utilizadas por el clúster. Esto se debe a que, si especificó más de dos subredes cuando creó el clúster, Amazon EKS seleccionará aleatoriamente las subredes que especificó para crear nuevas interfaces de red elástica en ellas. Estas interfaces de red permiten que el plano de control se comunique con los nodos. Amazon EKS no actualizará el clúster si la subred que selecciona no existe. No tiene control sobre las subredes que especificó en la creación del clúster en las que Amazon EKS elige crear una nueva interfaz de red.

Cuando inicia una actualización de la versión Kubernetes del clúster, la actualización puede fallar por el mismo motivo.

Problema

Se eliminó un grupo de seguridad especificado durante la creación del clúster: si especificó grupos de seguridad durante la creación del clúster, puede ver sus ID con el siguiente comando. Reemplace my-cluster por el nombre de su clúster.

aws eks describe-cluster --name my-cluster --query cluster.resourcesVpcConfig.securityGroupIds

Un ejemplo de salida sería el siguiente.

[
    "sg-EXAMPLE1"
]

Si se devuelve [], no se especificó ningún grupo de seguridad cuando se creó el clúster y el problema no es que falte un grupo de seguridad. Si se devuelven grupos de seguridad, confirme que los grupos de seguridad existen en su cuenta.

Solución

Confirme si estos grupos de seguridad existen en su cuenta.

vpc_id=$(aws eks describe-cluster --name my-cluster --query cluster.resourcesVpcConfig.vpcId --output text)
aws ec2 describe-security-groups --filters "Name=vpc-id,Values=$vpc_id" --query "SecurityGroups[*].GroupId"

Un ejemplo de salida sería el siguiente.

[
"sg-EXAMPLE2"
]

Si los ID de grupos de seguridad devueltos en la salida no coinciden con los ID de grupos de seguridad que se especificaron cuando se creó el clúster y desea que Amazon EKS actualice el clúster, debe cambiar los grupos de seguridad utilizados por el clúster. Amazon EKS no actualizará un clúster si los ID de grupos de seguridad especificados en la creación del clúster no existen.

Cuando inicia una actualización de la versión Kubernetes del clúster, la actualización puede fallar por el mismo motivo.

Preguntas frecuentes sobre el estado de los clústeres y los códigos de error con rutas de resolución

Amazon EKS detecta problemas con los clústeres de EKS y la infraestructura del clúster y los almacena en el estado del clúster. Puede detectar, solucionar y abordar los problemas del clúster más rápido con la ayuda de la información sobre el estado del clúster. Esto le permite crear entornos de aplicación más seguros y actualizados. Además, es posible que no pueda actualizar a versiones más recientes de Kubernetes o que Amazon EKS no pueda instalar actualizaciones de seguridad en un clúster degradado debido a problemas con la infraestructura necesaria o la configuración del clúster. Amazon EKS puede tardar 3 horas en detectar problemas o detectar que se resolvió un problema.

El estado de un clúster de Amazon EKS es una responsabilidad compartida entre Amazon EKS y sus usuarios. Usted es responsable de la infraestructura previa de los roles de IAM y las subredes de Amazon VPC, así como de cualquier otra infraestructura necesaria que deba proporcionarse con antelación. Amazon EKS detecta cambios en la configuración de esta infraestructura y del clúster.

Para acceder al estado de su clúster en la consola de Amazon EKS, busque una sección llamada Problemas del estado en la pestaña Descripción general de la página de detalles del clúster de Amazon EKS. Estos datos también estarán disponibles al llamar a la acción DescribeCluster en la API de EKS, por ejemplo, desde AWS Command Line Interface.

Las primeras dos columnas son las que se necesitan para los valores de respuesta de la API. El tercer campo del objeto Problemas en el estado del clúster es resourceIds, cuya devolución depende del tipo de problema.