**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 de salida del plano de control Al utilizar el modo de salida del plano de control `CUSTOMER_ROUTED`, es responsable de la conectividad de red desde las ENI del plano de control. En esta página, se describen los problemas más comunes y sus soluciones. ## Detección de un webhook con error Cuando el plano de control no puede acceder a un servidor de webhook o a un proveedor de OIDC, el síntoma suele aparecer como tiempo de espera del webhook. Para confirmarlo, cree o modifique un recurso que active el webhook y compruebe el error: ``` kubectl apply -f my-resource.yaml ``` Un error de conectividad o de DNS suele devolver un error similar al siguiente: ``` Error from server (InternalError): error when creating "my-resource.yaml": Internal error occurred: failed calling webhook "my-webhook.example.com": failed to call webhook: Post "https://my-webhook.example.com/validate?timeout=10s": context deadline exceeded ``` También puede comprobar los eventos recientes para ver si hay errores de webhook en todo el clúster: ``` kubectl get events --all-namespaces --field-selector reason=FailedCreate ``` + Si el error es un tiempo de espera (`context deadline exceeded`) o la conexión se ha rechazado, el plano de control no podrá acceder al punto de conexión del webhook. Consulte [No hay ruta de salida a los puntos de conexión necesarios](#egress-troubleshoot-natgw), [Las NACL bloquean el tráfico del webhook o del plano de control](#egress-troubleshoot-nacl) y [Grupos de seguridad que impiden el acceso](#egress-troubleshoot-sg). + Si el error menciona un error de DNS o de host no encontrado, el plano de control no puede resolver el punto de conexión. Consulte [Error al actualizar el conjunto de opciones de DHCP](#egress-troubleshoot-dhcp). ## No hay ruta de salida a los puntos de conexión necesarios **Síntomas:** + Se agota el tiempo de espera de los webhooks de admisión. + No se puede detectar el proveedor de OIDC. + Se detiene la creación o actualización de clústeres. **Causa:** Las subredes de la interfaz de red del plano de control no tienen ninguna ruta operativa hacia los puntos de conexión a los que debe acceder el plano de control. Lo más habitual es que falte una ruta predeterminada a un dispositivo de salida en la tabla de enrutamiento de la subred. Como alternativa, ese dispositivo está mal configurado. El dispositivo de salida suele ser una puerta de enlace de NAT. Sin embargo, puede ser una instancia de NAT, un firewall o un dispositivo proxy, o una puerta de enlace de tránsito a una VPC de salida centralizada. **Solución:** 1. Identifique las subredes que utiliza el clúster para las interfaces de red del plano de control: ``` aws eks describe-cluster --name my-cluster \ --query "cluster.resourcesVpcConfig.subnetIds" ``` 1. Para cada subred, compruebe la tabla de enrutamiento asociada: ``` aws ec2 describe-route-tables \ --filters "Name=association.subnet-id,Values=subnet-ExampleID1" ``` 1. Verifique que exista una ruta para `0.0.0.0/0` (o una ruta que cubra el punto de conexión) que dirija al dispositivo de salida. Si falta, agregue la ruta. En el siguiente ejemplo, se agrega una ruta de puerta de enlace NAT; sustituya su propio destino de salida (por ejemplo, una puerta de enlace de tránsito o una interfaz de red): ``` aws ec2 create-route \ --route-table-id rtb-ExampleID \ --destination-cidr-block 0.0.0.0/0 \ --nat-gateway-id nat-ExampleID ``` ## Las NACL bloquean el tráfico del webhook o del plano de control **Síntomas:** + Se agota el tiempo de espera de las llamadas de webhook de admisión (error: `failed calling webhook`). + Fallos intermitentes al crear o modificar recursos de Kubernetes que utilizan webhooks de mutación o validación. **Causa:** Las ACL de red de las subredes de ENI del plano de control bloquean el tráfico saliente a los puntos de conexión de los webhooks o bloquean el tráfico de retorno de los puertos efímeros entrantes. **Solución:** 1. Identifique las NACL asociadas a las subredes del plano de control: ``` aws ec2 describe-network-acls \ --filters "Name=association.subnet-id,Values=subnet-ExampleID1" ``` 1. Asegúrese de que existan las siguientes reglas:
DirecciónProtocoloRango de puertoDestino/OrigenAction
SalidaTCP4430.0.0.0/0 (o CIDR de webhook)Permitir
SalidaTCP10250CIDR de VPCPermitir
EntradaTCP1024–655350.0.0.0/0Permiso (tráfico de retorno efímero)
**nota** Las NACL no tienen estado. Debe permitir explícitamente el tráfico de retorno en los puertos efímeros (del 1024 al 65 535) en las reglas de entrada. Estas reglas cubren dos rutas diferentes. La regla del puerto 443 es para el tráfico saliente a los puntos de conexión de webhook y OIDC, que sale de la VPC a través del dispositivo de salida. La regla del puerto 10 250 es para la API de kubelet, que permanece dentro de la VPC entre el plano de control y los nodos. La falta de un dispositivo de salida no afecta al puerto 10 250, pero una ACL de red restrictiva puede bloquearlo. ## Grupos de seguridad que impiden el acceso **Síntomas:** + Las llamadas al webhook fallan. + El plano de control no puede acceder a la API de kubelet en los nodos (puerto 10 250). + `kubectl exec`, `kubectl logs` o `kubectl port-forward` fallan. **Causa:** El grupo de seguridad adjunto a las ENI del plano de control (el *grupo de seguridad del clúster*) no permite el tráfico saliente en los puertos necesarios. **Solución:** 1. Identifique el grupo de seguridad del clúster: ``` aws eks describe-cluster --name my-cluster \ --query "cluster.resourcesVpcConfig.clusterSecurityGroupId" ``` 1. Verifique que las reglas de salida permitan lo siguiente:
ProtocoloPuertoDestino
TCP4430.0.0.0/0 (puntos de conexión de webhook, proveedores de OIDC)
TCP10250Grupo de seguridad de nodos o CIDR de VPC (API de kubelet)
1. Si las reglas de salida son restrictivas, agregue reglas para el tráfico necesario: ``` aws ec2 authorize-security-group-egress \ --group-id sg-ExampleClusterSG \ --protocol tcp \ --port 443 \ --cidr 0.0.0.0/0 ``` **nota** Si tiene requisitos de salida estrictos y conoce los intervalos de IP de los puntos de conexión de webhook y OIDC, puede aplicar la regla del puerto 443 a esos CIDR específicos en lugar de `0.0.0.0/0`. La regla del puerto 10 250 (API de kubelet) es interna de la VPC, aplíquela al grupo de seguridad del nodo o al CIDR de la VPC, en lugar de a Internet. ## Error al actualizar el conjunto de opciones de DHCP **Síntomas:** + La resolución de DNS falla desde el plano de control. + Las operaciones de clúster que requieren búsquedas de DNS (detección de OIDC, resolución de webhooks) fallan. + El problema aparece después de cambiar las opciones de DHCP de la VPC o después de una actualización del plano de control. **Causa:** Se cambió el conjunto de opciones de DHCP de la VPC. Como alternativa, no incluye `AmazonProvidedDNS` en sus servidores de nombres de dominio. También podría faltar otro solucionador que pueda resolver los nombres que necesita el plano de control. El plano de control detecta automáticamente los cambios en el conjunto de opciones de DHCP y aplica la nueva configuración de DNS, normalmente en el plazo de una hora. El plano de control solo puede hacerlo cuando el rol de IAM del clúster concede los permisos de lectura de Amazon EC2 necesarios. **Solución:** 1. Verifique el conjunto de opciones de DHCP de la VPC: ``` aws ec2 describe-vpcs --vpc-ids vpc-ExampleID \ --query "Vpcs[0].DhcpOptionsId" \ --region region-code ``` ``` aws ec2 describe-dhcp-options --dhcp-options-ids dopt-ExampleID --region region-code ``` 1. Confirme que `domain-name-servers` incluya `AmazonProvidedDNS` (el solucionador de DNS proporcionado por Amazon, que es la base del CIDR IPv4 de su VPC más dos) u otro solucionador que pueda resolver los nombres que necesita el plano de control. 1. Confirme que el rol de IAM del clúster conceda `ec2:DescribeVpcs` y `ec2:DescribeDhcpOptions`. Sin estos permisos, el plano de control no puede leer las opciones de DHCP actualizadas ni actualizar la configuración de DNS. Para obtener más información, consulte [Rol de IAM del clúster de Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/cluster-iam-role.html). 1. Después de cambiar las opciones de DHCP, espere hasta una hora para que el plano de control detecte y aplique la nueva configuración automáticamente. No es necesario actualizar el clúster ni reemplazar la instancia. Si la resolución de DNS continúa fallando después de una hora y se cumplen los permisos anteriores, contacte con AWS Support. ## Problemas de enrutamiento de IPv6 **Síntomas:** + Los clústeres IPv6 no pueden acceder a los puntos de conexión de OIDC o webhook externos. + El registro de nodos funciona a través de IPv4, pero los servicios IPv6 fallan. **Causa:** En la tabla de enrutamiento de subredes falta una ruta `::/0` a una puerta de enlace de Internet de solo salida, o los grupos de seguridad o NACL no permiten el tráfico IPv6. **Solución:** 1. Verifique que exista una puerta de enlace de Internet de solo salida y que esté conectada a la VPC: ``` aws ec2 describe-egress-only-internet-gateways \ --filters "Name=attachment.vpc-id,Values=vpc-ExampleID" ``` 1. Compruebe que la tabla de enrutamiento de las subredes del plano de control tenga una ruta `::/0`: ``` aws ec2 describe-route-tables \ --filters "Name=association.subnet-id,Values=subnet-ExampleID1" \ --query "RouteTables[0].Routes[?DestinationIpv6CidrBlock=='::/0']" ``` 1. Si falta, agregue la ruta: ``` aws ec2 create-route \ --route-table-id rtb-ExampleID \ --destination-ipv6-cidr-block ::/0 \ --egress-only-internet-gateway-id eigw-ExampleID ``` 1. Asegúrese de que las NACL y los grupos de seguridad permitan el tráfico IPv6 saliente por el puerto 443 y los puertos efímeros entrantes. ## No se puede acceder al proveedor de OIDC **Síntomas:** + `IAM roles for service accounts` (IRSA) falla: los pods no pueden asumir roles. + Los eventos del clúster muestran errores de detección de OIDC. **Causa:** El plano de control no puede llegar al punto de conexión del proveedor de OIDC (por ejemplo, `oidc.eks.region-code.amazonaws.com`) porque la salida está bloqueada. **Solución:** 1. Verifique que la ruta de salida y la tabla de enrutamiento permitan el tráfico HTTPS saliente. Para ver los pasos de solución de problemas cuando falta la ruta de salida o está mal configurada, consulte [No hay ruta de salida a los puntos de conexión necesarios](#egress-troubleshoot-natgw). 1. Verifique que el grupo de seguridad del clúster permita el tráfico TCP 443 saliente a `0.0.0.0/0` (consulte [Grupos de seguridad que impiden el acceso](#egress-troubleshoot-sg)). 📝 [Edite esta página en GitHub](https://github.com/search?q=repo%3Aawsdocs%2Famazon-eks-user-guide+%5B%23control-plane-egress-troubleshooting%5D&type=code)