Keptn Lifecycle Toolkit (KLT)

Use Cases dla KLT:

1. Continuous Deployment and Delivery (CI/CD):
1. Automatyzacja procesu wdrażania aplikacji, minimalizując ryzyko błędów
2. Integracja z narzędziami CI/CD jak Jenkins, GitLab CI/CD
2. Automated Quality Gates:
1. Definiowanie i egzekwowanie kryteriów jakościowych przed wdrożeniem nowej wersji aplikacji
2. Automatyczne testowanie i weryfikacja zgodności z wymaganiami
3. Performance Monitoring:
1. Ciągłe monitorowanie wydajności aplikacji po wdrożeniu
2. Integracja z narzędziami monitorującymi jak Dynatrace, Prometheus, Grafana
4. Incident Management:
1. Automatyzacja zarządzania incydentami, szybka identyfikacja i rozwiązanie problemów
2. Integracja z systemami zarządzania incydentami jak Jira, ServiceNow
5. Rollback and Recovery:
1. Szybkie wycofywanie nieudanych wdrożeń do poprzedniej stabilnej wersji
2. Automatyzacja procesu przywracania systemu do stanu sprzed awarii
6. Service Level Objectives (SLOs):
1. Definiowanie i monitorowanie celów poziomu usług
2. Automatyczne reagowanie na naruszenia SLO, aby zapewnić ciągłość działania

Keptn Lifecycle Toolkit upraszcza i automatyzuje zarządzanie cyklem życia oprogramowania, co przyczynia się do zwiększenia efektywności operacyjnej i jakości dostarczanych aplikacji.

Keptn Quality Gates

Keptn Quality Gates oferują deklaratywny sposób definiowania kryteriów jakości usług. Keptn zbiera i ocenia te kryteria, aby zdecydować, czy nowa wersja aplikacji może zostać promowana do następnego etapu, czy musi zostać zatrzymana.

Proces oceny quality gate w Keptn opiera się na koncepcjach Wskaźników Poziomu Usług (SLI) i Celów Poziomu Usług (SLO). Umożliwia to deklaratywne określenie pożądanych celów jakości dla aplikacji i usług.

Definiowanie dostawców danych

Wszystko w Keptn jest konfigurowane za pomocą zasobów Kubernetes. Keptn pobiera wartości SLI (Service-Level Indicator ) od dostawców danych, takich jak Prometheus, Dynatrace czy Datadog, ocenia je w kontekście zdefiniowanych SLO (Service Level Objective),i zwraca wynik, który może być automatycznie przetworzony przez istniejący pipeline CD lub przez użytkownika, który ręcznie zdecyduje o dalszych krokach (np. promowanie do produkcji lub odesłanie do programisty w celu wprowadzenia poprawek).

Jak to działa w praktyce: Definiujemy w Keptn z jakich źródeł danych monitorowania ma korzystać dodając zasoby do KeptnMetricsProvider do naszego klastra Kubernetes. Dla nas będzie to Dynatrace.

SLI

Gdy już zdefiowaliśmy naszego providera musimy powiedzieć KEPTN-owi jaki SLI chcemy monitorować i jak je pobrać z Dynatrace. Robi się to za pomocą AnalysisValueTemplate. AnalysisValueTemplate definuje Service Level Indicator (SLI), który identyfikuje dane do analizy przez źródło danych do użycia i zapytanie do wydania. Jedna analiza może używać danych z wielu AnalysisValueTemplates.

W tym artykule utworzymy dwa zasoby AnalysisValueTemplate. Pierwszy sprawdza czy nasze środowisko ma zasoby aby wdrożyć nową wersje aplikacji (zasoby procesora, pamięci).

Drugim miernikiem będzie sprawdzanie czy nasza aplikacja po wdrożeniu nowej wersji spełnia nasze standardy (error-rate, reponse-time dla różnych percentyli i throughput).

Jak widać w spec.query polu powyższego zasobu, AnalysisValueTemplate zasoby obsługują składnię szablonów Go . Dzięki temu możesz uwzględnić w zapytaniu placeholder’s, które zostaną zastąpione w momencie pobierania konkretnych metryk. Jest to bardzo przydatne rozwiązanie na przykład gdy chcemy używać jednego template np. zapytanie o metryki jest takie samo dla różnych aplikacji. Dzięki temu nie trzeba tworzyć AnalysisValueTemplate zasobu na każde obciążenie, ale można go ponownie wykorzystać do różnych obciążeń i przekazać wartość rzeczywistego obciążenia w momencie wykonywania analizy czy też przekazywać które aplikacje mają być brane pod uwagę podczas analizy.

Definiowanie SLO

Następnym krokiem jest określenie naszych oczekiwań wobec Celów Poziomu Usług (SLO), czyli wyznaczenie celów, które chcemy osiągnąć. Można to zrobić za pomocą zasobu AnalysisDefinition, który wygląda następująco:

Ten zasób AnalysisDefinition zawiera cele, które odnoszą się do wcześniej stworzonych zasobów AnalysisValueTemplate. Jeśli przeanalizujemy go dokładnie zauważymy, że mogą one się różnić przypisanymi Wagami: np. weight: 2 co oznacza, że cel dotyczący poziomu błędów ma wyższy priorytet niż zużycie pamięci czy też procesora. W połączeniu z wynikami docelowymi zdefiniowanymi w sekcji totalScore oznacza to, że osiągnięcie celu dotyczącego poziomu błędów jest konieczne, aby analiza zakończyła się sukcesem lub przynajmniej osiągnęła stan ostrzegawczy. Stan ostrzegawczy można osiągnąć, jeśli na przykład cel dotyczący poziomu błędów zostanie spełniony, ale zużycie pamięci przekroczy ustalony limit 800M.

Warto zwrócić uwagę na to, że jedyne co musimy zdefiniować to AnalysisValueTemplate, oraz operatora metryk, skąd metryki zostaną pobrane, oraz które metryki zostaną pobrane i podane ewaluacji na podstawie informacji zawartych w KeptnMetricsProviders.

Wykonywanie analizy

Ostatnim etapem konfiguracji i wykorzystania Quality Gates W KEPTN jest uruchomienie analizy. Odbywa się to poprzez zastosowanie zasobu analizy który wygląda następująco:

Zastosowanie tego zasobu powoduje, że z Keptn:

• Pobierana jest AnalysisValueTemplate do którego odwołuje się ten, AnalysisDefinition który jest używany dla tej instancji analizy.
• Po pobraniu wartości cele AnalysisDefinition są oceniane i obliczany jest ogólny wynik
• W tej analizie wykorzystano wartości z ostatnich 5 min (ze względu na ustawienie spec.timeframe.recent na 5m). Alternatywnie możesz także określić konkretne ramy czasowe, korzystając z właściwości spec.timeframe.from oraz spec.timeframe .to.
• Udostępniamy również obciążenie argumentami do analizy, korzystając z spec.args właściwości. Argumenty przekazywane do analizy za pośrednictwem tej właściwości są używane podczas obliczania rzeczywistego zapytania przy użyciu ciągu szablonowego zasobu AnalysisValueTemplates. W naszym przypadku używamy tego w współczynniku błędów AnalysisValueTemplate , gdzie ustawiamy zapytanie na

builtin:service.errors.total.rate:splitBy():
avg&entitySelector=tag({{.service}}),type(SERVICE)

W przypadku naszego Analysis service ustawia na Easytravel . Wynikowe zapytanie to

builtin:service.errors.total.rate:splitBy():
avg&entitySelector=tag(Easytravel),type(SERVICE)

Sprawdzanie wyników

Po zastosowaniu Analysis zasobu możemy szybko sprawdzić jego stan za pomocą kubectl:

Dane wyjściowe tego polecenia informują nas, czy analiza została już ukończona. Jak widać powyżej analiza się zakończyła (STATE: Completed) oraz czy ewaluacja przeszła czy ma warning (u nas PASS: true)

Aby zagłębić się w wyniki i zobaczyć jakie informacje uzyskamy w statusie zasobu:

kubectl get analysis predeploy -n keptn -oyaml

To polecenie daje nam pełną reprezentację YAML Analysis:

Jak widać, daje nam to już znacznie więcej informacji, a najważniejszym elementem jest pole status.raw. Jest to reprezentacja JSON pobranych wartości i celów, które dla nich wyznaczyliśmy.

Status.raw jest tak naprawdę jsonem, który jest bardzo łatwy do czytania oraz konfiguracji

kubectl get analysis predeploy -n keptn -o=jsonpath='{.status.raw}' | jq

W obiekcie JSON widzimy:

• Lista celów, które zdefiniowaliśmy wcześniej w naszym AnalysisDefinition
• Wartości powiązanych metryk
• Rzeczywiste zapytanie użyte do pobrania danych z naszych źródeł danych monitorowania

Na tej podstawie każdemu celowi przypisuje się punktację równą wadze tego celu, jeśli cel został osiągnięty. Jeśli nie, cel otrzymuje ocenę 0. Warning Oprócz kryteriów możesz określić kryteria failure. Jeżeli tak jest i wartość metryki nie narusza kryteriów failure, ale kryteria ostrzegawcze, otrzymuje ocenę stanowiącą połowę wagi. Dzięki temu możesz jeszcze bardziej szczegółowo oceniać analizę. W naszym przypadku oba cele zostały osiągnięte, dzięki czemu otrzymujemy pełną liczbę punktów

Z racji, że zwrotka z analizy jest w postaci JSON, bardzo łatwo można ją formatować według własnych potrzeb i wykorzystać to jak chcemy.

Poniżej pokażę przykład prostego skryptu bash-owego który wyciąga scoring i czy nasza ewaluacja przeszła pomyślnie:

CI/CD Automatic Quality Gates

Mając to wszystko na uwadze z pomocą KEPTN-a i Quality Gates możemy stworzyć „niezniszczalne” potoki dostaw bazujące na różnych źródłach danych.

Wyobraźmy sobie taki scenariusz. Chcemy wdrożyć nową wersję aplikacji, przetestować ją, zweryfikować czy działą poprawnie i następnie promować ją na wyższe środowisko. Dzięki podejściu Gitopsowym i wykorzystaniu narzędzi takich jak KEPTN i Dynatrace możemy to zrobić w pełni automatycznie.

Poniżej screen z przykładowego wdrożenia:

Najpierw Quality Gates na podstawie metryk z Dynatrace sprawdza nam dostępność środowiska, czy CPU i pamięć nie są wysycone, oraz czy nie ma błędów, następnie deployujemy aplikacje na środowisku Przedprodukcyjnym, deployujemy konfiguracje Dynatrace za pomocą MONACO (link do blogu o Monaco), następują testy (jmetter, testy syntetyczne itp.), potem następuje evaluacja i ocenienie aplikacji na podstawie metryk z Dynatrace (response time, failurate, erros, throughput) jeśli uzyskamy wynik analizy który ustaliliśmy za akceptowalny to możemy wdrażać naszą nową wersje aplikacji na produkcji. Inny przykład, gdzie nasze środowsiko nie było odpowiednio przygotowane i Quality Gates zatrzymały wdrożenie po sprawdzeniu zasobów serwerowych:

Widzimy, że nasze środowisko nie spełniało zdefiniowanych przez nas progów, server nie był gotowy na wdrożenie nowej wersji aplikacji, więc KEPTN zatrzymał dalsze kroki pipelinu

Podsumowanie

W artykule zaprezentowałem jak można łatwo i szybko zdefiniować jedno lub wiele źródeł danych i pozwolić KEPTN-owi pobierać interesujące nas metryki. Stworznie przejsrzystego zestawu kryteriów jest łątwe i pozwala automatycznie ocenić stan testowanej usługi. Następnie przeprowadzona została analiza i interpretacja wyników. Udowodniono jak łatwo działać na plikach JSON które keptn dostarcza i przedstawiono przykład jak je wykorzystać oraz stworzylić przykładowy „niezniszczalny” pipline do wdrożeń przy wykorzystaniu narzędzia.

Wszystko to zrobiono wykorzystując manifesty Kubernetesa i umieszczając je w repozytorium GitOps obok manifestów naszej aplikacji.

Tomek jest Solution Consultant w Omnilogy. Jego praca skupia się na rozwiązaniu Dynatrace. Jego konikiem są automatyzacje.