Բարի երեկո, ես ուզում եմ ձեզ հետ կիսվել իմ փորձով Windows բեռնարկղերի համար AWS EKS (Elastic Kubernetes Service) ծառայությունը կարգավորելու և օգտագործելու վերաբերյալ, ավելի ճիշտ՝ դրա օգտագործման անհնարինության և AWS համակարգի կոնտեյներում հայտնաբերված սխալի մասին նրանց համար։ ովքեր հետաքրքրված են այս ծառայությունով Windows-ի կոնտեյներների համար, խնդրում ենք տակ cat.
Ես գիտեմ, որ Windows-ի կոնտեյներները հայտնի թեմա չեն, և քչերն են դրանք օգտագործում, բայց ես այնուամենայնիվ որոշեցի գրել այս հոդվածը, քանի որ Habré-ի վրա մի քանի հոդված կար kubernetes-ի և Windows-ի վրա, և դեռ կան այդպիսի մարդիկ:
Начало
Ամեն ինչ սկսվեց, երբ որոշվեց մեր ընկերության ծառայությունները տեղափոխել kubernetes, որը 70% Windows է և 30% Linux: Այդ նպատակով AWS EKS ամպային ծառայությունը դիտարկվել է որպես հնարավոր տարբերակներից մեկը։ Մինչև 8 թվականի հոկտեմբերի 2019-ը AWS EKS Windows-ը հանրային նախադիտման մեջ էր, ես սկսեցի դրանով, այնտեղ օգտագործվում էր kubernetes-ի հին 1.11 տարբերակը, բայց այնուամենայնիվ որոշեցի ստուգել և տեսնել, թե որ փուլում է այս ամպային ծառայությունը, աշխատում է արդյոք։ Ընդհանրապես, ինչպես պարզվեց, ոչ, դա եղել է մի վրիպակ, որտեղ ավելացվել է փոդերի հեռացումը, մինչդեռ հինները դադարել են արձագանքել ներքին ip-ով նույն ենթացանցից, ինչ windows worker հանգույցը:
Հետևաբար, որոշվեց հրաժարվել AWS EKS-ի օգտագործումից՝ հօգուտ մեր սեփական կլաստերի kubernetes-ի վրա նույն EC2-ի վրա, միայն թե մենք պետք է ինքներս նկարագրենք ամբողջ հավասարակշռումը և HA-ն՝ CloudFormation-ի միջոցով:
Amazon EKS Windows Container-ի աջակցությունն այժմ ընդհանուր առմամբ հասանելի է
Մարտին Բիբիի կողմից | 08 թվականի հոկտեմբերի 2019-ին
Մինչ ես կհասցնեի կաղապար ավելացնել CloudFormation-ին իմ սեփական կլաստերի համար, ես տեսա այս նորությունը
Իհարկե, ես իմ ամբողջ աշխատանքը մի կողմ դրեցի և սկսեցի ուսումնասիրել, թե ինչ են արել նրանք GA-ի համար, և թե ինչպես է ամեն ինչ փոխվել Public Preview-ով։ Այո, AWS-ը, լավ արեցիք, թարմացրել է windows worker node-ի պատկերները 1.14 տարբերակով, ինչպես նաև կլաստերը՝ EKS-ի 1.14 տարբերակը, այժմ աջակցում է windows հանգույցներին: Նախագիծը Հանրային նախադիտման կողմից Նրանք ծածկեցին դա և ասացին, որ հիմա օգտագործեք պաշտոնական փաստաթղթերը այստեղ.
EKS կլաստերի ինտեգրում ընթացիկ VPC-ին և ենթացանցերին
Բոլոր աղբյուրներում, հայտարարության վերևի հղումում, ինչպես նաև փաստաթղթերում, առաջարկվել է կլաստերը տեղակայել կամ սեփական eksctl ծրագրի միջոցով, կամ CloudFormation + kubectl-ի միջոցով՝ օգտագործելով միայն Amazon-ի հանրային ենթացանցերը, ինչպես նաև ստեղծել առանձին VPC նոր կլաստերի համար:
Այս տարբերակը հարմար չէ շատերի համար, նախ՝ առանձին VPC նշանակում է հավելյալ ծախսեր դրա արժեքի համար + ձեր ընթացիկ VPC-ի հետ հավասարազոր տրաֆիկ: Ի՞նչ պետք է անեն նրանք, ովքեր արդեն ունեն AWS-ում պատրաստի ենթակառուցվածք՝ իրենց սեփական Multiple AWS հաշիվներով, VPC-ով, ենթացանցերով, երթուղիների աղյուսակներով, տարանցիկ դարպասներով և այլն: Իհարկե, դուք չեք ցանկանում կոտրել կամ վերագործարկել այս ամենը, և դուք պետք է ինտեգրեք նոր EKS կլաստերը ընթացիկ ցանցային ենթակառուցվածքին, օգտագործելով գոյություն ունեցող VPC-ն և, առանձնացնելու համար, առավելագույնը ստեղծել նոր ենթացանցեր կլաստերի համար:
Իմ դեպքում այս ճանապարհն է ընտրվել, ես օգտագործել եմ գոյություն ունեցող VPC-ն, նոր կլաստերի համար ավելացրել եմ ընդամենը 2 հանրային ենթացանց և 2 մասնավոր ենթացանց, իհարկե, բոլոր կանոնները հաշվի են առնվել ըստ փաստաթղթերի։ .
Կար նաև մեկ պայման՝ EIP օգտագործող հանրային ենթացանցերում աշխատող հանգույցներ չկան:
eksctl ընդդեմ CloudFormation
Անմիջապես վերապահում կանեմ, որ փորձեցի կլաստերի տեղակայման երկու եղանակները, երկու դեպքում էլ պատկերը նույնն էր:
Ես օրինակ ցույց կտամ միայն eksctl-ի միջոցով, քանի որ այստեղ կոդը ավելի կարճ կլինի: Օգտագործելով eksctl, տեղակայեք կլաստերը 3 քայլով.
1. Մենք ինքնին ստեղծում ենք կլաստերը + Linux աշխատանքային հանգույցը, որը հետագայում կհյուրընկալի համակարգի կոնտեյներները և այդ նույն չարաբաստիկ 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-networkingԳոյություն ունեցող VPC-ում տեղակայելու համար պարզապես նշեք ձեր ենթացանցերի ID-ն, և eksctl-ն ինքը կորոշի VPC-ն:
Ապահովելու համար, որ ձեր աշխատանքային հանգույցները տեղաբաշխված են միայն մասնավոր ենթացանցում, դուք պետք է նշեք --node-private-networking հանգույցների խմբի համար:
2. Մենք տեղադրում ենք vpc-controller մեր կլաստերում, որն այնուհետև կմշակի մեր աշխատանքային հանգույցները՝ հաշվելով անվճար IP հասցեների, ինչպես նաև ատյանի վրա ENI-ների քանակը՝ ավելացնելով և հեռացնելով դրանք:
eksctl utils install-vpc-controllers --name yyy --approve3. Այն բանից հետո, երբ ձեր համակարգի կոնտեյներները հաջողությամբ գործարկվեն ձեր Linux աշխատանքային հանգույցում, ներառյալ vpc-controller-ը, մնում է միայն ստեղծել մեկ այլ հանգույց խումբ 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-networkingԱյն բանից հետո, երբ ձեր հանգույցը հաջողությամբ միացավ ձեր կլաստերին, և ամեն ինչ կարծես թե լավ է, այն գտնվում է «Պատրաստ» կարգավիճակում, բայց ոչ:
Սխալ vpc-controller-ում
Եթե փորձենք փոդներ գործարկել Windows Worker հանգույցի վրա, ապա կստանանք սխալ.
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-controller-ը ինչ-ինչ պատճառներով չի կատարել իր մասը և չի կարողացել նոր 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 և հասնել դրան, հետևաբար սխալներ են առաջանում:
Այո, իսկապես, մենք օգտագործում ենք հատուկ DNS սերվերներ VPC-ում և, սկզբունքորեն, չենք օգտագործում 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 աջակցություն, ես հույս ունեի լավագույնի համար, բայց ստացվեց, ինչպես միշտ:
Ուրբաթից մինչև երկուշաբթի իմ տոմսը չնշանակված մնաց, հետո որոշեցի նորից գրել նրանց և ընտրեցի Chat-ի պատասխան տարբերակը։ Կարճ ժամանակ սպասելուց հետո Հարշադ Մադհավին նշանակեցին ինձ տեսնելու, իսկ հետո սկսվեց...
Մենք 3 ժամ անընդմեջ դրա հետ վրիպազերծել ենք առցանց՝ փոխանցելով տեղեկամատյանները, տեղակայելով նույն կլաստերը AWS լաբորատորիայում՝ խնդիրը նմանեցնելու համար, նորից ստեղծելով կլաստերը իմ կողմից և այլն, միակ բանը, որին մենք հանգել ենք, այն է, որ տեղեկամատյաններում պարզ էր, որ լուծումը չի աշխատում AWS ներքին տիրույթի անունները, որոնց մասին ես գրել եմ վերևում, և Հարշադ Մադհավը խնդրեց ինձ ստեղծել վերահասցեավորում, իբր մենք օգտագործում ենք հատուկ DNS, և դա կարող է խնդիր լինել:
Forwarding
ap-xxx.compute.internal -> 10.x.x.2 (VPC CIDRBlock)
amazonaws.com -> 10.x.x.2 (VPC CIDRBlock)Դա այն էր, ինչ արվեց, օրն ավարտվեց: Հարշադ Մադհավը ետ գրեց, որ ստուգի այն, և այն պետք է աշխատի, բայց ոչ, բանաձևը բոլորովին չօգնեց:
Հետո շփում եղավ ևս 2 ինժեների հետ, մեկը պարզապես դուրս եկավ չաթից, ըստ երևույթին, նա վախենում էր բարդ դեպքից, երկրորդն իմ օրն անցկացրեց նորից վրիպազերծման, տեղեկամատյաններ ուղարկելու, երկու կողմից կլաստերներ ստեղծելու ամբողջ ցիկլի վրա, վերջ նա ուղղակի լավ ասաց, ինձ մոտ ստացվում է, ահա ես ամեն ինչ անում եմ քայլ առ քայլ պաշտոնական փաստաթղթերում, և դու և դու կհաջողվի:
Ինչին ես քաղաքավարի խնդրեցի նրան հեռանալ և մեկ ուրիշին նշանակել իմ տոմսը, եթե չգիտեք, թե որտեղ փնտրել խնդիրը:
Վերջնական
Երրորդ օրը ինձ նշանակեցին նոր ինժեներ Արուն Բ.-ին, և նրա հետ շփման հենց սկզբից անմիջապես պարզվեց, որ դա նախկին 3 ինժեները չէ։ Նա կարդաց ամբողջ պատմությունը և անմիջապես խնդրեց հավաքել տեղեկամատյանները՝ օգտագործելով իր սեփական սցենարը ps1-ում, որն իր github-ում էր։ Դրան նորից հաջորդեցին կլաստերների ստեղծման, հրամանների արդյունքների դուրսբերման, լոգերի հավաքման բոլոր կրկնությունները, բայց Արուն Բ.-ն ճիշտ ուղղությամբ էր ընթանում՝ դատելով ինձ տրված հարցերից։
Ե՞րբ մենք հասանք այն կետին, որ միացնենք -stderrthreshold=debug-ը նրանց vpc-վերահսկիչում, և ի՞նչ եղավ հետո: Իհարկե, դա չի աշխատում) պատիճը պարզապես չի սկսվում այս տարբերակով, աշխատում է միայն -stderrthreshold=info:
Այստեղ ավարտեցինք, և Արուն Բ.-ն ասաց, որ կփորձի վերարտադրել իմ քայլերը՝ նույն սխալը ստանալու համար։ Հաջորդ օրը ես պատասխան ստացա Արուն Բ.-ից, նա չհրաժարվեց այս գործից, այլ վերցրեց իրենց vpc-controller-ի վերանայման կոդը և գտավ այն վայրը, որտեղ այն գտնվում է և ինչու այն չի աշխատում.
Այսպիսով, եթե դուք օգտագործում եք հիմնական երթուղիների աղյուսակը ձեր VPC-ում, ապա լռելյայն այն չունի ասոցիացիաներ անհրաժեշտ ենթացանցերի հետ, որոնք այդքան անհրաժեշտ են vpc-վերահսկիչի համար, հանրային ենթացանցի դեպքում այն ունի հատուկ երթուղիների աղյուսակ: որ ունի ասոցիացիա։
Ձեռքով ավելացնելով հիմնական երթուղիների աղյուսակի ասոցիացիաները անհրաժեշտ ենթացանցերով և վերստեղծելով հանգույցների խումբը, ամեն ինչ հիանալի է աշխատում:
Հուսով եմ, որ Arun B.-ն իսկապես կզեկուցի այս սխալի մասին EKS ծրագրավորողներին, և մենք կտեսնենք vpc-controller-ի նոր տարբերակը, որտեղ ամեն ինչ կաշխատի առանց տուփի: Ներկայումս վերջին տարբերակն է՝ 602401143452.dkr.ecr.ap-southeast-1.amazonaws.com/eks/vpc-resource-controller:0.2.1
ունի այս խնդիրը.
Շնորհակալություն բոլորին, ովքեր կարդում են մինչև վերջ, փորձարկեք այն ամենը, ինչ պատրաստվում եք օգտագործել արտադրության մեջ, նախքան իրականացումը:
Source: www.habr.com