Hyvää iltapäivää, haluan jakaa kanssasi kokemukseni AWS EKS (Elastic Kubernetes Service) -palvelun asettamisesta ja käytöstä Windows-säilöille tai pikemminkin sen mahdottomuudesta ja AWS-järjestelmäsäiliöstä löytyneestä bugista niille. jotka ovat kiinnostuneita tästä Windows-konttipalvelusta, ota yhteyttä cat.
Tiedän, että Windows-säilöt eivät ole suosittu aihe, ja harvat ihmiset käyttävät niitä, mutta päätin silti kirjoittaa tämän artikkelin, koska Habrésta oli pari artikkelia kubernetesista ja Windowsista, ja sellaisia henkilöitä on edelleen.
alku
Kaikki alkoi siitä, kun yhtiömme palvelut päätettiin siirtää kubernetesiin, joka on 70 % Windows ja 30 % Linux. Tähän tarkoitukseen yhtenä mahdollisista vaihtoehdoista tarkasteltiin AWS EKS -pilvipalvelua. 8 asti AWS EKS Windows oli julkisessa esikatselussa, aloitin sillä, siellä käytettiin kubernetesin vanhaa 2019-versiota, mutta päätin kuitenkin tarkistaa sen ja katsoa missä vaiheessa tämä pilvipalvelu on, toimiiko se. ylipäätään, kuten kävi ilmi, ei, siinä oli virhe, joka liittyi podien poistamiseen, kun taas vanhat lakkasivat vastaamasta sisäisen ip:n kautta samasta aliverkosta kuin Windows Worker -solmu.
Siksi päätettiin luopua AWS EKS:n käytöstä oman klusterin hyväksi saman EC2:n kubernetesissä, vain meidän on kuvattava kaikki tasapainotukset ja HA itse CloudFormationin kautta.
Amazon EKS Windows Container -tuki on nyt yleisesti saatavilla
kirjoittanut Martin Beeby | 08 lokakuuta 2019
Ennen kuin ehdin lisätä mallin CloudFormationiin omaa klusteriani varten, näin tämän uutisen
Tietysti jätin kaiken työni sivuun ja aloin tutkia, mitä he tekivät GA:lle ja kuinka kaikki muuttui julkisen esikatselun avulla. Kyllä, AWS, hyvin tehty, päivitti Windows Worker -solmun kuvat versioon 1.14, samoin kuin itse klusterin, versio 1.14 EKS:ssä, tukee nyt Windows-solmuja. Project by Public Preview osoitteessa He peittivät sen ja sanoivat, että käytä nyt virallisia asiakirjoja täällä:
EKS-klusterin integrointi nykyiseen VPC:hen ja aliverkkoihin
Kaikissa lähteissä, ilmoituksen yllä olevassa linkissä ja dokumentaatiossa, ehdotettiin klusterin käyttöönottoa joko omalla eksctl-apuohjelmalla tai CloudFormation + kubectl after -apuohjelman kautta käyttämällä vain julkisia aliverkkoja Amazonissa sekä luomalla erillinen VPC uudelle klusterille.
Tämä vaihtoehto ei sovi monille; ensinnäkin erillinen VPC tarkoittaa lisäkustannuksia sen kustannuksista + peering-liikennettä nykyiseen VPC:hen. Mitä pitäisi tehdä niiden, joilla on jo valmis infrastruktuuri AWS:ssä, jossa on omat Multiple AWS -tilit, VPC, aliverkot, reittitaulukot, kauttakulkuyhdyskäytävä ja niin edelleen? Kaikkea tätä ei tietenkään haluta rikkoa tai tehdä uudelleen, vaan uusi EKS-klusteri täytyy integroida nykyiseen verkkoinfrastruktuuriin käyttämällä olemassa olevaa VPC:tä ja erottamista varten korkeintaan luoda uusia aliverkkoja klusteriin.
Minun tapauksessani tämä polku valittiin, käytin olemassa olevaa VPC:tä, lisäsin vain 2 julkista aliverkkoa ja 2 yksityistä aliverkkoa uuteen klusteriin, tietysti kaikki säännöt otettiin huomioon dokumentaation mukaan .
Oli myös yksi ehto: EIP:tä käyttävissä julkisissa aliverkoissa ei ole työntekijäsolmuja.
eksctl vs CloudFormation
Teen heti varauksen, että kokeilin molempia tapoja ottaa klusteri käyttöön, molemmissa tapauksissa kuva oli sama.
Näytän esimerkin vain käyttämällä eksctl:ää, koska tässä oleva koodi on lyhyempi. Ota klusteri käyttöön eksctl:n avulla kolmessa vaiheessa:
1. Luomme itse klusterin + Linux-työntekijäsolmun, joka isännöi myöhemmin järjestelmäkonttia ja samaa huonoonnista vpc-ohjainta.
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-networkingVoit ottaa käyttöön olemassa olevan VPC:n määrittämällä vain aliverkkojesi tunnukset, ja eksctl määrittää itse VPC:n.
Varmistaaksesi, että työntekijäsolmut otetaan käyttöön vain yksityisessä aliverkossa, sinun on määritettävä nodegroupille --node-private-networking.
2. Asennamme klusteriimme vpc-controllerin, joka sitten käsittelee työntekijäsolmumme, laskee vapaiden IP-osoitteiden määrän sekä ilmentymän ENI-osoitteiden määrän sekä lisää ja poistaa ne.
eksctl utils install-vpc-controllers --name yyy --approve3. Kun järjestelmäsäilösi on käynnistetty onnistuneesti Linux-työntekijäsolmussasi, mukaan lukien vpc-ohjain, jäljellä on vain luoda uusi solmuryhmä Windows työntekijöiden kanssa.
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-networkingKun solmu on muodostanut yhteyden klusteriisi ja kaikki näyttää olevan kunnossa, se on Valmis-tilassa, mutta ei.
Virhe vpc-ohjaimessa
Jos yritämme ajaa podeja Windows Worker -solmussa, saamme virheilmoituksen:
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]Jos katsomme syvemmälle, näemme, että esimerkkimme AWS:ssä näyttää tältä:
Ja sen pitäisi olla näin:
Tästä on selvää, että vpc-ohjain ei jostain syystä täyttänyt osuuttaan eikä voinut lisätä instanssiin uusia IP-osoitteita, jotta podit voisivat käyttää niitä.
Katsotaanpa vpc-controller podin lokeja ja tämä on mitä näemme:
kubectl loki -n kube-järjestelmä
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-haut eivät johtaneet mihinkään, koska ilmeisesti kukaan ei ollut vielä havainnut tällaista vikaa tai ei ollut julkaissut siitä ongelmaa, jouduin ensin miettimään vaihtoehtoja itse. Ensimmäisenä tuli mieleen se, että ehkä vpc-ohjain ei pysty ratkaisemaan tiedostoa ip-10-xxx.ap-xxx.compute.internal ja saavuttamaan sitä ja siksi tapahtuu virheitä.
Kyllä, todellakin käytämme mukautettuja DNS-palvelimia VPC:ssä, emmekä periaatteessa käytä Amazonin palvelimia, joten edes edelleenlähetystä ei ole määritetty tälle ap-xxx.compute.internal domainille. Testasin tätä vaihtoehtoa, eikä se tuottanut tuloksia, ehkä testi ei ollut puhdas, ja siksi edelleen, kun kommunikoin teknisen tuen kanssa, taipuin heidän ideaansa.
Koska ideoita ei varsinaisesti ollut, kaikki turvaryhmät olivat eksctl:n itsensä luomia, joten niiden toimivuudesta ei ollut epäilystäkään, reittitaulukot olivat myös oikein, nat, dns, Internet-yhteys työntekijöiden solmujen kanssa oli myös olemassa.
Lisäksi, jos otat työntekijäsolmun käyttöön julkiseen aliverkkoon käyttämättä —node-private-networkingia, vpc-ohjain päivitti tämän solmun välittömästi ja kaikki toimi kuin kellonkello.
Vaihtoehtoja oli kaksi:
- Anna periksi ja odota, kunnes joku kuvaa tämän bugin AWS:ssä ja korjaa sen, ja sitten voit turvallisesti käyttää AWS EKS Windowsia, koska ne julkaistiin juuri GA:ssa (8 päivää on kulunut tämän artikkelin kirjoittamisesta), monet todennäköisesti seuraa samaa tietä kuin minä.
- Kirjoita AWS-tukeen ja kerro heille ongelman ydin joukolla lokeja kaikkialta ja todista heille, että heidän palvelunsa ei toimi käytettäessä VPC:täsi ja aliverkkojasi, ei ole turhaan, että meillä oli yritystuki, sinun tulee käyttää ainakin kerran :)
Yhteydenpito AWS-insinöörien kanssa
Kun olen luonut lipun portaaliin, päätin vahingossa vastata minulle Web-sähköpostin tai tukikeskuksen kautta, tämän vaihtoehdon kautta he voivat vastata sinulle muutaman päivän kuluttua, vaikka lipussani oli vakavuus - järjestelmä heikentynyt, mikä tarkoitti vastausta alle 12 tunnin sisällä, ja koska Business-tukisuunnitelmassa on 24/7-tuki, toivoin parasta, mutta se meni kuten aina.
Lippuni jäi käyttämättä perjantaista maanantaihin, sitten päätin kirjoittaa heille uudelleen ja valitsin Chat-vastausvaihtoehdon. Hetken odottamisen jälkeen Harshad Madhav nimitettiin tapaamaan minua, ja sitten se alkoi...
Teimme virheenkorjauksen sen kanssa verkossa 3 tuntia peräkkäin, siirsimme lokeja, otimme käyttöön saman klusterin AWS-laboratoriossa emuloimaan ongelmaa, luomme klusterin uudelleen omalta osaltani ja niin edelleen. Ainoa asia, johon päädyimme, oli se, että lokeista kävi ilmi, että resol ei toiminut AWS:n sisäisiä verkkotunnuksia, joista kirjoitin yllä, ja Harshad Madhav pyysi minua luomaan edelleenlähetyksen, väitettiin, että käytämme mukautettua DNS: tä ja tämä voi olla ongelma.
Huolinta
ap-xxx.compute.internal -> 10.x.x.2 (VPC CIDRBlock)
amazonaws.com -> 10.x.x.2 (VPC CIDRBlock)Näin tehtiin, päivä oli ohi. Harshad Madhav kirjoitti takaisin tarkistaakseen asian ja sen pitäisi toimia, mutta ei, resoluutio ei auttanut ollenkaan.
Sitten kommunikoitiin kahden muun insinöörin kanssa, yksi yksinkertaisesti poistui chatista, ilmeisesti hän pelkäsi monimutkaista tapausta, toinen vietti päiväni jälleen täydessä virheenkorjaussyklissä, lokien lähettämisessä, klustereiden luomisessa molemmille puolille. lopussa hän sanoi vain hyvin, se toimii minulle, tässä minä teen kaiken askel askeleelta virallisessa dokumentaatiossa ja sinä ja sinä onnistut.
Pyysin häntä kohteliaasti lähtemään ja osoittamaan lippuani jonkun muun, jos et tiedä mistä etsiä ongelmaa.
finaali
Kolmantena päivänä minulle määrättiin uusi insinööri Arun B., jonka kanssa kommunikoinnin alusta lähtien oli heti selvää, että tämä ei ollut kolme edellistä insinööriä. Hän luki koko historian ja pyysi heti keräämään lokit käyttämällä omaa ps3-skriptiään, joka oli hänen githubissaan. Tätä seurasi taas kaikki iteraatiot klustereiden luomisesta, komentotulosten tulostamisesta, lokien keräämisestä, mutta Arun B. oli menossa oikeaan suuntaan minulle esitettyjen kysymysten perusteella.
Milloin päästiin siihen pisteeseen, että otettiin käyttöön -stderrthreshold=debug heidän vpc-ohjaimessaan, ja mitä tapahtui seuraavaksi? tietenkään se ei toimi) pod ei yksinkertaisesti käynnisty tällä valinnalla, vain -stderrthreshold=info toimii.
Päädyimme tähän ja Arun B. sanoi, että hän yrittää toistaa askeleeni saadakseen saman virheen. Seuraavana päivänä saan vastauksen Arun B:ltä. Hän ei hylännyt tätä tapausta, vaan otti heidän vpc-ohjaimen tarkistuskoodin ja löysi paikan, missä se on ja miksi se ei toimi:
Eli jos käytät VPC:ssäsi pääreittitaulukkoa, sillä oletuksena ei ole assosiaatioita tarvittaviin aliverkkoihin, jotka ovat niin tarpeellisia vpc-ohjaimelle, julkisen aliverkon tapauksessa sillä on mukautettu reittitaulukko. jolla on yhdistys.
Lisäämällä manuaalisesti assosiaatiot pääreittitaulukkoon tarvittavilla aliverkoilla ja luomalla solmuryhmä uudelleen, kaikki toimii täydellisesti.
Toivon, että Arun B. todella ilmoittaa tästä virheestä EKS-kehittäjille ja näemme uuden version vpc-ohjaimesta, jossa kaikki toimii heti. Tällä hetkellä uusin versio on: 602401143452.dkr.ecr.ap-southeast-1.amazonaws.com/eks/vpc-resource-controller:0.2.1
on tämä ongelma.
Kiitos kaikille loppuun asti lukeneille, testaa kaikkea, mitä aiot käyttää tuotannossa ennen käyttöönottoa.
Lähde: will.com