Dzień dobry, chcę podzielić się z Wami moimi doświadczeniami w konfiguracji i obsłudze usługi AWS EKS (Elastic Kubernetes Service) dla kontenerów Windows, a raczej o niemożności jej wykorzystania oraz o błędzie znalezionym w kontenerze systemu AWS, dla tych zainteresowanych tą usługą dla kontenerów Windows prosimy o wpis w kat.
Wiem, że kontenery Windows nie są popularnym tematem i niewiele osób z nich korzysta, ale mimo to zdecydowałem się napisać ten artykuł, ponieważ było kilka artykułów na temat Habré na Kubernetes i Windows i nadal są tacy ludzie.
początek
Wszystko zaczęło się od decyzji o migracji usług w naszej firmie na kubernetes, czyli w 70% Windows i 30% Linux. W tym celu jako jedną z możliwych opcji uznano usługę chmurową AWS EKS. Do 8 października 2019 AWS EKS Windows był w Public Preview, zacząłem od niego, używana była tam stara wersja kubernetesa 1.11, ale mimo wszystko postanowiłem to sprawdzić i zobaczyć na jakim etapie jest ta usługa w chmurze, czy działa w ogóle, jak się okazało, nie, był błąd polegający na dodaniu usuwania podów, podczas gdy stare przestały odpowiadać poprzez wewnętrzne IP z tej samej podsieci, co węzeł Windows Worker.
Dlatego zdecydowano się zrezygnować z używania AWS EKS na rzecz własnego klastra na Kubernetes na tym samym EC2, tyle że musielibyśmy sami opisać całe równoważenie i HA poprzez CloudFormation.
Obsługa kontenerów Windows Amazon EKS jest teraz ogólnie dostępna
autor: Martin Beeby | w dniu 08 października 2019 r
Zanim zdążyłem dodać szablon do CloudFormation dla mojego własnego klastra, zobaczyłem tę wiadomość
Oczywiście odłożyłem całą moją pracę i zacząłem studiować, co zrobili dla GA i jak wszystko się zmieniło dzięki Public Preview. Tak, AWS, dobra robota, zaktualizował obrazy węzła roboczego systemu Windows do wersji 1.14, a także samego klastra, wersja 1.14 w EKS, obsługuje teraz węzły systemu Windows. Projekt autorstwa Public Preview o godz Zatuszowali to i powiedzieli, że teraz użyj oficjalnej dokumentacji tutaj:
Integracja klastra EKS z obecną siecią VPC i podsieciami
We wszystkich źródłach, w powyższym linku w ogłoszeniu, jak i w dokumentacji, proponowano wdrożenie klastra albo poprzez autorskie narzędzie eksctl, albo poprzez CloudFormation + kubectl po, wyłącznie przy użyciu podsieci publicznych w Amazon, a także utworzenie oddzielne VPC dla nowego klastra.
Ta opcja nie jest odpowiednia dla wielu; po pierwsze, osobna VPC oznacza dodatkowe koszty w stosunku do jej kosztu + ruch peeringowy do Twojej obecnej VPC. Co powinni zrobić ci, którzy mają już gotową infrastrukturę w AWS z własnymi kontami Multiple AWS, VPC, podsieciami, tabelami tras, bramą tranzytową i tak dalej? Oczywiście nie chcesz tego wszystkiego psuć ani przerabiać, a nowy klaster EKS musisz zintegrować z obecną infrastrukturą sieciową, korzystając z istniejącej VPC i dla separacji co najwyżej stworzyć nowe podsieci dla klastra.
W moim przypadku wybrano tę ścieżkę, wykorzystałem istniejące VPC, do nowego klastra dodałem tylko 2 podsieci publiczne i 2 podsieci prywatne, oczywiście wszystkie zasady zostały wzięte pod uwagę zgodnie z dokumentacją .
Był też jeden warunek: brak węzłów roboczych w podsieciach publicznych korzystających z protokołu EIP.
eksctl vs CloudFormation
Od razu zastrzegam, że próbowałem obu metod wdrażania klastra, w obu przypadkach obraz był taki sam.
Pokażę przykład używając wyłącznie eksctl, ponieważ kod tutaj będzie krótszy. Używając eksctl, wdróż klaster w 3 krokach:
1. Tworzymy sam klaster + węzeł roboczy Linux, który później będzie hostował kontenery systemowe i ten sam niefortunny kontroler 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-networkingAby wdrożyć w istniejącej VPC, po prostu określ identyfikator swoich podsieci, a eksctl sam określi VPC.
Aby mieć pewność, że węzły robocze zostaną wdrożone tylko w podsieci prywatnej, należy określić --node-private-networking dla grupy węzłów.
2. Instalujemy w naszym klastrze kontroler vpc, który następnie będzie przetwarzał nasze węzły robocze, zliczając liczbę wolnych adresów IP, a także liczbę ENI na instancji, dodając je i usuwając.
eksctl utils install-vpc-controllers --name yyy --approve3. Po pomyślnym uruchomieniu kontenerów systemowych w węźle roboczym systemu Linux, łącznie z kontrolerem vpc, pozostaje jedynie utworzyć kolejną grupę węzłów z procesami roboczymi systemu 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-networkingGdy węzeł pomyślnie połączy się z klastrem i wszystko wydaje się być w porządku, ma on status Gotowy, ale nie.
Błąd w kontrolerze vpc
Jeśli spróbujemy uruchomić pody w węźle roboczym systemu Windows, pojawi się błąd:
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]Jeśli przyjrzymy się głębiej, zobaczymy, że nasza instancja w AWS wygląda następująco:
A powinno być tak:
Z tego jasno wynika, że kontroler vpc z jakiegoś powodu nie spełnił swojej roli i nie mógł dodać nowych adresów IP do instancji, aby pody mogły z nich korzystać.
Spójrzmy na logi modułu vpc-controller i oto co widzimy:
dziennik kubectl -n kube-system
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.Wyszukiwania w Google nic nie dały, bo najwyraźniej nikt jeszcze takiego błędu nie wyłapał, ani nie zamieścił na nim problemu, musiałem najpierw sam pomyśleć o opcjach. Pierwszą rzeczą, która przyszła mi na myśl, było to, że być może kontroler vpc nie może rozpoznać ip-10-xxx.ap-xxx.compute.internal i dotrzeć do niego, w związku z czym pojawiają się błędy.
Tak, rzeczywiście używamy niestandardowych serwerów DNS w VPC i w zasadzie nie korzystamy z serwerów Amazon, więc nawet przekierowanie nie zostało skonfigurowane dla tej domeny ap-xxx.compute.internal. Testowałem tę opcję i nie przyniosło to rezultatów, być może test nie był czysty, dlatego dalej, komunikując się z pomocą techniczną, uległem ich pomysłowi.
Ponieważ nie było żadnych pomysłów, wszystkie grupy bezpieczeństwa zostały utworzone przez samego eksctl, więc nie było wątpliwości co do ich przydatności, tablice tras również były prawidłowe, nat, dns, dostęp do Internetu z węzłami roboczymi też był.
Co więcej, jeśli wdrożysz węzeł roboczy w podsieci publicznej bez użycia —node-private-networking, węzeł ten zostanie natychmiast zaktualizowany przez kontroler vpc i wszystko będzie działać jak w zegarku.
Były dwie opcje:
- Daj sobie spokój i poczekaj, aż ktoś opisze ten błąd w AWS i go naprawi, a wtedy będziesz mógł bezpiecznie korzystać z AWS EKS Windows, ponieważ właśnie wypuścili w GA (w momencie pisania tego artykułu minęło 8 dni), wielu prawdopodobnie podążaj tą samą drogą co ja.
- Napisz do AWS Support i opowiedz im o istocie problemu całą masą logów zewsząd i udowodnij im, że ich usługa nie działa przy korzystaniu z Twojej VPC i podsieci, nie bez powodu mieliśmy wsparcie Biznesowe, warto skorzystać to chociaż raz :)
Komunikacja z inżynierami AWS
Po utworzeniu zgłoszenia na portalu przez pomyłkę zdecydowałem się odpowiedzieć mi przez Internet - e-mail lub centrum wsparcia, dzięki tej opcji mogą odpowiedzieć w ogóle po kilku dniach, mimo że moje zgłoszenie miało Poziom ważności - Uszkodzenie systemu, co oznaczało odpowiedź w ciągu <12 godzin, a ponieważ plan wsparcia Business obejmuje wsparcie 24 godziny na dobę, 7 dni w tygodniu, liczyłem na najlepsze, ale wyszło jak zawsze.
Moje zgłoszenie pozostało nieprzydzielone od piątku do poniedziałku, po czym zdecydowałem się napisać do nich ponownie i wybrałem opcję odpowiedzi na czacie. Po krótkim oczekiwaniu wyznaczono na wizytę Harshada Madhava i wtedy się zaczęło...
Debugowaliśmy z nim online przez 3 godziny z rzędu, przesyłając logi, wdrażając ten sam klaster w laboratorium AWS w celu emulacji problemu, ponownie tworząc klaster z mojej strony itd. Jedyne, do czego doszliśmy, to to, że z z logów było jasne, że resol nie działa na wewnętrznych nazwach domen AWS, o czym pisałem powyżej, a Harshad Madhav poprosił mnie o utworzenie przekierowania, rzekomo używamy niestandardowego DNS i z tym może być problem.
Przekierowanie
ap-xxx.compute.internal -> 10.x.x.2 (VPC CIDRBlock)
amazonaws.com -> 10.x.x.2 (VPC CIDRBlock)Tak się stało, dzień dobiegł końca. Harshad Madhav odpisał, żeby to sprawdzić i powinno działać, ale nie, to rozwiązanie wcale nie pomogło.
Potem była komunikacja z jeszcze 2 inżynierami, jeden po prostu wypadł z czatu, widocznie bał się skomplikowanej sprawy, drugi znów spędził dzień na pełnym cyklu debugowania, wysyłania logów, tworzenia klastrów po obu stronach, w koniec, po prostu powiedział dobrze, u mnie to działa, oto jestem, robię wszystko krok po kroku w oficjalnej dokumentacji, a ty i ty odniesiecie sukces.
Na co grzecznie poprosiłem aby wyszedł i przypisał do mojego biletu kogoś innego jeśli nie wiadomo gdzie szukać problemu.
Finał
Trzeciego dnia przydzielono mi nowego inżyniera Aruna B. i od samego początku komunikacji z nim było od razu jasne, że nie jest to 3 poprzednich inżynierów. Przeczytał całą historię i od razu poprosił o zebranie logów za pomocą własnego skryptu na ps1, który był na jego githubie. Potem znowu nastąpiły wszystkie iteracje tworzenia klastrów, wysyłania wyników poleceń, zbierania dzienników, ale Arun B. zmierzał we właściwym kierunku, sądząc po zadawanych mi pytaniach.
Kiedy doszliśmy do momentu włączenia opcji -stderrthreshold=debug w ich kontrolerze vpc i co stało się później? oczywiście to nie działa) kapsuła po prostu nie uruchamia się z tą opcją, działa tylko -stderrthreshold=info.
Skończyliśmy na tym, a Arun B. powiedział, że spróbuje odtworzyć moje kroki, aby uzyskać ten sam błąd. Następnego dnia otrzymuję odpowiedź od Aruna B. nie porzucił tej sprawy, ale wziął kod recenzyjny ich kontrolera vpc i znalazł miejsce, w którym się znajduje i dlaczego nie działa:
Tak więc, jeśli używasz głównej tabeli tras w swoim VPC, to domyślnie nie ma ona powiązań z niezbędnymi podsieciami, które są tak niezbędne dla kontrolera vpc, w przypadku podsieci publicznej ma niestandardową tabelę tras to ma skojarzenie.
Po ręcznym dodaniu powiązań do głównej tabeli tras z niezbędnymi podsieciami i ponownym utworzeniu grupy węzłów wszystko działa idealnie.
Mam nadzieję, że Arun B. naprawdę zgłosi ten błąd programistom EKS i zobaczymy nową wersję kontrolera vpc, w której wszystko będzie działać od razu po wyjęciu z pudełka. Obecnie najnowsza wersja to: 602401143452.dkr.ecr.ap-sutheast-1.amazonaws.com/eks/vpc-resource-controller:0.2.1
ma ten problem.
Dziękuję wszystkim, którzy doczytali do końca, przetestujcie wszystko, co będziecie używać na produkcji przed wdrożeniem.
Źródło: www.habr.com