W ciągu lat działalności Pinterest 300 milionów użytkowników serwisu stworzyło ponad 200 miliardów pinezek na ponad 4 miliardach tablic. Aby obsłużyć armię użytkowników i rozbudowaną bazę treści, portal opracował tysiące usług, od mikrousług, które mogą obsługiwać kilka procesorów, po ogromne monolity, które działają na całym parku maszyn wirtualnych. I nadszedł moment, w którym firma zwróciła się ku k8s. Co więc „kubik” tak bardzo zainteresował „Pinterest”? O tym dowiesz się z naszego tłumaczenia świeżego artykułu z .
Tak więc setki milionów użytkowników i setki miliardów pinezek. Aby obsłużyć armię użytkowników i rozbudowaną bazę treści, opracowaliśmy tysiące usług, od mikrousług, które mogą obsługiwać kilka procesorów, po ogromne monolity, które działają na całym parku maszyn wirtualnych. Dodatkowo mamy różnorodne frameworki, które również mogą wymagać zasobów CPU, pamięci lub dostępu do operacji we/wy.
W trakcie wsparcia tego zoo narzędzi zespół deweloperów napotyka szereg problemów:
- Inżynierowie nie mają ujednoliconego sposobu uruchamiania środowiska roboczego. Usługi stateless, usługi stateful oraz projekty w fazie aktywnego rozwoju opierają się na zupełnie różnych stosach technologicznych. Doprowadziło to do utworzenia całego kursu szkoleniowego dla inżynierów, a także znacznie utrudnia pracę naszemu zespołowi infrastrukturalnemu.
- Deweloperzy, posiadający własny park maszyn wirtualnych, wywierają ogromną presję na wewnętrznych administratorów. W rezultacie proste operacje, takie jak aktualizacja systemu operacyjnego lub AMI, rozciągają się na tygodnie i miesiące. To prowadzi do zwiększenia obciążeń w, wydawałoby się, całkowicie rutynowych sytuacjach.
- Trudności w tworzeniu globalnych narzędzi do zarządzania infrastrukturą na istniejących już rozwiązaniach. Sytuacja komplikuje się również tym, że znalezienie właścicieli maszyn wirtualnych jest trudne. Innymi słowy, nie wiemy, czy bezpiecznie można wydobyć te zasoby do pracy w innych częściach naszej infrastruktury.
Systemy orkiestracji kontenerów to sposób na ujednolicenie zarządzania obciążeniem. Otwierają przed Tobą drogę do zwiększenia szybkości rozwoju i upraszczają zarządzanie infrastrukturą, ponieważ wszystkie zasoby zaangażowane w projekt są zarządzane przez jeden scentralizowany system.
Rysunek 1: Priorytety infrastruktury (niezawodność, wydajność programistów i efektywność).
Zespół Cloud Management Platform w Pinterest zapoznał się z K8s w 2017 roku. W pierwszej połowie 2017 roku udokumentowaliśmy dużą część naszych zdolności produkcyjnych, w tym API i wszystkie nasze serwery internetowe. Następnie przeprowadziliśmy dokładną ocenę różnych systemów orkiestracji rozwiązań kontenerowych, budowy klastrów i ich obsługi. Pod koniec 2017 roku postanowiliśmy skorzystać z Kubernetes. Był wystarczająco elastyczny i miał szerokie wsparcie w społeczności deweloperów.
Do obecnego momentu stworzyliśmy własne narzędzia do wstępnego uruchamiania klastra oparte na Kops i przenieśliśmy istniejące komponenty infrastruktury na Kubernetes — takie jak sieć, bezpieczeństwo, metryki, logowanie, zarządzanie tożsamością i ruch. Zrealizowaliśmy również system modelowania obciążenia dla naszego zasobu, którego złożoność jest ukryta przed programistami. Teraz koncentrujemy się na zapewnieniu stabilności klastra, jego skalowaniu i podłączaniu nowych klientów.
Kubernetes: droga Pinterest
Rozpoczęcie pracy z Kubernetes w skali Pinterest jako platformy, która zdobędzie uznanie naszych inżynierów, wiązało się z wieloma trudnościami.
Jako duża firma zainwestowaliśmy znaczne środki w narzędzia infrastrukturalne. Przykładem mogą być narzędzia bezpieczeństwa, które obsługują certyfikaty i rozdzielają klucze, komponenty kontroli ruchu, systemy wykrywania usług, komponenty widoczności i przesyłania logów oraz metryk. Wszystko to zostało zebrane nie bez powodu: przeszliśmy normalną drogę prób i błędów, dlatego chcieliśmy zintegrować to wszystko w nową infrastrukturę na Kubernetes zamiast na nowo wymyślać stary rower na nowej platformie. Takie podejście znacznie uprościło migrację, ponieważ całe wsparcie aplikacji już istnieje, nie trzeba go tworzyć od podstaw.
Z drugiej strony, modeli prognozowania obciążenia w samym Kubernetes (na przykład wdrożeń, zadań i zestawów Daemon) jest niewystarczająco dla naszego projektu. Problemy z użytecznością stanowią ogromne przeszkody na drodze do przejścia na Kubernetes. Na przykład słyszeliśmy, jak deweloperzy usług narzekają na brak lub niepoprawne skonfigurowanie dostępu. Również spotykaliśmy się z niewłaściwym wykorzystaniem szablonów, co prowadziło do tworzenia setek kopii z identycznymi specyfikacjami i zadaniami, co skutkowało koszmarnymi problemami z debugowaniem.
Bardzo trudno było również utrzymać różne wersje w tym samym klastrze. Wyobraź sobie trudności w wsparciu klienta, gdy musisz działać w wielu wersjach tej samej platformy, z wszystkimi ich problemami, błędami i aktualizacjami.
Zasoby użytkowników i kontrolery Pinterest
Aby ułatwić naszym inżynierom proces wdrażania Kubernetes oraz uprościć infrastrukturę i przyspieszyć jej działanie, opracowaliśmy nasze własne definicje zasobów użytkowników (CRD).
CRD zapewniają następujące możliwości:
- Zintegrowanie różnych natywnych zasobów Kubernetes, aby działały jako jednolite obciążenie. Na przykład zasób PinterestService obejmuje wdrożenie, usługę dostępu i mapę konfiguracji. To pozwala deweloperom nie martwić się o konfigurację DNS.
- Wdrożenie niezbędnego wsparcia aplikacji. Użytkownik powinien skupić się tylko na specyfikacji kontenera zgodnie z własną logiką biznesową, podczas gdy kontroler CRD wdraża wszystkie niezbędne init-kontenery, zmienne środowiskowe i specyfikacje pod. Zapewnia to zasadniczo inny poziom komfortu dla deweloperów.
- Kontrolery CRD zarządzają również cyklem życia własnych zasobów i zwiększają dostępność debugowania. Obejmuje to zgodność pożądanych i rzeczywistych specyfikacji, aktualizację stanu CRD oraz prowadzenie dzienników zdarzeń i nie tylko. Bez CRD deweloperzy byliby zmuszeni do zarządzania licznymi zestawami zasobów, co tylko zwiększałoby prawdopodobieństwo błędów.
Oto przykład PinterestService i wewnętrznego zasobu, którym zarządza nasz kontroler:
Jak pokazano powyżej, aby obsłużyć użytkownika kontener, musimy zintegrować z nim kontener inicjalizacji oraz kilka dodatków, aby zapewnić bezpieczeństwo, widoczność i obsługę ruchu sieciowego. Dodatkowo stworzyliśmy szablony map konfiguracji i wdrożyliśmy wsparcie dla szablonów PVC w zadaniach wsadowych oraz śledzenie wielu zmiennych środowiskowych w celu monitorowania identyfikacji, zużycia zasobów i zbierania «śmieci».
Trudno wyobrazić sobie, że deweloperzy chcieliby napisać te pliki konfiguracyjne ręcznie bez wsparcia CRD, nie mówiąc już o dalszym wsparciu i debugowaniu konfiguracji.
Workflow wdrożenia aplikacji
Na powyższym rysunku pokazano, jak wdrożyć zasób użytkownika Pinterest w klastrze Kubernetes:
- Deweloperzy wchodzą w interakcję z naszym klastrem Kubernetes za pośrednictwem CLI i interfejsu użytkownika.
- Narzędzia CLI / UI pobierają pliki konfiguracyjne YAML pracy i inne właściwości buildu (ten sam identyfikator wersji) z Artifactory, a następnie przesyłają je do Usługi Zgłaszania Zadań. Ten krok zapewnia, że do klastra zostaną dostarczone tylko wersje produkcyjne.
- JSS jest bramą do różnych platform, w tym Kubernetes. Odbywa się tutaj uwierzytelnianie użytkownika, przydzielanie kwot i częściowa weryfikacja konfiguracji naszego CRD.
- Po weryfikacji CRD po stronie JSS informacje są przesyłane do API platformy k8s.
- Nasz kontroler CRD śledzi zdarzenia na wszystkich zasobach użytkownika. Przekształca CR w natywne zasoby k8s, dodaje niezbędne moduły, ustawia odpowiednie zmienne środowiskowe i wykonuje inne zadania pomocnicze, co zapewnia aplikacjom użytkownika odpowiednie wsparcie infrastrukturalne.
- Następnie kontroler CRD przesyła zebrane dane do API Kubernetes, aby mogły być przetwarzane przez scheduler i uruchomione.
Uwaga: to jest wczesna wersja procesu wdrożenia, która została stworzona dla pierwszych użytkowników nowej platformy k8s. Obecnie pracujemy nad udoskonaleniem tego procesu, aby w pełni zintegrować się z naszym nowym CI/CD. Oznacza to, że nie możemy opowiedzieć o wszystkim związanym z Kubernetes. Z niecierpliwością czekamy na możliwość podzielenia się naszym doświadczeniem i raportowania o postępach zespołu w tym kierunku w naszym następnym wpisie na blogu „Budowanie platformy CI/CD dla Pinterest”.
Rodzaje zasobów specjalnych
Na podstawie konkretnych potrzeb Pinterest opracowaliśmy następujące CRD, które odpowiadają różnym procesom roboczym:
- PinterestService — to od dawna funkcjonujące usługi stateless. Wiele naszych kluczowych systemów opartych jest na zestawie takich usług.
- PinterestJobSet modeluje paczki zadań całego cyklu. W Pinterest występuje powszechny scenariusz, w którym kilka zadań uruchamia te same kontenery równolegle, niezależnie od innych podobnych procesów.
- PinterestCronJob jest szeroko stosowany w połączeniu z małymi, regularnymi obciążeniami. To powłoka dla natywnej obsługi cron z mechanizmami wsparcia Pinterest, które odpowiadają za bezpieczeństwo, ruch, logi i metryki.
- PinterestDaemon obejmuje daemony infrastruktury. Ta rodzina nadal rośnie, gdyż dodajemy coraz więcej wsparcia dla naszych klastrów.
- PinterestTrainingJob obejmuje procesy Tensorflow i Pytorch, zapewniając ten sam poziom wsparcia podczas działania, co wszystkie inne CRD. Ponieważ w Pinterest aktywnie wykorzystuje się Tensorflow i inne systemy uczenia maszynowego, mieliśmy powód, aby zbudować osobną CRD wokół tych technologii.
Również pracujemy nad PinterestStatefulSet, który wkrótce będzie zaadaptowany dla magazynów danych i innych systemów stateful.
Wsparcie środowiska wykonawczego
Gdy moduł aplikacji uruchamia się w Kubernetes, automatycznie otrzymuje certyfikat do własnej identyfikacji. Certyfikat ten służy do dostępu do tajnego magazynu lub do komunikacji z innymi usługami przez mTLS. W międzyczasie, konfigurator inicjalizacji kontenerów i Daemon załadują wszystkie niezbędne zależności przed uruchomieniem aplikacji kontenerowej. Gdy wszystko będzie gotowe, sidecar ruchu i Daemon zarejestrują adres IP modułu w naszym Zookeeper, aby klienci mogli go odnaleźć. Całość będzie działała, ponieważ moduł sieciowy został skonfigurowany jeszcze przed uruchomieniem aplikacji.
Powyżej przedstawiono typowe przykłady wsparcia obciążeń w czasie wykonywania. Dla innych typów obciążeń może być wymagane nieco inne wsparcie, ale wszystkie są reprezentowane w postaci sidecar na poziomie pod, wirtualnych maszyn na poziomie węzła lub Daemon-ów. Dbamy o to, aby wszystko było wdrożone w ramach infrastruktury zarządzającej i skoordynowane między aplikacjami, co ostatecznie znacznie redukuje obciążenie w zakresie prac technicznych i wsparcia klientów.
Testowanie i QA
Zbudowaliśmy end-to-end pipeline testowy na istniejącej infrastrukturze testowej Kubernetes. Te testy obejmują wszystkie nasze klastry. Nasz pipeline przeszedł wiele przeróbek, zanim stał się częścią klastra produktowego.
Oprócz systemów testowych mamy systemy monitorowania i powiadamiania, które cały czas śledzą stan komponentów systemu, zużycie zasobów i inne ważne wskaźniki, powiadamiając nas tylko w razie potrzeby interwencji ludzkiej.
Alternatywy
Rozważaliśmy pewne alternatywy dla niestandardowych zasobów, takie jak kontrolery mutacji dostępu i systemy szablonów. Jednak wszystkie one wiązały się z poważnymi trudnościami w działaniu, dlatego wybraliśmy drogę CRD.
Kontroler mutacji dostępu był stosowany do wprowadzania sidecarów, zmiennych środowiskowych i innego wsparcia podczas wykonywania. Niemniej jednak, napotykał różnorodne problemy, takie jak związanie zasobów i zarządzanie ich cyklem życia, podczas gdy w CRD takich problemów nie występuje.
Uwaga: Systemy szablonów, takie jak diagramy Helm, są szeroko stosowane do uruchamiania aplikacji o podobnych konfiguracjach. Jednak nasze aplikacje robocze są zbyt różnorodne, aby zarządzać nimi za pomocą szablonów. Ponadto podczas ciągłego wdrażania z użyciem szablonów występuje zbyt wiele błędów.
Nadchodząca praca
Obecnie mamy do czynienia z mieszanym obciążeniem w naszych klastrach. Aby wspierać podobne procesy różnego typu i rozmiaru, pracujemy w następujących obszarach:
- Zbiór klastrów rozdziela duże aplikacje pomiędzy różne klastry w celu zapewnienia skalowalności i stabilności.
- Zapewnienie stabilności, skalowalności oraz widoczności klastra w celu stworzenia połączenia między aplikacją a jej SLA.
- Zarządzanie zasobami i limitami, aby aplikacje nie kolidowały ze sobą, a skala klastra była kontrolowana z naszej strony.
- Nowa platforma CI/CD do wsparcia i wdrażania aplikacji w Kubernetes.
Źródło: habr.com
