Sugeng sonten, aku pengin nuduhake karo sampeyan pengalaman babagan nyiyapake lan nggunakake layanan AWS EKS (Layanan Kubernetes Elastis) kanggo wadhah Windows, utawa luwih becik babagan ora bisa digunakake, lan bug sing ditemokake ing wadhah sistem AWS, kanggo sing sing kasengsem ing layanan iki kanggo kontaner Windows, please ing cat.
Aku ngerti yen wadhah Windows ora dadi topik populer, lan sawetara wong sing nggunakake, nanging aku isih mutusake nulis artikel iki, amarga ana sawetara artikel babagan Habré ing kubernetes lan Windows lan isih ana wong kaya ngono.
Начало
Iku kabeh diwiwiti nalika diputusake kanggo mindhah layanan ing perusahaan kita menyang kubernetes, yaiku 70% Windows lan 30% Linux. Kanggo tujuan iki, layanan awan AWS EKS dianggep minangka salah sawijining pilihan sing bisa ditindakake. Nganti 8 Oktober 2019, AWS EKS Windows ana ing Pratinjau Umum, aku miwiti, versi kubernetes 1.11 lawas digunakake ing kana, nanging aku mutusake kanggo mriksa lan ndeleng ing tahap apa layanan awan iki, apa bisa digunakake. ing kabeh, kang nguripake metu, ora, iku ana bug karo Kajaba saka njabut pods, nalika lawas mandheg nanggapi liwat ip internal saka subnet padha karo simpul buruh windows.
Mulane, iki mutusaké kanggo nglirwaaken nggunakake AWS EKS ing sih saka kluster dhewe ing kubernetes ing EC2 padha, mung kita kudu njlèntrèhaké kabeh wawas lan HA dhewe liwat CloudFormation.
Dhukungan Kontainer Amazon EKS Windows saiki Umumé Kasedhiya
dening Martin Beeby | ing 08 Oktober 2019
Sadurunge aku duwe wektu kanggo nambah cithakan kanggo CloudFormation kanggo cluster dhewe, Aku weruh warta iki
Mesthi wae, aku nyingkirake kabeh karyaku lan wiwit sinau apa sing ditindakake kanggo GA, lan kepiye kabeh diganti karo Pratinjau Umum. Ya, AWS, rampung, nganyari gambar kanggo windows worker node menyang versi 1.14, uga kluster kasebut, versi 1.14 ing EKS, saiki ndhukung node windows. Project dening Public Preview ing Dheweke nutupi lan ujar saiki nggunakake dokumentasi resmi ing kene:
Nggabungake kluster EKS menyang VPC lan subnet saiki
Ing kabeh sumber, ing pranala ing ndhuwur babagan woro-woro uga ing dokumentasi, diusulake kanggo nyebarake kluster kasebut liwat utilitas eksctl proprietary utawa liwat CloudFormation + kubectl sawise, mung nggunakake subnet umum ing Amazon, uga nggawe a VPC kapisah kanggo kluster anyar.
Opsi iki ora cocok kanggo akeh; pisanan, VPC sing kapisah tegese biaya tambahan kanggo biaya + lalu lintas peering menyang VPC sampeyan saiki. Apa sing kudu ditindakake dening wong-wong sing wis duwe infrastruktur siap ing AWS kanthi akun Multiple AWS, VPC, subnet, tabel rute, gateway transit lan liya-liyane? Mesthi, sampeyan ora pengin break utawa mbaleni kabeh iki, lan sampeyan kudu nggabungake kluster EKS anyar menyang infrastruktur jaringan saiki, nggunakake VPC ana lan, kanggo misahake, paling nggawe subnets anyar kanggo kluster.
Ing kasusku, dalan iki dipilih, aku nggunakake VPC sing wis ana, mung nambahake 2 subnet umum lan 2 subnet pribadi kanggo kluster anyar, mesthine kabeh aturan kasebut dianggep miturut dokumentasi. .
Ana uga siji syarat: ora ana simpul pekerja ing subnet umum sing nggunakake EIP.
eksctl vs CloudFormation
Aku bakal nggawe reservasi langsung yen aku nyoba loro cara kanggo nyebarake kluster, ing kasus kasebut, gambar kasebut padha.
Aku bakal nuduhake conto mung nggunakake eksctl wiwit kode kene bakal luwih cendhek. Nggunakake eksctl, pasang kluster ing 3 langkah:
1. Kita nggawe kluster dhewe + simpul buruh Linux, kang mengko bakal tuan rumah kontaner sistem lan sing padha gerah-fated vpc-controller.
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-networkingKanggo nyebarke menyang VPC ana, mung nemtokake id saka subnets, lan eksctl bakal nemtokake VPC dhewe.
Kanggo mesthekake yen simpul buruh sampeyan mung disebarake menyang subnet pribadi, sampeyan kudu nemtokake --node-private-networking kanggo nodegroup.
2. Kita nginstal vpc-controller ing kluster, sing banjur bakal ngolah kelenjar buruh, ngetung jumlah alamat IP gratis, uga nomer ENI ing conto kasebut, nambah lan mbusak.
eksctl utils install-vpc-controllers --name yyy --approve3. Sawise wadhah sistem wis kasil dibukak ing simpul buruh Linux, kalebu vpc-controller, kabeh sing isih kanggo nggawe nodegroup liyane karo buruh windows.
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-networkingSawise simpul wis kasil nyambung menyang kluster lan kabeh katon apik, iku ing status Siap, nanging ora.
Kesalahan ing vpc-controller
Yen kita nyoba mbukak pods ing simpul pekerja windows, kita bakal entuk kesalahan:
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]Yen katon luwih jero, kita bakal weruh yen conto ing AWS katon kaya iki:
Lan kudu kaya mangkene:
Saka iki cetha yen vpc-controller ora nepaki bagean kanggo sawetara alesan lan ora bisa nambah alamat IP anyar kanggo Kayata supaya pods bisa digunakake.
Ayo ndeleng log saka pod vpc-controller lan iki sing kita deleng:
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.Panelusuran ing Google ora nyebabake apa-apa, amarga ora ana sing nangkep bug kasebut, utawa durung ngirim masalah, aku kudu mikirake pilihan dhewe dhisik. Wangsulan: Bab ingkang pisanan sing teka ing atine sing mbok menawa vpc-controller ora bisa mutusake masalah ip-10-xxx.ap-xxx.compute.internal lan tekan lan mulane kasalahan dumadi.
Ya, pancen, kita nggunakake server DNS khusus ing VPC lan, ing prinsip, kita ora nggunakake sing Amazon, dadi malah nerusake ora dikonfigurasi kanggo domain ap-xxx.compute.internal iki. Aku dites pilihan iki, lan ora nggawa asil, mbok menawa test iki ora resik, lan mulane, luwih, nalika sesambungan karo technical support, aku succumbed kanggo idea sing.
Amarga ora ana gagasan, kabeh klompok keamanan digawe dening eksctl dhewe, mula ora ana keraguan babagan serviceability, tabel rute uga bener, nat, dns, akses Internet karo kelenjar buruh uga ana.
Kajaba iku, yen sampeyan masang simpul buruh menyang subnet umum tanpa nggunakake -node-private-networking, simpul iki langsung dianyari dening vpc-controller lan kabeh bisa digunakake kaya jam.
Ana rong pilihan:
- Menehi munggah lan ngenteni nganti wong njlèntrèhaké bug iki ing AWS lan padha ndandani iku, banjur sampeyan bisa aman nggunakake AWS EKS Windows, amarga padha mung dirilis ing GA (8 dina wis liwati nalika nulis artikel iki), akeh bakal mbokmenawa. ngetutake dalan sing padha karo aku.
- Tulis menyang Dhukungan AWS lan ngandhani inti saka masalah karo akeh log saka ngendi wae lan mbuktekake manawa layanan kasebut ora bisa digunakake nalika nggunakake VPC lan subnet, ora ana gunane yen kita duwe dhukungan Bisnis, sampeyan kudu nggunakake paling sepisan :)
Komunikasi karo insinyur AWS
Sawise nggawe tiket ing portal kasebut, aku salah milih nanggapi aku liwat Web - email utawa pusat dhukungan, liwat pilihan iki, dheweke bisa mangsuli sampeyan sawise sawetara dina, sanajan tiketku wis Keruwetan - Sistem cacat, sing temenan nanggepi ing <12 jam, lan wiwit rencana support Business wis 24/7 support, Aku ngarep-arep kanggo sing paling apik, nanging diaktifake metu minangka tansah.
Tiketku ditinggalake wiwit dina Jumuah nganti Senin, banjur aku mutusake kanggo nulis maneh lan milih pilihan respon Chat. Sawise ngenteni sawetara wektu, Harshad Madhav ditunjuk nemoni aku, banjur wiwit ...
We debugged karo online kanggo 3 jam saurutan, nransfer log, deploying kluster padha ing laboratorium AWS kanggo emulate masalah, nggawe maneh kluster ing sisih, lan ing, mung bab kita teka kanggo iku saka log iku cetha yen resol ora bisa digunakake jeneng domain internal AWS, kang aku wrote bab ndhuwur, lan Harshad Madhav takon kula kanggo nggawe nerusake, dinuga kita nggunakake DNS adat lan iki bisa dadi masalah.
Nerusake
ap-xxx.compute.internal -> 10.x.x.2 (VPC CIDRBlock)
amazonaws.com -> 10.x.x.2 (VPC CIDRBlock)Sing wis rampung, dina wis rampung. Harshad Madhav nulis maneh kanggo mriksa lan kudu bisa, nanging ora, resolusi kasebut ora mbantu.
Banjur ana komunikasi karo 2 engineers liyane, siji mung dropped metu saka chatting, ketoke dheweke wedi karo kasus Komplek, kaloro nglampahi dina maneh ing siklus lengkap debugging, ngirim log, nggawe kluster ing loro-lorone, ing pungkasan dheweke mung ngandika apik, iku bisa kanggo kula, kene aku kabeh langkah dening langkah ing dokumentasi resmi lan sampeyan lan sampeyan bakal sukses.
Kanggo kang sopan takon marang ninggalake lan nemtokake wong liya kanggo tiket yen sampeyan ora ngerti ngendi kanggo nggoleki masalah.
Rampung
Ing dina katelu, insinyur anyar Arun B. ditugasake kanggo aku, lan wiwit awal komunikasi karo dheweke langsung jelas yen iki dudu 3 insinyur sadurunge. Dheweke maca kabeh sejarah lan langsung njaluk ngumpulake log nggunakake skrip dhewe ing ps1, sing ana ing github. Iki diterusake maneh dening kabeh iterasi nggawe kluster, ngasilake asil printah, ngumpulake log, nanging Arun B. obah ing arah sing bener miturut pitakonan sing dijaluk marang aku.
Nalika kita tekan titik mbisakake -stderrthreshold = debug ing vpc-controller, lan apa kedaden sabanjuré? mesthi ora bisa) pod mung ora miwiti karo pilihan iki, mung -stderrthreshold = info dianggo.
Kita rampung ing kene lan Arun B. ujar manawa dheweke bakal nyoba ngasilake langkah-langkahku supaya entuk kesalahan sing padha. Dina sabanjuré aku nampa respon saka Arun B. dheweke ora nglirwakake kasus iki, nanging njupuk munggah kode review saka vpc-controller lan ketemu panggonan ngendi iku lan apa iku ora bisa:
Mangkono, yen sampeyan nggunakake tabel rute utama ing VPC sampeyan, mula kanthi standar ora ana hubungane karo subnet sing dibutuhake, sing perlu kanggo vpc-controller, ing kasus subnet umum, duwe tabel rute khusus. sing duwe asosiasi.
Kanthi nambahake asosiasi kanthi manual kanggo tabel rute utama kanthi subnet sing dibutuhake, lan nggawe nodegroup, kabeh bisa digunakake kanthi sampurna.
Mugi Arun B. tenan bakal laporan bug iki kanggo pangembang EKS lan kita bakal weruh versi anyar vpc-controller ngendi kabeh bakal bisa metu saka kothak. Saiki versi paling anyar yaiku: 602401143452.dkr.ecr.ap-southeast-1.amazonaws.com/eks/vpc-resource-controller:0.2.1
duwe masalah iki.
Thanks kanggo kabeh wong sing maca nganti pungkasan, nyoba kabeh sing bakal digunakake ing produksi sadurunge implementasine.
Source: www.habr.com