Добры дзень, жадаю падзяліцца з вамі сваім досведам па наладзе і выкарыстанню сэрвісу AWS EKS (Elastic Kubernetes Service) для Windows кантэйнераў, а дакладней аб немагчымасці яго выкарыстання, і знойдзеным багу ў сістэмным кантэйнеры AWS, тым каму цікавы гэты сэрвіс для Windows кантэйнераў, просьба пад кат.
Ведаю што windows кантэйнеры не папулярная тэма, і мала хто карыстаецца імі, але ўсё ж вырашыў напісаць гэты артыкул, бо на Хабры было пару артыкулаў па kubernetes і windows і такія людзі ўсё ж такі ёсць.
Пачатак
Усё пачалося з таго, што сэрвісы ў нашай кампаніі вырашана было міграваць у kubernetes, гэта 70% windows і 30% linux. Для гэтага як адзін з магчымых варыянтаў разглядаўся хмарны сэрвіс AWS EKS. Да 8 кастрычніка 2019 AWS EKS Windows быў у Public Preview, я пачаў з яго, версія kubernetes там выкарыстоўвалася старая 1.11, але я вырашыў праверыць яго ўсё роўна і паглядзець на якім этапе дадзены хмарны сэрвіс, ці працаздольны наогул, як аказалася не, там быў баг з даданнем выдаленнем подаў, пры гэтым старыя пераставалі адгукацца па ўнутраным ip з той жа падсеткі дзе і windows worker node.
Таму было прынята рашэнне адмовіцца ад выкарыстання AWS EKS у карысць уласнага кластара на kubernetes на тых жа EC2, толькі ўсё балансаванне і HA прыйшлося б апісваць самому праз CloudFormation.
Amazon EKS Windows Container Support Generally Available
by Martin Beeby | on 08 OCT 2019
Не паспеў я дапісаць template у CloudFormation для ўласнага кластара, як убачыў гэтую навіну
Я вядома ж адклаў усе свае напрацоўкі, і прыняўся вывучаць што яны зрабілі для GA, і як усё змянілася з Public Preview. Ды AWS малайцы абнавілі выявы для windows worker node да версіі 1.14 а сам кластар версіі 1.14 у EKS зараз з падтрымкай windows nodes. Праект па Public Preview на яны прыкрылі і сказалі карыстайцеся зараз афіцыйнай дакументацыяй вось тут:
Інтэграцыя кластара EKS у бягучы VPC і падсеткі
Ва ўсіх крыніцах, у спасылцы вышэй па анонсе і ў дакументацыі, прапаноўвалася дэплоіць кластар ці праз фірмовую ўтыліту eksctl або праз CloudFormation + kubectl пасля, толькі з выкарыстаннем public падсетак у Амазоне, а таксама са стварэннем асобнага VPC пад новы кластар.
Такі варыянт падыходзіць не шматлікім, па-першае асобны VPC гэта дадатковыя выдаткі на яго кошт + пірынг трафік да вашага бягучага VPC. Што рабіць тым у каго ўжо ёсць гатовая інфраструктура ў AWS са сваімі Multiple AWS accounts, VPC, subnets, route tables, transit gateway і гэтак далей? Вядома ж не жадаецца ўсё гэта ламаць ці перарабляць, і трэба інтэграваць новы кластар EKS у бягучую сеткавую інфраструктуру, выкарыстаючы наяўны VPC ну і для падзелу максімум стварыць новыя падсеткі для кластара.
У маім выпадку і быў абраны гэты шлях, я выкарыстаў наяўны VPC дадаў толькі па 2 public падсеткі і па 2 private падсеткі для новага кластара, вядома ж усе правілы былі ўлічаныя паводле дакументацыі .
Гэтак жа была адна ўмова ні якіх worker node у public subnets з выкарыстаннем EIP.
eksctl vs CloudFormation
Абмоўлюся адразу што я спрабаваў абодва метаду дэплою кластара, у абодвух выпадках была карціна аднолькавая.
Пакажу прыклад толькі з выкарыстаннем eksctl бо код, тут карацей атрымаецца. Пры дапамозе eksctl кластар дэплоіць у 3 крокі:
1.Ствараем сам кластар + Linux worker node на якім пазней размесцяцца сістэмныя кантэйнеры і той самы злапомны vpc-controller.
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.
Каб вашы worker node дэпляваліся толькі ў private падсетку, трэба паказаць — node-private-networking для nodegroup.
2. Усталёўваны vpc-controller у наш кластар, які будзе потым апрацоўваць нашы worker nodes лічачы кол-ць вольных ip адрасоў, а гэтак жа кол-ць ENI на інстансе, дадаючы і выдаляючы іх.
eksctl utils install-vpc-controllers --name yyy --approve3. Пасля таго як вашы сістэмныя кантэйнеры паспяхова запусціліся на вашай linux worker node у тым ліку vpc-controller, засталося толькі стварыць яшчэ адну nodegroup з windows workers.
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Пасля таго як ваша нода паспяхова зачапілася да вашага кластара і ўсё быццам бы добра яна ў статусе Ready, але не.
Памылка ў vpc-controller
Калі паспрабаваць запусціць pods на windows worker node то мы атрымаем памылку:
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-controller не адпрацаваў сваю частку па нейкім чынніку і не змог дадаць новых ip-адрасоў на інстанс, каб іх маглі выкарыстаць pod-ы.
Лезем глядзець логі pod-а vpc-controller і вось што мы бачым:
kubectl log -n kube-system
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.Пошукі ў гугле ні да чаго не прывялі, бо такі баг мабыць ні хто не злавіў яшчэ, ну ці не запосціў issue па ім, прыйшлося думаць спачатку варыянты самому. Першае што прыйшло ў галаву так гэта магчыма vpc-controller не можа адрэзалвіць ip-10-xxx.ap-xxx.compute.internal і дастукацца да яго і таму памылкі валяцца.
Так, сапраўды ў нас выкарыстоўваюцца кастамныя dns сервера ў VPC і амазонаўскія мы ў прынцыпе не выкарыстоўваем таму нават forwarding не быў наладжаны на гэты дамен ap-xxx.compute.internal. Я праверыў гэты варыянт, і ен не прынёс вынікаў, магчыма тэст быў не чыстым, і таму далей пры зносінах з тэхпадтрымкай я паддаўся на іх ідэю.
Бо ідэй асабліва не было, усе security group ствараліся самім eksctl таму верыць у іх спраўнасць не было сумневу, табліцы маршрутаў таксама былі правільнымі, nat, dns, доступ у інтэрнэт з worker nodes таксама быў.
Пры гэтым калі задэплоіць worker node у public падсетку без выкарыстання - node-private-networking, гэтая нода тут жа абнаўлялася vpc-controller-ом і ўсё працавала як гадзіннік.
Варыянтаў было два:
- Забіць і пачакаць пакуль хто тое апіша баг гэты ў AWS і яны яго выправяць і потым можна спакойна карыстацца AWS EKS Windows, бо яны толькі зарэлізаваліся ў GA(мінула 8 дзён на момант напісання артыкула), напэўна шматлікія пайдуць па тым жа шляху што і я .
- Напісаць у AWS Support і выкласці ім сутнасць праблемы са ўсім пачкам логаў адусюль і даказаць ім што іх сэрвіс не працуе пры выкарыстанні свайго VPC і падсетак, нездарма ў нас была Business падтрымка, трэба ж яе хоць раз выкарыстаць 🙂
Зносіны з інжынерамі AWS
Стварыўшы тыкет, на партале, я памылкова абраў адказаць мне праз Web - email or support center, праз гэты варыянт яны могуць вам адказаць праз некалькі дзён наогул, пры тым што мой тыкет меў Severity - System impaired, што мела на ўвазе адказ на працягу <12 гадзін, а так як у Business support plan 24/7 падтрымка, то я спадзяваўся на лепшае, але атрымалася як заўсёды.
Мой тыкет праваляўся ў Unassigned з пятніцы да панядзелку, потым я вырашыў напісаць ім яшчэ раз і абраў варыянт адказу Chat. Нядоўга счакаўшы да мяне прызначыў Harshad Madhav, і тут пачалося…
Мы дэбажылі з ім у рэжыме онлайн гадзіны 3 запар, перадача логаў, дэплой такога ж кластара ў лабараторыі AWS для эмуляцыі праблемы, перастварэнне кластара з майго боку і гэтак далей, адзіна да чаго мы дашлі гэта тое што па логах было відаць што не працуе резол унутраных даменных імёнаў AWS пра што я пісаў вышэй, і Harshad Madhav папрасіў мяне стварыць forwarding нібыта мы выкарыстоўваем кастамны днс і гэта можа быць праблемай.
Экспедыцыя
ap-xxx.compute.internal -> 10.x.x.2 (VPC CIDRBlock)
amazonaws.com -> 10.x.x.2 (VPC CIDRBlock)Што і было зроблена, дзень скончыўся Harshad Madhav адпісаўся што правер і павінна працаваць, але не, рэзолў ні чым не дапамог.
Далей былі зносіны яшчэ з 2 інжынерамі адзін проста адваліўся ад чата, мабыць спалохаўся складанага кейса, другі выдаткаваў мой дзень на зноў поўны цыкл дэбага, перасылку логаў, стварэнне кластараў з абодвух бакоў, у выніку ён проста сказаў ну ў мяне працуе, вось я па афіцыйнай дакументацыі ўсё раблю пакрокава зрабі і ты і ў цябе ўсё атрымаецца.
На што я ветліва папрасіў яго сысці, і прызначыць на мой тыкет іншага, калі ты не ведаеш, дзе шукаць праблему.
фінал
На трэці дзень, да мяне прызначыўся новы інжынер Arun B., і з самага пачатку зносін з ім было адразу зразумела што гэта не 3 папярэднія інжынеры. Ён прачытаў усю history адразу папрасіў сабраць логі яго самапісным скрыптам на ps1 які ляжаў у яго на гітхабе. Далей рушыла ўслед зноў усе ітэрацыі стварэння кластараў, высновы вынікаў каманд, збіранне логаў, але Arun B. рухаўся ў правільным кірунку судзячы па задаваных пытаннях мне.
Калі мы дайшлі да таго каб уключыць -stderrthreshold=debug у іхнім vpc-controller, і што адбылося далей? ён вядома ж не працуе) pod проста не запускаецца з такой опцыяй, працуе толькі -stderrthreshold=info.
На гэтым мы скончылі і Arun B. сказаў што будзе спрабаваць прайграваць мае крокі, каб атрымаць такую ж памылку. На наступны дзень я атрымліваю адказ ад Arun B. ён не кінуў гэты кейс, а ўзяўся за review code іхняга vpc-controller і знайшоў ткі месца дзе яно і чаму не працуе:
Такім чынам калі вы выкарыстоўваеце main route table у вашым VPC, то па дэфолце ў яго няма асацыяцый з патрэбнымі падсеткамі, так неабходныя vpc-controller-у, у выпадку з public падсеткай, у яе кастамная route table якая мае асацыяцыю.
Дадаўшы ўручную асацыяцыі для main route table з патрэбнымі падсеткамі, і перастварыўшы nodegroup усё працуе ідэальна.
Я спадзяюся што Arun B. сапраўды паведаміць аб гэтым багу распрацоўнікам EKS і мы ўбачым новую версію vpc-controller-а дзе будзе працаваць усе са скрынкі. На дадзены момант апошняя версія: 602401143452.dkr.ecr.ap-southeast-1.amazonaws.com/eks/vpc-resource-controller:0.2.1
мае гэтую праблему.
Дзякуй усім хто дачытаў да канца, тэстуйце ўсё што збіраецеся выкарыстоўваць у production, перад укараненнем.
Крыніца: habr.com