Kostka po kostce, metaklastry, plastry miodu, dystrybucja zasobów

Ryż. 1. Ekosystem Kubernetes w chmurze Alibaba

Od 2015 roku Alibaba Cloud Container Service for Kubernetes (ACK) jest jedną z najszybciej rozwijających się usług chmurowych w Alibaba Cloud. Obsługuje wielu klientów, a także wspiera wewnętrzną infrastrukturę Alibaba i inne usługi chmurowe firmy.

Podobnie jak w przypadku podobnych usług kontenerowych świadczonych przez światowej klasy dostawców usług w chmurze, naszymi najważniejszymi priorytetami są niezawodność i dostępność. Dlatego też stworzono skalowalną i globalnie dostępną platformę dla kilkudziesięciu tysięcy klastrów Kubernetes.

W tym artykule podzielimy się naszym doświadczeniem w zarządzaniu dużą liczbą klastrów Kubernetes w infrastrukturze chmurowej, a także architekturą platformy bazowej.

Wejście

Kubernetes stał się de facto standardem dla różnorodnych obciążeń w chmurze. Jak pokazano na ryc. 1 powyżej, coraz więcej aplikacji Alibaba Cloud działa obecnie w klastrach Kubernetes: aplikacje stanowe i bezstanowe, a także menedżery aplikacji. Zarządzanie Kubernetesem zawsze było ciekawym i poważnym tematem dyskusji dla inżynierów budujących i utrzymujących infrastrukturę. W przypadku dostawców usług chmurowych takich jak Alibaba Cloud na pierwszy plan wysuwa się kwestia skalowania. Jak zarządzać klastrami Kubernetes w tej skali? Omówiliśmy już najlepsze praktyki zarządzania ogromnymi klastrami Kubernetes zawierającymi 10 000 węzłów. Oczywiście jest to interesujący problem skalowania. Ale jest inna skala: ilość samych klastrów.

Omawialiśmy ten temat z wieloma użytkownikami ACK. Większość z nich decyduje się na uruchamianie dziesiątek, jeśli nie setek małych lub średnich klastrów Kubernetes. Są ku temu dobre powody: ograniczenie potencjalnych szkód, rozdzielenie klastrów dla różnych zespołów, utworzenie wirtualnych klastrów do testów. Jeśli ACK ma służyć globalnej publiczności za pomocą tego modelu użytkowania, musi niezawodnie i efektywnie zarządzać dużą liczbą klastrów w ponad 20 regionach.

Ryż. 2. Problemy zarządzania ogromną liczbą klastrów Kubernetes

Jakie są główne wyzwania związane z zarządzaniem klastrami na taką skalę? Jak pokazano na rysunku, należy rozwiązać cztery kwestie:

• Niejednorodność

ACK powinien obsługiwać różne typy klastrów, w tym standardowe, bezserwerowe, Edge, Windows i kilka innych. Różne klastry wymagają różnych opcji, komponentów i modeli hostingu. Niektórzy klienci potrzebują pomocy w dostosowaniu do swoich konkretnych przypadków.

• Różne rozmiary klastrów

Klastry różnią się wielkością: od kilku węzłów z kilkoma strąkami do dziesiątek tysięcy węzłów z tysiącami strąków. Wymagania dotyczące zasobów również są bardzo zróżnicowane. Niewłaściwa alokacja zasobów może mieć wpływ na wydajność, a nawet spowodować awarię.

• Różne wersje

Kubernetes rozwija się bardzo szybko. Nowe wersje wydawane są co kilka miesięcy. Klienci zawsze chętnie wypróbowują nowe funkcje. Chcą więc umieścić obciążenie testowe na nowych wersjach Kubernetesa, a obciążenie produkcyjne na stabilnych. Aby spełnić ten wymóg, ACK musi stale dostarczać klientom nowe wersje Kubernetes, zachowując jednocześnie wersje stabilne.

• Zgodność z bezpieczeństwem

Klastry są rozproszone w różnych regionach. W związku z tym muszą spełniać różne wymogi bezpieczeństwa i przepisy urzędowe. Na przykład klaster w Europie musi być zgodny z RODO, natomiast chmura finansowa w Chinach musi mieć dodatkowe poziomy ochrony. Wymagania te są obowiązkowe i niedopuszczalne jest ich ignorowanie, gdyż stwarza to ogromne ryzyko dla klientów platformy chmurowej.

Platforma ACK ma na celu rozwiązanie większości powyższych problemów. Obecnie niezawodnie i stabilnie zarządza ponad 10 tysiącami klastrów Kubernetes na całym świecie. Przyjrzyjmy się, jak to osiągnięto, w tym poprzez kilka kluczowych zasad projektowania/architektury.

Konstrukcja

Kostka po kostce i plaster miodu

W przeciwieństwie do scentralizowanej hierarchii architektura oparta na komórkach jest zwykle używana do skalowania platformy poza pojedyncze centrum danych lub do rozszerzania zakresu odzyskiwania po awarii.

Każdy region w chmurze Alibaba składa się z kilku stref (AZ) i zwykle odpowiada konkretnemu centrum danych. W dużym regionie (np. Huangzhou) często działają tysiące klastrów klientów Kubernetes z obsługą ACK.

ACK zarządza tymi klastrami Kubernetes przy użyciu samego Kubernetes, co oznacza, że ​​mamy uruchomiony metaklaster Kubernetes do zarządzania klastrami Kubernetes klientów. Architektura ta nazywana jest także „kube-on-kube” (KoK). Architektura KoK upraszcza zarządzanie klastrami klienckimi, ponieważ wdrażanie klastrów jest proste i deterministyczne. Co ważniejsze, możemy ponownie wykorzystać natywne funkcje Kubernetesa. Na przykład zarządzanie serwerami API poprzez wdrożenie, użycie operatora etcd do zarządzania wieloma plikami etcd. Taka rekurencja zawsze sprawia szczególną przyjemność.

W jednym regionie wdrożono kilka metaklastrów Kubernetes, w zależności od liczby klientów. Nazywamy te komórki metaklastrami. Aby zabezpieczyć się przed awarią całej strefy, ACK obsługuje wdrożenia multiaktywne w jednym regionie: metaklaster rozprowadza główne komponenty klastra klienta Kubernetes w wielu strefach i uruchamia je jednocześnie, czyli w trybie multi-active. Aby zapewnić niezawodność i wydajność mastera, ACK optymalizuje rozmieszczenie komponentów i zapewnia, że ​​serwer API i itp. są blisko siebie.

Model ten pozwala efektywnie, elastycznie i niezawodnie zarządzać Kubernetesem.

Planowanie zasobów metaklastra

Jak już wspomnieliśmy, liczba metaklastrów w każdym regionie zależy od liczby klientów. Ale w którym momencie dodać nowy metaklaster? Jest to typowy problem planowania zasobów. Z reguły zwyczajowo tworzy się nowy, gdy istniejące metaklastry wyczerpały wszystkie swoje zasoby.

Weźmy na przykład zasoby sieciowe. W architekturze KoK komponenty Kubernetes z klastrów klienckich są wdrażane jako pody w metaklastrze. Używamy Terway (Rys. 3) to wysokowydajna wtyczka opracowana przez Alibaba Cloud do zarządzania siecią kontenerów. Zapewnia bogaty zestaw zasad bezpieczeństwa i umożliwia łączenie się z wirtualnymi chmurami prywatnymi klientów (VPC) za pośrednictwem interfejsu Alibaba Cloud Elastic Networking Interface (ENI). Aby efektywnie dystrybuować zasoby sieciowe pomiędzy węzłami, podami i usługami w metaklastrze, musimy uważnie monitorować ich wykorzystanie w obrębie metaklastra wirtualnych chmur prywatnych. Kiedy zasoby sieciowe się wyczerpią, tworzona jest nowa komórka.

Aby określić optymalną liczbę klastrów klienckich w każdym metaklastrze, bierzemy pod uwagę również nasze koszty, wymagania dotyczące gęstości, przydział zasobów, wymagania dotyczące niezawodności i statystyki. Na podstawie wszystkich tych informacji podejmowana jest decyzja o utworzeniu nowego metaklastra. Należy pamiętać, że małe klastry mogą w przyszłości znacznie się rozwinąć, dlatego zużycie zasobów wzrasta, nawet jeśli liczba klastrów pozostaje niezmieniona. Zwykle pozostawiamy wystarczająco dużo wolnego miejsca, aby każdy klaster mógł się rozwijać.

Ryż. 3. Architektura sieci Terway

Skalowanie komponentów kreatora w klastrach klienckich

Komponenty kreatora mają różne potrzeby w zakresie zasobów. Zależą one od liczby węzłów i podów w klastrze, liczby niestandardowych kontrolerów/operatorów współpracujących z APIServerem.

W ACK każdy klaster klienta Kubernetes różni się rozmiarem i wymaganiami dotyczącymi czasu działania. Nie ma uniwersalnej konfiguracji umieszczania komponentów kreatora. Jeśli dla dużego klienta omyłkowo ustalimy niski limit zasobów, to jego klaster nie będzie w stanie udźwignąć obciążenia. Jeśli ustawisz konserwatywnie wysoki limit dla wszystkich klastrów, zasoby zostaną zmarnowane.

Aby znaleźć subtelny kompromis między niezawodnością a kosztami, ACK wykorzystuje system typów. Mianowicie definiujemy trzy typy klastrów: mały, średni i duży. Każdy typ ma oddzielny profil alokacji zasobów. Typ jest określany na podstawie obciążenia komponentów kreatora, liczby węzłów i innych czynników. Typ klastra może zmieniać się z biegiem czasu. ACK stale monitoruje te czynniki i może odpowiednio zwiększać/zmniejszać typ. Po zmianie typu klastra alokacja zasobów jest aktualizowana automatycznie przy minimalnej interwencji użytkownika.

Pracujemy nad ulepszeniem tego systemu poprzez bardziej szczegółowe skalowanie i bardziej precyzyjną aktualizację typów, aby zmiany te przebiegały płynniej i miały większy sens ekonomiczny.

Ryż. 4. Inteligentne przełączanie wielostopniowe

Ewolucja klastrów klienckich na dużą skalę

W poprzednich sekcjach omówiono niektóre aspekty zarządzania dużą liczbą klastrów Kubernetes. Istnieje jednak inny problem, który należy rozwiązać: ewolucja klastrów.

Kubernetes to „Linux” świata chmur. Jest stale aktualizowany i staje się bardziej modułowy. Musimy stale dostarczać naszym klientom nowe wersje, naprawiać luki i aktualizować istniejące klastry, a także zarządzać dużą liczbą powiązanych komponentów (CSI, CNI, Device Plugin, Scheduler Plugin i wiele innych).

Weźmy jako przykład zarządzanie komponentami Kubernetes. Na początek opracowaliśmy scentralizowany system rejestracji i zarządzania wszystkimi połączonymi komponentami.

Ryż. 5. Elastyczne i wtykowe komponenty

Zanim przejdziesz dalej, musisz upewnić się, że aktualizacja przebiegła pomyślnie. W tym celu opracowaliśmy system sprawdzania funkcjonalności podzespołów. Kontrola jest przeprowadzana przed i po aktualizacji.

Ryż. 6. Wstępne sprawdzenie elementów klastra

Aby szybko i niezawodnie aktualizować te komponenty, system ciągłego wdrażania współpracuje z obsługą częściowego rozwoju (skala szarości), pauz i innych funkcji. Standardowe kontrolery Kubernetes nie nadają się dobrze do tego przypadku użycia. Dlatego do zarządzania komponentami klastra opracowaliśmy zestaw specjalizowanych kontrolerów, zawierający wtyczkę oraz pomocniczy moduł sterujący (zarządzanie sidecar).

Na przykład kontroler BroadcastJob jest przeznaczony do aktualizowania komponentów na każdej maszynie roboczej lub sprawdzania węzłów na każdej maszynie. Zadanie rozgłaszania uruchamia moduł w każdym węźle klastra, podobnie jak zestaw daemonset. Jednak DaemonSet zawsze utrzymuje moduł działający przez długi czas, podczas gdy BroadcastJob go zwija. Kontroler rozgłoszeniowy uruchamia również pody na nowo dołączonych węzłach i inicjuje węzły niezbędnymi komponentami. W czerwcu 2019 otworzyliśmy kod źródłowy silnika automatyzacji OpenKruise, z którego sami korzystamy w firmie.

Ryż. 7. OpenKurise organizuje wykonanie zadania Broadcast na wszystkich węzłach

Aby pomóc klientom w wyborze właściwej konfiguracji klastra, udostępniamy również zestaw predefiniowanych profili, w tym profile Serverless, Edge, Windows i Bare Metal. W miarę poszerzania się krajobrazu i rosnących potrzeb naszych klientów, dodamy więcej profili, aby uprościć żmudny proces konfiguracji.

Ryż. 8. Zaawansowane i elastyczne profile klastrów dla różnych scenariuszy

Globalna obserwowalność w centrach danych

Jak pokazano na poniższym rys. 9 września usługa chmurowa Alibaba Cloud Container została wdrożona w dwudziestu regionach na całym świecie. Biorąc pod uwagę tę skalę, jednym z kluczowych celów ACK jest łatwe monitorowanie stanu działających klastrów, aby w przypadku napotkania problemu przez klaster kliencki móc szybko zareagować na sytuację. Inaczej mówiąc, trzeba wymyślić rozwiązanie, które pozwoli sprawnie i bezpiecznie zbierać statystyki w czasie rzeczywistym z klastrów klienckich we wszystkich regionach – i wizualnie prezentować wyniki.

Ryż. 9. Globalne wdrożenie usługi Alibaba Cloud Container w dwudziestu regionach

Podobnie jak wiele systemów monitorowania Kubernetes, naszym głównym narzędziem jest Prometheus. Dla każdego metaklastra agenci Prometheus zbierają następujące metryki:

• Wskaźniki systemu operacyjnego, takie jak zasoby hosta (procesor, pamięć, dysk itp.) i przepustowość sieci.
• Metryki dla systemu zarządzania metaklasterem i klastrem klienta, takie jak kube-apiserver, kube-controller-manager i kube-scheduler.
• Metryki z kubernetes-state-metrics i cadvisor.
• wskaźniki itp., takie jak czas zapisu dysku, rozmiar bazy danych, przepustowość łączy między węzłami itp.

Globalne statystyki są gromadzone przy użyciu typowego wielowarstwowego modelu agregacji. Dane monitorowania z każdego metaklastra są najpierw agregowane w każdym regionie, a następnie wysyłane do centralnego serwera, który przedstawia ogólny obraz. Wszystko działa poprzez mechanizm federacyjny. Serwer Prometheus w każdym centrum danych zbiera metryki z tego centrum danych, a centralny serwer Prometheus jest odpowiedzialny za agregację danych monitorowania. AlertManager łączy się z centralnym Prometheusem i w razie potrzeby wysyła alerty za pośrednictwem DingTalk, e-maila, SMS-a itp. Wizualizacja - za pomocą Grafany.

Na rysunku 10 system monitorowania można podzielić na trzy poziomy:

• Poziom graniczny

Warstwa najdalej od środka. Serwer Prometheus Edge Server działa w każdym metaklastrze, zbierając dane z klastrów meta i klientów w tej samej domenie sieciowej.

• Poziom kaskady

Zadaniem warstwy kaskadowej Prometheus jest zbieranie danych monitoringowych z wielu regionów. Serwery te działają na poziomie większych jednostek geograficznych, takich jak Chiny, Azja, Europa i Ameryka. W miarę rozwoju klastrów region można podzielić, a następnie w każdym nowym dużym regionie pojawi się serwer Prometheus na poziomie kaskadowym. Dzięki tej strategii możesz płynnie skalować w razie potrzeby.

• Poziom centralny

Centralny serwer Prometheus łączy się ze wszystkimi serwerami kaskadowymi i dokonuje ostatecznej agregacji danych. Aby zapewnić niezawodność, uruchomiono dwie centralne instancje Prometheus w różnych strefach, połączone z tymi samymi serwerami kaskadowymi.

Ryż. 10. Globalna wielopoziomowa architektura monitorowania oparta na mechanizmie federacyjnym Prometheus

Streszczenie

Rozwiązania chmurowe oparte na Kubernetes nadal zmieniają naszą branżę. Usługa kontenerowa Alibaba Cloud zapewnia bezpieczny, niezawodny i wydajny hosting - jest to jeden z najlepszych hostingów w chmurze Kubernetes. Zespół Alibaba Cloud mocno wierzy w zasady Open Source i społeczność open source. Na pewno będziemy nadal dzielić się naszą wiedzą z zakresu obsługi i zarządzania technologiami chmurowymi.

Źródło: www.habr.com