Przyp. tłum.: Dailymotion — jeden z największych na świecie serwisów hostingu wideo, a przez to znaczący użytkownik Kubernetes. W tym materiale architekt systemowy David Donchez dzieli się wynikami stworzenia produkcyjnej platformy firmy opartej na K8s, która zaczynała jako instalacja chmurowa w GKE i zakończyła się jako rozwiązanie hybrydowe, co pozwoliło osiągnąć lepszy czas reakcji i zaoszczędzić na kosztach infrastruktury.
Podejmując decyzję o przebudowie głównego API trzy lata temu, chcieliśmy opracować bardziej efektywny sposób umieszczania aplikacji i ułatwić . W tym celu postanowiliśmy wykorzystać platformę orkiestracji kontenerów i naturalnie wybraliśmy Kubernetes.
Dlaczego warto tworzyć własną platformę opartą na Kubernetes?
Produkcja API na poziomie produkcyjnym w najkrótszym możliwym czasie z pomocą Google Cloud
Lato 2016 roku
Trzy lata temu, tuż po zakupie Dailymotion przez , nasze zespoły inżynieryjne skupiły się na jednym globalnym celu: stworzyć zupełnie nowy produkt Dailymotion.
Na podstawie analizy kontenerów, rozwiązań do orkiestracji oraz naszego doświadczenia, upewniliśmy się, że Kubernetes to właściwy wybór. Część programistów już miała pojęcie o podstawowych koncepcjach i wiedziała, jak go używać, co było ogromnym atutem dla transformacji infrastruktury.
Z punktu widzenia infrastruktury potrzebny był mocny i elastyczny system do uruchamiania nowych typów aplikacji chmurowych (cloud-native). Wolaliśmy pozostać w chmurze na początku naszej podróży, aby spokojnie zbudować maksymalnie niezawodną lokalną platformę. Ostatecznie zdecydowaliśmy się wdrażać nasze aplikacje za pomocą Google Kubernetes Engine, wiedząc, że prędzej czy później przejdziemy na własne centra danych i zastosujemy strategię hybrydową.
Dlaczego wybraliśmy GKE?
Głównie na podstawie decyzji technicznych. Poza tym konieczne było szybkie dostarczenie infrastruktury odpowiadającej potrzebom biznesowym firmy. Mieliśmy kilka wymagań dotyczących umieszczania aplikacji, takich jak rozproszenie geograficzne, skalowalność i odporność na awarie.
Klastery GKE w Dailymotion
Ponieważ Dailymotion to platforma wideo dostępna na całym świecie, bardzo chciałyśmy poprawić jakość usługi, skracając czas oczekiwania latencji. Wcześniej był dostępny tylko w Paryżu, co było nieoptymalne. Chcieliśmy mieć możliwość uruchamiania aplikacji nie tylko w Europie, ale także w Azji i USA.
Ta wrażliwość na opóźnienia oznaczała, że trzeba będzie poważnie pracować nad architekturą sieci platformy. Podczas gdy większość usług chmurowych zmuszała do tworzenia własnej sieci w każdym regionie, a następnie łączenia ich przez VPN lub zarządzaną usługę, Google Cloud umożliwiał stworzenie w pełni routowalnej jednorodnej sieci obejmującej wszystkie regiony Google. To duży plus pod względem eksploatacji i wydajności systemu.
Ponadto z zadaniami świetnie radzą sobie usługi sieciowe i balancerzy obciążenia od Google Cloud. Umożliwiają one po prostu korzystanie z dowolnych publicznych adresów IP z każdego regionu, a wspaniały protokół BGP zajmie się wszystkim innym (tzn. przekieruje użytkowników do najbliższego klastra). Oczywiście w przypadku awarii ruch automatycznie przejdzie do innego regionu bez jakiejkolwiek interwencji człowieka.
Monitoring balancowania obciążenia w Google
Nasza platforma także aktywnie wykorzystuje procesory graficzne. Google Cloud pozwala na ich bardzo efektywne wykorzystanie bezpośrednio w klastrach Kubernetes.
Wówczas zespół infrastruktury głównie koncentrował się na starym stosie wdrożonym na serwerach fizycznych. Dlatego wykorzystanie zarządzanej usługi (w tym komponentów master Kubernetes) odpowiadało naszym wymaganiom i pozwalało na przeszkolenie zespołów w pracy z lokalnymi klastrami.
W rezultacie mogliśmy zacząć przyjmować produkcyjny ruch na infrastrukturze Google Cloud zaledwie 6 miesięcy po rozpoczęciu prac.
Jednak mimo wielu zalet, korzystanie z dostawcy chmurowego wiąże się z pewnymi kosztami, które mogą rosnąć w zależności od obciążenia. Dlatego dokładnie analizowaliśmy każdą używaną zarządzaną usługę, mając na względzie przyszłą możliwość implementacji ich na lokalnych serwerach. W rzeczywistości wdrażanie lokalnych klastrów rozpoczęło się pod koniec 2016 roku, a wtedy także zainicjowano strategię hybrydową.
Uruchomienie lokalnej platformy orkiestracji kontenerów Dailymotion
Jesień 2016 roku
W warunkach, gdy cały stos był gotowy do produkcji, a prace nad API , nadszedł czas, aby skupić się na regionalnych klastrach.
W tamtym czasie użytkownicy przeglądali miesięcznie ponad 3 miliardy filmów. Oczywiście, nasza własna rozbudowana sieć dostarczania treści funkcjonowała już od wielu lat. Chcieliśmy skorzystać z tego faktu i uruchomić klastry Kubernetes w istniejących centrach danych.
Infrastruktura Dailymotion obejmowała ponad 2500 serwerów w sześciu centrach danych. Wszystkie z nich są konfigurowane za pomocą Saltstack. Zaczęliśmy przygotowywać wszystkie niezbędne przepisy do utworzenia węzłów master i worker oraz klastra etcd.
Część sieciowa
Nasza sieć jest całkowicie routowalna. 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łniała wszystkie wymagania (ze względu na stosowane podejście na poziomie L3), okazała się . Idealnie wpasował się w istniejący model sieciowy infrastruktury.
Ponieważ chcieliśmy wykorzystać wszystkie dostępne elementy infrastruktury, przede wszystkim musieliśmy zająć się naszym rodzimym narzędziem sieciowym (używanym na wszystkich serwerach): wykorzystać je do ogłaszania zakresów adresów IP w sieci z węzłami Kubernetes. Pozwoliliśmy Calico przypisywać adresy IP podom, ale nie używaliśmy go i wciąż nie używamy do sesji BGP na sprzęcie sieciowym. W rzeczywistości routowaniem zajmuje się Exabgp, który ogłasza podsieci używane przez Calico. Umożliwia nam to dotarcie do dowolnego podu z wewnętrznej sieci (w szczególności z równoważników obciążenia).
Jak zarządzamy ruchem ingress
Aby przekierować przychodzące żądania do odpowiedniej usługi, postanowiono użyć Ingress Controller ze względu na jego integrację z zasobami ingress Kubernetes.
Trzy lata temu nginx-ingress-controller był najbardziej dojrzałym kontrolerem: Nginx był używany od dawna i był znany ze swojej stabilności i wydajności.
W naszym systemie postanowiliśmy umieścić kontrolery na dedykowanych serwerach blade 10-gigabitowych. Każdy kontroler łączył się z endpointem kube-apiserver odpowiedniego klastra. Na tych serwerach używano także Exabgp do ogłaszania publicznych lub prywatnych adresów IP. Topologia naszej sieci umożliwia korzystanie z BGP z tych kontrolerów do routingu całego ruchu bezpośrednio do podów, bez użycia usługi typu NodePort. Takie podejście pomaga uniknąć horyzontalnego ruchu między węzłami i zwiększa efektywność.
Ruch sieciowy z internetu do podów
Teraz, gdy zrozumieliśmy naszą hybrydową platformę, możemy zagłębić się w sam proces migracji ruchu.
Migracja ruchu z Google Cloud do infrastruktury Dailymotion
Jesień 2018 roku
Po prawie dwóch latach tworzenia, testowania i konfigurowania wreszcie uzyskaliśmy pełny stos Kubernetes, gotowy na przyjęcie części ruchu.
Obecna strategia routingu jest dość prosta, ale w pełni zaspokaja potrzeby. Oprócz publicznych adresów IP (w Google Cloud i Dailymotion) wykorzystuje się AWS Route 53 do definiowania polityk i przekierowywania użytkowników do klastra według naszego wyboru.
Przykład polityki routingu z użyciem Route 53
Z Google Cloud jest to proste, ponieważ używamy jednego adresu IP dla wszystkich klastrów, a użytkownik jest przekierowywany do najbliższego klastra GKE. W przypadku naszych klastrów technologia jest inna, ponieważ ich adresy IP się różnią.
Podczas migracji dążyliśmy do przekierowywania regionalnych zapytań do odpowiednich klastrów i ocenialiśmy korzyści takiego podejścia.
Ponieważ nasze klastry GKE są skonfigurowane do automatycznego skalowania przy użyciu Custom Metrics, zyskują/zmniejszają moce w zależności od napływającego ruchu.
W normalnym trybie cały regionalny ruch kierowany jest do lokalnego klastra, a GKE pełni rolę rezerwy na wypadek problemów (health-checki przeprowadza Route 53).
…
W przyszłości chcemy w pełni zautomatyzować polityki routingu, aby uzyskać autonomiczną hybrydową strategię, która nieustannie poprawia dostępność dla użytkowników. Jeśli chodzi o zalety: znacznie zmniejszyły się koszty chmury, a także udało się skrócić czas reakcji API. Ufamy otrzymanej platformie chmurowej i jesteśmy gotowi w razie potrzeby przekierować na nią więcej ruchu.
P.S. od tłumacza
Możesz również zainteresować się inną niedawną publikacją Dailymotion na temat Kubernetes. Jest ona poświęcona wdrażaniu aplikacji za pomocą Helm w wielu klastrach Kubernetes i około miesiąca temu.
Przeczytaj także na naszym blogu:
- «».
- «»;
- «»;
- «»;
- «»;
- «»;
- «»;
- «»;
- «»;
- «»;
- «».
Źródło: habr.com
