No se puede crear un clúster de AWS EKS con eksctl desde una PC con Windows 10. Aquí está el comando que estoy ejecutando
eksctl create cluster --name revit --version 1.17 --region ap-southeast-2 --fargate
Versión de eksctl: 0.25.0
Versión de la CLI de AWS: aws-cli/2.0.38 Python/3.7.7 Windows/10 exe/AMD64
Error al ejecutar el comando de creación de clúster
2020-08-08T19:05:35+10:00 [ℹ] eksctl version 0.25.0 2020-08-08T19:05:35+10:00 [ℹ] using region ap-southeast-2 2020-08-08T19:05:35+10:00 [!] retryable error (RequestError: send request failed caused by: Put "http://169.254.169.254/latest/api/token": dial tcp 169.254.169.254:80: connectex: A socket operation was attempted to an unreachable network.) from ec2metadata/GetToken - will retry after delay of 54.121635ms 2020-08-08T19:05:35+10:00 [!] retryable error (RequestError: send request failed caused by: Put "http://169.254.169.254/latest/api/token": dial tcp 169.254.169.254:80: connectex: A socket operation was attempted to an unreachable network.) from ec2metadata/GetToken - will retry after delay of 86.006168msTuve el mismo error, me deshice de él al proporcionar mis credenciales de AWS para el acceso programático (ID de clave de acceso de AWS, clave de acceso secreta de AWS):
$ aws configure La próxima vez que usé eksctl , simplemente no intentó autenticarse por sí solo y pasó el comando.
Sospecho que esto está relacionado con esto: https://aws.amazon.com/blogs/security/defense-in-depth-open-firewalls-reverse-proxies-ssrf-vulnerabilities-ec2-instance-metadata-service/
Específicamente:
Protección contra cortafuegos abiertos de capa 3 y NAT Por último, hay una última capa de defensa en IMDSv2 que está diseñada para proteger las instancias EC2 que se han configurado incorrectamente como enrutadores abiertos, cortafuegos de capa 3, VPN, túneles o dispositivos NAT. Con IMDSv2, la respuesta PUT que contiene el token secreto, de forma predeterminada, no podrá viajar fuera de la instancia. Esto se logra al establecer el tiempo de vida (TTL) predeterminado en los paquetes IP de bajo nivel que contienen el token secreto en "1", mucho más bajo que un valor típico, como "64". El hardware y el software que manejan paquetes, incluidas las instancias EC2, restan 1 del campo TTL de cada paquete cada vez que lo transmiten. Si el TTL llega a 0, el paquete se descarta y se envía un mensaje de error al remitente. Por lo tanto, un paquete con un TTL de "64" puede hacer sesenta y cuatro "saltos" en una red antes de abandonar, mientras que un paquete con un TTL de "1" puede existir solo en uno. Esta función permite que el tráfico legítimo llegue a un destino previsto, pero está diseñada para evitar que los paquetes se desplacen sin cesar en círculos si hay un bucle en la red.
¿Está por casualidad ejecutando el comando anterior desde un contenedor lanzado en modo puente? Tuve un problema similar. Si ese es el caso, puede ejecutarlo usando --network host o pasando los créditos como variables del sistema.