Kubernetes to doskonałe narzędzie do uruchamiania kontenerów Docker w klastrowym środowisku produkcyjnym. Istnieją jednak problemy, których Kubernetes nie jest w stanie rozwiązać. W przypadku częstych wdrożeń produkcyjnych potrzebujemy w pełni zautomatyzowanego wdrożenia Blue/Green, aby uniknąć przestojów w procesie, który wymaga również obsługi zewnętrznych żądań HTTP i wykonywania odciążeń SSL. Wymaga to integracji z modułem równoważenia obciążenia, takim jak ha-proxy. Kolejnym wyzwaniem jest półautomatyczne skalowanie samego klastra Kubernetes podczas pracy w środowisku chmurowym, np. częściowe skalowanie klastra w nocy.
Chociaż Kubernetes nie ma tych funkcji od razu po wyjęciu z pudełka, zapewnia interfejs API, którego można użyć do rozwiązania podobnych problemów. Narzędzia do automatycznego wdrażania Blue/Green i skalowania klastra Kubernetes zostały opracowane w ramach projektu Cloud RTI, który powstał w oparciu o open-source.
W tym artykule (transkrypcja wideo) pokazano, jak skonfigurować Kubernetes wraz z innymi komponentami typu open source, aby utworzyć środowisko gotowe do produkcji, które akceptuje kod z zatwierdzenia git bez przestojów w produkcji.
Tak więc, gdy już będziesz mieć dostęp do swoich aplikacji ze świata zewnętrznego, możesz zacząć w pełni konfigurować automatyzację, to znaczy doprowadzić ją do etapu, w którym możesz wykonać zatwierdzenie git i upewnić się, że to zatwierdzenie git trafi do produkcji. Naturalnie, realizując te kroki, wdrażając wdrożenie, nie chcemy napotkać przestojów. Zatem każda automatyzacja w Kubernetesie zaczyna się od API.
Kubernetes nie jest narzędziem, z którego można produktywnie korzystać od razu po wyjęciu z pudełka. Oczywiście możesz to zrobić, używać kubectl i tak dalej, ale nadal API jest najciekawszą i najbardziej użyteczną rzeczą na tej platformie. Używając API jako zestawu funkcji, możesz uzyskać dostęp do niemal wszystkiego, co chcesz zrobić w Kubernetesie. Sam kubectl również korzysta z API REST.
To jest REST, więc możesz używać dowolnego języka lub narzędzia do pracy z tym API, ale Twoje życie będzie znacznie łatwiejsze dzięki niestandardowym bibliotekom. Mój zespół napisał 2 takie biblioteki: jedną dla Java/OSGi i jedną dla Go. Ten drugi nie jest często używany, ale w każdym razie masz do dyspozycji te przydatne rzeczy. Są częściowo licencjonowanym projektem typu open source. Istnieje wiele takich bibliotek dla różnych języków, więc możesz wybrać te, które najbardziej Ci odpowiadają.
Dlatego zanim zaczniesz automatyzować wdrożenie, musisz upewnić się, że proces nie będzie podlegał żadnym przestojom. Na przykład nasz zespół przeprowadza wdrożenia produkcyjne w środku dnia, kiedy ludzie korzystają z aplikacji najwięcej, dlatego ważne jest, aby unikać opóźnień w tym procesie. Aby uniknąć przestojów, stosowane są 2 metody: wdrożenie niebieskie/zielone lub aktualizacja krocząca. W tym drugim przypadku, jeśli masz uruchomionych 5 replik aplikacji, są one aktualizowane sekwencyjnie, jedna po drugiej. Ta metoda działa świetnie, ale nie jest odpowiednia, jeśli podczas procesu wdrażania działają jednocześnie różne wersje aplikacji. W takim przypadku możesz zaktualizować interfejs użytkownika, gdy backend działa w starej wersji, a aplikacja przestanie działać. Dlatego z programistycznego punktu widzenia praca w takich warunkach jest dość trudna.
Jest to jeden z powodów, dla których wolimy wdrażać rozwiązania niebieskie/zielone w celu automatyzacji wdrażania naszych aplikacji. W przypadku tej metody należy upewnić się, że w danym momencie aktywna jest tylko jedna wersja aplikacji.
Mechanizm wdrażania niebiesko-zielonego wygląda następująco. Ruch dla naszych aplikacji odbieramy poprzez ha-proxy, który przekazuje go do działających replik aplikacji w tej samej wersji.
Kiedy dokonujemy nowego wdrożenia, korzystamy z Deployera, który otrzymuje nowe komponenty i wdraża nową wersję. Wdrożenie nowej wersji aplikacji oznacza, że tworzony jest nowy zestaw replik, po czym te repliki nowej wersji są uruchamiane w osobnym, nowym zasobniku. Jednak ha-proxy nic o nich nie wie i nie kieruje jeszcze do nich żadnego obciążenia.
Dlatego przede wszystkim konieczne jest sprawdzenie wydajności nowych wersji sprawdzania kondycji, aby upewnić się, że repliki są gotowe do obsługi obciążenia.
Wszystkie komponenty wdrożenia muszą obsługiwać jakąś formę kontroli kondycji. Może to być bardzo proste sprawdzenie wywołania HTTP, gdy otrzymasz kod ze statusem 200, lub bardziej szczegółowe sprawdzenie, podczas którego sprawdzisz połączenie replik z bazą danych i innymi usługami, stabilność połączeń środowiska dynamicznego i czy wszystko się uruchamia i działa poprawnie. Proces ten może być dość złożony.
Gdy system sprawdzi, czy wszystkie zaktualizowane repliki działają, Deployer zaktualizuje konfigurację i przekaże poprawną konfigurację confd, która ponownie skonfiguruje ha-proxy.
Dopiero po tym ruch zostanie przekierowany do podu z replikami nowej wersji, a stary pod zniknie.
Ten mechanizm nie jest cechą Kubernetesa. Koncepcja wdrożenia Blue/Green istnieje już od dłuższego czasu i zawsze korzystała z modułu równoważenia obciążenia. Najpierw kierujesz cały ruch na starą wersję aplikacji, a po aktualizacji całkowicie przenosisz go do nowej wersji. Zasadę tę stosuje się nie tylko w Kubernetesie.
Teraz przedstawię wam nowy komponent wdrożeniowy - Deployer, który przeprowadza kontrolę stanu, rekonfiguruje proxy i tak dalej. Jest to koncepcja, która nie dotyczy świata zewnętrznego i istnieje wewnątrz Kubernetesa. Pokażę Ci, jak możesz stworzyć własną koncepcję Deployera, korzystając z narzędzi open source.
Zatem pierwszą rzeczą, jaką robi Deployer, jest utworzenie kontrolera replikacji RC przy użyciu interfejsu API Kubernetes. To API tworzy pody i usługi do dalszego wdrożenia, czyli tworzy zupełnie nowy klaster dla naszych aplikacji. Gdy tylko RC będzie przekonany, że repliki zostały uruchomione, przeprowadzi kontrolę stanu ich funkcjonalności. W tym celu Deployer używa polecenia GET /health. Uruchamia odpowiednie komponenty skanowania i sprawdza wszystkie elementy wspierające działanie klastra.
Gdy wszystkie pody zgłoszą swój stan, Deployer tworzy nowy element konfiguracji — rozproszoną pamięć masową etcd, która jest używana wewnętrznie przez Kubernetes, w tym przechowuje konfigurację modułu równoważenia obciążenia. Zapisujemy dane do pliku etcd i do małego narzędzia o nazwie confd monitors etcd nowych danych.
Jeśli wykryje jakiekolwiek zmiany w konfiguracji początkowej, generuje nowy plik ustawień i przesyła go do ha-proxy. W tym przypadku ha-proxy uruchamia się ponownie bez utraty połączeń i kieruje obciążenie do nowych usług, które umożliwiają działanie nowej wersji naszych aplikacji.
Jak widać, pomimo mnóstwa komponentów, nie ma tu nic skomplikowanego. Musisz tylko zwrócić większą uwagę na API i itp. Chcę opowiedzieć o wdrażaczu open source, z którego sami korzystamy - Amdatu Kubernetes Deployer.
Jest to narzędzie do organizowania wdrożeń Kubernetes i posiada następujące funkcje:
- Wdrożenie w kolorze niebieskim/zielonym;
- skonfigurowanie zewnętrznego modułu równoważenia obciążenia;
- zarządzanie deskryptorami wdrażania;
- zarządzanie rzeczywistym wdrożeniem;
- sprawdzanie funkcjonalności kontroli stanu podczas wdrażania;
- implementacja zmiennych środowiskowych w podach.
Ten moduł wdrażania jest zbudowany na bazie interfejsu API Kubernetes i udostępnia interfejs API REST do zarządzania uchwytami i wdrożeniami, a także interfejs API protokołu Websocket do przesyłania strumieniowego dzienników podczas procesu wdrażania.
Umieszcza dane konfiguracyjne modułu równoważenia obciążenia w pliku etcd, więc nie musisz używać ha-proxy z gotową obsługą, ale z łatwością możesz użyć własnego pliku konfiguracyjnego modułu równoważenia obciążenia. Amdatu Deployer jest napisany w Go, podobnie jak sam Kubernetes i jest licencjonowany przez Apache.
Zanim zacząłem używać tej wersji programu wdrażającego, użyłem następującego deskryptora wdrożenia, który określał potrzebne mi parametry.
Jednym z ważnych parametrów tego kodu jest włączenie flagi „useHealthCheck”. Musimy określić, że podczas procesu wdrażania należy przeprowadzić kontrolę poprawności. To ustawienie można wyłączyć, jeśli we wdrożeniu używane są kontenery innych firm, które nie wymagają weryfikacji. Ten deskryptor wskazuje również liczbę replik i adres URL frontendu, którego potrzebuje ha-proxy. Na końcu znajduje się flaga specyfikacji poda „podspec”, która wywołuje Kubernetes w celu uzyskania informacji o konfiguracji portu, obrazie itp. Jest to dość prosty deskryptor JSON.
Kolejnym narzędziem będącym częścią projektu Amdatu o otwartym kodzie źródłowym jest Deploymentctl. Posiada interfejs użytkownika do konfigurowania wdrożeń, przechowuje historię wdrożeń i zawiera webhooki do wywołań zwrotnych od zewnętrznych użytkowników i programistów. Możesz nie używać interfejsu użytkownika, ponieważ sam Amdatu Deployer jest interfejsem API REST, ale ten interfejs może znacznie ułatwić wdrożenie bez angażowania żadnego interfejsu API. Deploymentctl napisano w OSGi/Vertx przy użyciu Angular 2.
Teraz zademonstruję powyższe na ekranie, korzystając z nagranego wcześniej nagrania, abyś nie musiał czekać. Będziemy wdrażać prostą aplikację Go. Nie martw się, jeśli jeszcze nie próbowałeś Go, jest to bardzo prosta aplikacja, więc powinieneś być w stanie to rozgryźć.
Tutaj tworzymy serwer HTTP, który odpowiada tylko na /health, więc ta aplikacja testuje tylko kontrolę stanu i nic więcej. Jeśli sprawdzenie zakończy się pomyślnie, używana jest struktura JSON pokazana poniżej. Zawiera wersję aplikacji, która zostanie wdrożona przez wdrażającego, komunikat widoczny na górze pliku oraz typ danych boolowskich – czy nasza aplikacja działa, czy nie.
Trochę oszukałem z ostatnią linijką, bo na górze pliku umieściłem stałą wartość logiczną, która w przyszłości pomoże mi wdrożyć nawet „niezdrową” aplikację. Zajmiemy się tym później.
Więc zacznijmy. Najpierw sprawdzamy obecność uruchomionych podów za pomocą polecenia ~ kubectl get pods i w oparciu o brak odpowiedzi z adresu URL frontendu upewniamy się, że aktualnie nie są wykonywane żadne wdrożenia.
Następnie na ekranie widać wspomniany przeze mnie interfejs Deploymentctl, w którym ustawiane są parametry wdrożenia: przestrzeń nazw, nazwa aplikacji, wersja wdrożenia, liczba replik, front-end URL, nazwa kontenera, obraz, limity zasobów, numer portu do kontroli stanu, itp. . Limity zasobów są bardzo ważne, ponieważ pozwalają na wykorzystanie maksymalnej możliwej ilości sprzętu. Tutaj możesz także wyświetlić dziennik wdrożenia.
Jeśli teraz powtórzysz polecenie ~ kubectl get pods, zobaczysz, że system „zawiesza się” na 20 sekund, podczas których ha-proxy jest rekonfigurowany. Następnie kapsuła zostaje uruchomiona, a naszą replikę można zobaczyć w dzienniku wdrożenia.
Wyciąłem z filmu 20-sekundowe oczekiwanie i teraz na ekranie widać, że została wdrożona pierwsza wersja aplikacji. Wszystko to zostało wykonane przy użyciu wyłącznie interfejsu użytkownika.
Teraz wypróbujmy drugą wersję. W tym celu zmieniam komunikat aplikacji z „Hello, Kubernetes!” na „Hello, Deployer!” system tworzy ten obraz i umieszcza go w rejestrze Dockera, po czym wystarczy ponownie kliknąć przycisk „Wdróż” w oknie Deploymentctl. W takim przypadku dziennik wdrożenia zostanie automatycznie uruchomiony w taki sam sposób, jak miało to miejsce podczas wdrażania pierwszej wersji aplikacji.
Polecenie ~ kubectl get pods pokazuje, że obecnie działają 2 wersje aplikacji, ale frontend pokazuje, że nadal działa wersja 1.
Moduł równoważenia obciążenia czeka na zakończenie sprawdzania stanu przed przekierowaniem ruchu do nowej wersji. Po 20 sekundach przełączamy się na curl i widzimy, że mamy teraz wdrożoną wersję 2 aplikacji, a pierwsza została usunięta.
Było to wdrożenie „zdrowej” aplikacji. Zobaczmy, co się stanie, jeśli w nowej wersji aplikacji zmienię parametr Healthy z true na false, co oznacza, że spróbuję wdrożyć nieprawidłową aplikację, która nie przeszła kontroli stanu. Może się tak zdarzyć, jeśli na etapie rozwoju aplikacji popełniono błędy konfiguracyjne i w takiej formie została ona wysłana do produkcji.
Jak widać, wdrożenie przechodzi przez wszystkie powyższe kroki, a ~kubectl get pods pokazuje, że oba pody są uruchomione. Jednak w przeciwieństwie do poprzedniego wdrożenia dziennik pokazuje stan przekroczenia limitu czasu. Oznacza to, że z powodu niepowodzenia kontroli stanu nie można wdrożyć nowej wersji aplikacji. W rezultacie widzisz, że system powrócił do korzystania ze starej wersji aplikacji, a nowa wersja została po prostu odinstalowana.
Zaletą tego jest to, że nawet jeśli do aplikacji wpłynie ogromna liczba jednoczesnych żądań, nie zauważą one nawet przestoju podczas wdrażania procedury wdrażania. Jeśli przetestujesz tę aplikację przy użyciu frameworka Gatling, który wysyła do niej tyle żądań, ile to możliwe, żadne z tych żądań nie zostanie odrzucone. Oznacza to, że nasi użytkownicy nawet nie zauważą aktualizacji wersji w czasie rzeczywistym. Jeśli się nie powiedzie, prace będą kontynuowane na starej wersji, a jeśli się powiedzie, użytkownicy przejdą na nową wersję.
Tylko jedna rzecz może zawieść - jeśli kontrola stanu zakończy się pomyślnie, ale aplikacja ulegnie awarii zaraz po zastosowaniu obciążenia, co oznacza, że załamanie nastąpi dopiero po zakończeniu wdrażania. W takim przypadku konieczne będzie ręczne przywrócenie starej wersji. Przyjrzeliśmy się więc, jak używać Kubernetesa z zaprojektowanymi dla niego narzędziami open source. Proces wdrażania będzie znacznie łatwiejszy, jeśli wbudujesz te narzędzia w potoki kompilacji/wdrożenia. Jednocześnie, aby rozpocząć wdrażanie, możesz skorzystać z interfejsu użytkownika lub w pełni zautomatyzować ten proces, wykorzystując na przykład zatwierdzenie do mastera.
Nasz serwer kompilacji utworzy obraz Dockera, prześle go do Docker Hub lub innego rejestru, którego używasz. Docker Hub obsługuje webhook, dzięki czemu możemy uruchomić zdalne wdrożenie poprzez Deployer w sposób pokazany powyżej. W ten sposób możesz w pełni zautomatyzować wdrożenie swojej aplikacji na potencjalną produkcję.
Przejdźmy do kolejnego tematu – skalowania klastra Kubernetes. Należy pamiętać, że polecenie kubectl jest poleceniem skalowania. Przy większej pomocy możemy łatwo zwiększyć liczbę replik w naszym istniejącym klastrze. Jednak w praktyce zazwyczaj chcemy zwiększyć liczbę węzłów, a nie podów.
Jednocześnie w godzinach pracy może być konieczne zwiększenie, a w nocy, aby obniżyć koszty usług Amazon, może zaistnieć potrzeba zmniejszenia liczby uruchomionych instancji aplikacji. Nie oznacza to jednak, że wystarczy skalowanie samej liczby podów, bo nawet jeśli jeden z węzłów będzie bezczynny, i tak trzeba będzie za to zapłacić Amazonowi. Oznacza to, że wraz ze skalowaniem podów konieczne będzie skalowanie liczby używanych maszyn.
Może to być wyzwaniem, ponieważ niezależnie od tego, czy korzystamy z Amazona, czy innej usługi w chmurze, Kubernetes nie wie nic o liczbie używanych maszyn. Brakuje narzędzia umożliwiającego skalowanie systemu na poziomie węzła.
Będziemy więc musieli zadbać zarówno o węzły, jak i strąki. W łatwy sposób możemy skalować uruchamianie nowych węzłów wykorzystując AWS API i maszyny grupy Scaling w celu skonfigurowania liczby węzłów workerowych Kubernetes. Możesz także użyć Cloud-init lub podobnego skryptu, aby zarejestrować węzły w klastrze Kubernetes.
Nowa maszyna startuje w grupie Skalowanie, inicjuje się jako węzeł, rejestruje się w rejestrze mastera i rozpoczyna pracę. Następnie możesz zwiększyć liczbę replik do użycia w powstałych węzłach. Skalowanie w dół wymaga większego wysiłku, gdyż trzeba mieć pewność, że taki krok nie doprowadzi do zniszczenia już działających aplikacji po wyłączeniu „niepotrzebnych” maszyn. Aby zapobiec takiemu scenariuszowi, należy ustawić węzły w stan „nieplanowany”. Oznacza to, że domyślny program planujący zignoruje te węzły podczas planowania podów DaemonSet. Program planujący nie usunie niczego z tych serwerów, ale także nie uruchomi tam żadnych nowych kontenerów. Następnym krokiem jest wyparcie węzła drenażowego, czyli przeniesienie z niego działających podów na inną maszynę lub inne węzły, które mają do tego wystarczającą pojemność. Po upewnieniu się, że w tych węzłach nie ma już żadnych kontenerów, możesz usunąć je z Kubernetes. Po tym dla Kubernetesa po prostu przestaną istnieć. Następnie musisz użyć API AWS, aby wyłączyć niepotrzebne węzły lub maszyny.
Możesz użyć Amdatu Scalerd, innego narzędzia skalującego typu open source, podobnego do API AWS. Zapewnia interfejs CLI umożliwiający dodawanie lub usuwanie węzłów w klastrze. Jego interesującą funkcją jest możliwość skonfigurowania harmonogramu za pomocą poniższego pliku json.
Pokazany kod zmniejsza pojemność klastra o połowę w porze nocnej. Konfiguruje zarówno liczbę dostępnych replik, jak i pożądaną pojemność klastra Amazon. Korzystanie z tego harmonogramu automatycznie zmniejszy liczbę węzłów w nocy i zwiększy je rano, oszczędzając koszty korzystania z węzłów z usługi w chmurze, takiej jak Amazon. Ta funkcja nie jest wbudowana w Kubernetes, ale użycie Scalerda umożliwi skalowanie tej platformy w dowolny sposób.
Chciałbym zauważyć, że wiele osób mówi mi: „Wszystko w porządku, ale co z moją bazą danych, która zwykle jest statyczna?” Jak uruchomić coś takiego w dynamicznym środowisku, takim jak Kubernetes? Moim zdaniem nie należy tego robić, nie należy próbować prowadzić hurtowni danych w Kubernetesie. Jest to technicznie możliwe, a w Internecie są tutoriale na ten temat, ale poważnie skomplikuje Ci to życie.
Tak, w Kubernetesie istnieje koncepcja trwałych magazynów i możesz spróbować uruchomić magazyny danych, takie jak Mongo lub MySQL, ale jest to dość pracochłonne zadanie. Wynika to z faktu, że hurtownie danych nie w pełni obsługują interakcję z dynamicznym środowiskiem. Większość baz danych wymaga znacznej konfiguracji, łącznie z ręczną konfiguracją klastra, nie lubi autoskalowania i innych podobnych rzeczy.
Nie warto zatem komplikować sobie życia próbując uruchomić hurtownię danych w Kubernetesie. Zorganizuj swoją pracę w tradycyjny sposób, korzystając ze znanych usług i po prostu zapewnij Kubernetesowi możliwość korzystania z nich.
Na zakończenie tematu chciałbym przedstawić Państwu platformę Cloud RTI opartą na Kubernetesie, nad którą pracuje mój zespół. Zapewnia scentralizowane rejestrowanie, monitorowanie aplikacji i klastrów oraz wiele innych przydatnych funkcji, które się przydadzą. Do monitorowania wyświetlania wykorzystuje różne narzędzia typu open source, takie jak Grafana.
Pojawiło się pytanie, po co używać modułu równoważenia obciążenia ha-proxy z Kubernetesem. Dobre pytanie, ponieważ obecnie istnieją 2 poziomy równoważenia obciążenia. Usługi Kubernetes nadal znajdują się na wirtualnych adresach IP. Nie można ich używać do portów na zewnętrznych hostach, ponieważ jeśli Amazon przeciąży swojego hosta w chmurze, adres się zmieni. Właśnie dlatego umieszczamy ha-proxy przed usługami – aby stworzyć bardziej statyczną strukturę umożliwiającą bezproblemową komunikację ruchu z Kubernetesem.
Kolejnym dobrym pytaniem jest to, w jaki sposób można zadbać o zmiany schematu bazy danych podczas wdrażania niebieskiego/zielonego? Faktem jest, że niezależnie od wykorzystania Kubernetesa, zmiana schematu bazy danych jest trudnym zadaniem. Musisz upewnić się, że stary i nowy schemat są kompatybilne, po czym możesz zaktualizować bazę danych, a następnie zaktualizować same aplikacje. Możesz wymieniać bazę danych na gorąco, a następnie aktualizować aplikacje. Znam osoby, które uruchomiły zupełnie nowy klaster bazy danych z nowym schematem. Jest to opcja, jeśli masz bazę danych bez schematów, taką jak Mongo, ale i tak nie jest to łatwe zadanie. Jeżeli nie mają Państwo dalszych pytań, dziękujemy za uwagę!
Kilka reklam 🙂
Dziękujemy za pobyt z nami. Podobają Ci się nasze artykuły? Chcesz zobaczyć więcej ciekawych treści? Wesprzyj nas składając zamówienie lub polecając znajomym, , unikalny odpowiednik serwerów klasy podstawowej, który został przez nas wymyślony dla Ciebie: (dostępne z RAID1 i RAID10, do 24 rdzeni i do 40 GB DDR4).
Dell R730xd 2 razy taniej w centrum danych Equinix Tier IV w Amsterdamie? Tylko tutaj w Holandii! Dell R420 — 2x E5-2430 2.2 GHz 6C 128 GB DDR3 2x960 GB SSD 1 Gb/s 100 TB — od 99 USD! Czytać o
Źródło: www.habr.com