Добро попладне, сакам да го споделам со вас моето искуство во поставувањето и користењето на услугата AWS EKS (Elastic Kubernetes Service) за контејнерите на Windows, поточно за неможноста да се користи и грешката пронајдена во контејнерот на системот AWS, за оние кои се заинтересирани за оваа услуга за контејнери на Windows, ве молиме под мачка.
Знам дека контејнерите на Windows не се популарна тема и малкумина ги користат, но сепак решив да ја напишам оваа статија, бидејќи имаше неколку статии на Habré на кубернетите и Windows и сè уште има такви луѓе.
почеток
Се започна кога беше одлучено услугите во нашата компанија да се мигрираат на kubernetes, што е 70% Windows и 30% Linux. За таа цел, облак услугата AWS EKS се сметаше како една од можните опции. До 8 октомври 2019 година, AWS EKS Windows беше во јавен преглед, почнав со него, таму се користеше старата 1.11 верзија на kubernetes, но сепак решив да ја проверам и да видам во која фаза е оваа облак услуга, дали работи воопшто, како што се испостави, не, таму беше грешка со додавање на отстранување на подови, додека старите престанаа да реагираат преку интерна ип од истата подмрежа како јазолот на работникот на Windows.
Затоа, беше одлучено да се откаже од употребата на AWS EKS во корист на нашиот сопствен кластер на kubernetes на истиот EC2, само што ќе треба да го опишеме целото балансирање и HA самите преку CloudFormation.
Поддршката за контејнер на Windows EKS на Amazon сега е општо достапна
од Мартин Биби | на 08 ОКТ 2019 г
Пред да имам време да додадам образец во CloudFormation за мојот сопствен кластер, ја видов оваа вест
Се разбира, ја оставив целата работа настрана и почнав да проучувам што направија за ГА и како сè се смени со Јавен преглед. Да, AWS, добро направено, ги ажурираше сликите за windows worker node до верзијата 1.14, како и самиот кластер, верзија 1.14 во EKS, сега ги поддржува windows јазлите. Проект од Јавен преглед на Тие го прикриваа и рекоа сега користете ја официјалната документација овде:
Интегрирање на 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, само наведете го ID на вашите подмрежи, а eksctl ќе го одреди самиот VPC.
За да се осигурате дека вашите работнички јазли се распоредени само на приватна подмрежа, треба да наведете --node-private-networking за јазлеста група.
2. Во нашиот кластер инсталираме vpc-контролер, кој потоа ќе ги обработува нашите работнички јазли, броејќи го бројот на бесплатни IP адреси, како и бројот на ENI на примерокот, додавајќи и отстранувајќи ги.
eksctl utils install-vpc-controllers --name yyy --approve3. Откако контејнерите на вашиот систем ќе бидат успешно лансирани на вашиот работник јазол на linux, вклучувајќи го и vpc-контролерот, останува само да се создаде друга јазла група со работници на 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-networkingОткако вашиот јазол успешно се поврза со вашиот кластер и се чини дека сè е во ред, тој е во статус Подготвен, но не.
Грешка во vpc-контролерот
Ако се обидеме да извршиме подлоги на јазол работник на Windows, ќе ја добиеме грешката:
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 адреси на примерокот за да може да ги користат подлогите.
Ајде да ги погледнеме дневниците на подлогата за vpc-контролер и ова е она што го гледаме:
кубектл дневник -n кубе-систем
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 Support и кажете им ја суштината на проблемот со цел куп логови од секаде и докажете им дека нивната услуга не работи при користење на вашиот VPC и подмрежи, не за џабе имавме поддршка за бизнис, треба да користите барем еднаш :)
Комуникација со инженерите на AWS
Откако направив тикет на порталот, по грешка избрав да ми одговорам преку веб - е-пошта или центар за поддршка, преку оваа опција тие можат да ви одговорат после неколку дена, и покрај тоа што мојот билет имаше сериозност - систем нарушен, што значеше одговор во рок од <12 часа, а бидејќи планот за деловна поддршка има 24/7 поддршка, се надевав на најдоброто, но испадна како и секогаш.
Тикетот ми остана неназначен од петок до понеделник, потоа решив повторно да им пишам и ја избрав опцијата Chat одговор. По кратко чекање, Харшад Мадхав беше назначен да ме види, а потоа почна ...
Дебагиравме со него на интернет 3 часа по ред, пренесувајќи логови, распоредувајќи го истиот кластер во лабораторијата AWS за да го емулираме проблемот, повторно креирајќи го кластерот од моја страна и така натаму, единственото нешто на што дојдовме е дека од во дневниците беше јасно дека резолуцијата не работи AWS внатрешни имиња на домени, за кои напишав погоре, и Харшад Мадхав ме замоли да создадам проследување, наводно користиме сопствен DNS и ова може да биде проблем.
Товар
ap-xxx.compute.internal -> 10.x.x.2 (VPC CIDRBlock)
amazonaws.com -> 10.x.x.2 (VPC CIDRBlock)Тоа е она што беше направено, денот заврши. Харшад Махав му напиша назад за да го провери и треба да работи, но не, резолуцијата воопшто не помогна.
Потоа имаше комуникација со уште 2 инженери, едниот едноставно испадна од разговорот, очигледно се плашеше од сложен случај, вториот ми го помина денот повторно на цел циклус на дебагирање, испраќање логови, создавање кластери од двете страни, во крај само добро кажа, мене ми оди, еве ме јас правам се чекор по чекор во официјалната документација и ти и ти ќе успееш.
На што учтиво го замолив да си замине и да додели некој друг на мојот билет ако не знаеш каде да го бараш проблемот.
Финале
Третиот ден ми беше назначен нов инженер Арун Б., кој од самиот почеток на комуникацијата со него веднаш беше јасно дека тоа не се 3-те претходни инженери. Ја прочитал целата историја и веднаш побарал да ги собере дневниците користејќи своја сопствена скрипта на ps1, која била на неговиот github. Повторно следеа сите повторувања на создавање кластери, издавање резултати од команди, собирање логови, но Арун Б. се движеше во вистинската насока судејќи според прашањата што ми беа поставени.
Кога стигнавме до точка да овозможиме -stderrthreshold=debug во нивниот vpc-контролер, и што се случи потоа? се разбира, не работи) подлогата едноставно не започнува со оваа опција, работи само -stderrthreshold=info.
Завршивме тука и Арун Б. рече дека ќе се обиде да ги репродуцира моите чекори за да ја добие истата грешка. Следниот ден добив одговор од Арун Б. тој не го напушти овој случај, туку го зеде кодот за преглед на нивниот vpc-контролер и го најде местото каде што е и зошто не работи:
Така, ако ја користите главната табела за рути во вашиот VPC, тогаш стандардно таа нема асоцијации со потребните подмрежи, кои се толку неопходни за vpc-контролерот, во случај на јавна подмрежа, таа има приспособена табела за рути што има асоцијација.
Со рачно додавање на асоцијации за главната табела на маршрути со потребните подмрежи и повторно креирање на јазлеста група, сè функционира совршено.
Се надевам дека Arun B. навистина ќе ја пријави оваа грешка кај програмерите на EKS и ќе видиме нова верзија на vpc-контролер каде што сè ќе функционира надвор од кутијата. Моментално најновата верзија е: 602401143452.dkr.ecr.ap-southeast-1.amazonaws.com/eks/vpc-resource-controller:0.2.1
го има овој проблем.
Ви благодариме на сите што прочитаа до крај, тестирајте сè што ќе го користите во производството пред имплементацијата.
Извор: www.habr.com