Boas tardes, quero compartir convosco a miña experiencia na configuración e uso do servizo AWS EKS (Elastic Kubernetes Service) para contedores de Windows, ou máis ben sobre a imposibilidade de usalo, e o erro atopado no contedor do sistema AWS, para aqueles que estean interesados neste servizo para contedores de Windows, por favor no cat.
Sei que os contedores de Windows non son un tema popular, e pouca xente os usa, pero aínda así decidín escribir este artigo, xa que había un par de artigos sobre Habré en kubernetes e Windows e aínda hai xente deste tipo.
Comezar
Todo comezou cando se decidiu migrar os servizos da nosa empresa a kubernetes, que é un 70% Windows e un 30% Linux. Para este fin, considerouse o servizo na nube AWS EKS como unha das opcións posibles. Ata o 8 de outubro de 2019, AWS EKS Windows estaba en vista previa pública, comecei con el, alí utilizábase a versión antiga 1.11 de kubernetes, pero decidín comprobalo de todos os xeitos e ver en que fase estaba este servizo na nube, se estaba funcionando. en absoluto, como resultou, non, houbo un erro coa adición de eliminar pods, mentres que os antigos deixaron de responder a través da ip interna desde a mesma subrede que o nodo de Windows Worker.
Polo tanto, decidiuse abandonar o uso de AWS EKS en favor do noso propio clúster en kubernetes no mesmo EC2, só que teriamos que describir todo o equilibrio e HA nós mesmos a través de CloudFormation.
A compatibilidade de contedores de Windows de Amazon EKS agora dispoñible xeralmente
por Martin Beeby | o 08 de outubro de 2019
Antes de ter tempo para engadir un modelo a CloudFormation para o meu propio clúster, vin esta noticia
Por suposto, deixei todo o meu traballo de lado e comecei a estudar o que fixeron por GA e como cambiou todo con Public Preview. Si, AWS, ben feito, actualizou as imaxes para o nodo de Windows Worker á versión 1.14, así como o propio clúster, versión 1.14 en EKS, agora admite nodos de Windows. Proxecto por Public Preview en Cubriron e dixeron que agora usa a documentación oficial aquí:
Integrando un clúster EKS na VPC e nas subredes actuais
En todas as fontes, na ligazón anterior sobre o anuncio, así como na documentación, propúxose implantar o clúster a través da utilidade propietaria eksctl ou a través de CloudFormation + kubectl despois, só usando subredes públicas en Amazon, así como a creación dun VPC separada para un novo clúster.
Esta opción non é adecuada para moitos; en primeiro lugar, un VPC separado significa custos adicionais polo seu custo + tráfico de interconexión ao teu VPC actual. Que deberían facer aqueles que xa teñen unha infraestrutura preparada en AWS coas súas propias contas de AWS múltiples, VPC, subredes, táboas de rutas, pasarela de tránsito, etc.? Por suposto, non quere romper ou refacer todo isto, e precisa integrar o novo clúster EKS na infraestrutura de rede actual, utilizando a VPC existente e, para a separación, como máximo crear novas subredes para o clúster.
No meu caso, escolleuse este camiño, usei o VPC existente, engadín só 2 subredes públicas e 2 subredes privadas para o novo clúster, por suposto, todas as regras foron tidas en conta segundo a documentación .
Tamén había unha condición: non había nodos de traballo nas subredes públicas que usasen EIP.
eksctl vs CloudFormation
Vou facer unha reserva de inmediato que probei os dous métodos de implantación dun clúster, en ambos os casos a imaxe era a mesma.
Mostrarei un exemplo só usando eksctl xa que o código aquí será máis curto. Usando eksctl, implementa o clúster en 3 pasos:
1. Creamos o propio clúster + nodo traballador de Linux, que posteriormente aloxará contedores do sistema e ese mesmo 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 nun VPC existente, só tes que especificar o ID das túas subredes e eksctl determinará o propio VPC.
Para asegurarse de que os seus nodos de traballo se despreguen só nunha subrede privada, cómpre especificar --node-private-networking para nodegroup.
2. Instalamos vpc-controller no noso clúster, que logo procesará os nosos nodos de traballo, contando o número de enderezos IP libres, así como o número de ENIs na instancia, engadindo e eliminando.
eksctl utils install-vpc-controllers --name yyy --approve3.Despois de que os contedores do sistema se lanzaron con éxito no nodo de traballo de Linux, incluído o controlador vpc, só queda crear outro grupo de nodos con traballadores 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-networkingDespois de que o teu nodo se conecte correctamente ao teu clúster e todo parece estar ben, está no estado Listo, pero non.
Erro no controlador vpc
Se tentamos executar pods nun nodo de Windows Worker, obteremos o erro:
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]Se miramos máis a fondo, vemos que a nosa instancia en AWS ten este aspecto:
E debería ser así:
Disto é evidente que o vpc-controller non cumpriu a súa parte por algún motivo e non puido engadir novos enderezos IP á instancia para que os pods puidesen utilizalos.
Vexamos os rexistros do pod vpc-controller e isto é o que vemos:
rexistro 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.As buscas en Google non levaron a nada, xa que, ao parecer, aínda ninguén detectara un erro así, ou non publicara ningún problema, primeiro tiven que pensar en opcións. O primeiro que se me ocorreu foi que quizais o vpc-controller non poida resolver ip-10-xxx.ap-xxx.compute.internal e chegar a el e, polo tanto, se producen erros.
Si, efectivamente, usamos servidores DNS personalizados no VPC e, en principio, non usamos os de Amazon, polo que nin sequera se configurou o reenvío para este dominio ap-xxx.compute.internal. Probei esta opción, e non deu resultados, quizais a proba non estaba limpa e, polo tanto, ademais, ao comunicarme co soporte técnico, sucumbín á súa idea.
Como realmente non había ideas, todos os grupos de seguridade foron creados polo propio eksctl, polo que non había dúbida sobre a súa utilidade, as táboas de rutas tamén eran correctas, nat, dns, o acceso a Internet con nodos de traballo tamén estaba alí.
Ademais, se implementas un nodo de traballo nunha subrede pública sen usar —node-private-networking, este nodo foi actualizado inmediatamente polo controlador vpc e todo funcionou como un reloxo.
Había dúas opcións:
- Renuncia e agarda ata que alguén describa este erro en AWS e o solucione, e entón podes usar AWS EKS Windows con seguridade, porque acaban de lanzarse en GA (pasaron 8 días no momento de escribir este artigo), probablemente moitos o farán. segue o mesmo camiño ca min.
- Escribe ao soporte de AWS e cóntalles a esencia do problema con un montón de rexistros de todas partes e demóstralles que o seu servizo non funciona cando usas a túa VPC e as túas subredes, non é por nada que tivemos soporte empresarial, deberías usar polo menos unha vez :)
Comunicación con enxeñeiros de AWS
Despois de crear un ticket no portal, optei por erro por responderme a través da Web - correo electrónico ou centro de soporte, a través desta opción poden responderche despois duns días, a pesar de que o meu ticket tiña Gravidade - Sistema deteriorado, o que significou unha resposta nun prazo de menos de 12 horas, e como o plan de soporte empresarial ten soporte 24 horas ao día, 7 días a semana, esperaba o mellor, pero resultou como sempre.
O meu ticket quedou sen asignar desde o venres ata o luns, entón decidín escribirlles de novo e escollín a opción de resposta ao chat. Despois de esperar un pouco, Harshad Madhav foi designado para verme, e entón comezou...
Depuramos con el en liña durante 3 horas seguidas, transferimos rexistros, despregamos o mesmo clúster no laboratorio de AWS para emular o problema, volvemos crear o clúster pola miña parte, etc., o único que chegamos é que de os rexistros estaba claro que o resol non funcionaba os nomes de dominio internos de AWS, dos que escribín anteriormente, e Harshad Madhav pediume que crease o reenvío, supostamente usamos DNS personalizado e isto podería ser un problema.
Reenvío
ap-xxx.compute.internal -> 10.x.x.2 (VPC CIDRBlock)
amazonaws.com -> 10.x.x.2 (VPC CIDRBlock)Iso foi o que se fixo, o día rematou. Harshad Madhav volveu escribir para comprobalo e debería funcionar, pero non, a resolución non axudou para nada.
Despois houbo comunicación con 2 enxeñeiros máis, un simplemente abandonou o chat, ao parecer tiña medo a un caso complexo, o segundo pasoume o día de novo nun ciclo completo de depuración, envío de rexistros, creación de clusters en ambos os dous lados, no final só dixo ben, a min funciona, aquí estou fago todo paso a paso na documentación oficial e ti e ti lograrémolo.
Ao que lle pedin educadamente que marchase e asignase a outra persoa o meu billete se non sabe onde buscar o problema.
Final
O terceiro día, asignáronme un novo enxeñeiro Arun B. e desde o primeiro momento da comunicación con el quedou claro de inmediato que este non era os 3 enxeñeiros anteriores. Leu todo o historial e inmediatamente pediu que recollera os rexistros usando o seu propio script na ps1, que estaba no seu github. Isto foi seguido de novo por todas as iteracións de creación de clústeres, saída de resultados de comandos, recollida de rexistros, pero Arun B. estaba movéndose na dirección correcta a xulgar polas preguntas que me fixeron.
Cando chegamos ao punto de habilitar -stderrthreshold=debug no seu controlador vpc, e que pasou despois? por suposto que non funciona) o pod simplemente non comeza con esta opción, só funciona -stderrthreshold=info.
Rematamos aquí e Arun B. dixo que tentaría reproducir os meus pasos para obter o mesmo erro. Ao día seguinte recibo unha resposta de Arun B. non abandonou este caso, pero tomou o código de revisión do seu controlador vpc e atopou o lugar onde está e por que non funciona:
Así, se usa a táboa de rutas principal na súa VPC, entón por defecto non ten asociacións coas subredes necesarias, que son tan necesarias para o controlador vpc, no caso dunha subrede pública, ten unha táboa de rutas personalizada. que ten unha asociación.
Engadindo manualmente asociacións para a táboa de rutas principal coas subredes necesarias e recreando o grupo de nodos, todo funciona perfectamente.
Espero que Arun B. informe realmente deste erro aos desenvolvedores de EKS e vexamos unha nova versión de vpc-controller onde todo funcionará fóra da caixa. Actualmente, a última versión é: 602401143452.dkr.ecr.ap-southeast-1.amazonaws.com/eks/vpc-resource-controller:0.2.1
ten este problema.
Grazas a todos os que leron ata o final, proba todo o que vas usar na produción antes da implementación.
Fonte: www.habr.com