Қайырлы күн, мен сіздермен Windows контейнерлеріне арналған AWS EKS (Elastic Kubernetes Service) қызметін орнату және пайдалану тәжірибесімен, дәлірек айтсақ, оны пайдалану мүмкін еместігі туралы және AWS жүйелік контейнерінде табылған қате туралы тәжірибеммен бөліскім келеді. Windows контейнерлеріне арналған осы қызметке қызығушылық танытатындар, мысық астында өтінеміз.
Мен Windows контейнерлері танымал тақырып емес екенін білемін және оларды аз адамдар пайдаланады, бірақ мен әлі де осы мақаланы жазуды шештім, өйткені Habré туралы kubernetes және Windows туралы бірнеше мақалалар болды және ондай адамдар әлі де бар.
Үй
Мұның бәрі компаниямыздағы қызметтерді 70% Windows және 30% Linux болатын kubernetes-ке көшіру туралы шешім қабылданған кезде басталды. Осы мақсатта AWS EKS бұлттық қызметі ықтимал нұсқалардың бірі ретінде қарастырылды. 8 жылдың 2019 қазанына дейін AWS EKS Windows Public Preview режимінде болды, мен онымен бастадым, онда кубернеттердің ескі 1.11 нұсқасы қолданылған, бірақ мен оны бәрібір тексеріп, бұл бұлттық қызметтің қай кезеңде екенін, оның жұмыс істеп тұрғанын көруді шештім. мүлде, белгілі болғандай, жоқ, бұл бөлімшелерді жоюға байланысты қате болды, ал ескілері Windows жұмысшы түйіні сияқты ішкі желіден ішкі IP арқылы жауап беруді тоқтатты.
Сондықтан, AWS EKS-ті бірдей EC2-дегі кубернеттерде өз кластеріміздің пайдасына пайдаланудан бас тарту туралы шешім қабылданды, тек біз CloudFormation арқылы барлық теңгерімдеуді және HA-ны сипаттауымыз керек еді.
Amazon EKS Windows контейнерлік қолдауы қазір жалпы қолжетімді
Мартин Биби | 08 қазан 2019 ж
Мен өз кластерім үшін CloudFormation-ға үлгі қосуға үлгермей тұрып, мен бұл жаңалықты көрдім.
Әрине, мен барлық жұмысымды бір жаққа қойып, олардың GA үшін не істегенін және Public Preview көмегімен бәрі қалай өзгергенін зерттей бастадым. Иә, AWS, жақсы жасалды, Windows жұмысшы түйініне арналған кескіндерді 1.14 нұсқасына, сондай-ақ кластердің өзі, EKS жүйесіндегі 1.14 нұсқасы енді Windows түйіндерін қолдайды. Қоғамдық алдын ала қарау арқылы жоба Олар мұны жасырып, енді ресми құжаттаманы мына жерде пайдаланыңыз:
EKS кластерін ағымдағы VPC және ішкі желілерге біріктіру
Барлық дереккөздерде, хабарландырудағы жоғарыдағы сілтемеде, сондай-ақ құжаттамада кластерді меншікті eksctl утилитасы арқылы немесе CloudFormation + kubectl арқылы, тек Amazon-да жалпыға қолжетімді ішкі желілерді пайдаланып, сонымен қатар құру ұсынылды. жаңа кластер үшін бөлек VPC.
Бұл опция көпшілік үшін жарамсыз; біріншіден, бөлек VPC оның құнына қосымша шығындарды білдіреді + ағымдағы VPC-ге трафикті қарау. Өзінің бірнеше AWS тіркелгілері, VPC, ішкі желілер, маршрут кестелері, транзиттік шлюз және т.б. бар AWS-те дайын инфрақұрылымы бар адамдар не істеуі керек? Әрине, сіз мұның бәрін бұзғыңыз немесе қайта жасағыңыз келмейді және жаңа EKS кластерін қолданыстағы VPC пайдалана отырып, ағымдағы желілік инфрақұрылымға біріктіру керек және бөлу үшін кластер үшін ең көбі жаңа ішкі желілерді жасау керек.
Менің жағдайда бұл жол таңдалды, мен бар VPC қолдандым, жаңа кластер үшін тек 2 жалпы ішкі желі және 2 жеке ішкі желі қосылды, әрине, құжаттамаға сәйкес барлық ережелер ескерілді. .
Сондай-ақ бір шарт болды: EIP пайдаланатын жалпы ішкі желілерде жұмысшы түйіндері жоқ.
eksctl және CloudFormation
Мен кластерді орналастырудың екі әдісін де қолданып көргенімді бірден ескертемін, екі жағдайда да сурет бірдей болды.
Мен мысалды тек eksctl арқылы көрсетемін, себебі мұнда код қысқа болады. eksctl көмегімен кластерді 3 қадаммен орналастырыңыз:
1. Біз кластердің өзін + Linux жұмысшы түйінін жасаймыз, ол кейінірек жүйелік контейнерлерді және сол бір сәтсіз 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-ге орналастыру үшін ішкі желілеріңіздің идентификаторын көрсетіңіз және eksctl VPC-нің өзін анықтайды.
Жұмысшы түйіндері тек жеке ішкі желіге орналастырылғанына көз жеткізу үшін түйін тобы үшін --node-private-networking параметрін көрсету керек.
2. Біз өз кластерімізге vpc-контроллер орнатамыз, ол кейін бос IP мекенжайларының санын, сондай-ақ данадағы ENI санын есептеп, оларды қосу және жою арқылы жұмыс түйіндерімізді өңдейді.
eksctl utils install-vpc-controllers --name yyy --approve3. Жүйелік контейнерлер Linux жұмысшы түйінінде, соның ішінде vpc-контроллерінде сәтті іске қосылғаннан кейін 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-контроллеріндегі қате
Егер біз windows жұмысшы түйінінде қосқыштарды іске қосуға тырыссақ, қатені аламыз:
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-контроллер қосқышының журналдарын қарастырайық және біз мынаны көреміз:
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 қолдау қызметіне жазыңыз және оларға барлық жерден алынған журналдар жиынтығымен мәселенің мәнін айтыңыз және оларға сіздің VPC және ішкі желілерді пайдаланған кезде олардың қызметі жұмыс істемейтінін дәлелдеңіз, бізде Бизнес қолдауы болғаны бекер емес, сіз пайдалануыңыз керек. кем дегенде бір рет :)
AWS инженерлерімен байланыс
Порталда билетті жасағаннан кейін, мен қателесіп маған Веб-электрондық пошта немесе қолдау орталығы арқылы жауап бердім, бұл опция арқылы олар сізге бірнеше күннен кейін жауап бере алады, менің билетімнің ауырлығы - жүйе бұзылғанына қарамастан. <12 сағат ішінде жауап беруді білдіреді және Бизнесті қолдау жоспарында тәулік бойы қолдау көрсетілетіндіктен, мен ең жақсысын күттім, бірақ ол әдеттегідей болды.
Менің билетім жұмадан дүйсенбіге дейін тағайындалмай қалды, содан кейін мен оларға қайта хат жазуды шештім және Чат жауап опциясын таңдадым. Аз уақыт күткеннен кейін Харшад Мадхав мені қабылдауға тағайындалды, содан кейін ол басталды...
Біз онымен 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-контроллер үшін өте қажет қажетті ішкі желілермен байланыстары жоқ, жалпы ішкі желі жағдайында оның теңшелетін маршрут кестесі бар. оның ассоциациясы бар.
Қажетті ішкі желілері бар негізгі маршрут кестесіне ассоциацияларды қолмен қосу және түйін тобын қайта жасау арқылы бәрі тамаша жұмыс істейді.
Arun B. бұл қате туралы шынымен EKS әзірлеушілеріне хабарлайды және біз vpc-контроллерінің жаңа нұсқасын көреміз, онда бәрі қораптан шығады. Қазіргі уақытта соңғы нұсқасы: 602401143452.dkr.ecr.ap-souteast-1.amazonaws.com/eks/vpc-resource-controller:0.2.1
бұл мәселе бар.
Соңына дейін оқығандардың барлығына рахмет, іске асырмас бұрын өндірісте қолданатын барлық нәрсені сынап көріңіз.
Ақпарат көзі: www.habr.com