**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 relacionados con los nodos híbridos
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](troubleshooting.md) la [Etiqueta del Centro de conocimientos para Amazon EKS](https://repost.aws/tags/knowledge-center/TA4IvCeWI1TE66q4jEj4Z9zg/amazon-elastic-kubernetes-service) en * AWS re:Post*. Si no puede resolver el problema, contacte a AWS Support.
**Solución de problemas del nodo con `nodeadm debug`:** puede ejecutar el comando `nodeadm debug` desde los nodos híbridos para comprobar que se cumplan 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](hybrid-nodes-nodeadm.md).
**Detección de problemas con los nodos híbridos mediante la información sobre clústeres:** la información sobre clústeres de Amazon EKS incluye *comprobaciones de información* que detectan problemas comunes con la configuración de los nodos híbridos de EKS en el clúster. Puede ver los resultados de todas las comprobaciones de información desde la Consola de administración de AWS, la AWS CLI y los AWS SDK. Para obtener más detalles acerca de la información del clúster, consulte [Preparación para las actualizaciones de las versiones de Kubernetes y solución de problemas de configuración incorrecta con información sobre clústeres](cluster-insights.md).
## Solución de problemas de instalación de nodos híbridos
Los siguientes temas de solución de problemas están relacionados con la instalación de las dependencias de los nodos híbridos en los hosts mediante el comando `nodeadm install`.
** `nodeadm` El comando falló `must run as root` **
El comando `nodeadm install` se debe ejecutar con un usuario que tenga privilegios de raíz o `sudo` en el host. Si ejecuta `nodeadm install` con un usuario que no tiene privilegios de raíz o `sudo`, el siguiente error aparecerá 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 `nodeadm install` 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](hybrid-nodes-networking.md). 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 `apt update`, `yum update` o `dnf update` 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 `apt update`, `yum update` o `dnf update` antes de ejecutar `nodeadm install`. De otro modo, 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**
Al ejecutar `nodeadm install`, si observa problemas en distintas etapas del proceso de instalación con errores que indiquen un tiempo de espera agotado o que se superó el plazo de contexto, es posible que tenga una conexión lenta que impide la instalación de 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](hybrid-nodes-nodeadm.md).
```
"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 la acción `DescribeCluster` de EKS. Si el rol de IAM de Nodos híbridos no tiene permiso para la acción `eks:DescribeCluster`, deberá transmitir el punto de conexión de la API de Kubernetes, el paquete de CA del clúster y el CIDR IPv4 del servicio a la configuración de nodos que transmite a `nodeadm` al ejecutar `nodeadm init`. 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](hybrid-nodes-creds.md).
```
"msg":"Command failed","error":"operation error EKS: DescribeCluster, https response error StatusCode: 403 ... AccessDeniedException"
```
**El rol de IAM de los Nodos híbridos carece de permisos para la acción `eks:ListAccessEntries`**
Cuando se ejecuta `nodeadm init`, `nodeadm` intenta validar si el clúster de EKS tiene una entrada de acceso del tipo `HYBRID_LINUX` asociada al rol de IAM de Nodos híbridos mediante una llamada a la acción `ListAccessEntries` de EKS. Si el rol de IAM de Nodos híbridos no tiene permiso para la acción `eks:ListAccessEntries`, debe transmitir el indicador `--skip cluster-access-validation` al ejecutar el comando `nodeadm init`. 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](hybrid-nodes-creds.md).
```
"msg":"Command failed","error":"operation error EKS: ListAccessEntries, https response error StatusCode: 403 ... AccessDeniedException"
```
**La IP del nodo no está dentro del CIDR de la red del nodo remoto**
Al ejecutar `nodeadm init`, se podría producir un error si la dirección IP del nodo no se encuentra dentro de los CIDR de red de nodos remotos especificados. El error tendrá un aspecto similar al siguiente ejemplo:
```
node IP 10.18.0.1 is not in any of the remote network CIDR blocks [10.0.0.0/16 192.168.0.0/16]
```
Este ejemplo muestra un nodo con la IP 10.18.0.1 que intenta unirse a un clúster con CIDR de red remota 10.0.0.0/16 y 192.168.0.0/16. El error se produce porque la IP 10.18.0.1 no se encuentra dentro de ninguno de los rangos.
Confirme que haya configurado correctamente las `RemoteNodeNetworks` para incluir todas las direcciones IP de los nodos. Para obtener más información sobre la configuración de la red, consulte [Cómo preparar las redes para los nodos híbridos](hybrid-nodes-networking.md).
+ Ejecute el siguiente comando en la región en la que se encuentra el clúster para comprobar las configuraciones de `RemoteNodeNetwork`. Verifique que los bloques de CIDR que aparecen en la salida incluyan el rango de IP del nodo y coincidan con los bloques de CIDR mencionados en el mensaje de error. Si no coinciden, confirme que el nombre del clúster y la región especificados en el archivo `nodeConfig.yaml` correspondan al clúster previsto.
```
aws eks describe-cluster --name CLUSTER_NAME --region REGION_NAME --query cluster.remoteNetworkConfig.remoteNodeNetworks
```
+ Verifique que el nodo sea el previsto:
+ Para confirmar que se trata del nodo correcto, verifique que el nombre de host y la dirección IP coincidan con los que desea registrar en el clúster.
+ Confirme que este nodo se encuentra en la red en las instalaciones correcta (aquella cuyo rango de CIDR se registró como `RemoteNodeNetwork` durante la configuración del clúster).
Si la IP del nodo aún no es la esperada, verifique lo siguiente:
+ Si utiliza IAM Roles Anywhere, `kubelet` realiza una consulta de DNS sobre el `nodeName` de IAM Roles Anywhere y usa una IP asociada con el nombre de nodo si está disponible. Si dispone de entradas de DNS para los nodos, confirme que dichas entradas apunten a direcciones IP que se encuentren dentro de los CIDR de la red de nodos remotos.
+ Si el nodo tiene múltiples interfaces de red, `kubelet` podría elegir como predeterminada una interfaz cuya dirección IP no esté dentro de los CIDR de la red de nodos remotos. Para utilizar una interfaz diferente, especifique su dirección IP con la marca `--node-ip` `kubelet` en el archivo `nodeConfig.yaml`. Para obtener más información, consulte [Referencia de `nodeadm` de nodos híbridos](hybrid-nodes-nodeadm.md). Para ver las interfaces de red del nodo y sus direcciones IP, ejecute el siguiente comando en el nodo:
```
ip addr show
```
**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 utilizar los siguientes comandos para comprobar el estado de `kubelet` y los registros de `kubelet`. 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 : 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](hybrid-nodes-networking.md).
+ Confirme que la VPC trasladada al clúster de EKS tenga rutas a la puerta de enlace de tránsito (TGW) o puerta de enlace privada virtual (VGW) para el nodo en las instalaciones y, opcionalmente, los CIDR del pod.
+ Confirme que cuenta con un grupo de seguridad adicional para el clúster de EKS que tenga reglas de entrada para los CIDR de los nodos en las instalaciones y, opcionalmente, los CIDR de los pods.
+ Confirme que el enrutador en las instalaciones esté configurado para permitir el tráfico hacia y desde el plano de control de EKS.
**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](hybrid-nodes-creds.md) y [Cómo preparar el acceso al clúster para los nodos híbridos](hybrid-nodes-cluster-prep.md).
+ Confirme que la identidad de los nodos híbridos coincide con el rol de IAM previsto para los nodos híbridos. Para ello, se puede ejecutar `sudo aws sts get-caller-identity` desde los nodos híbridos.
+ Compruebe que el rol de IAM de los Nodos híbridos tiene los permisos necesarios.
+ Confirme que en el clúster tiene una entrada de acceso a EKS para el rol de IAM de los Nodos híbridos o confirme que el ConfigMap de `aws-auth` tiene una entrada para el rol de IAM de los Nodos híbridos. Si utiliza entradas de acceso a EKS, confirme que la entrada de acceso para el rol de IAM de los Nodos híbridos sea del tipo de acceso `HYBRID_LINUX`. Si utiliza ConfigMap de `aws-auth`, confirme que la entrada para el rol de IAM de los Nodos híbridos cumpla con los requisitos y el formato que se detallan en [Cómo preparar el acceso al clúster para los nodos híbridos](hybrid-nodes-cluster-prep.md).
### 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 se actualizan al estado `Ready`. Si ha intentado instalar una CNI, pero no se ejecuta correctamente, consulte [Solución de problemas de la CNI de nodos híbridos](#hybrid-nodes-troubleshooting-cni) 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](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-forwarding-inbound-queries.html) 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 Consola de administración de AWS](view-kubernetes-resources.md).
## 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](hybrid-nodes-nodeadm.md).
**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
```
**Comprobar 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](hybrid-nodes-networking.md). 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. Consulte [Configuración de webhooks para nodos híbridos](hybrid-nodes-webhooks.md) para obtener más información sobre los requisitos para ejecutar webhooks en nodos híbridos.
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 :443: connect: no route to host
```
**Los comandos `kubectl logs` o `kubectl exec` no funcionan (comandos de la API de `kubelet`)**
Si los comandos `kubectl attach`, `kubectl cp`, `kubectl exec`, `kubectl logs` y `kubectl port-forward` agotan el tiempo de espera mientras otros comandos `kubectl` se ejecutan correctamente, es probable que el problema esté relacionado con la configuración de la red remota. Estos comandos se conectan a través del clúster al punto de conexión de `kubelet` en el nodo. Para obtener más información consulte () [Punto de conexión de `kubelet`](hybrid-nodes-concepts-kubernetes.md#hybrid-nodes-concepts-k8s-kubelet-api).
Verifique que las direcciones IP de los nodos y pods se encuentren dentro de los CIDR de la red de nodos remotos y de la red de pods remotos configurados para el clúster. Use los siguientes comandos para examinar las asignaciones de IP.
```
kubectl get nodes -o wide
```
```
kubectl get pods -A -o wide
```
Compare estas direcciones IP con los CIDR de red remota configurados para asegurarse de que el enrutamiento sea correcto. Para consultar los requisitos de configuración de red, consulte [Cómo preparar las redes para los nodos híbridos](hybrid-nodes-networking.md).
## 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.
Configuración del clúster de EKS
¿Son correctas las configuraciones de RemoteNodeNetwork y RemotePodNetwork?
Configuración de la VPC
¿Existen rutas para RemoteNodeNetwork y RemotePodNetwork en la tabla de enrutamiento de la VPC con el destino de la puerta de enlace de tránsito o la puerta de enlace virtual privada?
Configuración del grupo de seguridad
¿Existen reglas de entrada y salida para RemoteNodeNetwork y RemotePodNetwork?
Red on-premise
¿Existen rutas y acceso hacia y desde el plano de control de EKS, así como hacia y desde los nodos híbridos y los pods que se ejecutan en estos?
Configuración de la CNI
Si se utiliza una red superpuesta, ¿la configuración del grupo de IP de la CNI coincide la RemotePodNetwork configurada para el clúster de EKS si se utilizan webhooks?
**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 personalizados (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 [Configuración de una CNI para nodos híbridos](hybrid-nodes-cni.md).
**Solución de problemas de Cilium**
Si tiene problemas al ejecutar Cilium en nodos híbridos, consulte los [pasos de solución de problemas](https://docs.cilium.io/en/stable/operations/troubleshooting/) en la documentación de Cilium. Las secciones siguientes tratan problemas que pueden ser particulares 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://:443/api/v1/namespaces/kube-system\": dial tcp :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 `RemoteNodeNetwork` 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](https://docs.cilium.io/en/stable/network/concepts/ipam/cluster-pool/#expanding-the-cluster-pool) 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](https://docs.cilium.io/en/stable/gettingstarted/k8s-install-default/#install-the-cilium-cli) 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](https://docs.cilium.io/en/latest/network/bgp-control-plane/bgp-control-plane-operation/#failure-scenarios) en la documentación de Cilium.
**Servicio de**
```
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:
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](https://docs.tigera.io/calico/latest/operations/troubleshoot/) 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.
| Componente | Network |
| --- | --- |
| Servidor de la API de Calico | Nodo |
| Controladores de Calicon para Kubernetes | Pod |
| Agende de nodos de Calico | Nodo |
| Calico `typha` | Nodo |
| Controlador de nodos de CSI de Calico | Pod |
| Operador de Calico | Nodo |
**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:",
"Account": "",
"Arn": "arn:aws:sts:::assumed-role/"
}
```
** AWS Solución problemas de 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](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent.html) en la *Guía del usuario de AWS Systems Manager*.
| Descripción | Ubicación |
| --- | --- |
| Agente de SSM | Ubuntu: `/snap/amazon-ssm-agent/current/amazon-ssm-agent` RHEL y AL2023: `/usr/bin/amazon-ssm-agent` |
| Registros de SSM Agent | `/var/log/amazon/ssm` |
| AWSCredenciales de | `/root/.aws/credentials` |
| CLI de configuración de SSM | `/opt/ssm/ssm-setup-cli` |
**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](https://docs.aws.amazon.com/general/latest/gr/ssm.html). 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.
```
**De SSM `InvalidActivation` **
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"
```
**De SSM `ActivationExpired` **
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
```
** AWS Solución de problemas de 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](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/security_iam_troubleshoot.html) en la Guía del usuario de *AWS IAM Roles Anywhere*.
| Descripción | Ubicación |
| --- | --- |
| CLI de IAM Roles Anywhere | `/usr/local/bin/aws_signing_helper` |
| Ubicación y nombre predeterminados del certificado | `/etc/iam/pki/server.pem` |
| Ubicación y nombre predeterminados de la clave | `/etc/iam/pki/server.key` |
**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 para definir `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
```
### Ubuntu
**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
```
### Bottlerocket
Si tiene activado el contenedor de administración de Bottlerocket, puede acceder a este mediante SSH para realizar tareas avanzadas de depuración y resolución de problemas con privilegios elevados. Las siguientes secciones contienen comandos que se deben ejecutar en el contexto del host de Bottlerocket. Una vez que esté en el contenedor de administración, puede ejecutar `sheltie` para obtener un intérprete de comandos raíz completo en el host de Bottlerocket.
```
sheltie
```
Para ejecutar los comandos de las siguientes secciones desde el intérprete de comandos del contenedor de administración, también puede agregar el prefijo `sudo chroot /.bottlerocket/rootfs` a cada comando.
```
sudo chroot /.bottlerocket/rootfs
```
**Cómo utilizar logdog en la recopilación de registros**
Bottlerocket proporciona la utilidad `logdog` para recopilar de manera eficiente los registros y la información del sistema con fines de resolución de problemas.
```
logdog
```
La utilidad `logdog` recopila registros de varias ubicaciones en un host de Bottlerocket y los combina en un archivo tarball. De forma predeterminada, el archivo tarball se creará en `/var/log/support/bottlerocket-logs.tar.gz`, y se podrá acceder a este desde los contenedores del host en `/.bottlerocket/support/bottlerocket-logs.tar.gz`.
**Cómo acceder a los registros del sistema con journalctl**
Puede utilizar los siguientes comandos para comprobar el estado de los distintos servicios del sistema, como `kubelet` o `containerd`, entre otros, así como para ver sus registros. La marca `-f` seguirá los registros en tiempo real.
Para comprobar el estado del servicio `kubelet` y recuperar los registros de `kubelet`, puede ejecutar:
```
systemctl status kubelet
journalctl -u kubelet -f
```
Para comprobar el estado del servicio `containerd` y recuperar los registros de la instancia orquestada de `containerd`, puede ejecutar:
```
systemctl status containerd
journalctl -u containerd -f
```
Para comprobar el estado del servicio `host-containerd` y recuperar los registros de la instancia host de `containerd`, puede ejecutar:
```
systemctl status host-containerd
journalctl -u host-containerd -f
```
Para recuperar los registros de los contenedores de arranque y los contenedores host, puede ejecutar:
```
journalctl _COMM=host-ctr -f
```