Na przestrzeni lat 300 milionów użytkowników Pinteresta utworzyło ponad 200 miliardów pinów na ponad 4 miliardach tablic. Aby obsłużyć tę armię użytkowników i ogromną bazę treści, portal opracował tysiące usług, począwszy od mikrousług obsługiwanych przez kilka procesorów, po gigantyczne monolity działające na całej flocie maszyn wirtualnych. I wtedy nadszedł moment, gdy wzrok firmy padł na k8s. Dlaczego „kostka” dobrze wyglądała na Pintereście? Dowiesz się o tym z naszego tłumaczenia najnowszego artykułu z .
A więc setki milionów użytkowników i setki miliardów pinów. Aby obsłużyć tę armię użytkowników i ogromną bazę treści, opracowaliśmy tysiące usług, począwszy od mikrousług obsługiwanych przez kilka procesorów, po gigantyczne monolity działające na całych flotach maszyn wirtualnych. Ponadto mamy wiele frameworków, które mogą również wymagać dostępu do procesora, pamięci lub wejść/wyjść.
Utrzymując to zoo narzędzi, zespół programistów stoi przed wieloma wyzwaniami:
- Nie ma jednolitego sposobu, w jaki inżynierowie mogliby zarządzać środowiskiem produkcyjnym. Usługi bezstanowe, usługi stanowe i projekty będące w fazie aktywnego rozwoju opierają się na zupełnie innych stosach technologicznych. Doprowadziło to do powstania całego szkolenia dla inżynierów, a także poważnie komplikuje pracę naszego zespołu ds. infrastruktury.
- Deweloperzy posiadający własną flotę maszyn wirtualnych stanowią ogromne obciążenie dla wewnętrznych administratorów. W efekcie takie proste operacje jak aktualizacja systemu operacyjnego czy AMI zajmują tygodnie i miesiące. Prowadzi to do zwiększonego obciążenia pracą w pozornie absolutnie codziennych sytuacjach.
- Trudności w tworzeniu globalnych narzędzi do zarządzania infrastrukturą na bazie istniejących rozwiązań. Sytuację dodatkowo komplikuje fakt, że znalezienie właścicieli maszyn wirtualnych nie jest łatwe. Oznacza to, że nie wiemy, czy tę moc można bezpiecznie wydobyć do pracy w innych częściach naszej infrastruktury.
Systemy orkiestracji kontenerów to sposób na ujednolicenie zarządzania obciążeniem. Otwierają drzwi do zwiększenia szybkości rozwoju i upraszczają zarządzanie infrastrukturą, ponieważ wszystkimi zasobami zaangażowanymi w projekt zarządza się przez jeden scentralizowany system.
Rysunek 1: Priorytety infrastruktury (niezawodność, produktywność programistów i wydajność).
Zespół Cloud Management Platform na Pintereście odkrył K8 w 2017 roku. Do pierwszej połowy 2017 roku udokumentowaliśmy większość naszych możliwoś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, budowania klastrów i pracy z nimi. Pod koniec 2017 roku zdecydowaliśmy się na Kubernetes. Był dość elastyczny i szeroko wspierany w społeczności programistów.
Do tej pory zbudowaliśmy własne narzędzia do uruchamiania klastrów w oparciu o Kops i migrowaliśmy istniejące komponenty infrastruktury, takie jak sieć, bezpieczeństwo, metryki, rejestrowanie, zarządzanie tożsamością i ruch do Kubernetes. Wdrożyliśmy także 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 przyłączaniu nowych klientów.
Kubernetes: sposób na Pinterest
Rozpoczęcie pracy z Kubernetesem w skali Pinteresta jako platformą, którą pokochali nasi inżynierowie, wiązało się z wieloma wyzwaniami.
Jako duża firma dużo zainwestowaliśmy w narzędzia infrastrukturalne. Przykłady obejmują narzędzia bezpieczeństwa obsługujące przetwarzanie certyfikatów i dystrybucję kluczy, komponenty kontroli ruchu, systemy wykrywania usług, komponenty widoczności oraz komponenty wysyłania dzienników i metryk. Wszystko to zostało zebrane nie bez powodu: przeszliśmy normalną ścieżkę prób i błędów, dlatego chcieliśmy zintegrować cały ten sprzęt z nową infrastrukturą na Kubernetesie, zamiast wymyślać stare koło na nowej platformie. To podejście ogólnie uprościło migrację, ponieważ cała obsługa aplikacji już istnieje i nie trzeba tworzyć jej od zera.
Z drugiej strony modele prognozowania obciążenia w samym Kubernetesie (takie jak wdrożenia, zadania i zestawy Daemon) nie są wystarczające dla naszego projektu. Te problemy z użytecznością stanowią ogromne bariery w przejściu na Kubernetes. Na przykład słyszeliśmy, że twórcy usług narzekają na brakujące lub nieprawidłowe ustawienia logowania. Natknęliśmy się również na nieprawidłowe użycie silników szablonów, gdy utworzono setki kopii o tej samej specyfikacji i zadaniu, co skutkowało koszmarnymi problemami z debugowaniem.
Bardzo trudno było także utrzymać różne wersje w tym samym klastrze. Wyobraź sobie złożoność obsługi klienta, jeśli musisz pracować jednocześnie w wielu wersjach tego samego środowiska wykonawczego, ze wszystkimi związanymi z nimi problemami, błędami i aktualizacjami.
Właściwości i kontrolery użytkownika Pinteresta
Aby ułatwić naszym inżynierom wdrożenie Kubernetesa oraz uprościć i przyspieszyć naszą infrastrukturę, opracowaliśmy własne, niestandardowe definicje zasobów (CRD).
CRD zapewniają następującą funkcjonalność:
- Łączenie różnych natywnych zasobów Kubernetes, tak aby działały jako jedno obciążenie. Na przykład zasób PinterestService obejmuje wdrożenie, usługę logowania i mapę konfiguracji. Dzięki temu programiści nie muszą się martwić konfiguracją DNS.
- Zaimplementuj niezbędną obsługę aplikacji. Użytkownik musi skupić się wyłącznie na specyfikacji kontenera zgodnie ze swoją logiką biznesową, podczas gdy kontroler CRD implementuje wszystkie niezbędne kontenery inicjujące, zmienne środowiskowe i specyfikacje podów. Zapewnia to zasadniczo inny poziom komfortu dla programistów.
- Kontrolery CRD zarządzają także cyklem życia zasobów natywnych i poprawiają dostępność debugowania. Obejmuje to uzgadnianie pożądanych i rzeczywistych specyfikacji, aktualizację statusu CRD i prowadzenie dzienników zdarzeń i nie tylko. Bez CRD programiści byliby zmuszeni zarządzać wieloma zasobami, co tylko zwiększałoby prawdopodobieństwo błędu.
Oto przykład usługi PinterestService i zasobu wewnętrznego zarządzanego przez naszego kontrolera:
Jak widać powyżej, aby obsługiwać niestandardowy kontener, musimy zintegrować kontener init i kilka dodatków, aby zapewnić bezpieczeństwo, widoczność i ruch sieciowy. Ponadto stworzyliśmy szablony map konfiguracji i wdrożyliśmy obsługę szablonów PVC dla zadań wsadowych, a także śledzenie wielu zmiennych środowiskowych w celu śledzenia tożsamości, zużycia zasobów i usuwania śmieci.
Trudno sobie wyobrazić, że programiści chcieliby pisać te pliki konfiguracyjne ręcznie bez obsługi CRD, nie mówiąc już o dalszym utrzymywaniu i debugowaniu konfiguracji.
Przepływ pracy przy wdrażaniu aplikacji
Powyższy obraz pokazuje, jak wdrożyć niestandardowy zasób Pinteresta w klastrze Kubernetes:
- Programiści wchodzą w interakcję z naszym klastrem Kubernetes za pośrednictwem interfejsu CLI i interfejsu użytkownika.
- Narzędzia CLI/UI pobierają pliki YAML konfiguracji przepływu pracy i inne właściwości kompilacji (ten sam identyfikator wersji) z Artifactory, a następnie przesyłają je do usługi przesyłania zadań. Ten krok gwarantuje, że do klastra zostaną dostarczone tylko wersje produkcyjne.
- JSS to brama dla różnych platform, w tym Kubernetes. Tutaj użytkownik jest uwierzytelniany, wydawane są przydziały i częściowo sprawdzana jest konfiguracja naszego CRD.
- Po sprawdzeniu CRD po stronie JSS informacja przesyłana jest do API platformy k8s.
- Nasz kontroler CRD monitoruje zdarzenia na wszystkich zasobach użytkownika. Konwertuje CR na natywne zasoby K8, dodaje niezbędne moduły, ustawia odpowiednie zmienne środowiskowe i wykonuje inne prace pomocnicze, aby zapewnić, że skonteneryzowane aplikacje użytkownika mają wystarczające wsparcie infrastrukturalne.
- Kontroler CRD przekazuje następnie odebrane dane do API Kubernetes, aby mogły zostać przetworzone przez planistę i wprowadzone do produkcji.
Operacja: Ten przepływ prac wdrożeniowy przed wydaniem został stworzony dla pierwszych użytkowników nowej platformy k8s. Obecnie jesteśmy w trakcie udoskonalania tego procesu, aby w pełni zintegrować go z naszym nowym CI/CD. Oznacza to, że nie jesteśmy w stanie powiedzieć Ci wszystkiego, co dotyczy Kubernetesa. Z niecierpliwością czekamy na podzielenie się naszym doświadczeniem i postępami zespołu w tym kierunku w naszym kolejnym poście na blogu „Budowanie platformy CI/CD dla Pinteresta”.
Rodzaje zasobów specjalnych
W oparciu o specyficzne potrzeby Pinteresta opracowaliśmy następujące CRD, aby dopasować je do różnych przepływów pracy:
- PinterestService to usługi bezstanowe, które działają od dłuższego czasu. Wiele z naszych podstawowych systemów opiera się na zestawie takich usług.
- PinterestJobSet modeluje zadania wsadowe w pełnym cyklu. Typowym scenariuszem na Pintereście jest to, że wiele zadań uruchamia równolegle te same kontenery, niezależnie od innych podobnych procesów.
- PinterestCronJob jest szeroko stosowany w połączeniu z małymi okresowymi obciążeniami. Jest to opakowanie natywnej pracy crona z mechanizmami wsparcia Pinteresta odpowiedzialnymi za bezpieczeństwo, ruch, logi i metryki.
- PinterestDaemon zawiera demony infrastruktury. Rodzina ta stale się powiększa w miarę zwiększania wsparcia dla naszych klastrów.
- PinterestTrainingJob obejmuje procesy Tensorflow i Pytorch, zapewniając ten sam poziom wsparcia w czasie wykonywania, co wszystkie inne CRD. Ponieważ Pinterest aktywnie korzysta z Tensorflow i innych systemów uczenia maszynowego, mieliśmy powód, aby zbudować wokół nich oddzielny CRD.
Pracujemy także nad PinterestStatefulSet, który wkrótce zostanie dostosowany pod hurtownie danych i inne systemy stanowe.
Wsparcie w czasie wykonywania
Gdy moduł aplikacji działa na platformie Kubernetes, automatycznie otrzymuje certyfikat umożliwiający jego identyfikację. Ten certyfikat służy do uzyskiwania dostępu do tajnego magazynu lub do komunikacji z innymi usługami za pośrednictwem mTLS. W międzyczasie Konfigurator Container Init i Daemon pobiorą wszystkie niezbędne zależności przed uruchomieniem aplikacji kontenerowej. Kiedy wszystko będzie gotowe, Traffic Sidecar i Daemon zarejestrują adres IP modułu w naszym Zookeeperze, aby klienci mogli go odkryć. Wszystko to będzie działać, ponieważ moduł sieciowy został skonfigurowany przed uruchomieniem aplikacji.
Powyższe są typowymi przykładami obsługi obciążeń w środowisku wykonawczym. Inne typy obciążeń mogą wymagać nieco innej obsługi, ale wszystkie mają postać wózków bocznych na poziomie podów, demonów na poziomie węzła lub na poziomie maszyny wirtualnej. Dbamy o to, aby wszystko to zostało wdrożone w infrastrukturze zarządzania i było spójne we wszystkich aplikacjach, co ostatecznie znacznie zmniejsza obciążenie w zakresie prac technicznych i obsługi klienta.
Testowanie i kontrola jakości
Zbudowaliśmy kompleksowy potok testowy w oparciu o istniejącą infrastrukturę testową Kubernetes. Testy te dotyczą wszystkich naszych klastrów. Nasz rurociąg przeszedł wiele zmian, zanim stał się częścią klastra produktów.
Oprócz systemów testowych posiadamy systemy monitorujące i alarmujące, które stale monitorują stan komponentów systemu, zużycie zasobów i inne ważne wskaźniki, powiadamiając nas tylko wtedy, gdy konieczna jest interwencja człowieka.
Alternatywy
Przyjrzeliśmy się alternatywnym alternatywom dla zasobów niestandardowych, takim jak kontrolery dostępu mutacyjnego i systemy szablonów. Jednak wszystkie one wiążą się ze znacznymi wyzwaniami operacyjnymi, dlatego wybraliśmy trasę CRD.
Do wprowadzenia przyczepek bocznych, zmiennych środowiskowych i innej obsługi środowiska wykonawczego wykorzystano kontroler przyjmowania mutacji. Napotkał jednak różne problemy, takie jak wiązanie zasobów i zarządzanie cyklem życia, gdzie takie problemy nie występują w CRD.
Uwaga: Systemy szablonów, takie jak wykresy Helma, są również szeroko stosowane do uruchamiania aplikacji o podobnych konfiguracjach. Jednak nasze aplikacje do pracy są zbyt różnorodne, aby zarządzać nimi za pomocą szablonów. Również podczas ciągłego wdrażania będzie zbyt wiele błędów podczas korzystania z szablonów.
Nadchodzące prace
Obecnie mamy do czynienia z mieszanym obciążeniem we wszystkich naszych klastrach. Aby wesprzeć tego typu procesy różnego typu i wielkości, pracujemy w następujących obszarach:
- Zbiór klastrów umożliwia dystrybucję dużych aplikacji w różnych klastrach w celu zapewnienia skalowalności i stabilności.
- Zapewnienie stabilności klastra, skalowalności i widoczności w celu tworzenia łączności aplikacji i umów SLA.
- Zarządzanie zasobami i limitami tak, aby aplikacje nie kolidowały ze sobą, a skala klastra była kontrolowana z naszej strony.
- Nowa platforma CI/CD do obsługi i wdrażania aplikacji na Kubernetesie.
Źródło: www.habr.com