Wilujeng sonten, abdi hoyong bagikeun sareng anjeun pangalaman kuring dina nyetél sareng nganggo jasa AWS EKS (Layanan Kubernetes Elastis) pikeun wadah Windows, atanapi langkungna ngeunaan impossibility tina ngagunakeunana, sareng bug anu aya dina wadah sistem AWS, pikeun aranjeunna. anu kabetot dina layanan ieu peti Windows, mangga handapeun ucing.
Kuring terang yén wadah Windows sanés topik anu populér, sareng sababaraha jalma anu ngagunakeunana, tapi kuring tetep mutuskeun pikeun nyerat tulisan ieu, sabab aya sababaraha tulisan ngeunaan Habré dina kubernetes sareng Windows sareng masih aya jalma sapertos kitu.
ngamimitian
Éta sadayana dimimitian nalika diputuskeun pikeun migrasi jasa di perusahaan kami ka kubernetes, nyaéta 70% Windows sareng 30% Linux. Pikeun tujuan ieu, jasa awan AWS EKS dianggap salaku salah sahiji pilihan anu mungkin. Dugi ka 8 Oktober 2019, AWS EKS Windows aya dina Tilik Publik, kuring ngamimitian ku éta, versi kubernetes 1.11 anu lami dianggo di dinya, tapi kuring mutuskeun pikeun pariksa deui sareng ningali dina tahap naon jasa awan ieu, naha éta jalan. pisan, sakumaha tétéla, teu, éta aya bug ditambah nyoplokkeun pods, sedengkeun nu heubeul dieureunkeun ngabales via ip internal tina subnet sarua salaku titik worker windows.
Ku alatan éta, ieu mutuskeun pikeun abandon pamakéan AWS EKS dina ni'mat klaster sorangan on kubernetes on EC2 sarua, ngan urang kudu ngajelaskeun sagala balancing na HA sorangan via CloudFormation.
Amazon EKS Windows Container Rojongan ayeuna Umumna Sadia
ku Martin Beeby | tanggal 08 Okt 2019
Sateuacan kuring ngagaduhan waktos pikeun nambihan template ka CloudFormation pikeun kluster kuring sorangan, kuring ningali warta ieu
Tangtosna, abdi nempatkeun sagala karya kuring kumisan sarta mimiti diajar naon maranéhna ngalakukeun pikeun ga, sarta kumaha sagalana robah kalawan Sawangan Public. Leres, AWS, saé pisan, ngapdet gambar pikeun windows worker node kana vérsi 1.14, kitu ogé klasterna sorangan, versi 1.14 di EKS, ayeuna ngadukung windows nodes. Proyék ku Sawangan Umum di Aranjeunna nutupan éta sareng nyarios ayeuna nganggo dokuméntasi resmi di dieu:
Ngahijikeun klaster EKS kana VPC sareng subnet ayeuna
Dina sadaya sumber, dina tautan di luhur ngeunaan pengumuman ogé dina dokuméntasi, diusulkeun pikeun nyebarkeun kluster boh ngaliwatan utilitas eksctl proprietary atanapi ngalangkungan CloudFormation + kubectl saatosna, ngan ukur nganggo subnet umum di Amazon, ogé nyiptakeun a VPC misah pikeun klaster anyar.
Pilihan ieu henteu cocog pikeun seueur; kahiji, VPC anu misah hartosna biaya tambahan pikeun biaya + lalu lintas peering ka VPC anjeun ayeuna. Naon anu kedah dilakukeun ku jalma anu parantos gaduh infrastruktur siap-siap di AWS kalayan akun Multiple AWS, VPC, subnet, tabel rute, gateway transit sareng saterasna? Tangtu, anjeun teu hayang megatkeun atawa redo sadayana ieu, jeung anjeun kudu ngahijikeun klaster EKS anyar kana infrastruktur jaringan ayeuna, ngagunakeun VPC aya na, pikeun separation, paling nyieun subnets anyar pikeun klaster.
Bisi kuring, jalur ieu dipilih, kuring nganggo VPC anu tos aya, ngan ukur nambihan 2 subnet umum sareng 2 subnet swasta pikeun klaster énggal, tangtosna, sadaya aturan dipertimbangkeun dumasar kana dokuméntasi. .
Aya ogé hiji kaayaan: euweuh titik worker dina subnets umum ngagunakeun EIP.
eksctl vs CloudFormation
Kuring bakal nyieun reservasi katuhu jauh yén kuring diusahakeun duanana métode deploying klaster a, dina duanana kasus gambar éta sami.
Kuring baris némbongkeun conto ngan ngagunakeun eksctl saprak kode di dieu bakal pondok. Ngagunakeun eksctl, nyebarkeun klaster dina 3 léngkah:
1. Urang nyieun klaster sorangan + Linux Ubuntu worker node, nu engké bakal host wadahna Sistim na éta vpc-controller gering-fated sarua.
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-networkingDina raraga nyebarkeun ka VPC aya, ngan tangtukeun id of subnets Anjeun, sarta eksctl bakal nangtukeun VPC sorangan.
Pikeun mastikeun yén titik worker anjeun disebarkeun ngan ka subnet swasta, anjeun kedah netepkeun --node-private-networking pikeun nodegroup.
2. Urang install vpc-controller dina klaster urang, nu lajeng bakal ngolah titik worker urang, cacah jumlah alamat IP bébas, kitu ogé jumlah ENIs on conto, nambahkeun jeung miceun aranjeunna.
eksctl utils install-vpc-controllers --name yyy --approve3.Saatos wadah sistem anjeun parantos suksés diluncurkeun dina node worker Linux anjeun, kalebet vpc-controller, anu tetep nyaéta nyiptakeun nodegroup sanés sareng windows worker.
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-networkingSaatos titik anjeun parantos suksés nyambung ka kluster anjeun sareng sadayana sigana saé, éta aya dina status Siap, tapi henteu.
Kasalahan dina vpc-controller
Upami urang nyobian ngajalankeun pods dina node windows worker, urang bakal nampi kasalahan:
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]Upami urang ningali langkung jero, urang tingali yén conto urang di AWS sapertos kieu:
Sareng kedah sapertos kieu:
Ti ieu jelas yén vpc-controller teu nedunan bagian na pikeun sababaraha alesan na teu bisa nambahkeun alamat IP anyar pikeun conto nu pods bisa make eta.
Hayu urang tingali log tina pod vpc-controller sareng ieu anu urang tingali:
log kubectl -n kube-sistem
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.Pilarian dina Google henteu ngakibatkeun nanaon, sabab katingalina teu aya anu mendakan bug sapertos kitu, atanapi henteu acan masangkeun masalah éta, kuring kedah mikirkeun pilihan sorangan heula. Hal kahiji anu datang ka pikiran éta meureun vpc-controller teu bisa ngabéréskeun ip-10-xxx.ap-xxx.compute.internal sarta ngahontal eta sahingga kasalahan lumangsung.
Leres, saleresna, kami nganggo server DNS khusus dina VPC sareng, prinsipna, kami henteu nganggo Amazon, janten malah diteruskeun henteu dikonpigurasi pikeun domain ap-xxx.compute.internal ieu. Kuring diuji pilihan ieu, sarta eta teu mawa hasil, sugan test éta teu bersih, sarta ku kituna, salajengna, nalika komunikasi kalayan rojongan teknis, abdi succumbed kana gagasan maranéhanana.
Kusabab aya teu bener wae gagasan, kabéh grup kaamanan dijieun ku eksctl sorangan, jadi euweuh ragu ngeunaan serviceability maranéhna, tabel rute oge bener, nat, DNS, aksés Internet kalayan titik worker ogé aya.
Sumawona, upami anjeun nyebarkeun titik pagawé ka subnet umum tanpa nganggo -node-private-networking, titik ieu langsung diropéa ku vpc-controller sareng sadayana tiasa dianggo sapertos jam.
Aya dua pilihan:
- Masihan sareng antosan dugi aya anu ngajelaskeun bug ieu dina AWS sareng aranjeunna ngalereskeunana, teras anjeun tiasa aman nganggo AWS EKS Windows, sabab nembé dileupaskeun dina ga (8 dinten ka pengker dina waktos nyerat tulisan ieu), seueur anu bakal sigana. nuturkeun jalan anu sami sareng abdi.
- Nulis ka AWS Rojongan sarta ngabejaan aranjeunna hakekat masalah kalayan kebat sakabeh log ti madhab sarta ngabuktikeun ka aranjeunna yen layanan maranéhanana henteu jalan mun ngagunakeun VPC anjeun sarta subnets, éta teu keur nanaon nu urang boga rojongan Usaha, anjeun kudu make. sahenteuna sakali :)
Komunikasi sareng insinyur AWS
Saatos nyiptakeun tikét dina portal, kuring salah milih ngabales kuring via Wéb - email atanapi pusat dukungan, ngalangkungan pilihan ieu aranjeunna tiasa ngajawab anjeun saatos sababaraha dinten, sanaos kanyataan yén tikét kuring ngagaduhan Severity - Sistem gangguan, anu dimaksudkan respon dina <12 jam, sarta saprak rencana rojongan Usaha boga rojongan 24/7, Kuring miharep pikeun pangalusna, tapi tétéla sakumaha salawasna.
tikét abdi ditinggalkeun unassigned ti Jumaah dugi Senén, lajeng abdi mutuskeun nulis deui ka aranjeunna sarta milih pilihan respon Chat. Saatos ngantosan sakedap, Harshad Madhav ditunjuk pikeun ningali kuring, teras mimiti ...
Urang debugged kalawan eta online pikeun 3 jam dina urutan, mindahkeun log, deploying klaster sarua di laboratorium AWS pikeun emulate masalah, nyieun deui klaster di pihak kuring, jeung saterusna, hiji-hijina hal urang datang ka éta ti log éta écés yén resol henteu dianggo nami domain internal AWS, anu kuring nyerat di luhur, sareng Harshad Madhav naroskeun kuring nyiptakeun diteruskeun, disangka kami nganggo DNS khusus sareng ieu tiasa janten masalah.
Maju
ap-xxx.compute.internal -> 10.x.x.2 (VPC CIDRBlock)
amazonaws.com -> 10.x.x.2 (VPC CIDRBlock)Éta naon anu dilakukeun, dinten parantos réngsé. Harshad Madhav nyerat deui pikeun pariksa sareng éta kedah dianggo, tapi henteu, résolusi éta henteu ngabantosan pisan.
Teras aya komunikasi sareng 2 insinyur langkung, hiji ngan ukur kaluar tina obrolan, katingalina anjeunna sieun kasus anu rumit, anu kadua nyéépkeun dinten kuring deui dina siklus pinuh debugging, ngirim log, nyiptakeun klaster dina dua sisi, dina dua sisi. tungtung anjeunna ngan ceuk ogé, gawéna pikeun kuring, didieu kuring ngalakukeun sagalana step by step dina dokuméntasi resmi jeung anjeun jeung anjeun bakal sukses.
Anu kuring sopan naroskeun anjeunna angkat sareng napelkeun batur ka tikét kuring upami anjeun henteu terang dimana milarian masalahna.
Finale
Dina dinten katilu, insinyur anyar Arun B. ditugaskeun ka kuring, sarta ti mimiti komunikasi sareng anjeunna langsung jelas yén ieu teu 3 insinyur saméméhna. Anjeunna maca sadayana sajarah sareng langsung naroskeun pikeun ngumpulkeun log nganggo naskah sorangan dina ps1, anu aya dina github na. Ieu dituturkeun deui ku sagala iterasi nyieun klaster, outputting hasil paréntah, ngumpulkeun log, tapi Arun B. ieu pindah ka arah katuhu ditilik ku patarosan ditanya kuring.
Iraha urang nepi ka titik sangkan -stderrthreshold = debug di vpc-controller maranéhna, sarta naon anu lumangsung salajengna? tangtu teu dianggo) pod saukur teu dimimitian ku pilihan ieu, ngan -stderrthreshold = info jalan.
Urang réngsé di dieu sarta Arun B. ngomong yén manéhna baris nyoba baranahan léngkah kuring pikeun meunangkeun kasalahan anu sarua. Poé saterusna kuring narima respon ti Arun B. anjeunna teu abandon hal ieu, tapi nyandak kode review vpc-controller maranéhanana sarta manggihan tempat dimana éta sarta naha teu dianggo:
Janten, upami anjeun nganggo tabel rute utama dina VPC anjeun, maka sacara standar henteu gaduh asosiasi sareng subnet anu diperyogikeun, anu dipikabutuh pikeun vpc-controller, dina kasus subnet umum, éta gaduh tabel rute khusus. nu boga asosiasi.
Ku cara manual nambahkeun asosiasi pikeun tabel rute utama jeung subnets perlu, sarta nyieun deui nodegroup, sagalana jalan sampurna.
Kuring miharep éta Arun B. bener bakal ngalaporkeun bug ieu pamekar EKS sarta kami bakal ningali versi anyar vpc-controller dimana sagalana bakal dianggo out of the box. Ayeuna versi panganyarna nyaéta: 602401143452.dkr.ecr.ap-southeast-1.amazonaws.com/eks/vpc-resource-controller:0.2.1
boga masalah ieu.
Hatur nuhun ka sadayana anu maca dugi ka ahir, uji sadayana anu anjeun badé dianggo dina produksi sateuacan palaksanaan.
sumber: www.habr.com