Notatka. przeł.: Dailymotion to jedna z największych na świecie usług hostingu wideo i dlatego jest znaczącym użytkownikiem Kubernetes. W tym materiale architekt systemu David Donchez dzieli się wynikami tworzenia firmowej platformy produkcyjnej opartej na K8s, która rozpoczęła się od instalacji chmurowej w GKE, a zakończyła jako rozwiązanie hybrydowe, co pozwoliło uzyskać lepszy czas reakcji i oszczędności na kosztach infrastruktury.
Podjęcie decyzji o przebudowie podstawowego interfejsu API trzy lata temu chcieliśmy opracować bardziej efektywny sposób hostowania aplikacji i ułatwić to . W tym celu zdecydowaliśmy się wykorzystać platformę do orkiestracji kontenerów i naturalnie wybraliśmy Kubernetes.
Dlaczego warto zbudować własną platformę w oparciu o Kubernetes?
Błyskawiczne API na poziomie produkcyjnym przy użyciu Google Cloud
Lato 2016
Trzy lata temu, zaraz po zakupie Dailymotion przez , nasze zespoły inżynieryjne skupiają się na jednym globalnym celu: stworzeniu zupełnie nowego produktu Dailymotion.
Bazując na naszej analizie kontenerów, rozwiązań orkiestracyjnych i naszych dotychczasowych doświadczeniach, jesteśmy przekonani, że Kubernetes to właściwy wybór. Część programistów znała już podstawowe pojęcia i wiedziała, jak je wykorzystać, co było ogromną zaletą przy transformacji infrastruktury.
Z punktu widzenia infrastruktury potrzebny był wydajny i elastyczny system do hostowania nowych typów aplikacji natywnych w chmurze. Na początku naszej podróży zdecydowaliśmy się pozostać w chmurze, aby móc w spokoju zbudować możliwie najsolidniejszą platformę lokalną. Zdecydowaliśmy się na wdrażanie naszych aplikacji przy użyciu Google Kubernetes Engine, choć wiedzieliśmy, że prędzej czy później przeniesiemy się do własnych centrów danych i zastosujemy strategię hybrydową.
Dlaczego wybrałeś GKE?
Zdecydowaliśmy się na ten wybór głównie ze względów technicznych. Ponadto konieczne było szybkie udostępnienie infrastruktury odpowiadającej potrzebom biznesowym firmy. Mieliśmy pewne wymagania dotyczące aplikacji hostingowych, takie jak dystrybucja geograficzna, skalowalność i odporność na awarie.
Klastry GKE w Dailymotion
Ponieważ Dailymotion jest platformą wideo dostępną na całym świecie, bardzo chcieliśmy poprawić jakość usług poprzez skrócenie czasu oczekiwania (czas oczekiwania). Poprzednio był dostępny tylko w Paryżu, co nie było optymalne. Chciałem móc hostować aplikacje nie tylko w Europie, ale także w Azji i USA.
Ta wrażliwość na opóźnienia oznaczała, że trzeba będzie wykonać poważną pracę nad architekturą sieciową platformy. Podczas gdy większość usług w chmurze wymagała utworzenia własnej sieci w każdym regionie, a następnie połączenia ich przez VPN lub inną usługę zarządzaną, Google Cloud umożliwiło utworzenie pojedynczej sieci z pełnym routingiem, obejmującej wszystkie regiony Google. Jest to duży plus pod względem działania i wydajności systemu.
Poza tym usługi sieciowe i moduły równoważenia obciążenia z Google Cloud spisują się znakomicie. Pozwalają po prostu na wykorzystanie dowolnych publicznych adresów IP z każdego regionu, a resztę (czyli przekierowanie użytkowników do najbliższego klastra) zajmuje wspaniały protokół BGP. Oczywiście w przypadku awarii ruch zostanie automatycznie przekierowany do innego regionu bez jakiejkolwiek interwencji człowieka.
Monitorowanie równoważenia obciążenia Google
Nasza platforma również w dużym stopniu wykorzystuje procesory graficzne. Google Cloud pozwala na bardzo efektywne wykorzystanie ich bezpośrednio w klastrach Kubernetes.
W tamtym czasie zespół ds. infrastruktury skupiał się głównie na starszym stosie wdrożonym na serwerach fizycznych. Dlatego skorzystanie z usługi zarządzanej (w tym masterów Kubernetes) spełniło nasze wymagania i pozwoliło przeszkolić zespoły do pracy z lokalnymi klastrami.
Dzięki temu już po 6 miesiącach od rozpoczęcia prac mogliśmy rozpocząć odbiór ruchu produkcyjnego na infrastrukturze Google Cloud.
Jednak mimo szeregu zalet współpraca z dostawcą chmury wiąże się z pewnymi kosztami, które mogą wzrosnąć w zależności od obciążenia. Dlatego dokładnie analizowaliśmy każdą usługę zarządzaną, z której korzystaliśmy, mając nadzieję na wdrożenie jej w przyszłości lokalnie. Tak naprawdę wdrażanie klastrów lokalnych rozpoczęło się pod koniec 2016 roku i jednocześnie zainicjowano strategię hybrydową.
Uruchomienie lokalnej platformy do orkiestracji kontenerów Dailymotion
Jesień '2016
W warunkach kiedy cały stos był gotowy do produkcji i prac nad API przyszedł czas na skupienie się na klastrach regionalnych.
W tym czasie użytkownicy oglądali ponad 3 miliardy filmów miesięcznie. Oczywiście od wielu lat posiadamy własną, rozbudowaną sieć dostarczania treści. Chcieliśmy wykorzystać tę okoliczność i wdrożyć klastry Kubernetes w istniejących centrach danych.
Infrastruktura Dailymotion składała się z ponad 2,5 tys. serwerów w sześciu centrach danych. Wszystkie są konfigurowane za pomocą Saltstack. Zaczęliśmy przygotowywać wszystkie niezbędne receptury do tworzenia węzłów głównych i roboczych, a także klastra itp.
Część sieciowa
Nasza sieć jest całkowicie trasowana. Każdy serwer ogłasza swój adres IP w sieci za pomocą Exabgp. Porównaliśmy kilka wtyczek sieciowych i jedyną, która spełniła wszystkie potrzeby (ze względu na zastosowane podejście L3), była . Doskonale wpasowuje się w istniejący model infrastruktury sieciowej.
Ponieważ chcieliśmy wykorzystać wszystkie dostępne elementy infrastruktury, pierwszą rzeczą, którą musieliśmy zrobić, było wymyślenie naszego autorskiego narzędzia sieciowego (używanego na wszystkich serwerach): użyj go do reklamowania zakresów adresów IP w sieci z węzłami Kubernetes. Pozwoliliśmy Calico na przypisywanie adresów IP do podów, ale nie używaliśmy ich i nadal nie używamy do sesji BGP na sprzęcie sieciowym. W rzeczywistości routingiem zajmuje się Exabgp, który reklamuje podsieci używane przez Calico. Dzięki temu możemy dotrzeć do dowolnego poda z sieci wewnętrznej (a w szczególności z systemów równoważenia obciążenia).
Jak zarządzamy ruchem przychodzącym
Do przekierowania przychodzących żądań do wybranej usługi zdecydowano się na wykorzystanie Ingress Controllera ze względu na jego integrację z zasobami ingresowymi Kubernetes.
Trzy lata temu najbardziej dojrzałym kontrolerem był nginx-ingress-controller: Nginx istniał już od dawna i był znany ze swojej stabilności i wydajności.
W naszym systemie zdecydowaliśmy się umieścić kontrolery na dedykowanych serwerach typu blade 10-Gigabit. Każdy kontroler był podłączony do punktu końcowego kube-apiserver odpowiedniego klastra. Serwery te wykorzystywały również Exabgp do reklamowania publicznych lub prywatnych adresów IP. Nasza topologia sieci pozwala nam używać BGP z tych kontrolerów do kierowania całego ruchu bezpośrednio do podów bez korzystania z usługi takiej jak NodePort. Takie podejście pomaga uniknąć ruchu poziomego między węzłami i poprawia wydajność.
Ruch ruchu z Internetu do podów
Teraz, gdy rozumiemy naszą platformę hybrydową, możemy zagłębić się w sam proces migracji ruchu.
Migracja ruchu z infrastruktury Google Cloud do infrastruktury Dailymotion
Jesień '2018
Po prawie dwóch latach budowania, testowania i dostrajania w końcu mamy pełny stos Kubernetes gotowy na przyjęcie części ruchu.
Obecna strategia routingu jest dość prosta, ale wystarczająca do zaspokojenia potrzeb. Oprócz publicznych adresów IP (w Google Cloud i Dailymotion), AWS Route 53 służy do ustalania polityk i przekierowywania użytkowników do wybranego przez nas klastra.
Przykładowa polityka routingu przy użyciu Route 53
Dzięki Google Cloud jest to proste, ponieważ współdzielimy jeden adres IP we wszystkich klastrach, a użytkownik zostaje przekierowany do najbliższego klastra GKE. W przypadku naszych klastrów technologia jest inna, ponieważ ich adresy IP są różne.
Podczas migracji staraliśmy się przekierować zapytania regionalne do odpowiednich klastrów i oceniliśmy korzyści płynące z takiego podejścia.
Ponieważ nasze klastry GKE są skonfigurowane do automatycznego skalowania przy użyciu wskaźników niestandardowych, skalują się w górę/w dół na podstawie ruchu przychodzącego.
W trybie normalnym cały ruch regionalny kierowany jest do klastra lokalnego, a GKE pełni rolę rezerwy na wypadek problemów (kontrole stanu przeprowadza Route 53).
...
W przyszłości chcemy w pełni zautomatyzować zasady routingu, aby osiągnąć autonomiczną strategię hybrydową, która stale poprawia dostępność dla użytkowników. Plusem jest to, że koszty chmury zostały znacznie obniżone, a czas reakcji API nawet skrócony. Mamy zaufanie do powstałej platformy chmurowej i w razie potrzeby jesteśmy gotowi przekierować na nią większy ruch.
PS od tłumacza
Być może zainteresuje Cię także inny, niedawny post Dailymotion na temat Kubernetesa. Dedykowane jest do wdrażania aplikacji z Helmem na wielu klastrach Kubernetes i około miesiąc temu.
Przeczytaj także na naszym blogu:
- «".
- «";
- «";
- «";
- «";
- «";
- «";
- «";
- «";
- «";
- «".
Źródło: www.habr.com