Добър ден, искам да споделя с вас моя опит в настройката и използването на услугата AWS EKS (Elastic Kubernetes Service) за контейнери на Windows или по-скоро за невъзможността да се използва и грешката, открита в системния контейнер на AWS, за тези които се интересуват от тази услуга за Windows контейнери, моля под кат.
Знам, че контейнерите на Windows не са популярна тема и малко хора ги използват, но все пак реших да напиша тази статия, тъй като имаше няколко статии на Habré за kubernetes и Windows и все още има такива хора.
Начало
Всичко започна, когато беше решено да мигрираме услугите в нашата компания към kubernetes, което е 70% Windows и 30% Linux. За целта като една от възможните опции беше разгледана облачната услуга AWS EKS. До 8 октомври 2019 г. AWS EKS Windows беше в Public Preview, започнах с него, там беше използвана старата версия 1.11 на kubernetes, но все пак реших да го проверя и да видя на какъв етап е тази облачна услуга, дали работи изобщо, както се оказа, не, имаше грешка с добавянето на премахване на подове, докато старите спряха да отговарят чрез вътрешно ip от същата подмрежа като windows worker node.
Затова беше решено да се откажем от използването на AWS EKS в полза на нашия собствен клъстер на kubernetes на същия EC2, само че ще трябва да опишем цялото балансиране и HA сами чрез CloudFormation.
Поддръжката на Amazon EKS Windows Container вече е общодостъпна
от Мартин Бийби | на 08 ОКТ 2019 г
Преди да имам време да добавя шаблон към CloudFormation за моя собствен клъстер, видях тази новина
Разбира се, оставих цялата си работа настрана и започнах да изучавам какво правят за GA и как всичко се променя с Public Preview. Да, AWS, браво, актуализира изображенията за windows worker node до версия 1.14, както и самия клъстер, версия 1.14 в EKS, сега поддържа windows nodes. Проект от публичен преглед на Те го покриха и казаха, че сега използвайте официалната документация тук:
Интегриране на EKS клъстер в текущия VPC и подмрежи
Във всички източници, в връзката по-горе на съобщението, както и в документацията, беше предложено разгръщането на клъстера или чрез собствената помощна програма eksctl, или чрез CloudFormation + kubectl след това, като се използват само публични подмрежи в Amazon, както и създаване на отделен VPC за нов клъстер.
Тази опция не е подходяща за мнозина; първо, отделен VPC означава допълнителни разходи за неговата цена + пиъринг трафик към текущия ви VPC. Какво трябва да направят тези, които вече имат готова инфраструктура в AWS със собствени множество акаунти в AWS, VPC, подмрежи, таблици с маршрути, транзитен шлюз и т.н.? Разбира се, не искате да прекъсвате или преработвате всичко това и трябва да интегрирате новия EKS клъстер в текущата мрежова инфраструктура, като използвате съществуващия VPC и, за разделяне, най-много да създадете нови подмрежи за клъстера.
В моя случай беше избран този път, използвах съществуващия VPC, добавих само 2 публични подмрежи и 2 частни подмрежи за новия клъстер, разбира се, всички правила бяха взети под внимание според документацията .
Имаше и едно условие: никакви работни възли в обществени подмрежи, използващи EIP.
eksctl срещу CloudFormation
Веднага ще направя резервация, че опитах и двата метода за разполагане на клъстер, и в двата случая картината беше една и съща.
Ще покажа пример само с помощта на eksctl, тъй като кодът тук ще бъде по-кратък. Използвайки eksctl, разположете клъстера в 3 стъпки:
1. Създаваме самия клъстер + работния възел на Linux, който по-късно ще хоства системни контейнери и същия този злополучен 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-networkingЗа да разположите към съществуващ VPC, просто посочете идентификатора на вашите подмрежи и eksctl ще определи самия VPC.
За да сте сигурни, че вашите работни възли са разположени само в частна подмрежа, трябва да укажете --node-private-networking за nodegroup.
2. Инсталираме vpc-контролер в нашия клъстер, който след това ще обработва нашите работни възли, преброявайки броя на свободните IP адреси, както и броя на ENI в екземпляра, като ги добавя и премахва.
eksctl utils install-vpc-controllers --name yyy --approve3. След като вашите системни контейнери са стартирани успешно на вашия Linux работен възел, включително vpc-controller, всичко, което остава, е да създадете друга група възли с Windows Worker.
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-networkingСлед като вашият възел се свърже успешно с вашия клъстер и всичко изглежда наред, той е в състояние на готовност, но не.
Грешка във vpc-контролера
Ако се опитаме да стартираме pods на windows worker възел, ще получим грешката:
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]Ако погледнем по-дълбоко, виждаме, че нашият екземпляр в AWS изглежда така:
И трябва да е така:
От това става ясно, че vpc-контролерът не е изпълнил своята част по някаква причина и не е могъл да добави нови IP адреси към инстанцията, така че pods да могат да ги използват.
Нека да разгледаме регистрационните файлове на vpc-controller pod и ето какво виждаме:
kubectl дневник -n 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.Търсенията в Google не доведоха до нищо, тъй като очевидно никой все още не беше хванал такъв бъг или не беше публикувал проблем в него, трябваше първо сам да измисля опции. Първото нещо, което ми дойде на ум беше, че може би vpc-контролерът не може да разреши ip-10-xxx.ap-xxx.compute.internal и да го достигне и следователно възникват грешки.
Да, наистина използваме персонализирани DNS сървъри във VPC и по принцип не използваме такива на Amazon, така че дори препращането не беше конфигурирано за този домейн ap-xxx.compute.internal. Тествах тази опция и тя не доведе до резултати, може би тестът не беше чист и следователно, по-нататък, когато общувах с техническата поддръжка, се поддадох на тяхната идея.
Тъй като всъщност нямаше никакви идеи, всички групи за сигурност бяха създадени от самия eksctl, така че нямаше съмнение относно тяхната работоспособност, таблиците с маршрути също бяха правилни, nat, dns, достъп до интернет с работни възли също имаше.
Освен това, ако разположите работен възел в публична подмрежа, без да използвате —node-private-networking, този възел веднага се актуализира от vpc-контролера и всичко работи като часовник.
Имаше два варианта:
- Откажете се и изчакайте, докато някой опише този бъг в AWS и той го поправи, след което можете спокойно да използвате AWS EKS Windows, защото току-що пуснати в GA (изминаха 8 дни към момента на писане на тази статия), много вероятно ще следвай същия път като мен.
- Пишете на поддръжката на AWS и им кажете същността на проблема с цял куп логове отвсякъде и им докажете, че тяхната услуга не работи, когато използвате вашите VPC и подмрежи, не напразно имахме бизнес поддръжка, трябва да използвате поне веднъж :)
Комуникация с инженерите на AWS
След като създадох тикет на портала, погрешка избрах да ми отговорят чрез уеб - имейл или център за поддръжка, чрез тази опция те могат да ви отговорят след няколко дни изобщо, въпреки факта, че моят тикет имаше Severity - System impaired, което означаваше отговор в рамките на <12 часа и тъй като планът за бизнес поддръжка има 24/7 поддръжка, надявах се на най-доброто, но се оказа както винаги.
Моят билет беше оставен неразпределен от петък до понеделник, след което реших да им пиша отново и избрах опцията за отговор в чата. След като чаках за кратко, Харшад Мадхав беше назначен да ме види и тогава започна...
Отстранявахме грешки с него онлайн в продължение на 3 часа подред, прехвърляйки регистрационни файлове, внедрявайки същия клъстер в лабораторията на AWS, за да емулираме проблема, създавайки отново клъстера от моя страна и т.н., единственото нещо, до което стигнахме е, че от от регистрационните файлове беше ясно, че resol не работи с вътрешни имена на домейни на AWS, за които писах по-горе, и Harshad Madhav ме помоли да създам пренасочване, твърди се, че използваме персонализиран DNS и това може да е проблем.
Пренасочване
ap-xxx.compute.internal -> 10.x.x.2 (VPC CIDRBlock)
amazonaws.com -> 10.x.x.2 (VPC CIDRBlock)Това беше направено, денят свърши. Harshad Madhav писа обратно, за да го провери и трябва да работи, но не, резолюцията изобщо не помогна.
След това имаше комуникация с още 2 инженера, единият просто се отказа от чата, очевидно се страхуваше от сложен случай, вторият прекара деня ми отново в пълен цикъл на отстраняване на грешки, изпращане на регистрационни файлове, създаване на клъстери от двете страни, в накрая той просто каза добре, работи за мен, ето ме правя всичко стъпка по стъпка в официалната документация и вие ще успеете.
На което учтиво го помолих да си тръгне и да назначи някой друг за моя билет, ако не знаете къде да търсите проблема.
финал
На третия ден към мен беше назначен нов инженер Арун Б. и от самото начало на комуникацията с него веднага стана ясно, че това не са предишните 3 инженери. Той прочете цялата история и веднага поиска да събере регистрационните файлове, използвайки собствения си скрипт на ps1, който беше в неговия github. Това беше последвано отново от всички повторения на създаване на клъстери, извеждане на резултати от команди, събиране на регистрационни файлове, но Арун Б. се движеше в правилната посока, съдейки по зададените ми въпроси.
Кога стигнахме до точката на активиране на -stderrthreshold=debug в техния vpc-контролер и какво се случи след това? разбира се, че не работи) pod просто не стартира с тази опция, работи само -stderrthreshold=info.
Приключихме тук и Арун Б. каза, че ще опита да възпроизведе моите стъпки, за да получи същата грешка. На следващия ден получавам отговор от Arun B. той не изостави този случай, но взе кода за преглед на техния vpc-контролер и намери мястото, където се намира и защо не работи:
По този начин, ако използвате основната маршрутна таблица във вашия VPC, тогава по подразбиране тя няма асоциации с необходимите подмрежи, които са толкова необходими за vpc-контролера, в случай на публична подмрежа, тя има персонализирана маршрутна таблица който има асоциация.
Чрез ръчно добавяне на асоциации за основната маршрутна таблица с необходимите подмрежи и повторно създаване на групата възли, всичко работи перфектно.
Надявам се, че Arun B. наистина ще докладва тази грешка на разработчиците на EKS и ще видим нова версия на vpc-controller, където всичко ще работи от кутията. В момента най-новата версия е: 602401143452.dkr.ecr.ap-southeast-1.amazonaws.com/eks/vpc-resource-controller:0.2.1
има този проблем.
Благодаря на всички, които прочетоха до края, тествайте всичко, което ще използвате в производството преди внедряване.
Източник: www.habr.com