Buenas tardes, quiero compartir con ustedes mi experiencia en la configuración y uso del servicio AWS EKS (Elastic Kubernetes Service) para contenedores de Windows, o mejor dicho sobre la imposibilidad de usarlo, y el error encontrado en el contenedor del sistema AWS, para aquellos. Quienes estén interesados en este servicio para contenedores de Windows, por favor en cat.
Sé que los contenedores de Windows no son un tema popular y pocas personas los usan, pero aun así decidí escribir este artículo, ya que había un par de artículos sobre Habré en Kubernetes y Windows y todavía existen personas así.
principio
Todo empezó cuando se decidió migrar los servicios de nuestra empresa a kubernetes, que es 70% Windows y 30% Linux. Para ello, se consideró el servicio en la nube AWS EKS como una de las posibles opciones. Hasta el 8 de octubre de 2019, AWS EKS Windows estaba en versión preliminar pública, comencé con él, se usaba la versión anterior 1.11 de Kubernetes allí, pero decidí verificarlo de todos modos y ver en qué etapa se encontraba este servicio en la nube, si estaba funcionando. En absoluto, resultó que no, había un error al agregar la eliminación de pods, mientras que los antiguos dejaron de responder a través de la IP interna desde la misma subred que el nodo trabajador de Windows.
Por lo tanto, se decidió abandonar el uso de AWS EKS en favor de nuestro propio clúster en Kubernetes en el mismo EC2, solo que tendríamos que describir todo el equilibrio y HA nosotros mismos a través de CloudFormation.
La compatibilidad con contenedores de Windows de Amazon EKS ya está disponible con carácter general
de Martin Beeby | el 08 oct 2019
Antes de tener tiempo de agregar una plantilla a CloudFormation para mi propio clúster, vi esta noticia
Por supuesto, dejé todo mi trabajo a un lado y comencé a estudiar lo que hicieron para GA y cómo cambió todo con Public Preview. Sí, AWS, bien hecho, actualizó las imágenes para el nodo trabajador de Windows a la versión 1.14, así como el clúster en sí, la versión 1.14 en EKS, ahora admite nodos de Windows. Proyecto por vista previa pública en Lo encubrieron y dijeron que ahora usen la documentación oficial aquí:
Integración de un clúster EKS en la VPC y las subredes actuales
En todas las fuentes, en el enlace anterior al anuncio, así como en la documentación, se propuso implementar el clúster a través de la utilidad patentada eksctl o a través de CloudFormation + kubectl después, usando solo subredes públicas en Amazon, además de crear una VPC separada para un nuevo clúster.
Esta opción no es adecuada para muchos; en primer lugar, una VPC separada significa costos adicionales por su costo + tráfico de intercambio de tráfico a su VPC actual. ¿Qué deberían hacer aquellos que ya tienen una infraestructura lista para usar en AWS con sus propias cuentas múltiples de AWS, VPC, subredes, tablas de rutas, puerta de enlace de tránsito, etc.? Por supuesto, no desea romper ni rehacer todo esto, y necesita integrar el nuevo clúster EKS en la infraestructura de red actual, utilizando la VPC existente y, para la separación, como máximo crear nuevas subredes para el clúster.
En mi caso, se eligió esta ruta, utilicé la VPC existente, agregué solo 2 subredes públicas y 2 subredes privadas para el nuevo clúster, por supuesto, se tuvieron en cuenta todas las reglas según la documentación. .
También había una condición: ningún nodo trabajador en subredes públicas que utilizara EIP.
eksctl y CloudFormation
Haré una reserva de inmediato: probé ambos métodos para implementar un clúster, en ambos casos la imagen fue la misma.
Mostraré un ejemplo usando únicamente eksctl ya que el código aquí será más corto. Usando eksctl, implemente el clúster en 3 pasos:
1. Creamos el clúster en sí + el nodo trabajador de Linux, que luego albergará los contenedores del sistema y el mismo desafortunado controlador vpc.
eksctl create cluster
--name yyy
--region www
--version 1.14
--vpc-private-subnets=subnet-xxxxx,subnet-xxxxx
--vpc-public-subnets=subnet-xxxxx,subnet-xxxxx
--asg-access
--nodegroup-name linux-workers
--node-type t3.small
--node-volume-size 20
--ssh-public-key wwwwwwww
--nodes 1
--nodes-min 1
--nodes-max 2
--node-ami auto
--node-private-networkingPara implementar en una VPC existente, simplemente especifique la identificación de sus subredes y eksctl determinará la VPC en sí.
Para asegurarse de que sus nodos trabajadores se implementen solo en una subred privada, debe especificar --node-private-networking para nodegroup.
2. Instalamos vpc-controller en nuestro clúster, que luego procesará nuestros nodos trabajadores, contando la cantidad de direcciones IP libres, así como la cantidad de ENI en la instancia, agregándolas y eliminándolas.
eksctl utils install-vpc-controllers --name yyy --approve3.Después de que los contenedores de su sistema se hayan iniciado exitosamente en su nodo trabajador de Linux, incluido el controlador vpc, todo lo que queda es crear otro grupo de nodos con trabajadores de Windows.
eksctl create nodegroup
--region www
--cluster yyy
--version 1.14
--name windows-workers
--node-type t3.small
--ssh-public-key wwwwwwwwww
--nodes 1
--nodes-min 1
--nodes-max 2
--node-ami-family WindowsServer2019CoreContainer
--node-ami ami-0573336fc96252d05
--node-private-networkingDespués de que su nodo se haya conectado exitosamente a su clúster y todo parezca estar bien, estará en estado Listo, pero no.
Error en el controlador vpc
Si intentamos ejecutar pods en un nodo trabajador de Windows, obtendremos el error:
NetworkPlugin cni failed to teardown pod "windows-server-iis-7dcfc7c79b-4z4v7_default" network: failed to parse Kubernetes args: pod does not have label vpc.amazonaws.com/PrivateIPv4Address]Si miramos más profundamente, vemos que nuestra instancia en AWS se ve así:
Y debería quedar así:
De esto se desprende claramente que el controlador vpc no cumplió con su parte por algún motivo y no pudo agregar nuevas direcciones IP a la instancia para que los pods pudieran usarlas.
Miremos los registros del pod vpc-controller y esto es lo que vemos:
registro de kubectl -n sistema-kube
I1011 06:32:03.910140 1 watcher.go:178] Node watcher processing node ip-10-xxx.ap-xxx.compute.internal.
I1011 06:32:03.910162 1 manager.go:109] Node manager adding node ip-10-xxx.ap-xxx.compute.internal with instanceID i-088xxxxx.
I1011 06:32:03.915238 1 watcher.go:238] Node watcher processing update on node ip-10-xxx.ap-xxx.compute.internal.
E1011 06:32:08.200423 1 manager.go:126] Node manager failed to get resource vpc.amazonaws.com/CIDRBlock pool on node ip-10-xxx.ap-xxx.compute.internal: failed to find the route table for subnet subnet-0xxxx
E1011 06:32:08.201211 1 watcher.go:183] Node watcher failed to add node ip-10-xxx.ap-xxx.compute.internal: failed to find the route table for subnet subnet-0xxx
I1011 06:32:08.201229 1 watcher.go:259] Node watcher adding key ip-10-xxx.ap-xxx.compute.internal (0): failed to find the route table for subnet subnet-0xxxx
I1011 06:32:08.201302 1 manager.go:173] Node manager updating node ip-10-xxx.ap-xxx.compute.internal.
E1011 06:32:08.201313 1 watcher.go:242] Node watcher failed to update node ip-10-xxx.ap-xxx.compute.internal: node manager: failed to find node ip-10-xxx.ap-xxx.compute.internal.Las búsquedas en Google no condujeron a nada, ya que aparentemente nadie había detectado ese error todavía o no había publicado ningún problema al respecto, primero tuve que pensar en las opciones. Lo primero que me vino a la mente fue que quizás el vpc-controller no puede resolver ip-10-xxx.ap-xxx.compute.internal y alcanzarlo y por lo tanto ocurren errores.
Sí, efectivamente, utilizamos servidores DNS personalizados en la VPC y, en principio, no utilizamos los de Amazon, por lo que ni siquiera se configuró el reenvío para este dominio ap-xxx.compute.internal. Probé esta opción y no arrojó resultados, quizás la prueba no fue limpia y por eso, además, al comunicarme con el soporte técnico, sucumbí a su idea.
Como realmente no había ideas, todos los grupos de seguridad fueron creados por el propio eksctl, por lo que no había dudas sobre su capacidad de servicio, las tablas de rutas también eran correctas, nat, dns y el acceso a Internet con nodos trabajadores también estaban ahí.
Además, si implementa un nodo trabajador en una subred pública sin utilizar —node-private-networking, el controlador vpc actualizó inmediatamente este nodo y todo funcionó como un reloj.
Había dos opciones:
- Renuncie y espere hasta que alguien describa este error en AWS y lo solucione, y luego podrá usar AWS EKS Windows de manera segura, porque acaban de lanzarlo en GA (han pasado 8 días al momento de escribir este artículo), muchos probablemente lo harán. Sigue el mismo camino que yo.
- Escriba a AWS Support y cuénteles la esencia del problema con un montón de registros de todas partes y demuéstreles que su servicio no funciona cuando usa su VPC y subredes, no en vano tuvimos soporte empresarial, debería usar al menos una vez :)
Comunicación con ingenieros de AWS
Habiendo creado un ticket en el portal, por error elegí responderme vía Web - correo electrónico o centro de soporte, a través de esta opción pueden responderte después de unos días, a pesar de que mi ticket tenía Gravedad - Sistema deteriorado, lo cual significó una respuesta en menos de 12 horas y, dado que el plan de soporte empresarial cuenta con soporte 24 horas al día, 7 días a la semana, esperaba lo mejor, pero resultó como siempre.
Mi ticket quedó sin asignar desde el viernes hasta el lunes, entonces decidí escribirles nuevamente y elegí la opción de respuesta por chat. Después de esperar un corto tiempo, designaron a Harshad Madhav para verme, y entonces comenzó...
Lo depuramos en línea durante 3 horas seguidas, transfiriendo registros, implementando el mismo clúster en el laboratorio de AWS para emular el problema, recreando el clúster por mi parte, etc., lo único que llegamos es a eso de En los registros estaba claro que resol no funcionaba con los nombres de dominio internos de AWS, sobre los cuales escribí anteriormente, y Harshad Madhav me pidió que creara un reenvío, supuestamente usamos DNS personalizados y esto podría ser un problema.
Reenvío
ap-xxx.compute.internal -> 10.x.x.2 (VPC CIDRBlock)
amazonaws.com -> 10.x.x.2 (VPC CIDRBlock)Eso fue lo que se hizo, el día había terminado, Harshad Madhav volvió a escribir para comprobarlo y debería funcionar, pero no, la resolución no ayudó en nada.
Luego hubo comunicación con 2 ingenieros más, uno simplemente abandonó el chat, aparentemente tenía miedo de un caso complejo, el segundo nuevamente pasó mi día en un ciclo completo de depuración, enviando registros, creando clústeres en ambos lados, en el Al final solo dijo bien, a mí me funciona, aquí estoy, hago todo paso a paso en la documentación oficial y tú y tú lo lograréis.
A lo que cortésmente le pedí que se fuera y asignara a otra persona mi ticket si no sabe dónde buscar el problema.
Final
Al tercer día, me asignaron un nuevo ingeniero, Arun B., y desde el comienzo de la comunicación con él quedó inmediatamente claro que no se trataba de los 3 ingenieros anteriores. Leyó el historial completo e inmediatamente pidió recopilar los registros usando su propio script en ps1, que estaba en su github. A esto le siguieron nuevamente todas las iteraciones de creación de clústeres, generación de resultados de comandos y recopilación de registros, pero Arun B. estaba avanzando en la dirección correcta a juzgar por las preguntas que me hicieron.
¿Cuándo llegamos al punto de habilitar -stderrthreshold=debug en su vpc-controller y qué pasó después? por supuesto que no funciona) el pod simplemente no comienza con esta opción, solo funciona -stderrthreshold=info.
Terminamos aquí y Arun B. dijo que intentaría reproducir mis pasos para obtener el mismo error. Al día siguiente recibo una respuesta de Arun B. Él no abandonó este caso, pero tomó el código de revisión de su controlador vpc y encontró el lugar donde está y por qué no funciona:
Por lo tanto, si utiliza la tabla de rutas principal en su VPC, entonces, de forma predeterminada, no tiene asociaciones con las subredes necesarias, que son tan necesarias para el controlador vpc; en el caso de una subred pública, tiene una tabla de rutas personalizada. que tiene una asociación.
Al agregar manualmente asociaciones para la tabla de rutas principal con las subredes necesarias y volver a crear el grupo de nodos, todo funciona perfectamente.
Espero que Arun B. realmente informe este error a los desarrolladores de EKS y veamos una nueva versión de vpc-controller donde todo funcionará de inmediato. Actualmente la última versión es: 602401143452.dkr.ecr.ap-southeast-1.amazonaws.com/eks/vpc-resource-controller:0.2.1
tiene este problema.
Gracias a todos los que leyeron hasta el final, prueben todo lo que van a utilizar en producción antes de la implementación.
Fuente: habr.com