Өдрийн мэнд, би та бүхэнтэй Windows контейнерт зориулсан AWS EKS (Уян хатан Кубернетес Үйлчилгээ) үйлчилгээг тохируулах, ашиглах туршлагаасаа, эс тэгвээс үүнийг ашиглах боломжгүй байгаа болон AWS системийн контейнерээс олдсон алдааны талаар хуваалцахыг хүсч байна. Windows контейнерт зориулсан энэ үйлчилгээг сонирхож буй хүмүүс муурны доор оруулна уу.
Windows-ийн контейнерууд нь түгээмэл сэдэв биш бөгөөд цөөхөн хүн ашигладаг гэдгийг би мэднэ, гэхдээ би энэ нийтлэлийг бичихээр шийдсэн, учир нь kubernetes болон Windows дээр Хабрегийн талаар хэд хэдэн нийтлэл байсан бөгөөд ийм хүмүүс байсаар байна.
Начало
Энэ бүхэн манай компанийн үйлчилгээг 70% Windows, 30% Линукс бүхий kubernetes руу шилжүүлэхээр шийдсэн үеэс эхэлсэн. Энэ зорилгоор AWS EKS үүлэн үйлчилгээг боломжит хувилбаруудын нэг гэж үзсэн. 8 оны 2019-р сарын 1.11 хүртэл AWS EKS Windows нь Public Preview-д байсан, би үүгээр эхэлсэн, kubernetes-ийн хуучин XNUMX хувилбар тэнд ашиглагдаж байсан, гэхдээ би үүнийг шалгаж үзээд энэ үүлэн үйлчилгээ ямар шатандаа байгаа, ажиллаж байгаа эсэхийг харахаар шийдсэн. Үгүй ээ, энэ нь pods устгах нэмэлт алдаа байсан бол хуучин нь windows-ийн ажилчны зангилаатай нэг дэд сүлжээнээс дотоод ip-ээр дамжуулан хариу өгөхөө больсон.
Тиймээс AWS EKS-ийн хэрэглээг ижил EC2 дээрх kubernetes дээрх өөрийн кластерт ашиглахаас татгалзахаар шийдсэн бөгөөд зөвхөн бид CloudFormation-ээр дамжуулан бүх тэнцвэржүүлэх болон HA-г тайлбарлах хэрэгтэй болно.
Amazon EKS Windows Container Support одоо ерөнхийдөө боломжтой
Мартин Биби | 08 оны 2019-р сарын XNUMX-нд
Би өөрийн кластерт зориулж CloudFormation-д загвар нэмэхээс өмнө энэ мэдээг харсан.
Мэдээжийн хэрэг, би бүх ажлаа хойш тавьж, тэд GA-ийн төлөө юу хийснийг, Public Preview-ийн тусламжтайгаар бүх зүйл хэрхэн өөрчлөгдсөнийг судалж эхлэв. Тийм ээ, AWS сайн байна, Windows-ийн ажилчны зангилааны зургуудыг 1.14 хувилбар болгон шинэчилсэн, мөн кластер өөрөө буюу EKS-ийн 1.14 хувилбар нь одоо цонхны зангилааг дэмждэг болсон. Project by Public Preview at Тэд үүнийг нууж, одоо албан ёсны баримт бичгийг энд ашиглаарай гэж хэлэв.
EKS кластерийг одоогийн VPC болон дэд сүлжээнд нэгтгэх
Бүх эх сурвалжид дээрх зарын холбоос болон баримт бичигт кластерыг өмчийн eksctl хэрэгслээр эсвэл CloudFormation + kubectl-ээр дамжуулан байршуулахыг санал болгосон бөгөөд үүний дараа зөвхөн Амазон дахь нийтийн дэд сүлжээг ашиглах, түүнчлэн шинэ кластерт зориулж тусдаа VPC.
Энэ сонголт нь олон хүнд тохиромжгүй; нэгдүгээрт, тусдаа VPC нь түүний өртөг + таны одоогийн VPC руу чиглэсэн урсгалын нэмэлт зардал гэсэн үг юм. Өөрийн олон AWS данс, VPC, дэд сүлжээ, маршрутын хүснэгт, дамжин өнгөрөх гарц гэх мэт AWS-д бэлэн дэд бүтэцтэй хүмүүс юу хийх ёстой вэ? Мэдээжийн хэрэг, та энэ бүгдийг эвдэж, дахин хийхийг хүсэхгүй байгаа бөгөөд одоо байгаа VPC-г ашиглан шинэ EKS кластерийг одоогийн сүлжээний дэд бүтцэд нэгтгэх хэрэгтэй бөгөөд салгахдаа кластерт шинэ дэд сүлжээ үүсгэх хэрэгтэй.
Миний хувьд энэ замыг сонгосон, би одоо байгаа VPC-г ашигласан, шинэ кластерт зөвхөн 2 нийтийн дэд сүлжээ, 2 хувийн дэд сүлжээ нэмсэн, мэдээжийн хэрэг баримт бичгийн дагуу бүх дүрмийг харгалзан үзсэн болно. .
Мөн нэг нөхцөл байсан: EIP ашигладаг нийтийн дэд сүлжээнд ажилчны зангилаа байхгүй.
eksctl vs CloudFormation
Би кластер байршуулах хоёр аргыг туршсан гэдгээ даруй захиалах болно, аль алинд нь зураг ижил байсан.
Энд байгаа код богино байх тул би зөвхөн eksctl ашиглан жишээ үзүүлэх болно. eksctl ашиглан кластерыг 3 алхамаар байрлуулна:
1. Бид кластер өөрөө + Линуксийн ажилчны зангилаа үүсгэдэг бөгөөд энэ нь дараа нь системийн контейнерууд болон нөгөө л муу vpc-хянагчийг байрлуулах болно.
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-networkingОдоо байгаа VPC-д байршуулахын тулд дэд сүлжээнүүдийн id-г зааж өгвөл eksctl нь VPC-г өөрөө тодорхойлно.
Таны ажилчны зангилаа зөвхөн хувийн дэд сүлжээнд байршуулсан эсэхийг шалгахын тулд та зангилааны бүлэгт --node-private-networking-г зааж өгөх хэрэгтэй.
2. Бид vpc-хянагчийг кластертаа суулгаж, дараа нь бидний ажилчны зангилааг боловсруулж, үнэгүй IP хаягийн тоо, түүнчлэн жишээн дээрх ENI-ийн тоог тоолж, нэмж, хасах болно.
eksctl utils install-vpc-controllers --name yyy --approve3.Таны системийн контейнерууд vpc-хянагч зэрэг Линуксийн ажилчны зангилаа дээр амжилттай ажиллаж эхэлсний дараа цонхны ажилчидтай өөр зангилааны бүлэг үүсгэх л үлдлээ.
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-networkingТаны зангилаа кластерт амжилттай холбогдож, бүх зүйл хэвийн болсны дараа энэ нь Бэлэн төлөвт байгаа боловч үгүй.
Vpc хянагч дахь алдаа
Хэрэв бид цонхны ажилчны зангилаа дээр pods ажиллуулахыг оролдвол алдаа гарах болно:
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]Хэрэв бид илүү гүнзгий харвал AWS дээрх бидний жишээ дараах байдалтай байгааг харж болно.
Мөн энэ нь иймэрхүү байх ёстой:
Үүнээс үзэхэд vpc-хянагч нь ямар нэг шалтгааны улмаас үүргээ биелүүлээгүй бөгөөд инстанцуудад шинэ IP хаяг нэмэх боломжгүй байсан тул тэдгээрийг ашиглах боломжтой болно.
Vpc-controller pod-ийн бүртгэлийг харцгаая, бид үүнийг харж байна:
kubectl бүртгэл -n kube систем
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 дээрх хайлтууд ямар ч үр дүнд хүргэсэнгүй, учир нь хэн ч ийм алдааг хараахан илрүүлээгүй, эсвэл үүн дээр асуудал оруулаагүй байгаа тул би эхлээд сонголтуудыг бодох хэрэгтэй болсон. Хамгийн түрүүнд санаанд орж ирсэн зүйл бол vpc-хянагч нь ip-10-xxx.ap-xxx.compute.internal-ийг шийдэж чадахгүй байгаа тул алдаа гардаг.
Тийм ээ, үнэхээр бид VPC-д захиалгат DNS серверүүдийг ашигладаг бөгөөд зарчмын хувьд Amazon серверүүдийг ашигладаггүй тул энэ ap-xxx.compute.internal домайнд дамжуулалт тохируулагдаагүй байна. Би энэ сонголтыг туршиж үзсэн бөгөөд энэ нь үр дүнд хүрээгүй, магадгүй туршилт нь цэвэр биш байсан тул техникийн дэмжлэгтэй харилцахдаа би тэдний санааг дагав.
Үнэхээр ямар ч санаа байхгүй байсан тул бүх хамгаалалтын бүлгүүдийг eksctl өөрөө үүсгэсэн тул тэдгээрийн үйлчилгээнд эргэлзэх зүйлгүй, маршрутын хүснэгтүүд нь зөв, nat, dns, ажилчдын зангилаатай интернет холболт бас байдаг.
Түүнчлэн, хэрэв та —node-private-networking ашиглахгүйгээр ажилчны зангилаа нийтийн дэд сүлжээнд байршуулбал энэ зангилаа vpc-хянагчаар нэн даруй шинэчлэгдэж, бүх зүйл цаг шиг ажилладаг.
Хоёр сонголт байсан:
- Та бууж өгөөд, хэн нэгэн AWS дээрх энэ алдааг тайлбарлаж, засч залруулах хүртэл хүлээнэ үү, тэгвэл та AWS EKS Windows-ийг аюулгүй ашиглах боломжтой, учир нь тэд GA-д дөнгөж гарсан (энэ нийтлэлийг бичихэд 8 хоног өнгөрсөн), олон хүн магадгүй надтай ижил замаар яв.
- AWS Support-д бичиж, хаанаас ч байсан бүхэл бүтэн логуудын тусламжтайгаар асуудлын мөн чанарыг хэлж, таны VPC болон дэд сүлжээг ашиглах үед тэдний үйлчилгээ ажиллахгүй гэдгийг нотлоод бидэнд Бизнесийн дэмжлэг үзүүлсэн нь дэмий хоосон биш юм, та ашиглах хэрэгтэй. ядаж нэг удаа :)
AWS инженерүүдтэй харилцах
Портал дээр тасалбар үүсгэсний дараа би цахим шуудан эсвэл дэмжлэгийн төвөөр дамжуулан надад хариу өгөхийг андуурсан бөгөөд энэ сонголтоор тэд таны тасалбарын ноцтой байдал - системийн гэмтэлтэй байсан ч хэдхэн хоногийн дараа танд хариулах боломжтой. Энэ нь <12 цагийн дотор хариу өгөх гэсэн үг бөгөөд Бизнесийг дэмжих төлөвлөгөө нь 24/7 цагийн дэмжлэгтэй тул би хамгийн сайн сайхныг хүсэн хүлээж байсан ч үргэлжийнх шигээ болсон.
Миний тасалбар баасан гарагаас Даваа гараг хүртэл оногдоогүй байсан тул би тэдэн рүү дахин бичихээр шийдэж, Чатаар хариулах сонголтыг сонгосон. Хэсэг хүлээсний эцэст Харшад Мадхав надтай уулзахаар томилогдоод эхэлсэн...
Бид үүнтэй онлайнаар 3 цаг дараалан дибаг хийж, логуудыг шилжүүлж, AWS лабораторид асуудлыг дуурайхын тулд ижил кластерыг байрлуулж, миний зүгээс кластерыг дахин үүсгэсэн гэх мэтээр бидний олж мэдсэн цорын ганц зүйл бол логууд нь миний дээр бичсэн AWS дотоод домэйн нэрүүд ажиллахгүй байгаа нь тодорхой байсан бөгөөд Харшад Мадхав надаас дамжуулалт үүсгэхийг хүссэн тул бид захиалгат DNS ашигладаг бөгөөд энэ нь асуудал байж магадгүй юм.
Дамжуулалт
ap-xxx.compute.internal -> 10.x.x.2 (VPC CIDRBlock)
amazonaws.com -> 10.x.x.2 (VPC CIDRBlock)Ингээд л болсон, өдөр дууслаа. Харшад Мадхав үүнийг шалгахаар хариу бичсэн бөгөөд энэ нь ажиллах ёстой, гэхдээ үгүй, тогтоол огт тус болсонгүй.
Дараа нь дахиад 2 инженертэй харилцаж, нэг нь зүгээр л чатаа орхисон, тэр нарийн төвөгтэй хэргээс айсан бололтой, хоёр дахь нь дибаг хийх, лог илгээх, хоёр талдаа кластер үүсгэх зэрэг бүхэл бүтэн циклээр өдрийг өнгөрөөсөн. Эцэст нь тэр зүгээр л сайн гэж хэлсэн, энэ нь надад ашигтай, энд би албан ёсны баримт бичигт бүх зүйлийг алхам алхмаар хийж, та болон та амжилтанд хүрнэ.
Хэрэв та асуудлаа хаанаас хайхаа мэдэхгүй байгаа бол би түүнийг орхиж, миний тасалбарт өөр хэн нэгнийг томилохыг эелдэгээр гуйсан.
Төгсгөл
Гурав дахь өдөр надад шинэ инженер Арун Б-г томилсон бөгөөд түүнтэй харилцаж эхэлснээс хойш энэ нь өмнөх 3 инженер биш нь шууд тодорхой болсон. Тэр түүхийг бүхэлд нь уншаад тэр даруй өөрийн github дээр байсан ps1 дээр өөрийн скриптийг ашиглан бүртгэлийг цуглуулахыг хүссэн. Үүний дараагаар кластер үүсгэх, тушаалын үр дүнг гаргах, бүртгэл цуглуулах зэрэг бүх давталт давтагдсан боловч Арун Б. надаас асуусан асуултаас харахад зөв чиглэлд явж байсан.
Бид vpc-хянагчдаа -stderrthreshold=debug-г идэвхжүүлэх цэгт хэзээ ирсэн бэ, дараа нь юу болсон бэ? Мэдээж энэ нь ажиллахгүй байна) подвол зүгээр л энэ сонголтоор эхэлдэггүй, зөвхөн -stderrthreshold=info ажилладаг.
Бид энд дууссан бөгөөд Арун Б. ижил алдаа гаргахын тулд миний алхмуудыг давтах гэж оролдоно гэж хэлсэн. Маргааш нь би Арун Б-аас хариу ирсэн. Тэр энэ хэргийг орхиогүй, харин тэдний vpc-контроллерийн хяналтын кодыг авч, хаана байгаа, яагаад ажиллахгүй байгааг олж мэдэв.
Тиймээс, хэрэв та өөрийн VPC-ийн үндсэн маршрутын хүснэгтийг ашигладаг бол анхдагч байдлаар энэ нь vpc-контроллерт зайлшгүй шаардлагатай шаардлагатай дэд сүлжээнүүдтэй холбоогүй, нийтийн дэд сүлжээний хувьд тусгай чиглүүлэлтийн хүснэгттэй байдаг. тэр холбоо байдаг.
Шаардлагатай дэд сүлжээнүүдтэй үндсэн маршрутын хүснэгтийн холбоог гараар нэмж, зангилааны бүлгийг дахин үүсгэснээр бүх зүйл төгс ажилладаг.
Арун Б. үнэхээр энэ алдааг EKS-ийн хөгжүүлэгчдэд мэдээлнэ гэж найдаж байна, бид vpc-хянагчийн шинэ хувилбарыг харах болно, энд бүх зүйл хэвийн ажиллах болно. Одоогоор хамгийн сүүлийн хувилбар нь: 602401143452.dkr.ecr.ap-souteast-1.amazonaws.com/eks/vpc-resource-controller:0.2.1
ийм асуудалтай байна.
Дуустал нь уншсан бүх хүмүүст баярлалаа, хэрэгжүүлэхээс өмнө үйлдвэрлэлд ашиглах гэж байгаа бүх зүйлээ туршиж үзээрэй.
Эх сурвалж: www.habr.com