Notatka tłumaczenie: Ten przegląd z Weaveworks przedstawia najpopularniejsze strategie wdrażania aplikacji i pokazuje, jak te najbardziej zaawansowane można wdrożyć za pomocą operatora Kubernetes Flagger. Jest napisany prostym językiem i zawiera diagramy wizualne, które pozwalają nawet początkującym inżynierom zrozumieć zagadnienie.
Schemat pochodzi z strategie rolloutu wykonane w Container Solutions
Jednym z największych wyzwań stojących obecnie przed tworzeniem natywnych aplikacji chmurowych jest przyspieszenie wdrażania. W podejściu mikroserwisowym programiści już pracują i projektują całkowicie modułowe aplikacje, umożliwiając różnym zespołom jednoczesne pisanie kodu i wprowadzanie zmian w aplikacji.
Krótsze i częstsze wdrożenia mają następujące zalety:
- Czas wprowadzenia produktu na rynek jest skrócony.
- Nowe funkcje szybciej docierają do użytkowników.
- Informacje zwrotne od użytkowników szybciej docierają do zespołu programistów. Oznacza to, że zespół może szybciej dodawać funkcje i naprawiać problemy.
- Wzrasta morale programistów: praca z większą liczbą funkcji w fazie rozwoju jest przyjemniejsza.
Jednak wraz ze wzrostem częstotliwości wydań zwiększają się również szanse na negatywny wpływ na niezawodność aplikacji lub wygodę użytkownika. Dlatego ważne jest, aby zespoły operacyjne i DevOps budowały procesy i zarządzały strategiami wdrażania w sposób minimalizujący ryzyko dla produktu i użytkowników. (Możesz dowiedzieć się więcej o automatyzacji potoków CI/CD .)
W tym poście omówimy różne strategie wdrażania w Kubernetes, w tym wdrożenia kroczące i bardziej zaawansowane metody, takie jak rollouty typu canary i ich odmiany.
Strategie wdrażania
Istnieje kilka różnych typów strategii wdrażania, których można użyć w zależności od celu. Na przykład może być konieczne wprowadzenie zmian w określonym środowisku w celu dalszych testów lub w podzbiorze użytkowników/klientów, lub może być konieczne przeprowadzenie ograniczonych testów z użytkownikami przed wprowadzeniem funkcji publiczny.
Rolling (stopniowe, „rollingowe” wdrażanie)
Jest to standardowa strategia wdrażania w Kubernetes. Stopniowo, jeden po drugim, zastępuje pody ze starą wersją aplikacji podami z nową wersją – bez przestojów klastra.
Kubernetes czeka, aż nowe pody będą gotowe do pracy (sprawdzając je za pomocą ), zanim zaczniesz zwijać stare. Jeśli wystąpi problem, tę aktualizację kroczącą można przerwać bez zatrzymywania całego klastra. W pliku YAML opisującym typ wdrożenia nowy obraz zastępuje stary obraz:
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: awesomeapp
spec:
replicas: 3
template:
metadata:
labels:
app: awesomeapp
spec:
containers:
- name: awesomeapp
image: imagerepo-user/awesomeapp:new
ports:
- containerPort: 8080Parametry aktualizacji rollover można określić w pliku manifestu:
spec:
replicas: 3
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
template:
...
Odtwarzać
W tym najprostszym typie wdrożenia stare kapsuły są zabijane jednocześnie i zastępowane nowymi:
Odpowiedni manifest wygląda mniej więcej tak:
spec:
replicas: 3
strategy:
type: Recreate
template:
...Niebieski/zielony (wdrożenia niebiesko-zielone)
Strategia wdrażania niebiesko-zielonego (czasami nazywana także czerwono/czarną) polega na jednoczesnym wdrożeniu starej (zielonej) i nowej (niebieskiej) wersji aplikacji. Po opublikowaniu obu wersji zwykli użytkownicy mają dostęp do zielonej, natomiast niebieska jest dostępna dla zespołu QA w celu automatyzacji testów poprzez osobną usługę lub bezpośrednie przekierowanie portów:
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: awesomeapp-02
spec:
template:
metadata:
labels:
app: awesomeapp
version: "02"Po przetestowaniu wersji niebieskiej (nowej) i zatwierdzeniu jej wydania, usługa przełącza się na nią, a wersja zielona (stara) jest składana:
apiVersion: v1
kind: Service
metadata:
name: awesomeapp
spec:
selector:
app: awesomeapp
version: "02"
...Kanarek (wdrożenia na Wyspach Kanaryjskich)
Wdrożenia Canary są podobne do wdrożeń niebiesko-zielonych, ale zapewniają lepszą kontrolę i użytkowanie podejście krok po kroku. Ten typ obejmuje kilka różnych strategii, w tym „ukryte” premiery i testy A/B.
Strategię tę stosuje się, gdy istnieje potrzeba wypróbowania jakiejś nowej funkcjonalności, zwykle w backendzie aplikacji. Istotą tego podejścia jest stworzenie dwóch niemal identycznych serwerów: jeden obsługuje prawie wszystkich użytkowników, a drugi, z nowymi funkcjami, obsługuje tylko niewielką podgrupę użytkowników, po czym porównuje się wyniki ich pracy. Jeśli wszystko przebiegnie bez błędów, nowa wersja będzie sukcesywnie wdrażana na całą infrastrukturę.
Chociaż tę strategię można wdrożyć wyłącznie przy użyciu Kubernetesa, zastępując stare pody nowymi, znacznie wygodniej i prościej jest korzystać z siatki usług takiej jak Istio.
Na przykład możesz mieć dwa różne manifesty w Git: zwykły manifest ze znacznikiem 0.1.0 i kanaryjski manifest ze znacznikiem 0.2.0. Zmieniając wagi w manifeście bramy wirtualnej Istio, możesz kontrolować rozkład ruchu między tymi dwoma wdrożeniami:
Aby zapoznać się z przewodnikiem krok po kroku dotyczącym wdrażania wdrożeń Canary przy użyciu Istio, zobacz . (Notatka. przeł.: Przetłumaczyliśmy także materiały na temat wdrożeń kanarek na Istio .)
Wdrożenia Canary za pomocą narzędzia Weaveworks Flagger
pozwala łatwo i efektywnie zarządzać rolloutami Canary.
Flagger automatyzuje pracę z nimi. Wykorzystuje Istio lub AWS App Mesh do kierowania i przełączania ruchu oraz metryki Prometheus do analizy wyników. Dodatkowo analizę wdrożeń Canary można uzupełnić webhookami w celu przeprowadzenia testów akceptacyjnych, testów obciążeniowych i wszelkich innych rodzajów kontroli.
Na podstawie wdrożenia Kubernetes i, jeśli to konieczne, poziomego skalowania podów (HPA), Flagger tworzy zestawy obiektów (wdrożenia Kubernetes, usługi ClusterIP i usługi wirtualne Istio lub App Mesh) w celu analizy i wdrożenia wdrożeń kanaryjskich:
Implementacja pętli sterującej (pętla sterująca),Flagger stopniowo przełącza ruch na serwer Canary, jednocześnie mierząc kluczowe wskaźniki wydajności, takie jak procent udanych żądań HTTP, średni czas trwania żądania i stan podów. Na podstawie analizy KPI (Key Performance Indicators) kanarek albo rośnie, albo zapada się, a wyniki analizy publikowane są w Slacku. Opis i demonstrację tego procesu można znaleźć w materiale .
Wdrożenia ciemne (ukryte) lub A/B
Wdrożenie w ukryciu to kolejna odmiana strategii kanaryjskiej (z którą, nawiasem mówiąc, Flagger może również pracować). Różnica między wdrożeniami typu stealth i canary polega na tym, że wdrożenia typu stealth dotyczą frontendu, a nie backendu, jak wdrożenia canary.
Inna nazwa tych wdrożeń to testy A/B. Zamiast udostępniać nową funkcję wszystkim użytkownikom, jest ona oferowana tylko ograniczonej części z nich. Zazwyczaj ci użytkownicy nie są świadomi, że są pionierami w testowaniu (stąd określenie „wdrożenie ukryte”).
Korzystanie z przełączników funkcjonalnych (przełącznik funkcji) i innymi narzędziami, możesz monitorować sposób, w jaki użytkownicy wchodzą w interakcję z nową funkcją, czy są nią zainteresowani, czy nowy interfejs użytkownika jest dla nich mylący, oraz inne rodzaje wskaźników.
Wdrożenia Flaggera i A/B
Oprócz routingu opartego na wadze, Flagger może również kierować ruch do serwera Canary w oparciu o parametry HTTP. W testach A/B możesz używać nagłówków HTTP lub plików cookie, aby dotrzeć do określonego segmentu użytkowników. Jest to szczególnie skuteczne w przypadku aplikacji frontendowych, które wymagają powiązania sesji z serwerem (powinowactwo sesji). Więcej informacji można znaleźć w dokumentacji Flaggera.
Autor jest wdzięczny , inżynierowi Weaveworks (i twórcy Flaggera), za te wszystkie niesamowite wzorce wdrażania.
PS od tłumacza
Przeczytaj także na naszym blogu:
- «";
- «";
- «";
- «".
Źródło: www.habr.com