Xayrli kun, men siz bilan Windows konteynerlari uchun AWS EKS (Elastic Kubernetes Service) xizmatini sozlash va undan foydalanish, aniqrogʻi undan foydalanishning mumkin emasligi va ular uchun AWS tizim konteynerida topilgan xato haqida oʻz tajribam bilan oʻrtoqlashmoqchiman. Windows konteynerlari uchun ushbu xizmatga qiziqqanlar, iltimos, mushuk ostida.
Bilaman, Windows konteynerlari mashhur mavzu emas va ulardan kam odam foydalanadi, lekin men hali ham ushbu maqolani yozishga qaror qildim, chunki Habré haqida kubernetlar va Windows-da bir nechta maqolalar bor edi va hali ham shunday odamlar bor.
start
Hammasi kompaniyamizdagi xizmatlarni kubernetlarga, ya'ni 70% Windows va 30% Linuxga o'tkazishga qaror qilingandan keyin boshlandi. Shu maqsadda AWS EKS bulutli xizmati mumkin bo'lgan variantlardan biri sifatida ko'rib chiqildi. 8-yil 2019-oktabrgacha AWS EKS Windows Public Preview rejimida edi, men undan boshladim, kubernetlarning eski 1.11 versiyasi u yerda ishlatilgan, lekin baribir uni tekshirishga qaror qildim va bu bulut xizmati qaysi bosqichda ekanligini, u ishlayotgan yoki ishlamayaptimi? umuman olganda, ma'lum bo'lishicha, yo'q, u erda podlarni olib tashlash qo'shilishi bilan bog'liq xatolik bor edi, eskilari esa Windows ishchi tuguni bilan bir xil pastki tarmoqdan ichki IP orqali javob berishni to'xtatdilar.
Shu sababli, xuddi shu EC2-dagi kubernetlardagi o'z klasterimiz foydasiga AWS EKS-dan foydalanishdan voz kechishga qaror qilindi, faqat biz CloudFormation orqali barcha muvozanat va HAni o'zimiz tasvirlashimiz kerak edi.
Amazon EKS Windows konteynerlarini qo'llab-quvvatlash hozirda umuman mavjud
Martin Bibi tomonidan | 08 yil 2019-oktabr
O'z klasterim uchun CloudFormation-ga shablon qo'shishga ulgurmasdan oldin, men ushbu yangilikni ko'rdim.
Albatta, men barcha ishlarimni bir chetga surib, GA uchun nima qilganini va Public Preview bilan hamma narsa qanday o'zgarganini o'rganishni boshladim. Ha, AWS, yaxshi bajarildi, Windows ishchi tugunlari uchun tasvirlarni 1.14 versiyasiga yangiladi, shuningdek, klasterning o'zi, EKSdagi 1.14 versiyasi endi Windows tugunlarini qo'llab-quvvatlaydi. Loyihani Public Preview saytida Ular buni yashirishdi va endi bu erda rasmiy hujjatlardan foydalanishni aytishdi:
EKS klasterini joriy VPC va quyi tarmoqlarga integratsiya qilish
Barcha manbalarda, e'londagi yuqoridagi havolada, shuningdek hujjatlarda, klasterni xususiy eksctl yordam dasturi orqali yoki CloudFormation + kubectl orqali, faqat Amazon'dagi umumiy pastki tarmoqlardan foydalangan holda joylashtirish, shuningdek, yaratish taklif qilingan. yangi klaster uchun alohida VPC.
Ushbu parametr ko'pchilik uchun mos emas; birinchidan, alohida VPC uning narxiga qo'shimcha xarajatlar + joriy VPC ga qarashli trafikni anglatadi. O'zining bir nechta AWS hisoblari, VPC, pastki tarmoqlari, marshrut jadvallari, tranzit shlyuzi va boshqalarga ega AWS-da allaqachon tayyor infratuzilmaga ega bo'lganlar nima qilishlari kerak? Albatta, siz bularning barchasini buzish yoki qayta tiklashni xohlamaysiz va mavjud VPC-dan foydalanib, yangi EKS klasterini joriy tarmoq infratuzilmasiga integratsiya qilishingiz va ajratish uchun ko'pi bilan klaster uchun yangi pastki tarmoqlar yaratishingiz kerak.
Mening holatimda bu yo'l tanlandi, men mavjud VPC dan foydalandim, yangi klaster uchun faqat 2 ta umumiy pastki tarmoq va 2 ta shaxsiy subnet qo'shdim, albatta, barcha qoidalar hujjatlarga muvofiq hisobga olingan. .
Bundan tashqari, bitta shart mavjud edi: EIP-dan foydalanadigan umumiy pastki tarmoqlarda ishchi tugunlari yo'q.
eksctl va CloudFormation
Men klasterni joylashtirishning ikkala usulini ham sinab ko'rganimni darhol band qilaman, ikkala holatda ham rasm bir xil edi.
Men misolni faqat eksctl yordamida ko'rsataman, chunki bu erda kod qisqaroq bo'ladi. Eksctl dan foydalanib, klasterni 3 bosqichda joylashtiring:
1. Biz klasterning o'zi + Linux ishchi tugunini yaratamiz, u keyinchalik tizim konteynerlarini va o'sha yomon vpc-kontrollerni joylashtiradi.
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-networkingMavjud VPC ga o'rnatish uchun pastki tarmoqlaringiz identifikatorini ko'rsating va eksctl VPC ni o'zi aniqlaydi.
Ishchi tugunlaringiz faqat shaxsiy ichki tarmoqqa o'rnatilishini ta'minlash uchun siz tugun guruhi uchun --node-private-networking-ni belgilashingiz kerak.
2. Biz klasterimizga vpc-controllerni o'rnatamiz, u keyinchalik ishchi tugunlarimizni qayta ishlaydi, bepul IP manzillar sonini, shuningdek, misoldagi ENI sonini hisoblaydi, ularni qo'shadi va o'chiradi.
eksctl utils install-vpc-controllers --name yyy --approve3. Tizim konteynerlaringiz Linux ishchi tugunida, jumladan vpc-controllerda muvaffaqiyatli ishga tushirilgandan so'ng, Windows ishchilari bilan boshqa tugunlar guruhini yaratish qoladi.
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-networkingSizning tuguningiz klasteringizga muvaffaqiyatli ulangandan so'ng va hamma narsa yaxshi ko'rinadi, u Tayyor holatida, lekin yo'q.
Vpc-kontrollerda xato
Agar biz Windows ishchi tugunida podlarni ishga tushirishga harakat qilsak, xatoga duch kelamiz:
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]Agar chuqurroq qaraydigan bo'lsak, AWS-dagi misolimiz quyidagicha ko'rinishini ko'ramiz:
Va bu shunday bo'lishi kerak:
Bundan ko'rinib turibdiki, vpc-kontroller negadir o'z qismini bajarmagan va podlar ulardan foydalanishi uchun instansiyaga yangi IP manzillarni qo'sha olmagan.
Keling, vpc-controller podining jurnallarini ko'rib chiqaylik va biz buni ko'ramiz:
kubectl jurnali -n kube tizimi
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-dagi qidiruvlar hech narsaga olib kelmadi, chunki hali hech kim bunday xatolikka duch kelmagan yoki bu haqda hech qanday muammo yozmagan, men avval variantlarni o'zim o'ylab ko'rishim kerak edi. Aqlga kelgan birinchi narsa, ehtimol vpc-controller ip-10-xxx.ap-xxx.compute.internal-ni hal qila olmaydi va unga erisha olmaydi va shuning uchun xatolar yuzaga keladi.
Ha, haqiqatan ham, biz VPC-da maxsus DNS-serverlardan foydalanamiz va, qoida tariqasida, biz Amazon serverlaridan foydalanmaymiz, shuning uchun hatto bu ap-xxx.compute.internal domeni uchun yo'naltirish ham sozlanmagan. Men bu variantni sinab ko'rdim va natija bermadi, ehtimol test toza emas edi, shuning uchun texnik yordam bilan bog'langanda men ularning fikriga berildim.
Haqiqatan ham hech qanday g'oyalar yo'qligi sababli, barcha xavfsizlik guruhlari eksctl tomonidan yaratilgan, shuning uchun ularning xizmat ko'rsatish qobiliyatiga shubha yo'q edi, marshrut jadvallari ham to'g'ri, nat, dns, ishchi tugunlari bilan Internetga kirish ham mavjud edi.
Bundan tashqari, agar siz ishchi tugunni — node-private-networking-dan foydalanmasdan umumiy pastki tarmoqqa joylashtirsangiz, bu tugun vpc-controller tomonidan darhol yangilanadi va hamma narsa soat kabi ishlaydi.
Ikkita variant bor edi:
- Undan voz keching va kimdir AWS-da ushbu xatoni tasvirlab berguncha kuting va ular uni tuzatadi, keyin siz AWS EKS Windows-dan xavfsiz foydalanishingiz mumkin, chunki ular endigina GA-da chiqarilgan (ushbu maqolani yozish paytida 8 kun o'tdi), ko'pchilik ehtimol men bilan bir xil yo'ldan boring.
- AWS Support-ga yozing va ularga muammoning mohiyatini hamma joydan bir nechta jurnallar bilan ayting va ularga VPC va pastki tarmoqlaringizdan foydalanganda ularning xizmati ishlamasligini isbotlang, bizda Biznesni qo'llab-quvvatlashimiz bejiz emas, siz foydalanishingiz kerak. hech bo'lmaganda bir marta :)
AWS muhandislari bilan aloqa
Portalda chipta yaratgandan so'ng, men noto'g'ri veb-elektron pochta yoki qo'llab-quvvatlash markazi orqali menga javob berishni tanladim, bu variant orqali ular sizga bir necha kundan keyin javob berishlari mumkin, garchi mening chiptam jiddiyligi - tizim buzilgan bo'lsa ham. <12 soat ichida javob berishni nazarda tutgan va Biznesni qo'llab-quvvatlash rejasi 24/7 qo'llab-quvvatlanganligi sababli, men eng yaxshisiga umid qilgandim, lekin har doimgidek chiqdi.
Mening chiptam juma kunidan dushanbagacha tayinlanmagan edi, keyin men ularga yana yozishga qaror qildim va Chat javob variantini tanladim. Qisqa vaqt kutgandan so'ng, Harshad Madhav meni ko'rishga tayinlandi va keyin boshlandi ...
Biz u bilan ketma-ket 3 soat davomida onlayn disk raskadrovka qildik, jurnallarni o'tkazdik, muammoni taqlid qilish uchun AWS laboratoriyasida bir xil klasterni joylashtirdik, men tomondan klasterni qayta yaratdik va hokazo. jurnallarda rezolyutsiya yuqorida yozgan AWS ichki domen nomlari ishlamayotgani aniq edi va Harshad Madhav mendan yo'naltirishni yaratishni so'radi, go'yo biz maxsus DNS dan foydalanamiz va bu muammo bo'lishi mumkin.
Ekspeditsiya
ap-xxx.compute.internal -> 10.x.x.2 (VPC CIDRBlock)
amazonaws.com -> 10.x.x.2 (VPC CIDRBlock)Mana shunday bo'ldi, kun tugadi.Xarshad Madxav buni tekshirish uchun javob yozdi va u ishlashi kerak, lekin yo'q, rezolyutsiya umuman yordam bermadi.
Keyin yana 2 ta muhandis bilan aloqa o'rnatildi, biri shunchaki chatni tark etdi, shekilli, u murakkab holatdan qo'rqdi, ikkinchisi kunimni yana disk raskadrovka, jurnallar yuborish, har ikki tomonda klasterlar yaratish bilan o'tkazdi. end u faqat yaxshi dedi, bu men uchun ishlaydi, bu erda men rasmiy hujjatlarda hamma narsani bosqichma-bosqich bajaraman va siz va siz muvaffaqiyatga erishasiz.
Men undan muloyimlik bilan ketishini va agar muammoni qaerdan qidirishni bilmasangiz, mening chiptamga boshqa odamni tayinlashni so'radim.
Yakuniy
Uchinchi kuni menga yangi muhandis Arun B. tayinlandi va u bilan muloqotning boshidanoq bu avvalgi 3 muhandis emasligi darhol ma'lum bo'ldi. U butun tarixni o'qib chiqdi va darhol o'zining github-da joylashgan ps1-da o'z skriptidan foydalangan holda jurnallarni yig'ishni so'radi. Bu yana klasterlar yaratish, buyruqlar natijalarini chiqarish, jurnallarni yig'ishning barcha iteratsiyalari bilan davom etdi, ammo Arun B. menga berilgan savollarga qarab to'g'ri yo'nalishda harakat qilardi.
Biz ularning vpc-controller-da -stderrthreshold=debug-ni yoqish nuqtasiga qachon keldik va keyin nima bo'ldi? albatta ishlamaydi) pod oddiygina bu variant bilan boshlanmaydi, faqat -stderrthreshold=info ishlaydi.
Biz bu erda tugatdik va Arun B. xuddi shu xatoga yo'l qo'yish uchun mening qadamlarimni takrorlashga harakat qilishini aytdi. Ertasi kuni men Arun B.dan javob oldim. u bu ishni tashlab ketmadi, lekin vpc-kontrollerning ko'rib chiqish kodini oldi va uning qaerdaligini va nima uchun ishlamayotganini topdi:
Shunday qilib, agar siz VPC-da asosiy marshrut jadvalidan foydalansangiz, sukut bo'yicha u vpc-kontroller uchun juda zarur bo'lgan kerakli pastki tarmoqlar bilan bog'lanishga ega emas, umumiy pastki tarmoq bo'lsa, u maxsus marshrut jadvaliga ega. bu assotsiatsiyaga ega.
Asosiy marshrut jadvali uchun zarur pastki tarmoqlar bilan assotsiatsiyalarni qo'lda qo'shish va tugun guruhini qayta yaratish orqali hamma narsa mukammal ishlaydi.
Umid qilamanki, Arun B. haqiqatan ham bu xato haqida EKS ishlab chiquvchilariga xabar beradi va biz vpc-controllerning yangi versiyasini ko'ramiz, unda hamma narsa qutidan chiqib ketadi. Hozirda eng soʻnggi versiya: 602401143452.dkr.ecr.ap-southeast-1.amazonaws.com/eks/vpc-resource-controller:0.2.1
bu muammo bor.
Oxirigacha o'qigan barchaga rahmat, amalga oshirishdan oldin ishlab chiqarishda foydalanmoqchi bo'lgan hamma narsani sinab ko'ring.
Manba: www.habr.com