Amazon EKS Windows-ს GA-ში აქვს შეცდომები, მაგრამ ყველაზე სწრაფია

შუადღე მშვიდობისა, მინდა გაგიზიაროთ ჩემი გამოცდილება Windows კონტეინერებისთვის AWS EKS (ელასტიური Kubernetes სერვისის) სერვისის დაყენებისა და გამოყენების შესახებ, უფრო სწორად მისი გამოყენების შეუძლებლობისა და AWS სისტემის კონტეინერში აღმოჩენილი ხარვეზის შესახებ. ვინც დაინტერესებულია ამ სერვისით Windows კონტეინერებისთვის, გთხოვთ, ქვეშ cat.

ვიცი, რომ ვინდოუსის კონტეინერები არ არის პოპულარული თემა და ცოტა ადამიანი იყენებს მათ, მაგრამ მაინც გადავწყვიტე დამეწერა ეს სტატია, რადგან Habré-ზე იყო რამდენიმე სტატია kubernetes-ზე და Windows-ზე და ჯერ კიდევ არის ასეთი ხალხი.

დაწყება

ყველაფერი დაიწყო, როდესაც გადაწყდა ჩვენი კომპანიის სერვისების მიგრაცია kubernetes-ზე, რომელიც არის 70% Windows და 30% Linux. ამ მიზნით ერთ-ერთ შესაძლო ვარიანტად განიხილებოდა AWS EKS ღრუბლოვანი სერვისი. 8 წლის 2019 ოქტომბრამდე AWS EKS Windows იყო Public Preview-ში, დავიწყე ამით, იქ იყენებდნენ kubernetes-ის ძველი 1.11 ვერსიას, მაგრამ გადავწყვიტე მაინც გადამემოწმებინა და მენახა რა ეტაპზე იყო ეს ღრუბლოვანი სერვისი, მუშაობდა თუ არა. საერთოდ, როგორც გაირკვა, არა, იყო შეცდომა პოდების წაშლის დამატებით, ხოლო ძველებმა შეწყვიტეს რეაგირება შიდა IP-ით იმავე ქვექსელიდან, როგორც windows Worker კვანძი.

ამიტომ, გადაწყდა, რომ უარი ეთქვათ AWS EKS-ის გამოყენებაზე ჩვენივე კლასტერის სასარგებლოდ kubernetes-ზე იმავე EC2-ზე, მხოლოდ ჩვენ მოგვიწევდა აღვწეროთ ყველა დაბალანსება და HA თავად CloudFormation-ის საშუალებით.

Amazon EKS Windows Container მხარდაჭერა ახლა ზოგადად ხელმისაწვდომია

მარტინ ბიბის მიერ | 08 წლის 2019 ოქტ

სანამ დრო მქონდა CloudFormation-ში შაბლონის დამატების დრო ჩემი საკუთარი კლასტერისთვის, ვნახე ეს სიახლე Amazon EKS Windows Container მხარდაჭერა ახლა ზოგადად ხელმისაწვდომია

რა თქმა უნდა, მთელი ჩემი სამუშაო გვერდზე გადავდე და დავიწყე იმის შესწავლა, თუ რა გააკეთეს მათ GA-სთვის და როგორ შეიცვალა ყველაფერი Public Preview-ით. დიახ, AWS, კარგად გაკეთებული, განახლებულია Windows Worker Node-ის სურათები 1.14 ვერსიამდე, ისევე როგორც თავად კლასტერი, ვერსია 1.14 EKS-ში, ახლა მხარს უჭერს windows კვანძებს. პროექტი Public Preview at github მათ დაფარეს და თქვეს, ახლა გამოიყენეთ ოფიციალური დოკუმენტაცია აქ: EKS Windows მხარდაჭერა

EKS კლასტერის ინტეგრირება მიმდინარე VPC-სა და ქვექსელებში

ყველა წყაროში, განცხადების ზემოთ მოცემულ ბმულზე, ისევე როგორც დოკუმენტაციაში, შემოთავაზებული იყო კლასტერის განლაგება ან საკუთრებაში არსებული eksctl უტილიტის მეშვეობით, ან CloudFormation + kubectl-ის შემდეგ, მხოლოდ ამაზონის საჯარო ქვექსელის გამოყენებით, ისევე როგორც შექმნა. ცალკე VPC ახალი კლასტერისთვის.

ეს ვარიანტი არ არის შესაფერისი ბევრისთვის; პირველ რიგში, ცალკე VPC ნიშნავს დამატებით ხარჯებს მისი ღირებულებისთვის + თქვენი ამჟამინდელი VPC-ის ტრაფიკის შესატყვისი. რა უნდა გააკეთონ მათ, ვისაც უკვე აქვს მზა ინფრასტრუქტურა AWS-ში საკუთარი მრავალი AWS ანგარიშებით, VPC, ქვექსელებით, მარშრუტების ცხრილებით, სატრანზიტო კარიბჭით და ა.შ.? რა თქმა უნდა, თქვენ არ გსურთ ამ ყველაფრის დაშლა ან ხელახლა გაკეთება და თქვენ გჭირდებათ ახალი EKS კლასტერის ინტეგრირება მიმდინარე ქსელის ინფრასტრუქტურაში არსებული VPC-ის გამოყენებით და, განცალკევებისთვის, მაქსიმუმ ახალი ქვექსელის შექმნა კლასტერისთვის.

ჩემს შემთხვევაში აირჩიეს ეს გზა, გამოვიყენე არსებული VPC, დავამატე მხოლოდ 2 საჯარო ქვექსელი და 2 კერძო ქვექსელი ახალი კლასტერისთვის, რა თქმა უნდა, ყველა წესი გათვალისწინებული იყო დოკუმენტაციის მიხედვით. შექმენით თქვენი Amazon EKS Cluster VPC.

ასევე იყო ერთი პირობა: არ იყო მუშა კვანძები საჯარო ქვექსელებში EIP-ის გამოყენებით.

eksctl vs 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-ზე განლაგების მიზნით, უბრალოდ მიუთითეთ თქვენი ქვექსელის ID და eksctl თავად განსაზღვრავს VPC-ს.

იმის უზრუნველსაყოფად, რომ თქვენი მუშა კვანძები განლაგებულია მხოლოდ კერძო ქვექსელში, თქვენ უნდა მიუთითოთ --node-private-networking კვანძების ჯგუფისთვის.

2. ჩვენ ვაინსტალირებთ vpc-კონტროლერს ჩვენს კლასტერში, რომელიც შემდეგ დაამუშავებს ჩვენს მუშა კვანძებს, დათვლის უფასო IP მისამართების რაოდენობას, ასევე ENI-ების რაოდენობას ინსტანციაზე, დაამატებს და წაშლის მათ.

eksctl utils install-vpc-controllers --name yyy --approve

3. მას შემდეგ, რაც თქვენი სისტემის კონტეინერები წარმატებით ამოქმედდება თქვენს Linux მუშა კვანძზე, vpc-კონტროლერის ჩათვლით, რჩება მხოლოდ შექმნათ სხვა კვანძების ჯგუფი Windows Workers-ით.

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 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-კონტროლერმა რატომღაც არ შეასრულა თავისი ნაწილი და ვერ დაამატა ახალი 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.

გუგლში ძიებამ ვერაფერი გამოიწვია, რადგან აშკარად ჯერ არავის დაუფიქსირებია ასეთი ხარვეზი, ან არ გამოუქვეყნებია პრობლემა, ჯერ მე თვითონ მომიწია ვარიანტების მოფიქრება. პირველი, რაც გამახსენდა, იყო, რომ შესაძლოა vpc-კონტროლერმა ვერ გადაჭრას ip-10-xxx.ap-xxx.compute.internal და მიაღწიოს მას და, შესაბამისად, წარმოიქმნება შეცდომები.

დიახ, მართლაც, ჩვენ ვიყენებთ მორგებულ DNS სერვერებს VPC-ში და, პრინციპში, არ ვიყენებთ Amazon-ს, ამიტომ გადამისამართებაც კი არ იყო კონფიგურირებული ამ ap-xxx.compute.internal დომენისთვის. მე გამოვცადე ეს ვარიანტი და მან შედეგი არ მოიტანა, ალბათ ტესტი არ იყო სუფთა და, შესაბამისად, შემდგომ, ტექნიკურ მხარდაჭერასთან კომუნიკაციისას, მე დავემორჩილე მათ იდეას.

ვინაიდან იდეები ნამდვილად არ არსებობდა, უსაფრთხოების ყველა ჯგუფი შეიქმნა თავად eksctl-ის მიერ, ასე რომ, ეჭვი არ ეპარებოდა მათ სერვისულობაში, მარშრუტების ცხრილებიც სწორი იყო, nat, dns, ინტერნეტის წვდომა სამუშაო კვანძებითაც იყო.

უფრო მეტიც, თუ თქვენ განათავსებთ მუშა კვანძს საჯარო ქვექსელში —node-private-networking-ის გამოყენების გარეშე, ეს კვანძი მაშინვე განახლდა vpc-კონტროლერის მიერ და ყველაფერი მუშაობდა საათის მსგავსად.

ორი ვარიანტი იყო:

1. უარი თქვით და დაელოდეთ სანამ ვინმე აღწერს ამ შეცდომას AWS-ში და გამოასწორებს მას, შემდეგ კი შეგიძლიათ უსაფრთხოდ გამოიყენოთ AWS EKS Windows, რადგან ისინი ახლახან გამოუშვეს GA-ში (8 დღე გავიდა ამ სტატიის დაწერის მომენტში), ალბათ ბევრი მიჰყევი იმავე გზას, როგორც მე.
2. მიწერე AWS Support-ს და უთხარი მათ პრობლემის არსი ლოგების მთელი წყობით ყველგან და დაუმტკიცე, რომ მათი სერვისი არ მუშაობს თქვენი VPC და ქვექსელების გამოყენებისას, ტყუილად არ გვქონდა Business მხარდაჭერა, თქვენ უნდა გამოიყენოთ ერთხელ მაინც :)

კომუნიკაცია 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 წინა ინჟინერი. მან წაიკითხა მთელი ისტორია და მაშინვე სთხოვა ჟურნალების შეგროვება საკუთარი სკრიპტის გამოყენებით ps1-ზე, რომელიც მის github-ზე იყო. ამას ისევ მოჰყვა კლასტერების შექმნის ყველა გამეორება, ბრძანების შედეგების გამოტანა, ლოგების შეგროვება, მაგრამ არუნ ბ. სწორი მიმართულებით მოძრაობდა ჩემთვის დასმული კითხვების მიხედვით.

როდის მივედით იქამდე, რომ ჩართოთ -stderrthreshold=გამართვა მათ vpc-კონტროლერში და რა მოხდა შემდეგ? რა თქმა უნდა, ეს არ მუშაობს) პოდი უბრალოდ არ იწყება ამ პარამეტრით, მუშაობს მხოლოდ -stderrthreshold=info.

ჩვენ აქ დავასრულეთ და არუნ ბ-მ თქვა, რომ შეეცდებოდა ჩემი ნაბიჯების გამეორებას იგივე შეცდომის მისაღებად. მეორე დღეს მივიღე პასუხი Arun B.-სგან, მან არ მიატოვა ეს საქმე, მაგრამ აიღო მათი vpc-კონტროლერის განხილვის კოდი და იპოვა ადგილი, სადაც არის და რატომ არ მუშაობს:

ამრიგად, თუ თქვენ იყენებთ მთავარ მარშრუტების ცხრილს თქვენს VPC-ში, მაშინ მას ნაგულისხმევად არ აქვს ასოციაციები საჭირო ქვექსელებთან, რომლებიც ასე აუცილებელია vpc-კონტროლერისთვის, საჯარო ქვექსელის შემთხვევაში, მას აქვს მორგებული მარშრუტის ცხრილი. რომელსაც აქვს ასოციაცია.

მთავარი მარშრუტის ცხრილისთვის ასოციაციების ხელით დამატებით საჭირო ქვექსელებით და კვანძების ჯგუფის ხელახლა შექმნით, ყველაფერი იდეალურად მუშაობს.

იმედი მაქვს, რომ Arun B. ნამდვილად შეატყობინებს ამ შეცდომას EKS დეველოპერებს და ჩვენ ვიხილავთ vpc-კონტროლერის ახალ ვერსიას, სადაც ყველაფერი გამოსწორდება. ამჟამად უახლესი ვერსიაა: 602401143452.dkr.ecr.ap-southeast-1.amazonaws.com/eks/vpc-resource-controller:0.2.1
აქვს ეს პრობლემა.

მადლობა ყველას, ვინც ბოლომდე წაიკითხა, შეამოწმეთ ყველაფერი, რისი გამოყენებასაც აპირებთ წარმოებაში განხორციელებამდე.

წყარო: www.habr.com