Habari za mchana, ninataka kushiriki nawe uzoefu wangu katika kusanidi na kutumia huduma ya AWS EKS (Elastic Kubernetes Service) kwa vyombo vya Windows, au tuseme juu ya kutowezekana kwa kuitumia, na hitilafu inayopatikana kwenye chombo cha mfumo wa AWS, kwa wale. ambao wanavutiwa na huduma hii kwa vyombo vya Windows, tafadhali chini ya paka.
Ninajua kuwa vyombo vya Windows sio mada maarufu, na watu wachache huzitumia, lakini bado niliamua kuandika nakala hii, kwani kulikuwa na nakala kadhaa juu ya Habre kwenye kubernetes na Windows na bado kuna watu kama hao.
mwanzo
Yote ilianza ilipoamuliwa kuhamishia huduma katika kampuni yetu hadi kubernetes, ambayo ni 70% Windows na 30% Linux. Kwa kusudi hili, huduma ya wingu ya AWS EKS ilizingatiwa kuwa mojawapo ya chaguo zinazowezekana. Hadi Oktoba 8, 2019, AWS EKS Windows ilikuwa katika Muhtasari wa Umma, nilianza nayo, toleo la zamani la 1.11 la kubernetes lilitumika hapo, lakini niliamua kuiangalia na kuona huduma hii ya wingu ilikuwa katika hatua gani, ikiwa inafanya kazi. kabisa, kama ilivyotokea, hapana, kulikuwa na mdudu na kuongeza ya kuondoa maganda, wakati wale wa zamani waliacha kujibu kupitia ip ya ndani kutoka kwa subnet sawa na node ya mfanyakazi wa madirisha.
Kwa hivyo, iliamuliwa kuachana na matumizi ya AWS EKS ili kupendelea nguzo yetu wenyewe kwenye kubernetes kwenye EC2 hiyo hiyo, tu ndio tungelazimika kuelezea kusawazisha na HA sisi wenyewe kupitia CloudFormation.
Usaidizi wa Kontena ya Windows EKS ya Amazon sasa Unapatikana kwa Ujumla
na Martin Beeby | tarehe 08 OCT 2019
Kabla sijawa na wakati wa kuongeza kiolezo kwa CloudFormation kwa nguzo yangu mwenyewe, niliona habari hii
Kwa kweli, niliweka kazi yangu yote kando na nikaanza kusoma kile walichofanya kwa GA, na jinsi kila kitu kilibadilika na hakiki ya Umma. Ndiyo, AWS, imefanya vizuri, ilisasisha picha za nodi ya mfanyakazi wa windows kwa toleo la 1.14, pamoja na nguzo yenyewe, toleo la 1.14 katika EKS, sasa inasaidia nodi za windows. Project by Public Preview at Waliifunika na kusema sasa tumia hati rasmi hapa:
Kuunganisha nguzo ya EKS kwenye VPC ya sasa na nyati ndogo
Katika vyanzo vyote, kwenye kiunga kilicho hapo juu kwenye tangazo na vile vile kwenye hati, ilipendekezwa kupeleka nguzo hiyo kupitia shirika la umiliki la ekstl au kupitia CloudFormation + kubectl baada ya, kwa kutumia tu subnets za umma huko Amazon, na pia kuunda a. tenga VPC kwa nguzo mpya.
Chaguo hili halifai kwa wengi; kwanza, VPC tofauti inamaanisha gharama za ziada kwa gharama yake + kutazama trafiki kwa VPC yako ya sasa. Je, wale ambao tayari wana miundombinu iliyotengenezwa tayari katika AWS na akaunti zao za Multiple AWS, VPC, subnets, meza za njia, lango la usafiri na kadhalika? Bila shaka, hutaki kuvunja au kufanya upya haya yote, na unahitaji kuunganisha nguzo mpya ya EKS kwenye miundombinu ya mtandao ya sasa, kwa kutumia VPC iliyopo na, kwa kutenganisha, kwa kiasi kikubwa kuunda subnets mpya za nguzo.
Kwa upande wangu, njia hii ilichaguliwa, nilitumia VPC iliyopo, nikaongeza subnets 2 tu za umma na subnets 2 za kibinafsi kwa nguzo mpya, kwa kweli, sheria zote zilizingatiwa kulingana na nyaraka. .
Pia kulikuwa na sharti moja: hakuna nodi za wafanyikazi katika subnets za umma kwa kutumia EIP.
eksctl dhidi ya CloudFormation
Nitafanya uhifadhi mara moja kwamba nilijaribu njia zote mbili za kupeleka nguzo, katika hali zote mbili picha ilikuwa sawa.
Nitaonyesha mfano tu kwa kutumia eksctl kwani nambari hapa itakuwa fupi. Kutumia eksctl, peleka nguzo katika hatua 3:
1. Tunaunda kundi lenyewe + nodi ya mfanyakazi wa Linux, ambayo baadaye itapangisha vyombo vya mfumo na kidhibiti hicho cha vpc-fated.
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-networkingIli kupeleka kwa VPC iliyopo, bainisha tu kitambulisho cha subnets zako, na eksctl itabainisha VPC yenyewe.
Ili kuhakikisha kuwa nodi zako za wafanyikazi zimetumwa kwa subnet ya kibinafsi tu, unahitaji kubainisha --node-private-networking kwa nodegroup.
2. Tunaweka kidhibiti cha vpc kwenye kikundi chetu, ambacho kitashughulikia nodi za wafanyikazi wetu, kuhesabu idadi ya anwani za IP za bure, pamoja na nambari ya ENIs kwenye mfano, kuziongeza na kuziondoa.
eksctl utils install-vpc-controllers --name yyy --approve3.Baada ya kontena zako za mfumo kuzinduliwa kwa ufanisi kwenye nodi ya mfanyakazi wa Linux, ikiwa ni pamoja na kidhibiti cha vpc, kilichobaki ni kuunda kikundi kingine chenye wafanyakazi wa madirisha.
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-networkingBaada ya nodi yako kuunganishwa kwa mafanikio kwenye nguzo yako na kila kitu kinaonekana kuwa sawa, iko katika hali ya Tayari, lakini hapana.
Hitilafu katika kidhibiti cha vpc
Ikiwa tutajaribu kuendesha maganda kwenye nodi ya mfanyakazi wa windows, tutapata kosa:
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]Ikiwa tutaangalia zaidi, tunaona kuwa mfano wetu katika AWS unaonekana kama hii:
Na inapaswa kuwa kama hii:
Kutoka kwa hili ni wazi kwamba mtawala wa vpc hakutimiza sehemu yake kwa sababu fulani na hakuweza kuongeza anwani mpya za IP kwa mfano ili pods ziweze kuzitumia.
Wacha tuangalie magogo ya ganda la mtawala wa vpc na hii ndio tunaona:
kubectl logi -n mfumo wa 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.Utafutaji kwenye Google haukuongoza kwa chochote, kwa kuwa inaonekana hakuna mtu aliyepata mdudu kama huyo bado, au alikuwa hajachapisha suala juu yake, ilibidi nifikirie chaguzi mwenyewe kwanza. Jambo la kwanza lililokuja akilini ni kwamba labda kidhibiti cha vpc hakiwezi kutatua ip-10-xxx.ap-xxx.compute.internal na kuifikia na kwa hivyo makosa kutokea.
Ndiyo, kwa hakika, tunatumia seva maalum za DNS katika VPC na, kimsingi, hatutumii za Amazon, kwa hivyo hata usambazaji haukusanidiwa kwa kikoa hiki cha ap-xxx.compute.internal. Nilijaribu chaguo hili, na haikuleta matokeo, labda mtihani haukuwa safi, na kwa hiyo, zaidi, wakati wa kuwasiliana na msaada wa kiufundi, nilishindwa na wazo lao.
Kwa kuwa hakukuwa na maoni yoyote, vikundi vyote vya usalama viliundwa na eksctl yenyewe, kwa hivyo hakukuwa na shaka juu ya utumishi wao, meza za njia pia zilikuwa sahihi, nat, dns, ufikiaji wa mtandao na nodi za wafanyikazi pia zilikuwepo.
Zaidi ya hayo, ikiwa utapeleka nodi ya mfanyakazi kwenye subnet ya umma bila kutumia -nodi-private-networking, nodi hii ilisasishwa mara moja na kidhibiti cha vpc na kila kitu kilifanya kazi kama saa.
Kulikuwa na chaguzi mbili:
- Kutoa na kusubiri hadi mtu aelezee mdudu huu katika AWS na airekebishe, na kisha unaweza kutumia salama AWS EKS Windows, kwa sababu imetolewa tu katika GA (siku 8 zimepita wakati wa kuandika makala hii), wengi pengine fuata njia sawa na mimi.
- Andika kwa Msaada wa AWS na uwaambie kiini cha tatizo na rundo zima la magogo kutoka kila mahali na uwathibitishie kuwa huduma yao haifanyi kazi unapotumia VPC yako na subnets, sio bure kwamba tulikuwa na usaidizi wa Biashara, unapaswa kutumia. angalau mara moja :)
Mawasiliano na wahandisi wa AWS
Baada ya kuunda tikiti kwenye tovuti, nilichagua kunijibu kimakosa kupitia Wavuti - barua pepe au kituo cha usaidizi, kupitia chaguo hili wanaweza kukujibu baada ya siku chache kabisa, licha ya ukweli kwamba tikiti yangu ilikuwa na Ukali - Mfumo umeharibika, ambayo ilimaanisha jibu ndani ya <saa 12, na kwa kuwa mpango wa usaidizi wa Biashara una usaidizi wa 24/7, nilitarajia bora, lakini ikawa kama kawaida.
Tikiti yangu iliachwa bila kukabidhiwa kuanzia Ijumaa hadi Jumatatu, kisha niliamua kuwaandikia tena na kuchagua chaguo la majibu ya Chat. Baada ya kusubiri kwa muda mfupi, Harshad Madhav aliteuliwa kuniona, na ndipo ikaanza...
Tulitatua nayo mtandaoni kwa saa 3 mfululizo, tukihamisha magogo, tukipeleka kundi moja kwenye maabara ya AWS ili kuiga tatizo, kuunda tena nguzo kwa upande wangu, na kadhalika, jambo pekee tulilokuja nalo ni kwamba kutoka. kumbukumbu ilikuwa wazi kuwa suluhisho halifanyi kazi majina ya kikoa ya AWS, ambayo niliandika juu yake hapo juu, na Harshad Madhav aliniuliza niunde usambazaji, inadaiwa tunatumia DNS maalum na hii inaweza kuwa shida.
Uhamishaji
ap-xxx.compute.internal -> 10.x.x.2 (VPC CIDRBlock)
amazonaws.com -> 10.x.x.2 (VPC CIDRBlock)Hilo ndilo lililofanywa, siku ilikuwa imepita.
Halafu kulikuwa na mawasiliano na wahandisi wengine 2, mmoja aliacha tu kwenye gumzo, inaonekana aliogopa kesi ngumu, ya pili ilitumia siku yangu tena kwenye mzunguko kamili wa kurekebisha, kutuma magogo, kuunda nguzo pande zote mbili, kwenye mwisho alisema vizuri tu, inanifanyia kazi, hapa nilipo nafanya kila kitu hatua kwa hatua katika nyaraka rasmi na wewe na wewe utafanikiwa.
Ambayo kwa upole nilimwomba aondoke na kumpa mtu mwingine tiketi yangu ikiwa hujui wapi kutafuta tatizo.
Finale
Siku ya tatu, mhandisi mpya Arun B. alipewa kwangu, na tangu mwanzo wa mawasiliano naye ilikuwa wazi mara moja kwamba huyu hakuwa wahandisi 3 wa awali. Alisoma historia nzima na mara moja akauliza kukusanya magogo kwa kutumia hati yake mwenyewe kwenye ps1, ambayo ilikuwa kwenye github yake. Hii ilifuatwa tena na marudio yote ya kuunda vikundi, kutoa matokeo ya amri, kukusanya kumbukumbu, lakini Arun B. alikuwa akisogea katika mwelekeo sahihi akihukumu kwa maswali niliyoulizwa.
Je, ni lini tulifikia hatua ya kuwezesha -stderrthreshold=debug katika kidhibiti chao cha vpc, na nini kilifanyika baadaye? kwa kweli haifanyi kazi) ganda haianzi na chaguo hili, tu -stderrthreshold=info inafanya kazi.
Tulimaliza hapa na Arun B. akasema kwamba angejaribu kuzaliana hatua zangu ili kupata hitilafu sawa. Siku iliyofuata nilipokea jibu kutoka kwa Arun B. hakuacha kesi hii, lakini alichukua msimbo wa mapitio ya mtawala wao wa vpc na akapata mahali ilipo na kwa nini haifanyi kazi:
Kwa hivyo, ikiwa unatumia jedwali kuu la njia kwenye VPC yako, basi kwa chaguo-msingi haina uhusiano na subnets muhimu, ambazo ni muhimu sana kwa mtawala wa vpc, katika kesi ya subnet ya umma, ina meza ya njia maalum. ambayo ina muungano.
Kwa kuongeza manually vyama kwa meza kuu ya njia na subnets muhimu, na kuunda tena nodegroup, kila kitu kinafanya kazi kikamilifu.
Ninatumai kwamba Arun B. ataripoti hitilafu hii kwa wasanidi wa EKS na tutaona toleo jipya la kidhibiti cha vpc ambapo kila kitu kitafanya kazi nje ya boksi. Kwa sasa toleo jipya zaidi ni: 602401143452.dkr.ecr.ap-southeast-1.amazonaws.com/eks/vpc-resource-controller:0.2.1
ana tatizo hili.
Shukrani kwa kila mtu ambaye alisoma hadi mwisho, jaribu kila kitu utakachotumia katika uzalishaji kabla ya utekelezaji.
Chanzo: mapenzi.com