Bona tarda, vull compartir amb vosaltres la meva experiència en la configuració i ús del servei AWS EKS (Elastic Kubernetes Service) per a contenidors de Windows, o més aviat sobre la impossibilitat d'utilitzar-lo, i l'error trobat al contenidor del sistema AWS, per a aquells que estiguin interessats en aquest servei per a contenidors Windows, si us plau, sota el cat.
Sé que els contenidors de Windows no són un tema popular, i poca gent els fa servir, però encara vaig decidir escriure aquest article, ja que hi havia un parell d'articles sobre Habré a kubernetes i Windows i encara hi ha gent així.
Начало
Tot va començar quan es va decidir migrar els serveis de la nostra empresa a kubernetes, que és un 70% Windows i un 30% Linux. Per a això, es va considerar el servei al núvol AWS EKS com una de les opcions possibles. Fins al 8 d'octubre de 2019, AWS EKS Windows estava en vista prèvia pública, vaig començar amb ell, allà s'utilitzava l'antiga versió 1.11 de kubernetes, però vaig decidir comprovar-ho de totes maneres i veure en quina fase es trobava aquest servei al núvol, si funcionava. en absolut, com va resultar, no, hi havia un error amb l'addició d'eliminar les beines, mentre que els antics van deixar de respondre a través d'IP interna des de la mateixa subxarxa que el node de Windows Worker.
Per tant, es va decidir abandonar l'ús d'AWS EKS en favor del nostre propi clúster en kubernetes al mateix EC2, només hauríem de descriure tot l'equilibri i HA nosaltres mateixos mitjançant CloudFormation.
El suport de contenidors de Windows d'Amazon EKS ara disponible generalment
de Martin Beeby | el 08 d'octubre de 2019
Abans de tenir temps d'afegir una plantilla a CloudFormation per al meu propi clúster, vaig veure aquesta notícia
Per descomptat, vaig deixar tota la meva feina de banda i vaig començar a estudiar què van fer per GA i com va canviar tot amb Public Preview. Sí, AWS, ben fet, va actualitzar les imatges del node de treball de Windows a la versió 1.14, així com el propi clúster, versió 1.14 a EKS, ara admet els nodes de Windows. Projecte de Public Preview a Ho van cobrir i van dir que ara feu servir la documentació oficial aquí:
Integració d'un clúster EKS a la VPC i les subxarxes actuals
En totes les fonts, a l'enllaç anterior a l'anunci, així com a la documentació, es va proposar desplegar el clúster mitjançant la utilitat eksctl patentada o mitjançant CloudFormation + kubectl després, només utilitzant subxarxes públiques a Amazon, així com crear un VPC independent per a un clúster nou.
Aquesta opció no és adequada per a molts; en primer lloc, un VPC independent significa costos addicionals pel seu cost + trànsit de peering al vostre VPC actual. Què haurien de fer aquells que ja tenen una infraestructura preparada a AWS amb els seus propis comptes AWS múltiples, VPC, subxarxes, taules de rutes, passarel·la de trànsit, etc.? Per descomptat, no voleu trencar o refer tot això, i cal integrar el nou clúster EKS a la infraestructura de xarxa actual, utilitzant el VPC existent i, per separar-lo, com a màxim crear noves subxarxes per al clúster.
En el meu cas, es va triar aquest camí, vaig utilitzar el VPC existent, vaig afegir només 2 subxarxes públiques i 2 subxarxes privades per al nou clúster, per descomptat, es van tenir en compte totes les regles segons la documentació. .
També hi havia una condició: no hi havia nodes de treball a les subxarxes públiques que utilitzessin EIP.
eksctl vs CloudFormation
Faré una reserva de seguida que he provat els dos mètodes de desplegament d'un clúster, en ambdós casos la imatge era la mateixa.
Mostraré un exemple només utilitzant eksctl, ja que el codi aquí serà més curt. Amb eksctl, implementeu el clúster en 3 passos:
1. Creem el propi clúster + el node de treball de Linux, que després allotjarà els contenidors del sistema i el mateix controlador vpc desafortunat.
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-networkingPer implementar-lo en una VPC existent, només cal que especifiqueu l'identificador de les vostres subxarxes i eksctl determinarà la VPC.
Per assegurar-vos que els vostres nodes de treball només es despleguen a una subxarxa privada, heu d'especificar --node-private-networking per al grup de nodes.
2. Instal·lem vpc-controller al nostre clúster, que després processarà els nostres nodes de treball, comptant el nombre d'adreces IP lliures, així com el nombre d'ENI a la instància, afegint-los i eliminant-los.
eksctl utils install-vpc-controllers --name yyy --approve3.Un cop els contenidors del vostre sistema s'hagin llançat amb èxit al vostre node de treball de Linux, inclòs el controlador vpc, només queda crear un altre grup de nodes amb treballadors 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-networkingUn cop el vostre node s'ha connectat correctament al vostre clúster i tot sembla estar bé, es troba en estat A punt, però no.
Error al vpc-controller
Si intentem executar pods en un node de treballador de Windows, obtindrem l'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 mirem més a fons, veiem que la nostra instància a AWS té aquest aspecte:
I hauria de ser així:
D'això queda clar que el controlador vpc no va complir la seva part per algun motiu i no va poder afegir noves adreces IP a la instància perquè els pods poguessin utilitzar-les.
Mirem els registres del pod del controlador vpc i això és el que veiem:
registre 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.Les cerques a Google no van conduir a res, ja que pel que sembla ningú encara havia detectat aquest error, o no hi havia publicat cap problema, primer vaig haver de pensar jo mateix en les opcions. El primer que em va venir al cap va ser que potser el vpc-controller no pot resoldre ip-10-xxx.ap-xxx.compute.internal i arribar-hi i, per tant, es produeixen errors.
Sí, de fet, fem servir servidors DNS personalitzats a la VPC i, en principi, no fem servir els d'Amazon, de manera que ni tan sols es va configurar el reenviament per a aquest domini ap-xxx.compute.internal. Vaig provar aquesta opció i no va donar resultats, potser la prova no estava neta i, per tant, a més, quan em vaig comunicar amb el suport tècnic, vaig sucumbir a la seva idea.
Com que realment no hi havia idees, tots els grups de seguretat van ser creats pel mateix eksctl, de manera que no hi havia cap dubte sobre la seva utilitat, les taules de ruta també eren correctes, nat, dns, també hi havia accés a Internet amb nodes de treball.
A més, si desplegueu un node de treball a una subxarxa pública sense utilitzar —node-private-networking, aquest node es va actualitzar immediatament pel controlador vpc i tot funcionava com un rellotge.
Hi havia dues opcions:
- Renuncieu-hi i espereu fins que algú descrigui aquest error a AWS i el solucioni, i llavors podeu utilitzar AWS EKS Windows amb seguretat, perquè s'acaben de llançar a GA (han passat 8 dies en el moment d'escriure aquest article), probablement molts ho faran. segueix el mateix camí que jo.
- Escriviu a AWS Support i expliqueu-los l'essència del problema amb un munt de registres des de tot arreu i demostreu-los que el seu servei no funciona quan feu servir la vostra VPC i les vostres subxarxes, no en va teníem suport empresarial, hauríeu d'utilitzar almenys una vegada :)
Comunicació amb enginyers d'AWS
Després d'haver creat un bitllet al portal, vaig optar erròniament per respondre-me a través del web - correu electrònic o centre d'assistència, a través d'aquesta opció us poden respondre al cap d'uns dies, malgrat que el meu bitllet tenia Severitat - Sistema deteriorat, que significava una resposta en menys de 12 hores, i com que el pla d'assistència empresarial té assistència les 24 hores del dia, els 7 dies de la setmana, esperava el millor, però va resultar com sempre.
El meu bitllet es va deixar sense assignar de divendres a dilluns, després vaig decidir escriure'ls de nou i vaig triar l'opció de resposta al xat. Després d'esperar una estona, Harshad Madhav va ser designat per veure'm, i després va començar...
Hem depurat amb ell en línia durant 3 hores seguides, transferint registres, desplegant el mateix clúster al laboratori d'AWS per emular el problema, tornar a crear el clúster per part meva, i així successivament, l'únic que hem arribat és que de als registres estava clar que la resolució no funcionava amb els noms de domini intern d'AWS, sobre els quals vaig escriure més amunt, i Harshad Madhav em va demanar que creés un reenviament, suposadament utilitzem DNS personalitzat i això podria ser un problema.
Reenviament
ap-xxx.compute.internal -> 10.x.x.2 (VPC CIDRBlock)
amazonaws.com -> 10.x.x.2 (VPC CIDRBlock)Això és el que es va fer, el dia s'havia acabat. Harshad Madhav va respondre per comprovar-ho i hauria de funcionar, però no, la resolució no va ajudar gens.
Després hi va haver comunicació amb 2 enginyers més, un simplement va abandonar el xat, pel que sembla que tenia por d'un cas complex, el segon em va tornar a passar el dia en un cicle complet de depuració, enviant registres, creant clústers a banda i banda, en el al final acaba de dir bé, em funciona, aquí estic ho faig tot pas a pas a la documentació oficial i tu i tu ho aconseguiràs.
A la qual cosa li vaig demanar educadament que marxés i assigni algú altre al meu bitllet si no saps on buscar el problema.
Final
El tercer dia, em van assignar un nou enginyer Arun B. i des del primer moment de la comunicació amb ell va quedar clar de seguida que no eren els 3 enginyers anteriors. Va llegir tota la història i va demanar immediatament que recollissin els registres utilitzant el seu propi script a ps1, que estava al seu github. Això va ser seguit de nou per totes les iteracions de creació de clústers, resultats d'ordres, recopilació de registres, però Arun B. s'estava movent en la direcció correcta a jutjar per les preguntes que em van fer.
Quan vam arribar al punt d'habilitar -stderrthreshold=debug al seu controlador vpc i què va passar després? per descomptat, no funciona) el pod simplement no comença amb aquesta opció, només funciona -stderrthreshold=info.
Hem acabat aquí i Arun B. va dir que intentaria reproduir els meus passos per obtenir el mateix error. L'endemà rebo una resposta d'Arun B. no va abandonar aquest cas, sinó que va agafar el codi de revisió del seu controlador vpc i va trobar el lloc on es troba i per què no funciona:
Així, si utilitzeu la taula d'encaminament principal a la vostra VPC, per defecte no té associacions amb les subxarxes necessàries, tan necessàries per al controlador vpc, en el cas d'una subxarxa pública, té una taula d'encaminament personalitzada. que té una associació.
Afegint manualment associacions per a la taula de rutes principal amb les subxarxes necessàries i tornant a crear el grup de nodes, tot funciona perfectament.
Espero que l'Arun B. informi realment d'aquest error als desenvolupadors de l'EKS i veurem una nova versió de vpc-controller on tot funcionarà des de la caixa. Actualment, la darrera versió és: 602401143452.dkr.ecr.ap-southeast-1.amazonaws.com/eks/vpc-resource-controller:0.2.1
té aquest problema.
Gràcies a tots els que llegiu fins al final, proveu tot el que utilitzareu a la producció abans de la implementació.
Font: www.habr.com