Przyp. tłum.: Ten materiał przeglądowy od Weaveworks przedstawia najpopularniejsze strategie wdrażania aplikacji i omawia możliwość ich zaawansowanej realizacji za pomocą operatora Kubernetes Flagger. Został napisany prostym językiem i zawiera przejrzyste schematy, które pomagają zrozumieć temat nawet początkującym inżynierom.
Schemat pochodzi z strategii wdrażania, przygotowanego przez Container Solutions
Jednym z największych wyzwań przy tworzeniu aplikacji cloud native jest dziś przyspieszenie procesu wdrażania. Przy podejściu mikroserwisowym programiści pracują już z całkowicie modułowymi aplikacjami i projektują je, 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:
- Skraca się czas wprowadzenia na rynek.
- Nowe funkcje szybciej trafiają do użytkowników.
- Opinie użytkowników szybciej docierają do zespołu deweloperów, co oznacza, że zespół może szybciej uzupełniać funkcje i naprawiać problemy.
- Zwiększa się morale programistów: z większą liczbą funkcji w opracowaniu pracuje się bardziej interesująco.
Jednak zwiększona częstotliwość wydań podnosi również ryzyko negatywnego wpływu na niezawodność aplikacji lub doświadczenie użytkownika. Dlatego zespoły operacyjne i DevOps muszą budować procesy i zarządzać strategiami wdrażania w taki sposób, aby zminimalizować ryzyko dla produktu i użytkowników. (Dowiedz się więcej o automatyzacji pipeline'a CI/CD .)
W tej publikacji omówimy różne strategie wdrażania w Kubernetes, w tym wdrożenia typu rolling oraz bardziej zaawansowane metody, takie jak wdrożenia kanaryjskie i ich warianty.
Strategie wdrażania
Istnieje kilka różnych typów strategii wdrażania, które można wykorzystać w zależności od celu. Na przykład, może być konieczne wprowadzenie zmian w pewnym środowisku dla dalszego testowania, w subgrupie użytkowników/klientów lub przeprowadzenie ograniczonego testu na użytkownikach przed udostępnieniem pewnej funkcji publicznie.
Rolling (stopniowe, "nakładane" wdrożenie)
To standardowa strategia wdrażania w Kubernetes. Stopniowo, jeden po drugim, zastępuje pod'y ze starą wersją aplikacji pod'ami z nową wersją - bez przestojów klastra.
Kubernetes czeka na gotowość nowych pod'ów do pracy (sprawdzając je za pomocą ), zanim przystąpi do wycofywania starych. Jeśli wystąpi problem, takie wdrożenie można przerwać, nie zatrzymując 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 wdrażania można sprecyzować w pliku manifestu:
spec:
replicas: 3
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
template:
...
Recreate (przywrócenie)
W tym najprostszym typie wdrożenia stare pod'y są eliminowane wszystkie naraz i zastępowane nowymi:
Odpowiedni manifest wygląda mniej więcej tak:
spec:
replicas: 3
strategy:
type: Recreate
template:
...Blue/Green (wdrożenia niebiesko-zielone)
Strategia wdrożenia niebiesko-zielonego (czasami nazywana również czerwono/czarną) zakłada jednoczesne wdrożenie starej (zielonej) i nowej (niebieskiej) wersji aplikacji. Po umieszczeniu obu wersji zwykli użytkownicy mają dostęp do zielonej, podczas gdy niebieska jest dostępna dla zespołu QA do automatyzacji testów przez oddzielną 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 niebieskiej (nowej) wersji i zatwierdzeniu jej wydania, usługa przełącza się na nią, a zielona (stara) jest wycofywana:
apiVersion: v1
kind: Service
metadata:
name: awesomeapp
spec:
selector:
app: awesomeapp
version: "02"
...Canary (wdrożenia kanarowe)
Wdrożenia kanarowe są podobne do niebiesko-zielonych, ale lepiej zarządzane i wykorzystują stopniowy podział. Do tego typu należy kilka różnych strategii, w tym «ukryte» uruchomienia oraz testy A/B.
Ta strategia jest stosowana, gdy konieczne jest przetestowanie nowej funkcjonalności, zazwyczaj w backendzie aplikacji. Istotą podejścia jest stworzenie dwóch praktycznie identycznych serwerów: jeden obsługuje prawie wszystkich użytkowników, a drugi, z nowymi funkcjami, obsługuje tylko małą podgrupę użytkowników, po czym wyniki ich pracy są porównywane. Jeśli wszystko przebiega bez błędów, nowa wersja jest stopniowo wdrażana w całej infrastrukturze.
Chociaż tę strategię można zrealizować wyłącznie za pomocą Kubernetes, zastępując stare pod’y nowymi, znacznie wygodniej i łatwiej jest użyć service mesh, takiego jak Istio.
Na przykład możesz mieć dwa różne manifesty w Git: zwykły z tagiem 0.1.0 i "kanarkowy" z tagiem 0.2.0. Zmieniając wagi w manifeście wirtualnej bramy Istio, można zarządzać rozdzielaniem ruchu między tymi dwoma deployment’ami:
Krok po kroku przewodnik dotyczący realizacji kanarkowych wdrożeń za pomocą Istio można znaleźć w materiale . (Przyp. tłum.: Przetłumaczyliśmy również materiał dotyczący kanarkowych wdrożeń w Istio .)
Kanarkowe wdrożenia z Weaveworks Flagger
umożliwia łatwe i efektywne zarządzanie kanarkowymi wdrożeniami.
Flagger automatyzuje ich działanie. Wykorzystuje Istio lub AWS App Mesh do routingu i przełączania ruchu, a także metryki Prometheus do analizy wyników. Ponadto, analizę kanarkowych wdrożeń można wzbogacić o webhooki do przeprowadzania testów akceptacyjnych, obciążeniowych i innych rodzajów weryfikacji.
Na podstawie deployment’u Kubernetes i, w razie potrzeby, poziomej skalowania pod’ów (HPA), Flagger tworzy zbiory obiektów (deployment’y Kubernetes, usługi ClusterIP i wirtualne usługi Istio lub App Mesh) do analizy i realizacji kanarkowych wdrożeń:
Wdrażając kontur zarządzania (control loop), Flagger stopniowo przełącza ruch na kanarkowy serwer, jednocześnie mierząc kluczowe wskaźniki wydajności, takie jak odsetek udanych żądań HTTP, średni czas trwania żądania i zdrowie pod’ów. Na podstawie analizy KPI (kluczowych wskaźników wydajności) część kanarkowa albo rośnie, albo się zmniejsza, a wyniki analizy są publikowane w Slacku. Opis i demonstrację tego procesu można znaleźć w materiale .
Ciemne (ukryte) lub wdrożenia A/B
Ukryte wdrożenie to kolejna wariacja strategii canary (z którą, nawiasem mówiąc, Flagger też może współpracować). Różnica między ukrytym a wdrożeniem canary polega na tym, że ukryte wdrożenia dotyczą frontendu, a nie backendu, jak w przypadku canary.
Inna nazwa tych wdrożeń to testy A/B. Zamiast udostępniać nową funkcję wszystkim użytkownikom, oferuje się ją jedynie ograniczonej ich grupie. Zazwyczaj ci użytkownicy nie zdają sobie sprawy, że są testerami-pionierami (stąd termin „ukryte wdrożenie”).
Za pomocą przełączników funkcjonalności (feature toggles) i innych narzędzi można monitorować, jak użytkownicy wchodzą w interakcję z nową funkcją, czy ich przyciąga, czy uważają nowy interfejs użytkownika za nieczytelny oraz inne typy metryk.
Flagger i wdrożenia A/B
Oprócz routingu na podstawie wag, Flagger może także kierować ruch do serwera canary w zależności od parametrów HTTP. W testach A/B można używać nagłówków HTTP lub plików cookie do przekierowania określonego segmentu użytkowników. Jest to szczególnie skuteczne w przypadku aplikacji frontendowych, które wymagają przypisania sesji do serwera (session affinity). Dodatkowe informacje można znaleźć w dokumentacji Flagger.
Autor wyraża wdzięczność , inżynierowi Weaveworks (i twórcy Flaggera), za wszystkie te niesamowite schematy wdrożenia.
P.S. od tłumacza
Przeczytaj także na naszym blogu:
- «»;
- «»;
- «»;
- «».
Źródło: habr.com
