Arratsalde on, Windows-eko edukiontzietarako AWS EKS (Elastic Kubernetes Zerbitzua) zerbitzua konfiguratu eta erabiltzen dudan esperientzia partekatu nahi dizuet, edo hobeto esanda, hura erabiltzeko ezintasunari buruz eta AWS sistemaren edukiontzian aurkitutako akatsa, horientzat. Windows-eko edukiontzietarako zerbitzu honetan interesa dutenek, mesedez cat.
Badakit Windows-eko edukiontziak ez direla gai ezaguna, eta jende gutxik erabiltzen ditu, baina hala ere artikulu hau idaztea erabaki nuen, HabrΓ©-ri buruzko artikulu pare bat zeudelako kubernetes eta Windows-en eta oraindik ere badagoelako jendea.
ΠΠ°ΡΠ°Π»ΠΎ
Dena gure enpresako zerbitzuak kubernetesera migratzea erabaki zenean hasi zen, hau da, %70 Windows eta %30 Linuxera. Horretarako, AWS EKS hodeiko zerbitzua hartu zen aukera posibleetako bat. 8ko urriaren 2019ra arte, AWS EKS Windows Aurrebista Publikoan zegoen, horrekin hasi nintzen, kubernetes-en 1.11 bertsio zaharra erabiltzen zen bertan, baina hala ere egiaztatzea erabaki nuen eta hodeiko zerbitzu hau zein fasetan zegoen, funtzionatzen zuen ala ez. inondik ere, ondorioztatu zenez, ez, akats bat zegoen lekak kentzearekin batera, zaharrek Windows Worker nodoaren azpisare beretik barne ip bidez erantzuteari utzi zioten bitartean.
Hori dela eta, AWS EKS erabiltzeari uztea erabaki zen EC2 berean kubernetes-en kluster propioaren alde, oreka eta HA guztiak deskribatu beharko genituzke bakarrik CloudFormation bidez.
Amazon EKS Windows edukiontzien euskarria orain eskuragarri dago
Egilea: Martin Beeby | 08ko urriaren 2019an
Nire klusterrako CloudFormation txantiloi bat gehitzeko denbora izan baino lehen, albiste hau ikusi nuen
Noski, nire lan guztia alde batera utzi eta GArentzat zer egin zuten aztertzen hasi nintzen, eta dena nola aldatu zen Public Preview-ekin. Bai, AWS-ek, ondo egina, windows worker nodoaren irudiak 1.14 bertsiora eguneratu zituen, baita klusterrak berak ere, 1.14 bertsioak EKSn, orain windows nodoak onartzen ditu. Aurreikuspen publikoaren proiektua Estali zuten eta esan zuten orain erabili hemen dokumentazio ofiziala:
EKS kluster bat egungo VPC eta azpisareetan integratzea
Iturri guztietan, iragarkiaren goiko estekan eta baita dokumentazioan ere, klusterra exctl utilitate jabedunaren bidez edo ondoren CloudFormation + kubectl bidez zabaltzea proposatu zen, Amazoneko azpisare publikoak soilik erabiliz, baita bat sortzea ere. Kluster berri baterako VPC bereizia.
Aukera hau ez da askorentzat egokia; lehenik eta behin, aparteko VPC batek kostu gehigarriak suposatzen ditu bere kostuagatik + trafikoa parekatzea zure uneko VPCarekin. Zer egin beharko lukete AWS-n dagoeneko prestatutako azpiegitura bat dutenek beren AWS kontu anitzekin, VPCrekin, azpisareekin, ibilbide-taulekin, garraio-atebidearekin eta abarrekin? Jakina, ez duzu hau guztia hautsi edo berregin nahi, eta EKS kluster berria egungo sare-azpiegituran integratu behar duzu, lehendik dagoen VPC-a erabiliz eta, bereizteko, gehienez ere klusterraren azpisare berriak sortu.
Nire kasuan, bide hau aukeratu zen, lehendik zegoen VPC erabili nuen, 2 azpisare publiko eta 2 azpisare pribatu bakarrik gehitu nituen kluster berrirako, noski, arau guztiak kontuan hartu ziren dokumentazioaren arabera. .
Baldintza bat ere bazegoen: EIP erabiliz azpisare publikoetan langile-nodorik ez.
eksctl vs CloudFormation
Erreserba bat egingo dut berehala kluster bat zabaltzeko bi metodoak probatu ditudala, bi kasuetan irudia berdina zen.
Exctl erabiliz soilik adibide bat erakutsiko dut hemen kodea laburragoa izango baita. Exctl erabiliz, inplementatu clustera 3 urratsetan:
1. Klusterra bera + Linux-eko langile-nodoa sortzen dugu, gero sistemaren edukiontziak eta vpc-kontrolatzaile hori bera hartuko duena.
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-networkingLehendik dagoen VPC batean inplementatzeko, zure azpisareen IDa zehaztu besterik ez dago, eta eksctl-ek VPC bera zehaztuko du.
Zure langile-nodoak azpisare pribatu batean soilik inplementatzen direla ziurtatzeko, --node-private-networking zehaztu behar duzu nodegroup-erako.
2. Gure klusterrean vpc-controller instalatzen dugu, eta, ondoren, gure langile-nodoak prozesatuko ditu, doako IP helbideen kopurua zenbatuta, baita instantziako ENI kopurua ere, gehituz eta kenduz.
eksctl utils install-vpc-controllers --name yyy --approve3.Zure sistemaren edukiontziak zure Linux langile-nodoan arrakastaz abiarazi ondoren, vpc-controller barne, geratzen dena da Windows-eko langileekin beste nodo-talde bat sortzea.
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-networkingZure nodoa zure klusterera ondo konektatu eta dena ondo dagoela dirudi, Prest egoeran dago, baina ez.
Errore bat vpc-controller-en
Windows Worker nodo batean pods exekutatzen saiatzen bagara, errorea jasoko dugu:
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]Sakonago begiratzen badugu, ikusiko dugu AWS-en gure instantzia hau itxura duela:
Eta honela izan beharko luke:
Hortik argi dago vpc-controller-ek ez zuela bere zatia bete arrazoiren batengatik eta ezin izan zuela instantziara IP helbide berriak gehitu, podek erabili ahal izateko.
Ikus ditzagun vpc-controller pod-aren erregistroak eta hau da ikusten duguna:
kubectl erregistroa -n kube-sistema
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.Google-n egindako bilaketak ez zuen ezer ekarri, itxuraz oraindik inork ez baitzuen horrelako akatsik harrapatu, edo ez baitzuen arazorik argitaratu, lehenik neuk pentsatu behar izan nuen aukerak. Burura etorri zitzaidan lehenengo gauza izan zen, agian, vpc-controller-ek ezin duela ip-10-xxx.ap-xxx.compute.internal konpondu eta bertara iritsi eta horregatik akatsak gertatzen dira.
Bai, hain zuzen ere, DNS zerbitzari pertsonalizatuak erabiltzen ditugu VPCn eta, printzipioz, ez ditugu Amazon-ak erabiltzen, beraz, birbidaltzea ere ez zen konfiguratu ap-xxx.compute.internal domeinu honetarako. Aukera hau probatu nuen, eta ez zuen emaitzarik ekarri, beharbada proba ez zen garbia, eta horregatik, gainera, laguntza teknikoarekin komunikatzean, haien ideiari men egin nion.
Benetan ideiarik ez zegoenez, segurtasun talde guztiak eksctl-ek berak sortu zituen, beraz, ez zegoen zalantzarik haien zerbitzuaren inguruan, ibilbide-taulak ere zuzenak ziren, nat, dns, langile-nodoekin Interneterako sarbidea ere hor zegoen.
Gainera, langile-nodo bat azpisare publiko batean inplementatzen baduzu βnode-private-networking erabili gabe, nodo hau berehala eguneratu zuen vpc-controller-ek eta dena erlojupeko moduan funtzionatu zuen.
Bi aukera zeuden:
- Eman eman eta itxaron norbaitek akats hau AWS-n deskribatu eta konpondu arte, eta orduan seguru erabil dezakezu AWS EKS Windows, GA-n kaleratu berri dutelako (artikulu hau idazteko unean 8 egun pasatu dira), seguru asko. jarraitu nire bide bera.
- Idatzi AWS Support-era eta kontatu arazoaren funtsa nonahiko erregistro mordo batekin eta frogatu haien zerbitzuak ez duela funtzionatzen zure VPC eta azpisareak erabiltzen dituzunean, ez da ezertarako enpresen laguntza izan genuena, erabili beharko zenuke. gutxienez behin :)
Komunikazioa AWSko ingeniariekin
Atarian txartel bat sortuta, oker aukeratu dut Web bidez erantzutea - posta elektronikoa edo laguntza-zentroaren bidez, aukera honen bidez egun batzuk igaro ondoren erantzun diezazukete, nire txartelak Larritasuna - Sistema hondatua izan arren, eta horrek <12 orduko epean erantzuna esan nahi zuen, eta Enpresa-laguntza planak 24/7 laguntza daukanez, onena espero nuen, baina beti bezala atera zen.
Nire txartela esleitu gabe geratu zen ostiraletik astelehenera arte, orduan beraiei berriro idaztea erabaki nuen eta Txat erantzun aukera aukeratu nuen. Denbora gutxian itxaron ondoren, Harshad Madhav ni ikusteko izendatu zuten, eta orduan hasi zen...
Linean 3 orduz jarraian arazketa egin genuen, erregistroak transferituz, kluster bera AWS laborategian zabalduz arazoa emulatzeko, nire aldetik kluster-a berriro sortuz, eta abar, lortu genuen gauza bakarra da. Erregistroetan argi zegoen resol-k ez zuela funtzionatzen AWS barneko domeinu-izenak, eta horri buruz idatzi nuen goian, eta Harshad Madhav-ek birbidaltzea sortzeko eskatu zidan, ustez DNS pertsonalizatuak erabiltzen ditugu eta arazo bat izan liteke.
Birbidaltzean
ap-xxx.compute.internal -> 10.x.x.2 (VPC CIDRBlock)
amazonaws.com -> 10.x.x.2 (VPC CIDRBlock)Hori egin zen, eguna amaitu zen. Harshad Madhavek idatzi zuen egiaztatzeko eta funtzionatu beharko luke, baina ez, ebazpenak ez zuen batere lagundu.
Ondoren, beste 2 ingeniarirekin komunikazioa egon zen, bat besterik ez zen txatetik irten zen, itxuraz kasu konplexu baten beldur zen, bigarrenak berriro eman zuen nire eguna arazketa-ziklo oso batean, erregistroak bidaltzen, bi aldeetan klusterrak sortzen, amaieran esan zuen ondo, niretzat balio du, hemen nago dena pausoz pauso egiten dut dokumentazio ofizialean eta zuk eta zuk lortuko duzu.
Horri adeitsu eskatu nion alde egiteko eta nire txartela beste norbait esleitzeko arazoa non bilatu ez badakizu.
finale
Herenegun, Arun B. ingeniari berri bat esleitu zidaten, eta harekin komunikazioaren hasiera-hasieratik berehala ikusi zen hori ez zela aurreko 3 ingeniariak. Historia osoa irakurri eta berehala bere github-en zegoen ps1-en bere script-a erabiliz erregistroak biltzeko eskatu zuen. Horren ondoren, klusterrak sortzeko, komandoen emaitzak ateratzeko, erregistroak biltzeko iterazio guztiak jarraitu ziren, baina Arun B. norabide egokian zihoan egindako galderen arabera.
Noiz iritsi ginen -stderrthreshold=debug beren vpc-kontrolatzailean gaitzera, eta zer gertatu zen gero? noski, ez du funtzionatzen) poda ez da aukera honekin hasten, -stderrthreshold=info bakarrik funtzionatzen du.
Hemen amaitu genuen eta Arun B.-k esan zuen nire urratsak erreproduzitzen saiatuko zela errore bera lortzeko. Hurrengo egunean, Arun B.-ren erantzuna jaso nuen, ez zuen kasu hau alde batera utzi, baina euren vpc-kontrolagailuaren berrikuspen kodea hartu eta non dagoen eta zergatik ez duen funtzionatzen aurkitu zuen:
Horrela, zure VPC-ko bide-taula nagusia erabiltzen baduzu, lehenespenez, ez du beharrezko azpisareekin asoziaziorik, vpc-kontrolagailuarentzat hain beharrezkoak direnak, azpisare publiko baten kasuan, ibilbide-taula pertsonalizatua du. duen elkartea.
Bide-taula nagusirako elkarteak eskuz gehituz beharrezko azpisareekin eta nodo-taldea berriro sortuz, dena primeran funtzionatzen du.
Espero dut Arun B.-k EKS garatzaileei akats hau benetan jakinaraziko diela eta vpc-controller-en bertsio berri bat ikusiko dugu, non dena kutxatik kanpo funtzionatuko duen. Une honetan azken bertsioa hau da: 602401143452.dkr.ecr.ap-southeast-1.amazonaws.com/eks/vpc-resource-controller:0.2.1
arazo hau dauka.
Eskerrik asko amaiera arte irakurri duzuen guztioi, probatu ekoizpenean erabiliko duzun guztia ezarri aurretik.
Iturria: www.habr.com