Prynhawn da, rwyf am rannu gyda chi fy mhrofiad o sefydlu a defnyddio gwasanaeth AWS EKS (Gwasanaeth Elastig Kubernetes) ar gyfer cynwysyddion Windows, neu yn hytrach am amhosibl ei ddefnyddio, a'r nam a geir yng nghynhwysydd system AWS, ar gyfer y rheini sydd â diddordeb yn y gwasanaeth hwn ar gyfer cynwysyddion Windows, os gwelwch yn dda o dan cath.
Gwn nad yw cynwysyddion Windows yn bwnc poblogaidd, ac ychydig o bobl sy'n eu defnyddio, ond penderfynais ysgrifennu'r erthygl hon o hyd, gan fod cwpl o erthyglau ar Habré ar kubernetes a Windows ac mae yna bobl o'r fath o hyd.
Dechrau
Dechreuodd y cyfan pan benderfynwyd mudo'r gwasanaethau yn ein cwmni i kubernetes, sef 70% Windows a 30% Linux. Ar gyfer hyn, ystyriwyd gwasanaeth cwmwl AWS EKS fel un o'r opsiynau posibl. Hyd at Hydref 8, 2019, roedd AWS EKS Windows mewn Rhagolwg Cyhoeddus, dechreuais ag ef, defnyddiwyd yr hen fersiwn 1.11 o kubernetes yno, ond penderfynais ei wirio beth bynnag a gweld ar ba gam yr oedd y gwasanaeth cwmwl hwn, a oedd yn gweithio o gwbl, fel y digwyddodd, na, roedd yna nam gyda'r ychwanegiad o ddileu codennau, tra bod yr hen rai yn rhoi'r gorau i ymateb trwy ip mewnol o'r un subnet â nod y gweithiwr ffenestri.
Felly, penderfynwyd rhoi'r gorau i ddefnyddio AWS EKS o blaid ein clwstwr ein hunain ar kubernetes ar yr un EC2, dim ond y byddai'n rhaid i ni ddisgrifio'r holl gydbwyso a HA ein hunain trwy CloudFormation.
Cefnogaeth Cynhwysydd Windows Amazon EKS Ar Gael yn Gyffredinol nawr
gan Martin Beeby | ar 08 Hydref 2019
Cyn i mi gael amser i ychwanegu templed i CloudFormation ar gyfer fy nghlwstwr fy hun, gwelais y newyddion hwn
Wrth gwrs, rhoddais fy holl waith o'r neilltu a dechreuais astudio'r hyn a wnaethant ar gyfer GA, a sut y newidiodd popeth gyda Rhagolwg Cyhoeddus. Do, fe ddiweddarodd AWS, yn dda, y delweddau ar gyfer nod gweithiwr ffenestri i fersiwn 1.14, yn ogystal â'r clwstwr ei hun, fersiwn 1.14 yn EKS, bellach yn cefnogi nodau ffenestri. Prosiect gan Rhagolwg Cyhoeddus yn Fe wnaethon nhw ei orchuddio a dweud nawr defnyddiwch y dogfennau swyddogol yma:
Integreiddio clwstwr EKS i'r VPC ac is-rwydweithiau cyfredol
Ym mhob ffynhonnell, yn y ddolen uchod ar y cyhoeddiad yn ogystal ag yn y ddogfennaeth, cynigiwyd defnyddio'r clwstwr naill ai trwy'r cyfleustodau perchnogol eksctl neu trwy CloudFormation + kubectl ar ôl, gan ddefnyddio is-rwydweithiau cyhoeddus yn Amazon yn unig, yn ogystal â chreu a VPC ar wahân ar gyfer clwstwr newydd.
Nid yw'r opsiwn hwn yn addas i lawer; yn gyntaf, mae VPC ar wahân yn golygu costau ychwanegol am ei gost + traffig yn edrych ar eich VPC presennol. Beth ddylai'r rhai sydd eisoes â seilwaith parod yn AWS gyda'u cyfrifon AWS Lluosog eu hunain, VPC, is-rwydweithiau, tablau llwybr, porth tramwy ac yn y blaen ei wneud? Wrth gwrs, nid ydych chi am dorri neu ail-wneud hyn i gyd, ac mae angen i chi integreiddio'r clwstwr EKS newydd i'r seilwaith rhwydwaith presennol, gan ddefnyddio'r VPC presennol ac, ar gyfer gwahanu, ar y mwyaf creu is-rwydweithiau newydd ar gyfer y clwstwr.
Yn fy achos i, dewiswyd y llwybr hwn, defnyddiais y VPC presennol, ychwanegu dim ond 2 is-rwydweithiau cyhoeddus a 2 is-rwydweithiau preifat ar gyfer y clwstwr newydd, wrth gwrs, cymerwyd yr holl reolau i ystyriaeth yn ôl y ddogfennaeth .
Roedd un amod hefyd: dim nodau gweithiwr mewn is-rwydweithiau cyhoeddus yn defnyddio EIP.
eksctl vs CloudFormation
Byddaf yn archebu ar unwaith fy mod wedi rhoi cynnig ar y ddau ddull o leoli clwstwr, yn y ddau achos roedd y darlun yr un peth.
Byddaf yn dangos enghraifft yn unig gan ddefnyddio eksctl gan y bydd y cod yma yn fyrrach. Gan ddefnyddio eksctl, defnyddiwch y clwstwr mewn 3 cham:
1. Rydym yn creu'r clwstwr ei hun + nod gweithiwr Linux, a fydd yn ddiweddarach yn cynnal cynwysyddion system a'r un vpc-rheolwr anffodus hwnnw.
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-networkingEr mwyn defnyddio VPC sy'n bodoli eisoes, nodwch id eich is-rwydweithiau, a bydd eksctl yn pennu'r VPC ei hun.
Er mwyn sicrhau bod eich nodau gweithiwr yn cael eu defnyddio i is-rwydwaith preifat yn unig, mae angen i chi nodi --node-private-networking ar gyfer nodegroup.
2. Rydyn ni'n gosod rheolydd vpc yn ein clwstwr, a fydd wedyn yn prosesu ein nodau gweithiwr, gan gyfrif nifer y cyfeiriadau IP rhad ac am ddim, yn ogystal â nifer yr ENI ar yr enghraifft, gan eu hychwanegu a'u tynnu.
eksctl utils install-vpc-controllers --name yyy --approve3.Ar ôl i'ch cynwysyddion system lansio'n llwyddiannus ar eich nod gweithiwr Linux, gan gynnwys vpc-controller, y cyfan sy'n weddill yw creu nodegroup arall gyda gweithwyr ffenestri.
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-networkingAr ôl i'ch nod gysylltu'n llwyddiannus â'ch clwstwr ac mae'n ymddangos bod popeth yn iawn, mae mewn statws Parod, ond na.
Gwall yn y rheolydd vpc
Os byddwn yn ceisio rhedeg codennau ar nod gweithiwr ffenestri, byddwn yn cael y gwall:
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]Os edrychwn yn ddyfnach, gwelwn fod ein hachos yn AWS yn edrych fel hyn:
A dylai fod fel hyn:
O hyn mae'n amlwg na chyflawnodd y rheolydd vpc ei ran am ryw reswm ac ni allai ychwanegu cyfeiriadau IP newydd at yr enghraifft fel y gallai'r codennau eu defnyddio.
Edrychwn ar foncyffion pod y rheolydd vpc a dyma a welwn:
log kubectl -n ciwb-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.Ni arweiniodd chwiliadau ar Google at unrhyw beth, oherwydd mae'n debyg nad oedd neb wedi dal byg o'r fath eto, neu heb bostio mater arno, roedd yn rhaid i mi feddwl am opsiynau fy hun yn gyntaf. Y peth cyntaf a ddaeth i'r meddwl oedd efallai na all y vpc-controller ddatrys ip-10-xxx.ap-xxx.compute.internal a'i gyrraedd ac felly mae gwallau'n digwydd.
Ydym, yn wir, rydym yn defnyddio gweinyddwyr DNS arferol yn y VPC ac, mewn egwyddor, nid ydym yn defnyddio rhai Amazon, felly nid oedd hyd yn oed anfon ymlaen wedi'i ffurfweddu ar gyfer y parth ap-xxx.compute.internal hwn. Profais yr opsiwn hwn, ac ni ddaeth â chanlyniadau, efallai nad oedd y prawf yn lân, ac felly, ymhellach, wrth gyfathrebu â chymorth technegol, ildiais i'w syniad.
Gan nad oedd unrhyw syniadau mewn gwirionedd, crëwyd yr holl grwpiau diogelwch gan eksctl ei hun, felly nid oedd amheuaeth ynghylch eu defnyddioldeb, roedd y tablau llwybr hefyd yn gywir, nat, dns, roedd mynediad i'r Rhyngrwyd gyda nodau gweithwyr yno hefyd.
Ar ben hynny, os ydych chi'n defnyddio nôd gweithiwr i is-rwydwaith cyhoeddus heb ddefnyddio —nôd-preifat-rwydweithio, cafodd y nod hwn ei ddiweddaru ar unwaith gan y rheolydd vpc ac roedd popeth yn gweithio fel clocwaith.
Roedd dau opsiwn:
- Rhowch y gorau iddi ac aros nes bod rhywun yn disgrifio'r nam hwn yn AWS a'u bod yn ei drwsio, ac yna gallwch chi ddefnyddio AWS EKS Windows yn ddiogel, oherwydd eu bod newydd ryddhau yn GA (8 diwrnod wedi mynd heibio ar adeg ysgrifennu'r erthygl hon), mae'n debyg y bydd llawer yn dilynwch yr un llwybr â mi.
- Ysgrifennwch at AWS Support a dywedwch wrthynt hanfod y broblem gyda chriw cyfan o logiau o bob man a phrofwch iddynt nad yw eu gwasanaeth yn gweithio wrth ddefnyddio'ch VPC ac is-rwydweithiau, nid am ddim y cawsom gymorth busnes, dylech ei ddefnyddio o leiaf unwaith :)
Cyfathrebu â pheirianwyr AWS
Ar ôl creu tocyn ar y porth, dewisais ar gam i ymateb i mi trwy Web - e-bost neu ganolfan gymorth, trwy'r opsiwn hwn gallant eich ateb ar ôl ychydig ddyddiau o gwbl, er gwaethaf y ffaith bod gan fy nhocyn Difrifoldeb - Nam ar y system, sy'n yn golygu ymateb o fewn <12 awr, a chan fod gan y cynllun cymorth busnes gefnogaeth 24/7, roeddwn yn gobeithio am y gorau, ond fe drodd fel bob amser.
Gadawyd fy nhocyn heb ei aseinio o ddydd Gwener tan ddydd Llun, yna penderfynais ysgrifennu atynt eto a dewis yr opsiwn ymateb Chat. Ar ôl aros am gyfnod byr, penodwyd Harshad Madhav i'm gweld, ac yna dechreuodd ...
Fe wnaethom ddadfygio ag ef ar-lein am 3 awr yn olynol, gan drosglwyddo boncyffion, defnyddio'r un clwstwr yn labordy AWS i efelychu'r broblem, ail-greu'r clwstwr ar fy rhan i, ac yn y blaen, yr unig beth y daethom ato yw hynny o y logiau roedd yn amlwg nad oedd y resol yn gweithio enwau parth mewnol AWS, yr ysgrifennais amdanynt uchod, a gofynnodd Harshad Madhav imi greu anfon ymlaen, honnir ein bod yn defnyddio DNS arferol a gallai hyn fod yn broblem.
Ymlaen
ap-xxx.compute.internal -> 10.x.x.2 (VPC CIDRBlock)
amazonaws.com -> 10.x.x.2 (VPC CIDRBlock)Dyna beth a wnaed, daeth y diwrnod i ben. Ysgrifennodd Harshad Madhav yn ôl i'w wirio a dylai weithio, ond na, ni wnaeth y penderfyniad helpu o gwbl.
Yna roedd cyfathrebu gyda 2 beirianwyr mwy, un yn syml gollwng allan o'r sgwrs, mae'n debyg ei fod yn ofni achos cymhleth, yr ail treulio fy niwrnod eto ar gylch llawn o debugging, anfon logiau, creu clystyrau ar y ddwy ochr, yn y diwedd dywedodd yn unig yn dda, mae'n gweithio i mi, dyma fi yn gwneud popeth cam wrth gam yn y ddogfennaeth swyddogol a byddwch a byddwch yn llwyddo.
Gofynnais yn gwrtais iddo adael a phenodi rhywun arall i'm tocyn os nad ydych chi'n gwybod ble i chwilio am y broblem.
Terfynol
Ar y trydydd diwrnod, neilltuwyd peiriannydd newydd Arun B. i mi, ac o'r cychwyn cyntaf o gyfathrebu ag ef roedd yn amlwg ar unwaith nad dyma'r 3 peiriannydd blaenorol. Darllenodd yr hanes cyfan a gofynnodd ar unwaith i gasglu'r logiau gan ddefnyddio ei sgript ei hun ar ps1, a oedd ar ei github. Dilynwyd hyn eto gan yr holl iteriadau o greu clystyrau, allbynnu canlyniadau gorchymyn, casglu logiau, ond roedd Arun B. yn symud i'r cyfeiriad cywir gan farnu yn ôl y cwestiynau a ofynnwyd i mi.
Pryd wnaethon ni gyrraedd y pwynt o alluogi -stderrthreshold=debug yn eu rheolydd vpc, a beth ddigwyddodd nesaf? wrth gwrs nid yw'n gweithio) nid yw'r pod yn dechrau gyda'r opsiwn hwn, dim ond -stderrthreshold=info sy'n gweithio.
Gorffenasom yma a dywedodd Arun B. y byddai'n ceisio atgynhyrchu fy nghamau i gael yr un gwall. Y diwrnod canlynol caf ymateb gan Arun B. ni roddodd y gorau i'r achos hwn, ond ymgymerodd â chod adolygu eu rheolydd vpc a chanfod y man lle mae a pham nad yw'n gweithio:
Felly, os ydych chi'n defnyddio'r prif dabl llwybr yn eich VPC, yna yn ddiofyn nid oes ganddo gysylltiadau â'r is-rwydweithiau angenrheidiol, sydd mor angenrheidiol ar gyfer y rheolydd vpc, yn achos is-rwydwaith cyhoeddus, mae ganddo dabl llwybr arferol. sydd â chysylltiad.
Trwy ychwanegu cysylltiadau â llaw ar gyfer y prif fwrdd llwybr gyda'r is-rwydweithiau angenrheidiol, ac ail-greu'r grŵp nodau, mae popeth yn gweithio'n berffaith.
Rwy'n gobeithio y bydd Arun B. wir yn adrodd y bug hwn i ddatblygwyr EKS a byddwn yn gweld fersiwn newydd o vpc-controller lle bydd popeth yn gweithio allan o'r bocs. Ar hyn o bryd y fersiwn diweddaraf yw: 602401143452.dkr.ecr.ap-southeast-1.amazonaws.com/eks/vpc-resource-controller:0.2.1
sydd â'r broblem hon.
Diolch i bawb sy'n darllen hyd y diwedd, profwch bopeth rydych chi'n mynd i'w ddefnyddio wrth gynhyrchu cyn ei weithredu.
Ffynhonnell: hab.com