Dea-tráthnóna, ba mhaith liom mo thaithí a roinnt leat maidir le seirbhís AWS EKS (Seirbhís Leaisteacha Kubernetes) a bhunú agus a úsáid le haghaidh coimeádáin Windows, nó ina áit sin faoin dodhéanta é a úsáid, agus an fabht a fhaightear i gcoimeádán an chórais AWS, dóibh siúd a bhfuil suim acu sa tseirbhís seo le haghaidh coimeádáin Windows, le do thoil faoi cat.
Tá a fhios agam nach ábhar coitianta iad coimeádáin Windows, agus is beag duine a úsáideann iad, ach chinn mé fós an t-alt seo a scríobh, ós rud é go raibh cúpla alt ar Habré ar kubernetes agus Windows agus fós tá daoine den sórt sin ann.
Tosaigh
Thosaigh sé ar fad nuair a socraíodh na seirbhísí inár gcuideachta a aistriú go kubernetes, is é sin 70% Windows agus 30% Linux. Chun na críche sin, measadh go raibh seirbhís scamall AWS EKS mar cheann de na roghanna féideartha. Go dtí 8 Deireadh Fómhair, 2019, bhí AWS EKS Windows i Réamhamhairc Poiblí, thosaigh mé leis, baineadh úsáid as an sean-leagan 1.11 de kubernetes ann, ach chinn mé é a sheiceáil ar aon nós agus a fheiceáil cén chéim a bhí an tseirbhís scamall seo, cibé an raibh sé ag obair ar chor ar bith, mar a d'éirigh sé amach, ní hea, bhí fabht ann nuair a cuireadh pods ar shiúl, agus stop na sean-cinn ag freagairt trí IP inmheánach ón bhfo-líon céanna leis an nód oibrithe fuinneoga.
Mar sin, socraíodh úsáid AWS EKS a thréigean i bhfabhar ár mbraisle féin ar kubernetes ar an EC2 céanna, ní bheadh orainn ach cur síos a dhéanamh ar an gcothromaíocht agus ar an HA féin trí CloudFormation.
Tacaíocht Coimeádán Windows Amazon EKS Ar Fáil go Ginearálta anois
le Martin Beeby | ar 08 Deireadh Fómhair 2019
Sula raibh am agam teimpléad a chur le CloudFormation do mo bhraisle féin, chonaic mé an nuacht seo
Ar ndóigh, chuir mé mo chuid oibre ar fad ar leataobh agus thosaigh mé ag déanamh staidéir ar an méid a rinne siad do GA, agus ar an gcaoi a d'athraigh gach rud le Réamhamhairc Poiblí. Sea, rinne AWS, go maith, na híomhánna a nuashonrú le haghaidh nód oibrithe fuinneoga go leagan 1.14, chomh maith leis an mbraisle féin, leagan 1.14 in EKS, tacaíonn sé le nóid fuinneoga anois. Tionscadal le Réamhamhairc Phoiblí ag Chlúdaigh siad é agus dúirt siad anois úsáid a bhaint as an doiciméadú oifigiúil anseo:
Cnuasach EKS a chomhtháthú leis an VPC reatha agus na folíonta
I ngach foinse, sa nasc thuas ar an bhfógra chomh maith leis an doiciméadú, beartaíodh an braisle a imscaradh tríd an bhfóntas eksctl dílseánaigh nó trí CloudFormation + kubectl after, ag baint úsáide as ach subnets poiblí in Amazon, chomh maith le cruthú a VPC ar leith do bhraisle nua.
Níl an rogha seo oiriúnach do go leor; ar an gcéad dul síos, ciallaíonn VPC ar leith costais bhreise dá chostas + ag breathnú ar thrácht ar do VPC reatha. Cad ba cheart dóibh siúd a bhfuil bonneagar réidh acu cheana féin in AWS a bhfuil a gcuntais Iolracha AWS féin, VPC, folíonta, táblaí bealaigh, geata idirthurais agus mar sin de a dhéanamh? Ar ndóigh, níl tú ag iarraidh é seo go léir a bhriseadh nó a athdhéanamh, agus ní mór duit an braisle EKS nua a chomhtháthú leis an mbonneagar líonra reatha, ag baint úsáide as an VPC atá ann cheana féin agus, le haghaidh scaradh, ar a mhéad folíonta nua a chruthú don bhraisle.
I mo chás, roghnaíodh an cosán seo, d'úsáid mé an VPC atá ann cheana féin, chuir mé ach 2 subnets poiblí agus 2 subnets príobháideacha leis an mbraisle nua, ar ndóigh, cuireadh na rialacha go léir san áireamh de réir na ndoiciméad .
Bhí coinníoll amháin ann freisin: gan aon nóid oibrithe i bhfolíonta poiblí a úsáideann EIP.
eksctl vs CloudFormation
Déanfaidh mé áirithint láithreach gur bhain mé triail as an dá mhodh chun braisle a imscaradh, bhí an pictiúr mar a chéile sa dá chás.
Ní thaispeánfaidh mé sampla ach ag baint úsáide as eksctl ós rud é go mbeidh an cód anseo níos giorra. Ag baint úsáide as eksctl, imscaradh an braisle i 3 chéim:
1. Cruthaímid an braisle féin + nód oibrí Linux, a óstach níos déanaí ar choimeádáin chórais agus an rialtóir vpc-fuath céanna sin.
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-networkingChun imscaradh chuig VPC atá ann cheana féin, ní gá ach aitheantas do chuid folíonta a shonrú, agus cinnfidh eksctl an VPC féin.
Chun a chinntiú nach n-imscartar do nóid oibrithe ach chuig folíon príobháideach, ní mór duit --node-private-networking a shonrú le haghaidh nódghrúpa.
2. Suiteáil muid vpc-rialtóir inár mbraisle, a phróiseálfaidh ár nóid oibrithe ansin, ag comhaireamh líon na seoltaí IP saor in aisce, chomh maith le líon na ENI ar an gcás, ag cur leo agus á mbaint amach.
eksctl utils install-vpc-controllers --name yyy --approve3.Tar éis do choimeádáin chórais seoladh go rathúil ar do nód oibrithe Linux, lena n-áirítear vpc-controller, níl fágtha ach nódghrúpa eile a chruthú le hoibrithe fuinneoga.
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-networkingTar éis do nód a bheith ceangailte go rathúil le do bhraisle agus is cosúil go bhfuil gach rud go breá, tá sé i stádas Réidh, ach níl.
Earráid sa rialtóir vpc
Má dhéanaimid iarracht pods a rith ar nód oibrithe fuinneoga, gheobhaidh muid an earráid:
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]Má fhéachaimid níos doimhne, feicimid go bhfuil an chuma seo ar ár n-áit in AWS:
Agus ba chóir go mbeadh sé mar seo:
Ón seo tá sé soiléir nár chomhlíon an vpc-rialtóir a chuid ar chúis éigin agus nach bhféadfadh sé seoltaí IP nua a chur leis an ásc ionas go bhféadfadh na pods iad a úsáid.
Breathnaímid ar logaí an phod rialaitheora vpc agus seo a fheicimid:
logáil kubectl -n cube-córas
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.Ní raibh aon rud mar thoradh ar chuardaigh ar Google, mar de réir dealraimh ní raibh fabht den sórt sin gafa ag éinne go fóill, nó nach raibh ceist curtha air, bhí orm smaoineamh ar roghanna mé féin ar dtús. Ba é an chéad rud a tháinig chun cuimhne ná b'fhéidir nach féidir leis an rialtóir vpc ip-10-xxx.ap-xxx.compute.internal a réiteach agus é a bhaint amach agus mar sin tarlaíonn earráidí.
Sea, go deimhin, bainimid úsáid as freastalaithe DNS saincheaptha sa VPC agus, i bprionsabal, ní úsáidimid cinn Amazon, mar sin ní raibh fiú cur ar aghaidh cumraithe don fhearann ap-xxx.compute.internal seo. Thástáil mé an rogha seo, agus níor thug sé torthaí, b'fhéidir nach raibh an tástáil glan, agus dá bhrí sin, a thuilleadh, nuair a bhí mé ag déanamh cumarsáide le tacaíocht theicniúil, ghéill mé dá smaoineamh.
Ós rud é nach raibh aon smaointe ann i ndáiríre, chruthaigh eksctl féin gach grúpa slándála, agus mar sin ní raibh aon amhras ann faoina inseirbhíse, bhí na táblaí bealaigh ceart freisin, bhí rochtain Idirlín le nóid oibrithe ann freisin.
Ina theannta sin, má imscarann tú nód oibrithe chuig folíon poiblí gan úsáid a bhaint as —nód-príobháideach-líonra, rinne an rialtóir vpc an nód seo a nuashonrú láithreach agus d'oibrigh gach rud mar obair clog.
Bhí dhá rogha ann:
- Tabhair suas é agus fan go dtí go ndéanann duine cur síos ar an bhfabht seo in AWS agus go ndéanann siad é a shocrú, agus ansin is féidir leat AWS EKS Windows a úsáid go sábháilte, toisc go bhfuil siad díreach tar éis scaoileadh i GA (8 lá imithe ag am scríofa an ailt seo), is dócha go mbeidh go leor lean an cosán céanna liomsa .
- Scríobh chuig Tacaíocht AWS agus inis dóibh an croílár na faidhbe le bunch iomlán de logs ó gach áit agus a chruthú dóibh nach n-oibríonn a gcuid seirbhíse nuair a úsáid do VPC agus subnets, nach bhfuil sé do rud ar bith go raibh muid tacaíocht Gnó, ba chóir duit a úsáid. uair amháin ar a laghad :)
Cumarsáid le hinnealtóirí AWS
Tar éis ticéad a chruthú ar an tairseach, roghnaigh mé trí dhearmad freagra a thabhairt orm tríd an nGréasán - ríomhphost nó ionad tacaíochta, tríd an rogha seo is féidir leo tú a fhreagairt tar éis cúpla lá ar chor ar bith, in ainneoin go raibh déine ar mo thicéad - Lagú ar an gcóras, a chiallaigh freagra laistigh <12 uair an chloig, agus ós rud é go bhfuil an plean tacaíochta Gnó tacaíocht 24/7, bhí súil agam le haghaidh an chuid is fearr, ach d'éirigh sé amach mar i gcónaí.
Fágadh mo thicéad gan shannadh ón Aoine go dtí an Luan, ansin bheartaigh mé scríobh chucu arís agus roghnaigh mé an rogha freagartha Comhrá. Tar éis fanacht ar feadh tamaill ghearr, ceapadh Harshad Madhav chun mé a fheiceáil, agus ansin thosaigh sé ...
Rinneamar dífhabhtaithe leis ar líne ar feadh 3 uair i ndiaidh a chéile, ag aistriú logaí, ag imscaradh an bhraisle chéanna i saotharlann AWS chun aithris a dhéanamh ar an bhfadhb, ag athchruthú an bhraisle ar mo thaobh, agus mar sin de, is é an t-aon rud a tháinig muid chuige ná sin ó na logs bhí sé soiléir nach raibh an resol ag obair ainmneacha fearainn inmheánacha AWS, a scríobh mé faoi thuas, agus Harshad Madhav iarr orm a chruthú ar aghaidh, líomhnaítear go n-úsáideann muid DNS saincheaptha agus d'fhéadfadh sé seo a bheith ina fhadhb.
Ag dul ar aghaidh
ap-xxx.compute.internal -> 10.x.x.2 (VPC CIDRBlock)
amazonaws.com -> 10.x.x.2 (VPC CIDRBlock)Sin a rinneadh, tháinig deireadh leis an lá. Scríobh Harshad Madhav ar ais lena sheiceáil agus ba cheart go n-oibreodh sé, ach ní hea, níor chabhraigh an rún ar chor ar bith.
Ansin bhí cumarsáid ann le 2 innealtóir níos mó, thit ceann amháin as an gcomhrá, is cosúil go raibh eagla air roimh chás casta, chaith an dara ceann mo lá arís ar thimthriall iomlán dífhabhtaithe, ag seoladh logaí, ag cruthú braislí ar an dá thaobh, sa deireadh a dúirt sé go maith, oibríonn sé domsa, anseo tá mé ag déanamh gach rud céim ar chéim sa doiciméadú oifigiúil agus beidh tú féin agus tú rath.
D’iarr mé go múinte air imeacht agus duine eile a shannadh do mo thicéad mura bhfuil a fhios agat cá háit a lorgódh an fhadhb.
Deiridh
Ar an tríú lá, sannadh innealtóir nua Arun B. dom, agus ó thús na cumarsáide leis bhí sé soiléir láithreach nach é seo na 3 innealtóirí roimhe seo. Léigh sé an stair iomlán agus d'iarr sé láithreach na logaí a bhailiú ag baint úsáide as a script féin ar ps1, a bhí ar a github. Ina dhiaidh sin arís rinneadh gach atriall maidir le braislí a chruthú, torthaí orduithe a aschur, logaí a bhailiú, ach bhí Arun B. ag bogadh sa treo ceart ag breith ar na ceisteanna a cuireadh orm.
Cathain a shroicheamar an pointe chun -stderrthreshold=debug a chumasú ina rialtóir vpc, agus cad a tharla ina dhiaidh sin? ar ndóigh ní oibríonn sé) ní thosaíonn an pod leis an rogha seo, ach oibríonn -stderrthreshold=info.
Chríochnaíomar anseo agus dúirt Arun B. go ndéanfadh sé iarracht mo chéimeanna a atáirgeadh chun an earráid chéanna a fháil. An lá dár gcionn gheobhaidh mé freagra ó Arun B. níor thréig sé an cás seo, ach ghlac sé le cód athbhreithnithe a rialtóra vpc agus fuair sé an áit ina bhfuil sé agus cén fáth nach n-oibríonn sé:
Mar sin, má úsáideann tú an príomh-tábla bealaigh i do VPC, ansin de réir réamhshocraithe níl baint aige leis na folíonta riachtanacha, atá chomh riachtanach don rialtóir vpc, i gcás fo-líon poiblí, tá tábla bealaigh saincheaptha aige. go bhfuil cumann.
Trí chomhlachais a chur leis de láimh don phríomhthábla bealaigh leis na subnets riachtanacha, agus an nódghrúpa a athchruthú, oibríonn gach rud go foirfe.
Tá súil agam go ndéanfaidh Arun B. an fabht seo a thuairisciú i ndáiríre d'fhorbróirí EKS agus feicfimid leagan nua de vpc-controller ina n-oibreoidh gach rud as an mbosca. Is é an leagan is déanaí faoi láthair: 602401143452.dkr.ecr.ap-southeast-1.amazonaws.com/eks/vpc-resource-controller:0.2.1
an fhadhb seo.
Buíochas le gach duine a léann go dtí an deireadh, déan tástáil ar gach rud atá tú ag dul a úsáid i dtáirgeadh sula gcuirtear i bhfeidhm é.
Foinse: will.com