**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 del modo automático de EKS 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: + Utilice un recurso `NodeDiagnostic` de Kubernetes para recuperar registros de nodos mediante el [Agente de supervisión de nodos](#auto-node-monitoring-agent). Para ver más pasos, consulte [Recuperación de los registros de nodos de un nodo administrado mediante kubectl y S3](auto-get-logs.md). + Usa un recurso `NodeDiagnostic` de Kubernetes para capturar el tráfico de red en un nodo. Para ver más pasos, consulte [Captura del tráfico de red un nodo administrado mediante kubectl y S3](auto-get-tcpdump.md). + Utilice el comando AWS de la CLI de `get-console-output` EC2 para recuperar la salida de la consola de los nodos. Para ver más pasos, consulte [Obtenga la salida de la consola de una instancia administrada por EC2 mediante la CLI de AWS EC2](#auto-node-console). + Utilice *contenedores de depuración* de Kubernetes para recuperar registros de nodos. Para ver más pasos, consulte [Obtenga los registros de los nodos mediante *contenedores de depuración* y la `kubectl` CLI](#auto-node-debug-logs). **nota** El modo automático de EKS utiliza instancias administradas por EC2. No puede acceder directamente a las instancias administradas por EC2, ni siquiera mediante SSH. Es posible que tenga los siguientes problemas con soluciones específicas para los componentes del modo automático de EKS: + Los pods están atascados en el estado `Pending` y no están programados en los nodos del modo automático. Para obtener soluciones, consulte [Solución de problemas de pods que no se pueden programar en el nodo del modo automático](#auto-troubleshoot-schedule). + Instancias administradas de EC2 que no se unen al clúster como nodos de Kubernetes. Para obtener soluciones, consulte [Solución de problemas de un nodo que no se une al clúster](#auto-troubleshoot-join). + Errores y problemas con los `NodePools`, `PersistentVolumes` y `Services` que utilizan los controladores incluidos en el modo automático de EKS. Para obtener soluciones, consulte [Solución de problemas de los controladores incluidos en el modo automático](#auto-troubleshoot-controllers). + La seguridad mejorada de los pods impide compartir volúmenes entre pods. Para obtener soluciones, consulte [Cómo compartir volúmenes entre pods](#auto-troubleshoot-share-pod-volumes). Puede utilizar los siguientes métodos para solucionar problemas de los componentes del modo automático de EKS: + [Obtenga la salida de la consola de una instancia administrada por EC2 mediante la CLI de AWS EC2](#auto-node-console) + [Obtenga los registros de los nodos mediante *contenedores de depuración* y la `kubectl` CLI](#auto-node-debug-logs) + [Consulte los recursos asociados al modo automático de EKS en la consola de AWS](#auto-node-ec2-web) + [Consulte los errores de IAM en la cuenta de AWS](#auto-node-iam) + [Detección de problemas de conectividad de los nodos con el `VPC Reachability Analyzer`](#auto-node-reachability) ## 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 [Detección de los problemas de estado de los nodos y reparación automática de los nodos](node-health.md). ## 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. 1. Confirme que `kubectl` se encuentra instalado y conectado al clúster 1. (Opcional) Utilice el nombre de una implementación de Kubernetes para enumerar los pods asociados. ``` kubectl get pods -l app= ``` 1. Utilice el nombre del pod de Kubernetes para determinar el ID de instancia de EC2 del nodo asociado. ``` kubectl get pod -o wide ``` 1. Utilice el ID de instancia de EC2 para recuperar la salida de la consola. ``` aws ec2 get-console-output --instance-id --latest --output text ``` ## 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](auto-get-logs.md). 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. 1. Lance un contenedor de depuración. El siguiente comando usa `i-01234567890123456` para el ID de instancia del nodo, `-it` asigna `tty` y adjunta `stdin` para el uso interactivo y utiliza el perfil `sysadmin` del archivo kubeconfig. ``` kubectl debug node/i-01234567890123456 -it --profile=sysadmin --image=public.ecr.aws/amazonlinux/amazonlinux:2023 ``` Un ejemplo de salida sería el siguiente. ``` Creating debugging pod node-debugger-i-01234567890123456-nxb9c with container debugger on node i-01234567890123456. If you don't see a command prompt, try pressing enter. bash-5.2# ``` 1. Desde el intérprete de comandos, ahora puede instalar `util-linux-core`, que proporciona el comando `nsenter`. Use `nsenter` para ingresar el espacio de nombres de montaje del PID 1 (`init`) en el host y ejecutar el comando `journalctl` para transmitir los registros desde el `kubelet`: ``` yum install -y util-linux-core nsenter -t 1 -m journalctl -f -u kubelet ``` 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. + [Volúmenes de EBS](https://console.aws.amazon.com/ec2/home#Volumes) + Para ver los volúmenes del modo automático de EKS, busque la clave de etiqueta `eks:eks-cluster-name` + [Balanceadores de carga](https://console.aws.amazon.com/ec2/home#LoadBalancers) + Para ver los equilibradores de carga del modo automático de EKS, busque la clave de etiqueta `eks:eks-cluster-name` + [Instancias de EC2](https://console.aws.amazon.com/ec2/home#Instances) + Para ver las instancias del modo automático de EKS, busque la clave de etiqueta `eks:eks-cluster-name` ## Consulte los errores de IAM en la cuenta de AWS 1. Vaya a la consola de CloudTrail 1. Seleccione “Historial de eventos” en el panel de navegación izquierdo 1. Aplique filtros de códigos de error: + AccessDenied + UnauthorizedOperation + InvalidClientTokenId 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](associate-workload.md). ## 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: 1. Ejecute `kubectl get nodeclaim` para buscar `NodeClaims` con `Ready = False`. ``` kubectl get nodeclaim ``` 1. Ejecute `kubectl describe nodeclaim ` y busque en **Estado** cualquier problema que impida que el nodo se una al clúster. ``` kubectl describe nodeclaim ``` **Mensajes de error comunes:** `Error getting launch template configs` Es posible que reciba este error si configura etiquetas personalizadas en `NodeClass` con los permisos predeterminados del rol de IAM del clúster. Consulte [Más información sobre las identidades y el acceso en el modo automático de EKS](auto-learn-iam.md). `Error creating fleet` Es posible que exista algún problema de autorización al hacer la llamada `RunInstances` desde la API de EC2. Compruebe si hay errores en AWS CloudTrail y consulte en [Rol de IAM del clúster del modo automático de Amazon EKS](auto-cluster-iam-role.md) los permisos de IAM requeridos. ### Detección de problemas de conectividad de los nodos con el `VPC Reachability Analyzer` **nota** Se le cobrará por cada análisis que ejecute el Analizador de accesibilidad de VPC. Para obtener más información sobre precios, consulte [Precios de Amazon VPC](https://aws.amazon.com/vpc/pricing/). 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](https://docs.aws.amazon.com/vpc/latest/reachability/what-is-reachability-analyzer.html) 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: + **ID de instancia** de un nodo que no puede unirse al clúster + Dirección IP del **punto de conexión del servidor de API de Kubernetes** 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 Consola de administración de AWS. 1. Haga clic en “Crear y analizar ruta”. 1. Proporcione un nombre para el análisis (por ejemplo, “Error en la unión de nodos”). 1. En “Tipo de origen” seleccione “Instancias”. 1. Ingrese el ID de instancia del nodo que falla como “Origen”. 1. En “Destino de ruta”, seleccione “Dirección IP”. 1. Ingrese una de las direcciones IP del servidor de API como “Dirección de destino”. 1. Amplíe la sección “Configuración de encabezados de paquetes adicionales”. 1. Ingrese 443 como “Puerto de destino”. 1. Seleccione “Protocolo” como TCP si aún no está seleccionado. 1. Haga clic en “Crear y analizar ruta”. 1. El análisis puede tardar unos minutos en completarse. Si los resultados del análisis indican un error de accesibilidad, indicarán dónde se produjo el error en la ruta de la red para que pueda resolver el problema. ## 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" ``` ## Visualización de los eventos de Karpenter en los registros del plano de control En el caso de los clústeres de EKS con los registros del plano de control habilitados, puede obtener información sobre las acciones y el proceso de toma de decisiones de Karpenter consultándolos. Esto puede resultar especialmente útil para solucionar problemas del modo automático de EKS relacionados con el aprovisionamiento, el escalado y la terminación de los nodos. Para ver los eventos relacionados con Karpenter, utilice la siguiente consulta de CloudWatch Logs Insights: ``` fields @timestamp, @message | filter @logStream like /kube-apiserver-audit/ | filter @message like 'DisruptionBlocked' or @message like 'DisruptionLaunching' or @message like 'DisruptionTerminating' or @message like 'DisruptionWaitingReadiness' or @message like 'Unconsolidatable' or @message like 'FailedScheduling' or @message like 'NoCompatibleInstanceTypes' or @message like 'NodeRepairBlocked' or @message like 'Disrupted' or @message like 'Evicted' or @message like 'FailedDraining' or @message like 'TerminationGracePeriodExpiring' or @message like 'TerminationFailed' or @message like 'FailedConsistencyCheck' or @message like 'InsufficientCapacityError' or @message like 'UnregisteredTaintMissing' or @message like 'NodeClassNotReady' | sort @timestamp desc ``` Esta consulta filtra [eventos específicos relacionados con Karpenter](https://github.com/kubernetes-sigs/karpenter/blob/main/pkg/events/reason.go) en los registros de auditoría de kube-apiserver. Los eventos incluyen varios estados de interrupción, errores de programación, problemas de capacidad y problemas relacionados con los nodos. Al analizar estos registros, puede comprender mejor lo siguiente: + Por qué Karpenter está tomando ciertas medidas. + Cualquier problema que impida el aprovisionamiento, el escalado o la terminación adecuados de los nodos. + Posibles problemas de capacidad o compatibilidad con los tipos de instancias. + Eventos del ciclo de vida de los nodos, como interrupciones, expulsiones o terminaciones. Para usar esta consulta, siga estos pasos: 1. Diríjase a la consola de CloudWatch. 1. Seleccione “Logs Insights” en el panel de navegación izquierdo. 1. Elija el grupo de registros para los registros del plano de control de su clúster de EKS. 1. Pegue la consulta en el editor de consultas. 1. Ajuste el intervalo de tiempo según sea necesario. 1. Ejecute la consulta Los resultados le mostrarán una cronología de los eventos relacionados con Karpenter, lo que le ayudará a solucionar problemas y a comprender el comportamiento del modo automático EKS en su clúster. Para revisar las acciones de Karpenter en un nodo específico, puede añadir el siguiente filtro de línea que especifica el ID de la instancia a la consulta antes mencionada: ``` |filter @message like /[.replaceable]`i-12345678910123456`/ ``` **nota** Para utilizar esta consulta, el registro del plano de control debe estar habilitado en el clúster de EKS. Si aún no lo ha hecho, consulte [Envío de los registros del plano de control a Registros de CloudWatch](control-plane-logs.md). ## Solución de problemas de los controladores incluidos en el modo automático Si surge un problema con un controlador, averigüe lo siguiente: + Si los recursos asociados a ese controlador tienen el formato adecuado y son válidos. + Si los recursos RBAC de Kubernetes y AWS IAM están configurados correctamente para el clúster. Para obtener más información, consulte [Más información sobre las identidades y el acceso en el modo automático de EKS](auto-learn-iam.md). ## Recursos relacionados Use estos artículos de AWS re:Post para obtener pasos avanzados de solución de problemas: + [¿Cómo se solucionan los problemas de escalado más comunes en el modo automático de EKS?](https://repost.aws/articles/ARLpQOknr5Rb-w5iAT9sUBpQ) + [¿Cómo soluciono los problemas de aprovisionamiento de grupos de nodos personalizados y clases de nodos en el modo automático de Amazon EKS?](https://repost.aws/articles/ARPcmFS1POTgqPCBdcZFp6BQ) + [¿Cómo soluciono los problemas de los grupos de nodos integrados en el modo automático de EKS con un estado desconocido?](https://repost.aws/en/articles/ARLhrdl45TRASGkvViwtBG0Q)