Magandang hapon, gusto kong ibahagi sa iyo ang aking karanasan sa pag-set up at paggamit ng serbisyo ng AWS EKS (Elastic Kubernetes Service) para sa mga lalagyan ng Windows, o sa halip tungkol sa imposibilidad ng paggamit nito, at ang bug na makikita sa lalagyan ng AWS system, para sa mga na interesado sa serbisyong ito para sa mga lalagyan ng Windows, mangyaring sa ilalim ng pusa.
Alam ko na ang mga lalagyan ng Windows ay hindi sikat na paksa, at kakaunti ang gumagamit ng mga ito, ngunit nagpasya pa rin akong isulat ang artikulong ito, dahil mayroong ilang mga artikulo sa HabrΓ© sa kubernetes at Windows at mayroon pa ring ganoong mga tao.
simula
Nagsimula ang lahat nang mapagpasyahan na ilipat ang mga serbisyo sa aming kumpanya sa kubernetes, na 70% Windows at 30% Linux. Para sa layuning ito, ang serbisyo sa cloud ng AWS EKS ay itinuturing na isa sa mga posibleng opsyon. Hanggang Oktubre 8, 2019, ang AWS EKS Windows ay nasa Public Preview, sinimulan ko ito, ang lumang 1.11 na bersyon ng mga kubernetes ay ginamit doon, ngunit nagpasya akong suriin pa rin ito at tingnan kung anong yugto ang serbisyo ng cloud na ito, kung ito ay gumagana. sa lahat, bilang ito ay naging, hindi, ito ay mayroong isang bug sa pagdaragdag ng pag-alis ng mga pod, habang ang mga luma ay tumigil sa pagtugon sa pamamagitan ng panloob na ip mula sa parehong subnet bilang windows worker node.
Samakatuwid, napagpasyahan na talikuran ang paggamit ng AWS EKS pabor sa sarili nating cluster sa mga kubernetes sa parehong EC2, kailangan lang nating ilarawan ang lahat ng pagbabalanse at HA sa pamamagitan ng CloudFormation.
Ang Amazon EKS Windows Container Support ay Karaniwang Available na ngayon
ni Martin Beeby | noong 08 OCT 2019
Bago ako magkaroon ng oras upang magdagdag ng isang template sa CloudFormation para sa aking sariling kumpol, nakita ko ang balitang ito
Siyempre, isinantabi ko ang lahat ng aking trabaho at nagsimulang pag-aralan kung ano ang ginawa nila para sa GA, at kung paano nagbago ang lahat sa Public Preview. Oo, AWS, mahusay na ginawa, na-update ang mga imahe para sa windows worker node sa bersyon 1.14, pati na rin ang cluster mismo, bersyon 1.14 sa EKS, ay sumusuporta na ngayon sa mga windows node. Proyekto sa pamamagitan ng Public Preview sa Tinakpan nila ito at sinabing gamitin na ngayon ang opisyal na dokumentasyon dito:
Pagsasama ng EKS cluster sa kasalukuyang VPC at mga subnet
Sa lahat ng mga mapagkukunan, sa link sa itaas sa anunsyo pati na rin sa dokumentasyon, iminungkahi na i-deploy ang cluster alinman sa pamamagitan ng proprietary eksctl utility o sa pamamagitan ng CloudFormation + kubectl pagkatapos, gamit lamang ang mga pampublikong subnet sa Amazon, pati na rin ang paglikha ng isang hiwalay na VPC para sa isang bagong cluster.
Ang opsyong ito ay hindi angkop para sa marami; una, ang isang hiwalay na VPC ay nangangahulugan ng mga karagdagang gastos para sa gastos nito + peering na trapiko sa iyong kasalukuyang VPC. Ano ang dapat gawin ng mga mayroon nang nakahanda na imprastraktura sa AWS na may sarili nilang Multiple AWS account, VPC, subnets, route table, transit gateway at iba pa? Siyempre, hindi mo gustong sirain o gawing muli ang lahat ng ito, at kailangan mong isama ang bagong EKS cluster sa kasalukuyang imprastraktura ng network, gamit ang kasalukuyang VPC at, para sa paghihiwalay, sa karamihan ay lumikha ng mga bagong subnet para sa cluster.
Sa aking kaso, ang landas na ito ay pinili, ginamit ko ang umiiral na VPC, nagdagdag lamang ng 2 pampublikong subnet at 2 pribadong subnet para sa bagong cluster, siyempre, ang lahat ng mga patakaran ay isinasaalang-alang ayon sa dokumentasyon .
Mayroon ding isang kundisyon: walang worker node sa mga pampublikong subnet na gumagamit ng EIP.
eksctl kumpara sa CloudFormation
Magpapareserba ako kaagad na sinubukan ko ang parehong paraan ng pag-deploy ng isang cluster, sa parehong mga kaso ang larawan ay pareho.
Magpapakita ako ng isang halimbawa gamit lamang ang eksctl dahil ang code dito ay magiging mas maikli. Gamit ang eksctl, i-deploy ang cluster sa 3 hakbang:
1. Ginagawa namin ang mismong cluster + Linux worker node, na magho-host ng mga container ng system at ang parehong masamang 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-networkingUpang ma-deploy sa isang umiiral na VPC, tukuyin lamang ang id ng iyong mga subnet, at ang eksctl ang tutukoy sa VPC mismo.
Upang matiyak na ang iyong mga node ng manggagawa ay na-deploy lamang sa isang pribadong subnet, kailangan mong tukuyin ang --node-private-networking para sa nodegroup.
2. Nag-i-install kami ng vpc-controller sa aming cluster, na magpoproseso ng aming mga worker node, binibilang ang bilang ng mga libreng IP address, pati na rin ang bilang ng mga ENI sa instance, idinaragdag at aalisin ang mga ito.
eksctl utils install-vpc-controllers --name yyy --approve3.Pagkatapos matagumpay na mailunsad ang iyong mga system container sa iyong Linux worker node, kasama ang vpc-controller, ang natitira na lang ay lumikha ng isa pang nodegroup na may mga manggagawa sa 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-networkingPagkatapos na matagumpay na nakakonekta ang iyong node sa iyong cluster at mukhang maayos na ang lahat, ito ay nasa Ready na status, ngunit hindi.
Error sa vpc-controller
Kung susubukan naming magpatakbo ng mga pod sa isang windows worker node, makukuha namin ang 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]Kung titingnan natin nang mas malalim, makikita natin na ganito ang hitsura ng ating instance sa AWS:
At ito ay dapat na ganito:
Mula dito ay malinaw na ang vpc-controller ay hindi natupad ang bahagi nito para sa ilang kadahilanan at hindi maaaring magdagdag ng mga bagong IP address sa instance upang magamit ng mga pod ang mga ito.
Tingnan natin ang mga log ng vpc-controller pod at ito ang nakikita natin:
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.Ang mga paghahanap sa Google ay hindi humantong sa anumang bagay, dahil tila wala pang nakahuli ng ganoong bug, o hindi pa nakapag-post ng isyu tungkol dito, kailangan ko munang mag-isip ng mga pagpipilian sa aking sarili. Ang unang bagay na pumasok sa isip ay na marahil ang vpc-controller ay hindi maaaring malutas ang ip-10-xxx.ap-xxx.compute.internal at maabot ito at samakatuwid ay may mga error.
Oo, sa katunayan, gumagamit kami ng mga custom na DNS server sa VPC at, sa prinsipyo, hindi kami gumagamit ng mga Amazon, kaya kahit na ang pagpapasa ay hindi na-configure para sa ap-xxx.compute.internal na domain na ito. Sinubukan ko ang pagpipiliang ito, at hindi ito nagdala ng mga resulta, marahil ang pagsubok ay hindi malinis, at samakatuwid, higit pa, kapag nakikipag-usap sa teknikal na suporta, sumuko ako sa kanilang ideya.
Dahil wala talagang anumang mga ideya, ang lahat ng mga grupo ng seguridad ay nilikha ng eksctl mismo, kaya walang duda tungkol sa kanilang kakayahang magamit, ang mga talahanayan ng ruta ay tama rin, nat, dns, Internet access na may mga node ng manggagawa ay naroon din.
Bukod dito, kung mag-deploy ka ng worker node sa isang pampublikong subnet nang hindi gumagamit ng βnode-private-networking, ang node na ito ay agad na na-update ng vpc-controller at lahat ay gumana tulad ng clockwork.
Mayroong dalawang mga pagpipilian:
- Isuko ito at maghintay hanggang sa may maglarawan sa bug na ito sa AWS at ayusin nila ito, at pagkatapos ay ligtas mong magagamit ang AWS EKS Windows, dahil kakalabas lang nila sa GA (8 araw na ang lumipas sa oras ng pagsulat ng artikulong ito), marami ang malamang na sundan ang parehong landas tulad ng sa akin.
- Sumulat sa AWS Support at sabihin sa kanila ang kakanyahan ng problema sa isang buong bungkos ng mga log mula sa lahat ng dako at patunayan sa kanila na ang kanilang serbisyo ay hindi gumagana kapag ginagamit ang iyong VPC at mga subnet, ito ay hindi para sa wala na kami ay nagkaroon ng suporta sa Negosyo, dapat mong gamitin kahit minsan lang :)
Komunikasyon sa mga inhinyero ng AWS
Pagkagawa ng isang tiket sa portal, nagkamali akong pinili na tumugon sa akin sa pamamagitan ng Web - email o support center, sa pamamagitan ng opsyong ito ay masasagot ka nila pagkatapos ng ilang araw, sa kabila ng katotohanan na ang aking tiket ay may Severity - System impaired, na Nangangahulugan ang isang tugon sa loob ng <12 oras, at dahil ang plano ng suporta sa Negosyo ay may 24/7 na suporta, umaasa ako para sa pinakamahusay, ngunit ito ay naging tulad ng dati.
Ang aking tiket ay hindi naitalaga mula Biyernes hanggang Lunes, pagkatapos ay nagpasya akong sumulat muli sa kanila at pinili ang opsyon sa pagtugon sa Chat. Matapos maghintay ng maikling panahon, si Harshad Madhav ay hinirang na makita ako, at pagkatapos ay nagsimula ito...
Na-debug namin ito online sa loob ng 3 oras na magkakasunod, naglilipat ng mga log, nag-deploy ng parehong cluster sa laboratoryo ng AWS para tularan ang problema, muling gumawa ng cluster sa bahagi ko, at iba pa, ang tanging napuntahan namin ay mula sa ang mga log ay malinaw na ang resol ay hindi gumagana ang mga panloob na pangalan ng domain ng AWS, na isinulat ko tungkol sa itaas, at hiniling sa akin ni Harshad Madhav na gumawa ng pagpapasa, diumano'y gumagamit kami ng custom na DNS at ito ay maaaring maging isang problema.
pagpapasa
ap-xxx.compute.internal -> 10.x.x.2 (VPC CIDRBlock)
amazonaws.com -> 10.x.x.2 (VPC CIDRBlock)Iyon ang ginawa, natapos ang araw. Sumulat si Harshad Madhav upang suriin ito at dapat itong gumana, ngunit hindi, ang resolusyon ay hindi nakatulong.
Pagkatapos ay nagkaroon ng komunikasyon sa 2 higit pang mga inhinyero, ang isa ay umalis lamang sa chat, tila natatakot siya sa isang kumplikadong kaso, ang pangalawa ay ginugol muli ang aking araw sa isang buong cycle ng pag-debug, pagpapadala ng mga log, paglikha ng mga kumpol sa magkabilang panig, sa ending maganda lang ang sinabi niya, it works for me, eto ako ginagawa ko lahat step by step sa official documentation at magtatagumpay ka at ikaw.
Kung saan magalang kong hiniling sa kanya na umalis at magtalaga ng ibang tao sa aking tiket kung hindi mo alam kung saan hahanapin ang problema.
Huling
Sa ikatlong araw, isang bagong inhinyero na si Arun B. ang itinalaga sa akin, at mula sa simula ng pakikipag-usap sa kanya ay agad na malinaw na hindi ito ang 3 nakaraang mga inhinyero. Binasa niya ang buong kasaysayan at agad na hiniling na kolektahin ang mga log gamit ang kanyang sariling script sa ps1, na nasa kanyang github. Ito ay sinundan muli ng lahat ng mga pag-ulit ng paglikha ng mga kumpol, pag-output ng mga resulta ng command, pagkolekta ng mga log, ngunit si Arun B. ay gumagalaw sa tamang direksyon ayon sa mga tanong na itinanong sa akin.
Kailan tayo nakarating sa punto ng pagpapagana -stderrthreshold=debug sa kanilang vpc-controller, at ano ang sumunod na nangyari? siyempre hindi ito gumagana) ang pod ay hindi lamang nagsisimula sa pagpipiliang ito, tanging -stderrthreshold=info ang gumagana.
Natapos kami dito at sinabi ni Arun B. na susubukan niyang kopyahin ang aking mga hakbang upang makakuha ng parehong pagkakamali. Kinabukasan nakatanggap ako ng tugon mula kay Arun B. hindi niya pinabayaan ang kasong ito, ngunit kinuha ang review code ng kanilang vpc-controller at nakita ang lugar kung nasaan ito at kung bakit hindi ito gumagana:
Kaya, kung gagamitin mo ang pangunahing talahanayan ng ruta sa iyong VPC, kung gayon bilang default ay wala itong mga asosasyon sa mga kinakailangang subnet, na napakahalaga para sa vpc-controller, sa kaso ng isang pampublikong subnet, mayroon itong custom na talahanayan ng ruta na may asosasyon.
Sa pamamagitan ng manu-manong pagdaragdag ng mga asosasyon para sa pangunahing talahanayan ng ruta na may mga kinakailangang subnet, at muling paggawa ng nodegroup, lahat ay gumagana nang perpekto.
Umaasa ako na talagang iuulat ni Arun B. ang bug na ito sa mga developer ng EKS at makakakita tayo ng bagong bersyon ng vpc-controller kung saan gagana ang lahat sa labas ng kahon. Kasalukuyang ang pinakabagong bersyon ay: 602401143452.dkr.ecr.ap-southeast-1.amazonaws.com/eks/vpc-resource-controller:0.2.1
may ganitong problema.
Salamat sa lahat ng nagbasa hanggang sa huli, subukan ang lahat ng iyong gagamitin sa produksyon bago ang pagpapatupad.
Pinagmulan: www.habr.com