Solución de problemas del modo automático de 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.

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.

Con el modo automático de EKS, AWS asume más responsabilidad por las instancias de EC2 de la cuenta de AWS. EKS asume la responsabilidad del tiempo de ejecución del contenedor en los nodos, el sistema operativo en los nodos y determinados controladores. Incluye un controlador de almacenamiento en bloque, un controlador de equilibrio de carga y un controlador de computación.

Debe utilizar las API de Kubernetes y AWS para solucionar problemas en los nodos. Puede hacer lo siguiente:

Es posible que tenga los siguientes problemas con soluciones específicas para los componentes del modo automático de EKS:

Puede utilizar los siguientes métodos para solucionar problemas de los componentes del modo automático de EKS:

Agente de supervisión de nodos

El modo automático de EKS incluye el agente de supervisión de nodos de Amazon EKS. Puede utilizar este agente para ver información de solución de problemas y depuración relativa a los nodos. El agente de supervisión de nodos publica events de Kubernetes y conditions de nodos. Para obtener más información, consulte Cómo habilitar la reparación automática de los nodos e investigar los problemas de estado de los nodos.

Obtenga la salida de la consola de una instancia administrada por EC2 mediante la CLI de AWS EC2

Este procedimiento ayuda a solucionar problemas en el arranque o a nivel del kernel.

En primer lugar, debe determinar el ID de la instancia de EC2 asociada a la carga de trabajo. En segundo lugar, utilice AWS CLI para recuperar la salida de la consola.

Obtenga los registros de los nodos mediante contenedores de depuración y la kubectl CLI

La forma recomendada de recuperar los registros de un nodo del modo automático de EKS es utilizar el recurso NodeDiagnostic. Para ver los pasos, consulte Recuperación de los registros de nodos de un nodo administrado mediante kubectl y S3.

Sin embargo, puede transmitir los registros activos desde una instancia mediante el comando kubectl debug node. Este comando lanza un nuevo pod en el nodo que desea depurar y que puede usar de forma interactiva.

Por motivos de seguridad, la imagen del contenedor de Amazon Linux no instala muchos binarios de forma predeterminada. Puede usar el comando yum whatprovides a fin de identificar el paquete que debe instalarse para proporcionar un binario determinado.

yum whatprovides ps

Last metadata expiration check: 0:03:36 ago on Thu Jan 16 14:49:17 2025.
procps-ng-3.3.17-1.amzn2023.0.2.x86_64 : System and process monitoring utilities
Repo        : @System
Matched from:
Filename    : /usr/bin/ps
Provide    : /bin/ps

procps-ng-3.3.17-1.amzn2023.0.2.x86_64 : System and process monitoring utilities
Repo        : amazonlinux
Matched from:
Filename    : /usr/bin/ps
Provide    : /bin/ps

Consulte los recursos asociados al modo automático de EKS en la consola de AWS

Puede utilizar la consola de AWS para ver el estado de los recursos asociados al clúster del modo automático de EKS.

Consulte los errores de IAM en la cuenta de AWS

Busque errores relacionados con el clúster de EKS. Utilice los mensajes de error para actualizar las entradas de acceso de EKS, el rol de IAM del clúster o el rol de IAM del nodo. Es posible que tenga que asociar una nueva política a estos roles con permisos para el modo automático de EKS.

Solución de problemas de pods que no se pueden programar en el nodo del modo automático

Si el estado de los pods es Pending y no se programan en un nodo del modo automático, verifique si el manifiesto de implementación o el pod tiene nodeSelector. Si nodeSelector está presente, asegúrese de que use eks.amazonaws.com/compute-type: auto para programar en los nodos creados con el modo automático de EKS. Para obtener más información sobre las etiquetas de nodos utilizadas por el modo automático de EKS, consulte Cómo controlar si una carga de trabajo se implementa en nodos del modo automático de EKS.

Solución de problemas de un nodo que no se une al clúster

El modo automático de EKS configura automáticamente las nuevas instancias de EC2 con la información correcta para que se unan al clúster, lo que incluye el punto de conexión del clúster y la autoridad de certificación (CA) del clúster. Sin embargo, es posible que estas instancias sigan sin unirse al clúster de EKS como nodo. Ejecute los siguientes comandos para identificar las instancias que no se unieron al clúster:

Mensajes de error comunes:

Detección de problemas de conectividad de los nodos con el VPC Reachability Analyzer

Una de las razones por las que una instancia no se unió al clúster es un problema de conectividad de red que le impide acceder al servidor de API. Para diagnosticar este problema, puede usar el Analizador de accesibilidad de VPC para efectuar un análisis de la conectividad entre un nodo que no puede unirse al clúster y el servidor de API. Necesitará dos datos:

Para obtener el ID de instancia, tendrá que crear una carga de trabajo en el clúster para que el modo automático de EKS lance una instancia de EC2. Esto también crea un objeto NodeClaim en el clúster que tendrá el ID de la instancia. Ejecute kubectl get nodeclaim -o yaml para imprimir todas las NodeClaims del clúster. Cada NodeClaim contiene el ID de instancia como un campo y, de nuevo, en ProviderID:

kubectl get nodeclaim -o yaml

Un ejemplo de salida sería el siguiente.

    nodeName: i-01234567890123456
    providerID: aws:///us-west-2a/i-01234567890123456

Puede determinar el punto de conexión del servidor de API de Kubernetes mediante la ejecución de kubectl get endpoint kubernetes -o yaml. Las direcciones se encuentran en el campo de direcciones:

kubectl get endpoints kubernetes -o yaml

Un ejemplo de salida sería el siguiente.

apiVersion: v1
kind: Endpoints
metadata:
  name: kubernetes
  namespace: default
subsets:
- addresses:
  - ip: 10.0.143.233
  - ip: 10.0.152.17
  ports:
  - name: https
    port: 443
    protocol: TCP

Con estos dos datos, puede efectuar el análisis s. Primero, vaya al Analizador de accesibilidad de VPC en la AWS Management Console.

Cómo compartir volúmenes entre pods

Los nodos del modo automático de EKS se configuran con SELinux en modo de aplicación, lo que proporciona un mayor aislamiento entre los pods que se ejecutan en el mismo nodo. Cuando SELinux está habilitado, a la mayoría de los pods no privilegiados se les aplicará automáticamente su propia etiqueta de seguridad multicategoría (MCS). Esta etiqueta MCS es única para cada pod y está diseñada para garantizar que el proceso de un pod no pueda manipular el proceso de ningún otro pod o del host. Incluso si un pod etiquetado funciona como raíz y tiene acceso al sistema de archivos del host, no podrá manipular los archivos, hacer llamadas confidenciales del sistema desde el host, acceder al tiempo de ejecución del contenedor ni obtener la clave secreta del kubelet.

Por este motivo, es posible que tenga problemas al intentar compartir datos entre pods. Por ejemplo, una PersistentVolumeClaim con el modo de acceso ReadWriteOnce no permitirá que varios pods accedan al volumen simultáneamente.

Para habilitar este uso compartido entre pods, puede usar seLinuxOptions de los pods para configurar la misma etiqueta MCS en esos pods. En este ejemplo, asignamos las tres categorías c123,c456,c789 al pod. Esto no entrará en conflicto con ninguna de las categorías que se asignen automáticamente a los pods en el nodo, ya que solo se les asignarán dos categorías.

securityContext:
  seLinuxOptions:
    level: "s0:c123,c456,c789"

Solución de problemas de los controladores incluidos en el modo automático

Si surge un problema con un controlador, averigüe lo siguiente: