Solución de problemas relacionados con los nodos híbridos

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.

En este tema se tratan algunos errores habituales que pueden aparecer al utilizar los Nodos híbridos de Amazon EKS y cómo solucionarlos. Para obtener información adicional sobre la solución de problemas, consulte Solución de problemas con los clústeres y nodos de Amazon EKS la Etiqueta del Centro de conocimientos para Amazon EKS en AWS re:Post. Si no puede resolver el problema, contacte a AWS Support.

Puede ejecutar el comando nodeadm debug desde los nodos híbridos para comprobar que se cumplen los requisitos de red y credenciales. Para obtener más información acerca del comando nodeadm debug, consulte Referencia de nodeadm de nodos híbridos.

Solución de problemas de instalación de nodos híbridos

Los temas de solución de problemas de esta sección están relacionados con la instalación de las dependencias de los nodos híbridos en los hosts mediante el comando nodeadm install.

Se produjo un error must run as root con el comando de nodeadm

El comando nodeadm install se debe ejecutar con un usuario que tenga privilegios de raíz/sudo en el host. Si ejecuta nodeadm install con un usuario que no tiene privilegios de raíz/sudo, aparecerá el siguiente error en el resultado de nodeadm.

"msg":"Command failed","error":"must run as root"

No se puede conectar a las dependencias

El comando nodeadm install instala las dependencias necesarias para los nodos híbridos. Algunas de las dependencias de los nodos híbridos son containerd, kubelet, kubectl y AWS SSM o componentes de AWS IAM Roles Anywhere. Debe tener acceso desde el lugar donde ejecuta la instalación de nodeadm para descargar estas dependencias. Para obtener más información sobre la lista de ubicaciones a las que debe tener acceso, consulte Cómo preparar las redes para los nodos híbridos. Si no tiene acceso, se producirán errores similares a los siguientes en el resultado de nodeadm install.

"msg":"Command failed","error":"failed reading file from url: ...: max retries achieved for http request"

No se pudo actualizar el administrador de paquetes

El comando nodeadm install ejecuta la actualización de apt o la actualización de yum/dnf antes de instalar las dependencias de los nodos híbridos. Si este paso no se realiza correctamente, es posible que se produzcan errores similares a los siguientes. Para solucionarlo, puede ejecutar la actualización de apt o la actualización de yum/dnf antes de ejecutar nodeadm install o puede intentar volver a ejecutar nodeadm install.

failed to run update using package manager

Se ha superado el tiempo de espera o el plazo de contexto

Durante la ejecución de nodeadm install, si aparecen en varias etapas del proceso de instalación con errores que indican que se ha superado el tiempo de espera o el plazo de contexto, es posible que la conexión sea lenta y que impida instalar las dependencias de los nodos híbridos antes de que se cumplan los tiempos de espera. Para solucionar estos problemas, puede intentar utilizar la marca --timeout en nodeadm para prolongar los tiempos de espera para descargar las dependencias.

nodeadm install K8S_VERSION --credential-provider CREDS_PROVIDER --timeout 20m0s
      

Solución de problemas de conexión de nodos híbridos

Los temas de solución de problemas de esta sección están relacionados con el proceso de conexión de nodos híbridos a clústeres de EKS mediante el comando nodeadm init.

Errores de operaciones o esquemas no compatibles

Si al ejecutar nodeadm init aparecen errores relacionados con operation error o unsupported scheme, compruebe nodeConfig.yaml para garantizar que tenga el formato correcto y que se ha transmitido a nodeadm. Para obtener más información sobre el formato y las opciones para nodeConfig.yaml, consulte Referencia de nodeadm de nodos híbridos.

"msg":"Command failed","error":"operation error ec2imds: GetRegion, request canceled, context deadline exceeded"

El rol de IAM de los Nodos híbridos carece de permisos para la acción eks:DescribeCluster

Cuando se ejecuta nodeadm init, nodeadm intenta recopilar información sobre el clúster de EKS mediante una llamada a Describir clúster. Si el rol de IAM de los Nodos híbridos no tiene permiso para la acción eks:DescribeCluster. Para obtener más información sobre los permisos necesarios para el rol de IAM de los Nodos híbridos, consulte Cómo preparar las credenciales para los nodos híbridos.

"msg":"Command failed","error":"operation error EKS: DescribeCluster, https response error StatusCode: 403 ... AccessDeniedException"

Los nodos híbridos no aparecen en el clúster de EKS

Si ejecutó nodeadm init y se completó, pero los nodos híbridos no aparecen en el clúster, es posible que haya problemas con la conexión de red entre los nodos híbridos y el plano de control de EKS, que no tenga configurados los permisos de grupo de seguridad necesarios o que no tenga la asignación necesaria del rol de IAM de nodos híbridos al control de acceso basado en roles (RBAC) de Kubernetes. Para iniciar el proceso de depuración, puede comprobar el estado de kubelet y los registros de kubelet con los siguientes comandos. Ejecute los siguientes comandos desde los nodos híbridos que no se pudieron unir al clúster.

systemctl status kubelet

journalctl -u kubelet -f

No se puede establecer comunicación con el clúster

Si el nodo híbrido no se pudo comunicar con el plano de control del clúster, es posible que se produzcan registros similares a los siguientes.

"Failed to ensure lease exists, will retry" err="Get ..."

"Unable to register node with API server" err="Post ..."

Failed to contact API server when waiting for CSINode publishing ... dial tcp <ip address>: i/o timeout

Si aparecen estos mensajes, compruebe lo siguiente para asegurarse de que cumple con los requisitos de los nodos híbridos que se indican en Cómo preparar las redes para los nodos híbridos.

No autorizado

Si el nodo híbrido se pudo comunicar con el plano de control de EKS pero no se pudo registrar, es posible que vea registros similares a los siguientes. Tenga en cuenta que la diferencia clave en los mensajes de registro que aparecen a continuación es el error Unauthorized. Esto indica que el nodo no pudo realizar sus tareas porque no tiene los permisos necesarios.

"Failed to ensure lease exists, will retry" err="Unauthorized"

"Unable to register node with API server" err="Unauthorized"

Failed to contact API server when waiting for CSINode publishing: Unauthorized

Si aparecen estos mensajes, compruebe lo siguiente para asegurarse de que cumple con los requisitos de los nodos híbridos que se indican en Cómo preparar las credenciales para los nodos híbridos y Cómo preparar el acceso al clúster para los nodos híbridos.

Los nodos híbridos están registrados en el clúster de EKS, pero aparecen en estado Not Ready

Si los nodos híbridos se registraron correctamente en el clúster de EKS, pero los nodos híbridos aparecen en estado Not Ready, lo primero que hay que comprobar es el estado de la interfaz de red de contenedores (CNI). Si no ha instalado una CNI, lo normal es que los nodos híbridos se encuentren en estado Not Ready. Una vez que una CNI se instala y se ejecuta correctamente, los nodos pasan a tener el estado Preparado. Si ha intentado instalar una CNI, pero no se ejecuta correctamente, consulte Solución de problemas de la CNI de nodos híbridos en esta página.

Las solicitudes de firma de certificados (CSR) están atascadas en estado Pendiente

Después de conectar nodos híbridos al clúster de EKS, si ve que hay CSR pendientes correspondientes a los nodos híbridos, significa que los nodos híbridos no cumplen los requisitos para la aprobación automática. Las CSR para nodos híbridos se aprueban y emiten automáticamente si las CSR para nodos híbridos fueron creadas por un nodo con etiqueta eks.amazonaws.com/compute-type: hybrid, y la CSR tiene los siguientes nombres alternativos de asunto (SAN): al menos un SAN de DNS igual al nombre del nodo y los SAN de IP pertenecen a los CIDR de la red de nodos remotos.

Ya existe un perfil híbrido

Si ha cambiado la configuración de nodeadm e intenta volver a registrar el nodo con la nueva configuración, es posible que aparezca un error que indica que el perfil híbrido ya existe, pero su contenido ha cambiado. En lugar de ejecutar nodeadm init entre los cambios de configuración, ejecute nodeadm uninstall seguido de nodeadm install y nodeadm init. Esto garantiza una limpieza adecuada con los cambios en la configuración.

"msg":"Command failed","error":"hybrid profile already exists at /etc/aws/hybrid/config but its contents do not align with the expected configuration"

El nodo híbrido no pudo resolver la API privada

Después de ejecutar nodeadm init, si aparece un error en los registros de kubelet que indique que no se ha establecido contacto con el servidor de la API de Kubernetes de EKS debido a que no such host, es posible que tenga que cambiar la entrada de DNS del punto de conexión de la API de Kubernetes de EKS en la red en las instalaciones o a nivel de host. Consulte Reenvío de consultas de DNS entrantes a la VPC en la documentación de AWS Route53.

Failed to contact API server when waiting for CSINode publishing: Get ... no such host

No se pueden ver los nodos híbridos en la consola de EKS

Si ha registrado los nodos híbridos, pero no puede verlos en la consola de EKS, compruebe los permisos de la entidad principal de IAM que utiliza para ver la consola. La entidad principal de IAM que utiliza debe tener permisos mínimos específicos de IAM y Kubernetes para ver los recursos de la consola. Para obtener más información, consulte Visualización de los recursos de Kubernetes en la AWS Management Console.

Solución de problemas de ejecución de nodos híbridos

Si los nodos híbridos registrados en el clúster de EKS se encontraban en estado Ready y, posteriormente, pasaron al estado Not Ready, existe una amplia gama de problemas que pueden haber contribuido al mal estado, como que el nodo carezca de recursos suficientes para la CPU, la memoria o el espacio en disco disponible, o que el nodo esté desconectado del plano de control de EKS. Puede seguir los pasos que se indican a continuación para solucionar los problemas de los nodos y, si no puede resolver el problema, contacte a AWS Support.

Ejecute nodeadm debug desde los nodos híbridos para comprobar que se cumplen los requisitos de red y credenciales. Para obtener más información acerca del comando nodeadm debug, consulte Referencia de nodeadm de nodos híbridos.

Obtención del estado de los nodos

kubectl get nodes -o wide

Comprobación de las condiciones y los eventos de nodos

kubectl describe node NODE_NAME
      

Obtención del estado de los pods

kubectl get pods -A -o wide

Comprobación de las condiciones y los eventos de pods

kubectl describe pod POD_NAME
      

Comprobación de los registros de pods

kubectl logs POD_NAME
      

Comprobación de los registros de kubectl

systemctl status kubelet

journalctl -u kubelet -f

Las sondas de actividad del pod fallan o los webhooks no funcionan

Si las aplicaciones, complementos o webhooks que se ejecutan en los nodos híbridos no se inician correctamente, es posible que existan problemas de red que bloqueen la comunicación con los pods. Para que el plano de control de EKS se ponga en contacto con los webhooks que se ejecutan en nodos híbridos, debe configurar el clúster de EKS con una red de pods remotos y disponer de rutas para el CIDR de pods en las instalaciones en la tabla de enrutamiento de VPC con el destino como la puerta de enlace de tránsito (TGW), la puerta de enlace virtual privada (VPW) u otra puerta de enlace que utilice para conectar la VPC con la red en las instalaciones. Para obtener más información sobre los requisitos de red para los nodos híbridos, consulte Cómo preparar las redes para los nodos híbridos. Además, debe permitir este tráfico en el firewall en las instalaciones y asegurarse de que el enrutador puede dirigir correctamente el tráfico a los pods.

A continuación aparece un mensaje de registro de pod común para este escenario, en el que ip-address es la IP del clúster del servicio de Kubernetes.

dial tcp <ip-address>:443: connect: no route to host

Solución de problemas de la CNI de nodos híbridos

Si tiene problemas al iniciar Cilium o Calico al principio con nodos híbridos, la mayoría de las veces se debe a problemas de red entre los nodos híbridos o los pods de la CNI que se ejecutan en los nodos híbridos y el plano de control de EKS. Asegúrese de que el entorno cumpla los requisitos que se indican en Cómo preparar las redes para los nodos híbridos. Resulta útil dividir el problema en partes.

El nodo híbrido se encuentra en estado Ready sin una CNI instalada

Si los nodos híbridos se encuentran en el estado Ready, pero no ha instalado una CNI en el clúster, es posible que haya artefactos de CNI antiguos en los nodos híbridos. De forma predeterminada, al desinstalar Cilium y Calico con herramientas como Helm, los recursos del disco no se eliminan de las máquinas físicas o virtuales. Además, es posible que las definiciones de recursos personalizadas (CRD) de estas CNI aún estén presentes en el clúster a partir de una instalación anterior. Para obtener más información, consulte las secciones Cómo eliminar Cilio y Cómo eliminar Calico en Cómo configurar una CNI para nodos híbridos.

Solución de problemas de Cilium

Si tiene problemas al ejecutar Cilium en nodos híbridos, consulte los pasos de solución de problemas en la documentación de Cilium. En las siguientes secciones se describen los problemas que pueden ser exclusivos de la implementación de Cilium en nodos híbridos.

Cilium no se inicia

Si los agentes de Cilium que se ejecutan en cada nodo híbrido no se inician, compruebe si hay errores en los registros de los pods de agentes de Cilium. El agente de Cilium requiere conectividad con el punto de conexión de la API de Kubernetes de EKS para poder iniciarse. Se producirá un error al iniciar el agente de Cilium si la conectividad no está configurada correctamente. En este caso, aparecerán mensajes de registro similares a los siguientes en los registros del pod del agente de Cilium.

msg="Unable to contact k8s api-server"
level=fatal msg="failed to start: Get \"https://<k8s-cluster-ip>:443/api/v1/namespaces/kube-system\": dial tcp <k8s-cluster-ip>:443: i/o timeout"

El agente de Cilium se ejecuta en la red host. El clúster de EKS debe estar configurado con RemoteNodeNetwork para la conectividad con Cilium. Confirme que cuenta con un grupo de seguridad adicional para el clúster de EKS con una regla de entrada para la RemoteNodeNetwork, que dispone de rutas en la VPC para la RemodeNodeNetwork y que la red en las instalaciones está configurada correctamente para permitir la conectividad con el plano de control de EKS.

Si el operador de Cilium está en ejecución y algunos de los agentes de Cilium se ejecutan, pero no la totalidad, confirme que tiene direcciones IP de pod disponibles para asignarlas a todos los nodos del clúster. El tamaño de los CIDR de pods asignables se configura al usar la administración de IP del grupo del clúster con clusterPoolIPv4PodCIDRList en la configuración de Cilium. El tamaño del CIDR por nodo se configura con el ajuste clusterPoolIPv4MaskSize de la configuración de Cilium. Consulte Ampliación del grupo de clústeres en la documentación de Cilium para obtener más información.

El BGP de Cilium no funciona

Si utiliza el plano de control de BGP de Cilium para anunciar las direcciones de los pods o servicios en la red en las instalaciones, puede utilizar los siguientes comandos de la CLI de Cilium para comprobar si BGP anuncia las rutas a los recursos. Para conocer los pasos que se deben seguir para instalar la CLI de Cilium, consulte Instalación de la CLI de Cilium en la documentación de Cilium.

Si BGP funciona correctamente, debería ver los nodos híbridos con el estado de sesión established en el resultado. Es posible que necesite trabajar con el equipo de redes para identificar los valores correctos para el AS local, el AS del vecino y la dirección del vecino del entorno.

cilium bgp peers

cilium bgp routes

Si utiliza el BGP de Cilium para anunciar las IP de los servicios con el tipo LoadBalancer, debe tener la misma etiqueta tanto en el CiliumLoadBalancerIPPool como en el servicio, que se debe utilizar en el selector del CiliumBGPAdvertisement. A continuación se muestra un ejemplo. Tenga en cuenta que, si utiliza el BGP de Cilium para anunciar las IP de los servicios del tipo LoadBalancer, es posible que las rutas de BGP se interrumpan durante el reinicio del agente de Cilium. Para obtener más información, consulte los Escenarios de error en la documentación de Cilium.

Servicio

kind: Service
apiVersion: v1
metadata:
  name: guestbook
  labels:
    app: guestbook
spec:
  ports:
  - port: 3000
    targetPort: http-server
  selector:
    app: guestbook
  type: LoadBalancer

CiliumLoadBalancerIPPool

apiVersion: cilium.io/v2alpha1
kind: CiliumLoadBalancerIPPool
metadata:
  name: guestbook-pool
  labels:
    app: guestbook
spec:
  blocks:
  - cidr: <CIDR to advertise>
  serviceSelector:
    matchExpressions:
      - { key: app, operator: In, values: [ guestbook ] }

CiliumBGPAdvertisement

apiVersion: cilium.io/v2alpha1
kind: CiliumBGPAdvertisement
metadata:
  name: bgp-advertisements-guestbook
  labels:
    advertise: bgp
spec:
  advertisements:
    - advertisementType: "Service"
      service:
        addresses:
          - ExternalIP
          - LoadBalancerIP
      selector:
        matchExpressions:
          - { key: app, operator: In, values: [ guestbook ] }

Solución de problemas de Calico

Si tiene problemas al ejecutar Cilium en nodos híbridos, consulte los pasos de solución de problemas en la documentación de Calico. En las siguientes secciones se describen los problemas que pueden ser exclusivos de la implementación de Calico en nodos híbridos.

En la siguiente tabla se resumen los componentes de Calico y se indica si se ejecutan en la red de nodos o de pods de forma predeterminada. Si configuró Calico para usar NAT para el tráfico de pods saliente, la red en las instalaciones debe estar configurada para dirigir el tráfico al CIDR del nodo en las instalaciones. Además, las tablas de enrutamiento de la VPC deben estar configuradas con una ruta para el CIDR del nodo en las instalaciones con la puerta de enlace de tránsito (TGW) o la puerta de enlace privada virtual (VGW) como destino. Si no va a configurar Calico para usar NAT para el tráfico de pods saliente, la red en las instalaciones debe estar configurada para dirigir el tráfico al CIDR del pod en las instalaciones. Además, las tablas de enrutamiento de la VPC deben estar configuradas con una ruta para el CIDR del pod en las instalaciones con la puerta de enlace de tránsito (TGW) o la puerta de enlace privada virtual (VGW) como destino.

Los recursos de Calico están programados o se ejecutan en nodos acordonados

Los recursos de Calico que no se ejecutan como un DaemonSet tienen tolerancias flexibles de forma predeterminada gracias a las cuales es posible programarlos en nodos acordonados que no están preparados para programar o ejecutar pods. Para ajustar las tolerancias para los recursos de Calico que no son de DaemonSet, puede cambiar la instalación del operador de modo que incluya lo siguiente.

installation:
  ...
  controlPlaneTolerations:
  - effect: NoExecute
    key: node.kubernetes.io/unreachable
    operator: Exists
    tolerationSeconds: 300
  - effect: NoExecute
    key: node.kubernetes.io/not-ready
    operator: Exists
    tolerationSeconds: 300
  calicoKubeControllersDeployment:
    spec:
      template:
        spec:
          tolerations:
          - effect: NoExecute
            key: node.kubernetes.io/unreachable
            operator: Exists
            tolerationSeconds: 300
          - effect: NoExecute
            key: node.kubernetes.io/not-ready
            operator: Exists
            tolerationSeconds: 300
  typhaDeployment:
    spec:
      template:
        spec:
          tolerations:
          - effect: NoExecute
            key: node.kubernetes.io/unreachable
            operator: Exists
            tolerationSeconds: 300
          - effect: NoExecute
            key: node.kubernetes.io/not-ready
            operator: Exists
            tolerationSeconds: 300

Solución de problemas de credenciales

Tanto para las activaciones híbridas de AWS SSM como para AWS IAM Roles Anywhere, puede validar que las credenciales del rol de IAM de los Nodos híbridos estén configuradas correctamente en los nodos híbridos. Para ello, ejecute el siguiente comando desde los nodos híbridos. Confirme que el nombre del nodo y el nombre del rol de IAM de los Nodos híbridos son los esperados.

sudo aws sts get-caller-identity

{
    "UserId": "ABCDEFGHIJKLM12345678910:<node-name>",
    "Account": "<aws-account-id>",
    "Arn": "arn:aws:sts::<aws-account-id>:assumed-role/<hybrid-nodes-iam-role/<node-name>"
}

Solución problemas de AWS Systems Manager (SSM)

Si utiliza activaciones híbridas de AWS SSM para las credenciales de nodos híbridos, tenga en cuenta los siguientes directorios y artefactos de SSM que nodeadm instala en los nodos híbridos. Para obtener más información sobre el agente de SSM, consulte Uso del agente de SSM en la Guía del usuario de AWS Systems Manager.

Reinicio del agente de SSM

Para resolver algunos problemas, se puede reiniciar el agente de SSM. Puede utilizar los comandos que aparecen a continuación para reiniciarlo.

AL2023 y otros sistemas operativos

systemctl restart amazon-ssm-agent

Ubuntu

systemctl restart snap.amazon-ssm-agent.amazon-ssm-agent

Compruebe la conectividad con los puntos de conexión de SSM

Confirme que se puede conectar a los puntos de conexión de SSM desde los nodos híbridos. Para obtener una lista de los puntos de conexión de SSM, consulte Puntos de conexión y cuotas de AWS Systems Manager. Sustituya us-west-2 en el comando que aparece a continuación por la región de AWS de activación híbrida de AWS SSM.

ping ssm.us-west-2.amazonaws.com

Visualización del estado de la conexión de las instancias de SSM registradas

Puede comprobar el estado de conexión de las instancias que están registradas en las activaciones híbridas de SSM con el siguiente comando de la AWS CLI. Sustituya el ID de máquina por el ID de máquina de la instancia.

aws ssm get-connection-status --target mi-012345678abcdefgh
      

Falta de coincidencia de la suma de comprobación de la CLI de configuración de SSM

Al ejecutar nodeadm install, si detecta un problema de falta de coincidencia de la suma de comprobación de ssm-setup-cli, deberá confirmar que no haya instalaciones de SSM más antiguas en el host. Si hay instalaciones de SSM antiguas en el host, elimínelas y vuelva a ejecutar nodeadm install para resolver el problema.

Failed to perform agent-installation/on-prem registration: error while verifying installed ssm-setup-cli checksum: checksum mismatch with latest ssm-setup-cli.

InvalidActivation De SSM

Si aparece un error al registrar la instancia en AWS SSM, confirme que la region, activationCode y activationId en el nodeConfig.yaml son correctos. La región de AWS del clúster de EKS debe coincidir con la región de activación híbrida de SSM. Si estos valores están mal configurados, es posible que aparezca un error similar al siguiente.

ERROR Registration failed due to error registering the instance with AWS SSM. InvalidActivation

ExpiredTokenException de SSM: el token de seguridad incluido en la solicitud ha vencido

Si el agente de SSM no puede actualizar las credenciales, es posible que aparezca una ExpiredTokenException. En este escenario, si se puede conectar a los puntos de conexión de SSM desde los nodos híbridos, es posible que tenga que reiniciar el agente de SSM para forzar la actualización de credenciales.

"msg":"Command failed","error":"operation error SSM: DescribeInstanceInformation, https response error StatusCode: 400, RequestID: eee03a9e-f7cc-470a-9647-73d47e4cf0be, api error ExpiredTokenException: The security token included in the request is expired"

Error de SSM al ejecutar el comando de registro de la máquina

Si aparece un error al registrar la máquina en SSM, es posible que tenga que volver a ejecutar nodeadm install para asegurarse de que todas las dependencias de SSM están instaladas correctamente.

"error":"running register machine command: , error: fork/exec /opt/aws/ssm-setup-cli: no such file or directory"

ActivationExpired De SSM

Al ejecutar nodeadm init, si aparece un error al registrar la instancia en SSM debido a que la activación ha caducado, tendrá que crear una nueva activación híbrida de SSM, actualizar nodeConfig.yaml con el activationCode y el activationId de la nueva activación híbrida de SSM y volver a ejecutar nodeadm init.

"msg":"Command failed","error":"SSM activation expired. Please use a valid activation"

ERROR Registration failed due to error registering the instance with AWS SSM. ActivationExpired

SSM no pudo actualizar las credenciales almacenadas en caché

Si se presenta un error al actualizar las credenciales almacenadas en caché, es posible que el archivo /root/.aws/credentials se haya eliminado del host. En primer lugar, compruebe la activación híbrida de SSM y asegúrese de que esté activa y de que los nodos híbridos estén configurados correctamente para utilizar la activación. Compruebe los registros del agente de SSM en /var/log/amazon/ssm y vuelva a ejecutar el comando nodeadm init una vez que haya resuelto el problema del SSM.

"Command failed","error":"operation error SSM: DescribeInstanceInformation, get identity: get credentials: failed to refresh cached credentials"

Limpie SSM

Para eliminar el agente de SSM del host, puede ejecutar los siguientes comandos.

dnf remove -y amazon-ssm-agent
sudo apt remove --purge amazon-ssm-agent
snap remove amazon-ssm-agent
rm -rf /var/lib/amazon/ssm/Vault/Store/RegistrationKey

Solución de problemas de AWS IAM Roles Anywhere

Si utiliza AWS IAM Roles Anywhere para las credenciales de nodos híbridos, tenga en cuenta los siguientes directorios y artefactos que nodeadm instala en los nodos híbridos. Para obtener más información sobre la solución de problemas de IAM Roles Anywhere, consulte Solución de problemas de identidad y acceso de AWS IAM Roles Anywhere en la Guía del usuario de AWS IAM Roles Anywhere.

IAM Roles Anywhere no pudo volver a refrescar las credenciales almacenadas en caché

Si detecta un error al refrescar las credenciales almacenadas en caché, revise el contenido de /etc/aws/hybrid/config y confirme que IAM Roles Anywhere se ha configurado correctamente en la configuración de nodeadm. Confirme que /etc/iam/pki existe. Cada nodo debe tener un certificado y una clave únicos. De forma predeterminada, cuando se utiliza IAM Roles Anywhere como proveedor de credenciales, nodeadm utiliza /etc/iam/pki/server.pem para la ubicación y el nombre del certificado, y /etc/iam/pki/server.key para la clave privada. Es posible que tenga que crear los directorios antes de colocar los certificados y las claves en los directorios con sudo mkdir -p /etc/iam/pki. Puede comprobar el contenido del certificado con el siguiente comando.

openssl x509 -text -noout -in server.pem

open /etc/iam/pki/server.pem: no such file or directory
could not parse PEM data
Command failed {"error": "... get identity: get credentials: failed to refresh cached credentials, process provider error: error in credential_process: exit status 1"}

IAM Roles Anywhere no está autorizado para realizar sts:AssumeRole

Si se presenta un problema de acceso denegado en los registros de kubelet para la operación sts:AssumeRole al utilizar IAM Roles Anywhere, compruebe la política de confianza del rol de IAM de Nodos híbridos para confirmar que la entidad principal del servicio de IAM Roles Anywhere puede asumir el rol de IAM de Nodos híbridos. Además, confirme que el ARN del anclaje de veracidad esté configurado correctamente en la política de confianza del rol de IAM de Nodos híbridos y que el rol de IAM de Nodos híbridos se haya agregado al perfil de IAM Roles Anywhere.

could not get token: AccessDenied: User: ... is not authorized to perform: sts:AssumeRole on resource: ...

IAM Roles Anywhere no está autorizado a establecer roleSessionName

Si se presenta un problema de acceso denegado en los registros de kubelet al configurar el roleSessionName, confirme que acceptRoleSessionName se ha establecido en verdadero para el perfil de IAM Roles Anywhere.

AccessDeniedException: Not authorized to set roleSessionName

Solución de problemas del sistema operativo

RHEL

Fallos en el registro del administrador de derechos o suscripciones

Si ejecuta nodeadm install y se produce un error al instalar las dependencias de los nodos híbridos debido a problemas de registro de derechos, asegúrese de haber configurado correctamente el nombre de usuario y la contraseña de Red Hat en el host.

This system is not registered with an entitlement server

No se encontró GLIBC

Si utiliza Ubuntu para el sistema operativo e IAM Roles Anywhere para el proveedor de credenciales con nodos híbridos y se presenta el problema de que no se encontró GLIBC, puede instalar esa dependencia manualmente para resolver el problema.

GLIBC_2.32 not found (required by /usr/local/bin/aws_signing_helper)

Ejecute los siguientes comandos para instalar la dependencia.

ldd --version
sudo apt update && apt install libc6
sudo apt install glibc-source