Günortanız xeyir, mən sizinlə Windows konteynerləri üçün AWS EKS (Elastic Kubernetes Service) xidmətinin qurulması və istifadəsi, daha doğrusu ondan istifadənin qeyri-mümkünlüyü və AWS sistem konteynerində aşkar edilən səhv haqqında təcrübəmi bölüşmək istəyirəm. Windows konteynerləri üçün bu xidmətlə maraqlananlar, xahiş edirik cat altında.
Bilirəm ki, Windows konteynerləri populyar mövzu deyil və onlardan az adam istifadə edir, amma yenə də bu məqaləni yazmağa qərar verdim, çünki kubernetlərdə və Windows-da Habré haqqında bir neçə məqalə var idi və hələ də belə insanlar var.
Start
Hər şey şirkətimizdəki xidmətləri 70% Windows və 30% Linux olan kubernetlərə köçürmək qərara alındıqdan sonra başladı. Bu məqsədlə AWS EKS bulud xidməti mümkün variantlardan biri kimi nəzərdən keçirilib. 8 oktyabr 2019-cu il tarixinə qədər AWS EKS Windows Public Preview-da idi, mən onunla başladım, orada kubernetlərin köhnə 1.11 versiyası istifadə olunurdu, amma hər halda onu yoxlamaq qərarına gəldim və bu bulud xidmətinin hansı mərhələdə olduğunu, işlədiyini görməyə qərar verdim. ümumiyyətlə, göründüyü kimi, yox, podların çıxarılması ilə bağlı bir səhv var idi, köhnələr isə Windows işçi node ilə eyni alt şəbəkədən daxili ip vasitəsilə cavab verməyi dayandırdılar.
Buna görə də, eyni EC2-də kubernetlərdəki öz klasterimizin xeyrinə AWS EKS-in istifadəsindən imtina etmək qərara alındı, yalnız bütün balanslaşdırma və HA-nı CloudFormation vasitəsilə özümüz təsvir etməli olacağıq.
Amazon EKS Windows Konteyner Dəstəyi indi Ümumiyyətlə mövcuddur
Martin Beeby tərəfindən | 08 oktyabr 2019-cu il
Öz klasterim üçün CloudFormation-a şablon əlavə etməyə vaxt tapmamışdan əvvəl bu xəbəri gördüm.
Təbii ki, bütün işlərimi bir kənara qoyub onların GA üçün nə etdiklərini və Public Preview ilə hər şeyin necə dəyişdiyini öyrənməyə başladım. Bəli, AWS, yaxşı iş gördü, Windows işçi qovşağı üçün şəkilləri 1.14 versiyasına yenilədi, həmçinin klasterin özü, EKS-də 1.14 versiyası indi Windows qovşaqlarını dəstəkləyir. Public Preview tərəfindən layihə Bunu ört-basdır etdilər və dedilər ki, indi burada rəsmi sənədlərdən istifadə edin:
EKS klasterinin cari VPC və alt şəbəkələrə inteqrasiyası
Bütün mənbələrdə, elandakı yuxarıdakı linkdə, eləcə də sənədlərdə, klasterin ya xüsusi eksctl utiliti vasitəsilə, ya da CloudFormation + kubectl vasitəsilə, yalnız Amazonda ictimai alt şəbəkələrdən istifadə etməklə, həmçinin yeni klaster üçün ayrı VPC.
Bu seçim çoxları üçün uyğun deyil; birincisi, ayrıca VPC onun dəyəri + cari VPC-yə baxış trafiki üçün əlavə xərclər deməkdir. Öz Çoxsaylı AWS hesabları, VPC, alt şəbəkələri, marşrut cədvəlləri, tranzit şlüzləri və s. olan AWS-də artıq hazır infrastruktura malik olanlar nə etməlidirlər? Əlbəttə ki, siz bütün bunları pozmaq və ya yenidən etmək istəmirsiniz və mövcud VPC-dən istifadə edərək yeni EKS klasterini cari şəbəkə infrastrukturuna inteqrasiya etməli və ayrılmaq üçün ən çoxu klaster üçün yeni alt şəbəkələr yaratmalısınız.
Mənim vəziyyətimdə bu yol seçildi, mən mövcud VPC-dən istifadə etdim, yeni klaster üçün yalnız 2 ictimai alt şəbəkə və 2 şəxsi alt şəbəkə əlavə etdim, əlbəttə ki, sənədlərə uyğun olaraq bütün qaydalar nəzərə alındı. .
Bir şərt də var idi: EIP istifadə edən ictimai alt şəbəkələrdə işçi qovşaqları yoxdur.
eksctl vs CloudFormation
Dərhal qeyd edəcəyəm ki, çoxluq yerləşdirməyin hər iki üsulunu sınamışam, hər iki halda şəkil eyni idi.
Mən yalnız eksctl istifadə edərək nümunə göstərəcəyəm, çünki buradakı kod daha qısa olacaq. eksctl istifadə edərək, klasteri 3 addımda yerləşdirin:
1. Biz klasterin özünü + Linux işçi qovşağını yaradırıq, sonra sistem konteynerlərini və eyni uğursuz vpc-nəzarətçini qəbul edəcək.
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-networkingMövcud VPC-yə yerləşdirmək üçün sadəcə alt şəbəkələrinizin id-sini göstərin və eksctl VPC-nin özünü müəyyən edəcək.
İşçi qovşaqlarınızın yalnız şəxsi alt şəbəkəyə yerləşdirilməsini təmin etmək üçün nodegroup üçün --node-private-networking-i təyin etməlisiniz.
2. Biz klasterimizdə vpc-nəzarətçi quraşdırırıq, o, daha sonra işçi qovşaqlarımızı emal edəcək, pulsuz IP ünvanlarının sayını, eləcə də instansiyadakı ENI-lərin sayını hesablayacaq, onları əlavə edib çıxaracaq.
eksctl utils install-vpc-controllers --name yyy --approve3. Sistem konteynerləriniz vpc-nəzarətçi də daxil olmaqla, Linux işçi nodeunuzda uğurla işə salındıqdan sonra qalan şey Windows işçiləri ilə başqa bir nodeqrup yaratmaqdır.
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-networkingQovşağınız klasterinizə uğurla qoşulduqdan və hər şey qaydasında göründükdən sonra o, Hazır statusundadır, lakin yox.
Vpc nəzarətçisində xəta
Bir Windows işçi qovşağında podları işə salmağa çalışsaq, səhv alacağıq:
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]Daha dərindən baxsaq, görərik ki, AWS-dəki nümunəmiz belə görünür:
Və bu belə olmalıdır:
Buradan aydın olur ki, vpc-nəzarətçi nədənsə üzərinə düşəni yerinə yetirməyib və podların istifadə edə bilməsi üçün instansiyaya yeni IP ünvanları əlavə edə bilməyib.
Gəlin vpc-nəzarətçi podunun qeydlərinə baxaq və gördüyümüz budur:
kubectl jurnalı -n kube sistemi
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-da axtarışlar heç nəyə gətirib çıxarmadı, deyəsən, hələ heç kim belə bir səhvə rast gəlmədiyindən və ya bu barədə problem yazmadığından, əvvəlcə özüm variantları düşünməli oldum. İlk ağlıma gələn o oldu ki, bəlkə də vpc-nəzarətçi ip-10-xxx.ap-xxx.compute.internal-ı həll edə bilmir və ona çata bilmir və buna görə də xətalar baş verir.
Bəli, həqiqətən, biz VPC-də xüsusi DNS serverlərindən istifadə edirik və prinsipcə, Amazon serverlərindən istifadə etmirik, buna görə də bu ap-xxx.compute.internal domeni üçün yönləndirmə konfiqurasiya edilməmişdir. Mən bu seçimi sınaqdan keçirdim və nəticə vermədi, bəlkə də test təmiz deyildi və buna görə də, texniki dəstək ilə əlaqə qurarkən onların fikrinə tab gətirdim.
Həqiqətən heç bir fikir olmadığından, bütün təhlükəsizlik qrupları eksctl özü tərəfindən yaradılmışdır, buna görə də onların xidmət qabiliyyətinə şübhə yox idi, marşrut cədvəlləri də düzgün idi, nat, dns, işçi qovşaqları ilə İnternetə çıxış da var idi.
Üstəlik, əgər siz — node-private-networking istifadə etmədən işçi qovşağını ictimai alt şəbəkəyə yerləşdirsəniz, bu node vpc nəzarətçisi tərəfindən dərhal yeniləndi və hər şey saat mexanizmi kimi işlədi.
İki variant var idi:
- Bundan imtina edin və kimsə AWS-də bu səhvi təsvir edənə qədər gözləyin və onlar onu düzəldiblər, sonra siz AWS EKS Windows-dan təhlükəsiz istifadə edə bilərsiniz, çünki onlar GA-da yenicə buraxılıblar (bu məqalənin yazıldığı vaxtdan 8 gün keçib), çoxları yəqin ki, mənimlə eyni yolla get.
- AWS Dəstək xidmətinə yazın və onlara hər yerdən bütöv bir jurnalla problemin mahiyyətini söyləyin və onlara sübut edin ki, sizin VPC və alt şəbəkələrdən istifadə edərkən onların xidmətinin işləmədiyini sübut edin, bizim Biznes dəstəyimiz əbəs yerə deyil, siz istifadə etməlisiniz. heç olmasa bir dəfə :)
AWS mühəndisləri ilə əlaqə
Portalda bilet yaratdıqdan sonra səhvən mənə Veb - e-poçt və ya dəstək mərkəzi vasitəsilə cavab verməyi seçdim, bu seçim vasitəsilə onlar sizə bir neçə gündən sonra cavab verə bilərlər, baxmayaraq ki, biletimdə ciddilik - sistem pozulmuşdur. <12 saat ərzində cavab verməyi nəzərdə tuturdu və Biznes dəstək planının 24/7 dəstəyi olduğundan, ən yaxşısına ümid edirdim, lakin həmişə olduğu kimi oldu.
Biletim cümə günündən bazar ertəsinə qədər təyin olunmamış qaldı, sonra mən onlara yenidən yazmaq qərarına gəldim və Çat cavab seçimini seçdim. Qısa müddət gözlədikdən sonra Harşad Mədhav məni görməyə təyin olundu və sonra başladı...
Biz onunla 3 saat ardıcıl olaraq onlayn olaraq düzəliş etdik, qeydləri köçürdük, problemi təqlid etmək üçün eyni klasteri AWS laboratoriyasında yerləşdirdik, mənim tərəfimdən klasteri yenidən yaratdıq və s. qeydlərdə aydın oldu ki, yuxarıda yazdığım AWS daxili domen adları həlli işləmir və Harshad Madhav məndən yönləndirmə yaratmağımı xahiş etdi, guya biz xüsusi DNS istifadə edirik və bu problem ola bilər.
Ekspeditorluq
ap-xxx.compute.internal -> 10.x.x.2 (VPC CIDRBlock)
amazonaws.com -> 10.x.x.2 (VPC CIDRBlock)Bu edildi, gün bitdi. Harşad Madhav yoxlamaq üçün cavab yazdı və işləməlidir, amma yox, qətnamə heç bir kömək etmədi.
Sonra daha 2 mühəndislə əlaqə yarandı, biri sadəcə söhbətdən çıxdı, görünür, mürəkkəb bir işdən qorxdu, ikincisi günümü yenidən tam ayıklama, log göndərmək, hər iki tərəfdə klasterlər yaratmaqla keçirdi. sonunda o, sadəcə yaxşı dedi, mənim üçün işləyir, mən buradayam rəsmi sənədlərdə hər şeyi addım-addım edirəm və siz və siz uğur qazanacaqsınız.
Problemi harada axtaracağınızı bilmirsinizsə, nəzakətlə ondan ayrılıb biletimə başqasını təyin etməsini xahiş etdim.
Final
Üçüncü gün mənə yeni mühəndis Arun B. təyin olundu və onunla ünsiyyətin əvvəlindən dərhal aydın oldu ki, bu, əvvəlki 3 mühəndis deyil. O, bütün tarixi oxudu və dərhal github-da olan ps1-də öz skriptindən istifadə edərək qeydləri toplamaq istədi. Bunun ardınca klasterlərin yaradılması, əmrlərin nəticələrinin çıxarılması, jurnalların toplanması kimi bütün təkrarlar təkrarlandı, lakin Arun B. mənə verilən suallara əsasən düzgün istiqamətdə hərəkət edirdi.
Onların vpc-nəzarətçisində -stderrthreshold=debug funksiyasını işə salmaq məqamına nə vaxt gəldik və bundan sonra nə oldu? əlbəttə ki, işləmir) pod sadəcə bu seçimlə başlamır, yalnız -stderrthreshold=info işləyir.
Burada bitirdik və Arun B. eyni səhvi almaq üçün mənim addımlarımı təkrar etməyə çalışacağını söylədi. Ertəsi gün Arun B-dən cavab alıram. o, bu işi tərk etmədi, lakin onların vpc-nəzarətçisinin nəzərdən keçirmə kodunu götürdü və onun harada olduğunu və niyə işləmədiyini tapdı:
Beləliklə, VPC-nizdə əsas marşrut cədvəlindən istifadə edirsinizsə, o zaman standart olaraq, vpc-nəzarətçi üçün zəruri olan lazımi alt şəbəkələrlə əlaqəsi yoxdur, ictimai alt şəbəkə vəziyyətində, xüsusi marşrut cədvəlinə malikdir. birlik.
Lazımi alt şəbəkələrlə əsas marşrut cədvəli üçün assosiasiyaları əl ilə əlavə etməklə və nodeqrupu yenidən yaratmaqla hər şey mükəmməl işləyir.
Ümid edirəm ki, Arun B. həqiqətən də bu səhvi EKS tərtibatçılarına bildirəcək və biz vpc-nəzarətçinin yeni versiyasını görəcəyik, burada hər şey qutudan çıxacaq. Hazırda ən son versiya: 602401143452.dkr.ecr.ap-souteast-1.amazonaws.com/eks/vpc-resource-controller:0.2.1
bu problemi var.
Sona qədər oxuyan hər kəsə təşəkkür edirik, istehsalda istifadə edəcəyiniz hər şeyi həyata keçirməzdən əvvəl sınaqdan keçirin.
Mənbə: www.habr.com