Kubernetes to doskonałe narzędzie do uruchamiania kontenerów Docker w zgrupowanym środowisku produkcyjnym. Istnieją jednak zadania, które Kubernetes nie jest w stanie rozwiązać. Przy częstym wdrażaniu w środowisku produkcyjnym potrzebujemy w pełni zautomatyzowanego wdrożenia Blue/Green, aby uniknąć przestojów w tym procesie, który również wymaga obsługi zewnętrznych żądań HTTP i realizacji eksportu SSL. Wymaga to integracji z takim serwerem równoważącym, jak ha-proxy. Kolejnym zadaniem jest półautomatyczne skalowanie samego klastra Kubernetes w chmurze, na przykład częściowe zmniejszanie skali klastra w nocy.
Choć Kubernetes nie ma tych funkcji "prosto z pudełka", oferuje API, z którego można skorzystać, aby rozwiązać podobne problemy. Narzędzia do automatyzowanego wdrożenia Blue/Green i skalowania klastra Kubernetes zostały opracowane w ramach projektu Cloud RTI, który stworzono na podstawie open-source.
W tym artykule, będącym transkrypcją wideo, opisano, jak skonfigurować Kubernetes wraz z innymi komponentami open-source, aby uzyskać gotowe do produkcji środowisko, które bez przestojów w produkcji przyjmuje kod z commita git commit.
A więc, po uzyskaniu dostępu do swoich aplikacji z zewnątrz, można przystąpić do pełnej konfiguracji automatyzacji, czyli doprowadzić ją do etapu, na którym można wykonać git commit i upewnić się, że ten git commit kończy się w produkcji. Oczywiście, przy realizacji tych kroków, podczas wdrażania, nie chcemy doświadczać przestojów. Zatem wszelka automatyzacja w Kubernetes zaczyna się od API.
Kubernetes to nie jest narzędzie, które można efektywnie wykorzystywać "prosto z pudełka". Oczywiście, można tak zrobić, używając kubectl i tak dalej, ale to API jest najciekawszą i najbardziej przydatną częścią tej platformy. Korzystając z API jako zestawu funkcji, można uzyskać dostęp niemal do wszystkiego, co chcesz zrobić w Kubernetes. Sam kubectl również korzysta z REST API.
To jest REST, więc możesz używać dowolnych języków i narzędzi do pracy z tym API, ale znacznie ułatwią ci życie biblioteki użytkowników. Mój zespół napisał 2 takie biblioteki: jedną dla Java / OSGi i jedną dla Go. Ta druga nie jest często używana, ale w każdym razie masz te użyteczne narzędzia do dyspozycji. Są one częściowo licencjonowanym projektem open-source. Istnieje wiele takich bibliotek dla różnych języków, więc możesz wybrać najbardziej odpowiednie.
Zanim jednak przystąpisz do automatyzacji wdrażania, musisz upewnić się, że ten proces nie będzie narażony na jakiekolwiek przestoje. Na przykład nasz zespół przeprowadza wdrożenia produkcyjne w południe, kiedy ludzie maksymalnie korzystają z aplikacji, dlatego bardzo ważne jest, aby uniknąć opóźnień w tym procesie. Aby uniknąć przestojów, stosuje się 2 metody: wdrażanie blue/green lub skrolling update. W tym drugim przypadku, jeśli masz 5 replik aplikacji, są one aktualizowane jedna po drugiej. Ta metoda działa świetnie, ale nie jest odpowiednia, gdy podczas wdrażania masz uruchomione różne wersje aplikacji. W takim przypadku możesz zaktualizować interfejs użytkownika, podczas gdy backend będzie pracować ze starszą wersją, co spowoduje przerwanie działania aplikacji. Dlatego z punktu widzenia programowania praca w takich warunkach jest dość trudna.
Jednym z powodów, dla których preferujemy używać wdrożenia blue/green do automatyzacji wdrażania naszych aplikacji, jest to, że w tym podejściu musisz upewnić się, że w danym momencie aktywna jest tylko jedna wersja aplikacji.
Mechanizm wdrożenia blue/green wygląda następująco. Otrzymujemy ruch dla naszych aplikacji przez ha-proxy, które kieruje go do uruchomionych replik aplikacji tej samej wersji.
Kiedy następuje nowe wdrożenie, używamy Deployer, któremu dostarczane są nowe komponenty, a on przeprowadza wdrożenie nowej wersji. Wdrożenie nowej wersji aplikacji oznacza, że "podnosi się" nowy zestaw replik, po czym te repliki nowej wersji uruchamiane są w oddzielnym, nowym podzie. Jednak ha-proxy nic o nich nie wie i na razie nie kieruje do nich żadnego obciążenia.
Dlatego w pierwszej kolejności należy przeprowadzić testy sprawności nowych wersji health checking, aby upewnić się, że repliki są gotowe do obsługi obciążenia.
Wszystkie komponenty wdrożeniowe muszą wspierać jakąś formę health check. Może to być bardzo prosta kontrola HTTP z wywołaniem, kiedy otrzymujesz kod ze statusem 200, lub bardziej szczegółowa kontrola, w której sprawdzasz połączenie replik z bazą danych i innymi usługami, stabilność połączeń w dynamicznym środowisku, czy wszystko działa i funkcjonuje poprawnie. Proces ten może być dość skomplikowany.
Po tym, jak system upewni się w sprawności wszystkich zaktualizowanych replik, Deployer zaktualizuje konfigurację i przekaże właściwy confd, który przestawi ha-proxy.
Tylko po tym ruch będzie kierowany do podu z replikami nowej wersji, a stary pod zniknie.
Ten mechanizm nie jest cechą Kubernetes. Koncepcja Blue/green deployment istnieje od dłuższego czasu i zawsze wykorzystywała load balancer. Najpierw kierujesz cały ruch do starej wersji aplikacji, a po aktualizacji całkowicie przekierowujesz go na nową wersję. Ta zasada jest stosowana nie tylko w Kubernetes.
Teraz przedstawię wam nowy komponent wdrożenia – Deployer, który wykonuje testy sprawności, rekonfiguruje proxy i tak dalej. To koncept, który nie odnosi się do świata zewnętrznego i istnieje wewnątrz Kubernetes. Pokażę, jak stworzyć własny koncept Deployer przy użyciu narzędzi open-source.
Pierwszą rzeczą, jaką robi Deployer, jest stworzenie kontrolera replikacji RC za pomocą API Kubernetes. To API tworzy pody i usługi do dalszego wdrożenia, czyli tworzy całkowicie nowy klaster dla naszych aplikacji. Gdy tylko RC upewni się, że repliki zostały uruchomione, przeprowadzi ich kontrolę zdrowia poprzez Health check. W tym celu w Deployerze wykorzystuje się polecenie GET /health. Uruchamia ono odpowiednie komponenty weryfikujące i sprawdza wszystkie elementy odpowiadające za działanie klastra.
Po tym, jak wszystkie pody zgłoszą swoje "zdrowie", Deployer tworzy nowy element konfiguracji – rozproszone magazynowanie etcd, które jest używane wewnątrz Kubernetes, w tym do przechowywania konfiguracji load balancera. Zapisujemy dane w etcd, a małe narzędzie confd monitoruje etcd w poszukiwaniu nowych danych.
Jeśli znajdzie jakieś zmiany w początkowej konfiguracji, generuje nowy plik konfiguracyjny i przekazuje go ha-proxy. W takim przypadku ha-proxy jest restartowane bez utraty jakichkolwiek połączeń i kieruje obciążenie do nowych usług, które zapewniają działanie nowej wersji naszych aplikacji.
Jak widzicie, pomimo dużej liczby komponentów, nie ma tu nic skomplikowanego. Musisz po prostu poświęcić więcej uwagi API i etcd. Chcę wam opowiedzieć o open-source'owym deploerze, z którego sami korzystamy – to Amdatu Kubernetes Deployer.
To narzędzie do orkiestracji wdrożeń Kubernetes z takimi funkcjami:
- wdrożenie Blue/Green deployment;
- konfiguracja zewnętrznego load balancera;
- zarządzanie deskryptorami wdrożeń;
- zarządzanie rzeczywistym wdrożeniem;
- kontrola zdrowia Health checks w trakcie wdrożenia;
- wstrzykiwanie zmiennych środowiskowych do podów.
Ten Deployer został stworzony na bazie Kubernetes API i stanowi REST API do zarządzania deskryptorami i wdrożeniami, a także Websocket API do strumieniowego przesyłania logów w trakcie wdrożenia.
Umieszcza on dane konfiguracyjne load balancera w etcd, dzięki czemu nie musisz korzystać z ha-proxy z obsługą "prosto z pudełka", a łatwo używać własnego pliku konfiguracyjnego load balancera. Amdatu Deployer został napisany w Go, tak jak sam Kubernetes, i jest licencjonowany na zasadzie Apache.
Przed rozpoczęciem korzystania z tej wersji deploiera skorzystałem z następującego opisu wdrożenia, w którym zawarte są potrzebne mi parametry.
Jednym z ważnych parametrów tego kodu jest włączenie flagi „useHealthCheck”. Musimy określić, że podczas wdrażania należy przeprowadzić kontrolę działności. Parametr ten może być wyłączony, gdy w wdrożeniu używane są kontenery od zewnętrznych dostawców, które nie muszą być kontrolowane. W tym opisie zawarte są również liczba replik oraz URL frontend, potrzebny dla ha-proxy. Na końcu znajduje się flaga specyfikacji podu „podspec”, która odnosi się do Kubernetes w celu uzyskania informacji na temat konfiguracji portów, obrazu itd. Jest to dość prosty opis w formacie JSON.
Kolejnym narzędziem, które jest częścią projektu open-source Amdatu, jest Deploymentctl. Posiada on interfejs użytkownika UI do konfigurowania wdrożenia, przechowuje historię wdrożeń i zawiera webhooks do zwrotów od użytkowników zewnętrznych i deweloperów. Możesz nie korzystać z UI, ponieważ sam Amdatu Deployer jest REST API, ale ten interfejs może znacznie ułatwić ci wdrożenie bez angażowania jakiegokolwiek API. Deploymentctl napisany jest w OSGi/Vertx z wykorzystaniem Angular 2.
Teraz zaprezentuję to, co powiedziałem wcześniej na ekranie, używając wcześniej nagranej sesji, abyście nie musieli czekać. Wdrożymy prostą aplikację w Go. Nie martwcie się, jeśli wcześniej nie mieliście do czynienia z Go, to bardzo prosta aplikacja, więc wszystko powinno być dla was jasne.
Tutaj tworzymy serwer HTTP, który odpowiada jedynie na /health, więc ta aplikacja tylko sprawdza działność health check i nic więcej. Jeśli kontrola się powiedzie, uruchomiona zostanie pokazana poniżej struktura JSON. Zawiera ona wersję aplikacji, która ma być wdrożona przez deploiera, wiadomość, którą widzicie na górze pliku oraz boolean – czy nasza aplikacja działa, czy nie.
Z ostatnią linią trochę oszukałem, ponieważ umieściłem na początku pliku stałą wartość boolean, która później pomoże mi wdrożyć nawet „niedziałającą” aplikację. Później się tym zajmiemy.
Zatem zaczynamy. Najpierw sprawdzamy, czy są uruchomione jakieś pody za pomocą polecenia ~ kubectl get pods i braku odpowiedzi na adres URL frontendu upewniamy się, że w tej chwili nie są prowadzone żadne wdrożenia.
Następnie na ekranie widzicie interfejs Deploymentctl, o którym wspomniałem, w którym ustawiane są parametry wdrożenia: przestrzeń nazw, nazwa aplikacji, wersja wdrożenia, liczba replik, URL frontendu, nazwa kontenera, obraz, limity zasobów, numer portu do sprawdzenia health check itd. Limity zasobów są bardzo ważne, ponieważ pozwalają wykorzystać maksymalnie możliwą ilość sprzętu. Tutaj również można przejrzeć dziennik wdrożenia Deployment log.
Jeśli teraz powtórzymy polecenie ~ kubectl get pods, widać, że system "zamyka się" na 20 sekund, podczas których następuje rekonfiguracja ha-proxy. Po tym pod uruchamia się i naszą replikę można zobaczyć w dzienniku wdrożenia.
Wyciąłem z wideo 20-sekundowe oczekiwanie, a teraz widzicie na ekranie, że pierwsza wersja aplikacji została wdrożona. Wszystko to zostało zrobione wyłącznie za pomocą UI.
Teraz spróbujmy drugiej wersji. W tym celu zmieniam wiadomość aplikacji z „Hello, Kubernetes!” na „Hello, Deployer!”, system tworzy ten obraz i umieszcza go w rejestrze Dockera, po czym po prostu jeszcze raz klikamy przycisk „Deploy” w oknie Deploymentctl. Przy tym automatycznie uruchamia się dziennik wdrożenia dokładnie tak, jak to miało miejsce przy wdrożeniu pierwszej wersji aplikacji.
Polecenie ~ kubectl get pods pokazuje, że obecnie uruchomione są 2 wersje aplikacji, jednak frontend pokazuje, że wciąż działa wersja 1.
Load balancer czeka, aż zostanie przeprowadzona kontrola health check, po czym przekieruje ruch na nową wersję. Po 20 s przełączamy się na curl i widzimy, że teraz mamy wdrożoną wersję 2 aplikacji, a wersja pierwsza została usunięta.
Było to wdrożenie „zdrowej” aplikacji — healthy. Spójrzmy, co się stanie, jeśli dla nowej wersji aplikacji zmienię wartość parametru Healthy z true na false, czyli spróbuję wdrożyć aplikację unhealthy, która nie przeszła testu sprawności. Może się to zdarzyć, jeśli na etapie rozwoju w aplikacji pojawiły się jakieś błędy konfiguracyjne i została ona w takiej formie przesłana do produkcji.
Jak widać, proces wdrożenia przebiega przez wszystkie wymienione etapy, a ~ kubectl get pods pokazuje, że oba podsy są uruchomione. Jednak w przeciwieństwie do poprzedniego wdrożenia, log pokazuje stan timeout. Oznacza to, że z powodu nieprzechodzenia health check nowa wersja aplikacji nie może zostać wdrożona. W rezultacie widzisz, że system wrócił do używania starej wersji aplikacji, a nowa wersja została po prostu usunięta.
Dobrą wiadomością jest to, że nawet jeśli masz ogromną liczbę równoczesnych zapytań kierowanych do aplikacji, użytkownicy nawet nie zauważą przestoju podczas realizacji procedury wdrożenia. Jeśli przetestujesz tę aplikację za pomocą frameworka Gatling, który wysyła maksymalną liczbę zapytań, żadne z tych zapytań nie zostanie odrzucone. Oznacza to, że nasi użytkownicy nawet nie zauważą aktualizacji wersji w czasie rzeczywistym. Jeśli to się nie powiedzie, praca będzie kontynuowana na starej wersji, a jeśli się powiedzie – użytkownicy przejdą na nową wersję.
Istnieje tylko jedna rzecz, która może doprowadzić do niepowodzenia – jeśli health check przeszedł pomyślnie, a aplikacja uległa awarii, gdy tylko została obciążona, to kolaps nastąpi dopiero po zakończeniu wdrożenia. W takim przypadku będziesz musiał ręcznie powrócić do starej wersji. Tak więc przyjrzeliśmy się, jak używać Kubernetes z dedykowanymi narzędziami open-source. Proces wdrożenia będzie przebiegał znacznie łatwiej, jeśli zintegrowasz te narzędzia z pipelines budowy/wdrożenia. W tym przypadku do uruchomienia wdrożenia możesz użyć zarówno interfejsu użytkownika, jak i całkowicie zautomatyzować ten proces, na przykład stosując commit do master.
Nasz serwer budowy Build Server stworzy obraz Docker, wrzuci go do Docker Hub lub innego używanego przez Ciebie rejestru. Docker Hub obsługuje webhooki, dlatego możemy zainicjować zdalne wdrożenie przez Deployer pokazanym powyżej sposobem. Dzięki temu można całkowicie zautomatyzować wdrożenie aplikacji do potencjalnego środowiska produkcyjnego.
Przejdźmy do omówienia kolejnego tematu – skalowania klastra Kubernetes. Zauważę, że polecenie kubectl jest poleceniem do skalowania. Dzięki temu łatwo możemy zwiększyć liczbę replik w naszym klastrze. W praktyce jednak zazwyczaj chcemy zwiększać liczbę nie podów, a nód.
W ciągu dnia może być konieczne zwiększenie liczby instancji, a w nocy, aby obniżyć koszty usług Amazon – zmniejszenie liczby uruchomionych instancji aplikacji. Nie oznacza to, że wystarczy skalować tylko liczbę podów, ponieważ nawet jeśli jeden z nód będzie nieużywany, i tak będziesz musiał płacić za niego Amazon. Oznacza to, że obok skalowania podów, musisz również skalować liczbę używanych maszyn.
Może to stanowić wyzwanie, ponieważ niezależnie od tego, czy używamy Amazon czy innej usługi chmurowej, Kubernetes nic nie wie o liczbie używanych maszyn. Brakuje mu narzędzia do skalowania systemu na poziomie nód.
Musimy więc zadbać zarówno o nody, jak i o pody. Możemy łatwo skalować uruchamianie nowych nód za pomocą AWS API oraz grupy skalowania do konfiguracji liczby roboczych węzłów Kubernetes. Można również użyć skryptu cloud-init lub podobnego do rejestracji nód w klastrze Kubernetes.
Nowa maszyna uruchamia się w grupie Scaling, inicjuje się jako węzeł, rejestruje się w rejestrze głównym i zaczyna działać. Po tym można zwiększyć liczbę replik do wykorzystania na powstałych węzłach. Zmniejszenie skali wymaga większych wysiłków, ponieważ trzeba upewnić się, że taki krok nie doprowadzi do zniszczenia już działających aplikacji po odłączeniu „niepotrzebnych” maszyn. Aby zapobiec takiemu scenariuszowi, należy przywrócić węzły do statusu „unschedulable”. Oznacza to, że domyślny scheduler przy planowaniu podów DaemonSet zignoruje te węzły. Scheduler nie usunie nic z tych serwerów, ale nie będzie również uruchamiać na nich nowych kontenerów. Następnym krokiem jest usunięcie węzła drain node, co oznacza przeniesienie działających podów na inną maszynę lub inne węzły, które mają wystarczającą pojemność. Upewniwszy się, że na tych węzłach nie ma już żadnych kontenerów, można je usunąć z Kubernetes. Po tym dla Kubernetes przestaną one po prostu istnieć. Następnie należy użyć AWS API do wyłączenia niepotrzebnych węzłów lub maszyn.
Możesz użyć Amdatu Scalerd — kolejnego narzędzia open-source do skalowania, podobnego do AWS API. Oferuje CLI do dodawania lub usuwania węzłów w klastrze. Jego interesującą cechą jest możliwość skonfigurowania harmonogramu za pomocą następnego pliku json.
Przedstawiony kod zmniejsza pojemność klastra w nocy o połowę. Ustawiono w nim zarówno liczbę dostępnych replik, jak i pożądaną pojemność klastra Amazon. Użycie tego harmonogramu automatycznie zmniejszy liczbę węzłów w nocy i zwiększy je rano, pozwalając zaoszczędzić na kosztach korzystania z węzłów takiego chmurowego serwisu, jak Amazon. Ta funkcja nie jest wbudowana w Kubernetes, ale użycie Scalerd pozwala na dowolne skalowanie tej platformy.
Chciałbym zwrócić uwagę, że wiele osób mówi mi: „To wszystko dobrze, ale co z moją bazą danych, która zazwyczaj jest w stanie statycznym?” W jaki sposób można uruchomić coś podobnego w tak dynamicznym środowisku, jak Kubernetes? Moim zdaniem, nie powinieneś tego robić, nie powinieneś starać się organizować pracy magazynu danych w Kubernetes. Technicznie jest to możliwe, a w internecie znajdują się przewodniki na ten temat, jednak bardzo to utrudni twoje życie.
Tak, w Kubernetes istnieje pojęcie trwałych magazynów, i możesz spróbować uruchamiać takie magazyny danych jak Mongo lub MySQL, ale jest to dość pracochłonne zadanie. Wynika to z faktu, że magazyny danych nie do końca wspierają interakcję z dynamicznym otoczeniem. Większość baz danych wymaga znacznej konfiguracji, w tym ręcznego ustawienia klastra, nie lubi automatycznego skalowania i innych podobnych rzeczy.
Dlatego nie warto komplikować sobie życia, próbując uruchomić magazyn danych w Kubernetes. Zorganizuj ich pracę w tradycyjny sposób przy użyciu znanych serwisów i po prostu pozwól Kubernetes na ich wykorzystywanie.
Na zakończenie chciałbym przedstawić platformę Cloud RTI opartą na Kubernetes, nad którą pracuje mój zespół. Zapewnia ona centralne prowadzenie logów, monitorowanie aplikacji i klastrów oraz posiada wiele innych przydatnych funkcji, które się przydadzą. Wykorzystuje różne narzędzia open-source, takie jak Grafana do wyświetlania monitoringu.
Pojawiło się pytanie, dlaczego używać z Kubernetes load balancera ha-proxy. Dobre pytanie, ponieważ obecnie istnieją dwa poziomy balansowania obciążenia. Usługi Kubernetes nadal działają na wirtualnych adresach IP. Nie możesz używać ich dla portów zewnętrznych maszyn hostujących, ponieważ jeśli Amazon przeładowałby swój hosting w chmurze, adres by się zmienił. Dlatego umieszczamy ha-proxy przed usługami — aby stworzyć bardziej statyczną strukturę dla nieprzerwanego przepływu ruchu z Kubernetes.
Jeszcze jedno dobre pytanie – jak można zadbać o zmianę schematu bazy danych podczas wdrażania blue/green? Faktem jest, że niezależnie od użycia Kubernetes, zmiana schematu bazy danych to skomplikowane zadanie. Musisz zapewnić kompatybilność starego i nowego schematu, po czym możesz zaktualizować bazę danych, a następnie same aplikacje. Możesz wykonać „gorącą wymianę” bazy danych, a następnie zaktualizować aplikacje. Znam ludzi, którzy uruchamiali zupełnie nowy klaster bazy danych z nowym schematem, to opcja, jeśli masz bazę danych bez schematu, typu Mongo, ale w każdym razie to nie jest proste zadanie. Jeśli więcej pytań nie ma, dziękuję za uwagę!
Trochę reklamy 🙂
Dziękujemy, że jesteś z nami. Podobają Ci się nasze artykuły? Chcesz zobaczyć więcej interesujących materiałów? Wspieraj nas składając zamówienie lub polecając nas znajomym, , unikatowy odpowiednik serwerów entry-level, który został stworzony przez nas dla Ciebie: (dostępne opcje z RAID1 i RAID10, do 24 rdzeni i do 40GB DDR4).
Dell R730xd dwa razy tańszy w centrum danych Equinix Tier IV w Amsterdamie? Tylko u nas w Holandii! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — od 99 dolarów! Czytaj o tym
Źródło: habr.com
