Wdrożenie Canary w Kubernetes nr 1: Gitlab CI

Będziemy używać Gitlab CI i ręcznego GitOps do wdrożenia i wykorzystania wdrożenia Canary w Kubernetesie

Artykuły z tej serii:

• (Ten artykuł)
• Wdrożenie Canary przy użyciu ArgoCI
• Wdrożenie Canary przy użyciu Istio
• Wdrożenie Canary przy użyciu Jenkins-X Istio Flagger

Wdrożenie Canary wykonamy ręcznie poprzez GitOps i utworzymy/modyfikujemy główne zasoby Kubernetes. Ten artykuł ma na celu przede wszystkim wprowadzenie z tym, jak przebiega wdrożenie w Kubernetes Canary, ponieważ istnieją skuteczniejsze metody automatyzacji, które rozważymy w kolejnych artykułach.

https://www.norberteder.com/canary-deployment/

Wdrożenie na Wyspach Kanaryjskich

W przypadku strategii Canary aktualizacje są najpierw stosowane tylko do podzbioru użytkowników. Poprzez monitorowanie, rejestrowanie danych, testy ręczne lub inne kanały przesyłania opinii, wydanie jest testowane przed udostępnieniem wszystkim użytkownikom.

Wdrożenie Kubernetes (aktualizacja ciągła)

Domyślną strategią wdrożenia Kubernetes jest aktualizacja stopniowa, podczas której uruchamiana jest określona liczba podów z nowymi wersjami obrazów. Jeśli zostały utworzone bez problemów, pody ze starymi wersjami obrazów są kończone i równolegle tworzone są nowe pody.

GitOps

W tym przykładzie używamy GitOps, ponieważ:

• używając Gita jako pojedynczego źródła prawdy
• używamy Git Operations do kompilacji i wdrażania (nie są potrzebne żadne polecenia inne niż git tag/merge)

Przykład

Przyjmijmy dobrą praktykę – posiadanie jednego repozytorium na kod aplikacji i jedno na infrastrukturę.

Repozytorium aplikacji

To bardzo proste API Python+Flask, które zwraca odpowiedź w formacie JSON. Zbudujemy pakiet za pośrednictwem GitlabCI i wypchniemy wynik do rejestru Gitlab. W rejestrze mamy dwie różne wersje wydania:

• wuestkamp/k8s-deployment-example-app:v1
• wuestkamp/k8s-deployment-example-app:v2

Jedyną różnicą między nimi jest zmiana w zwracanym pliku JSON. Używamy tej aplikacji, aby jak najłatwiej wizualizować, z którą wersją się komunikujemy.

Repozytorium infrastruktury

W tej rzepie będziemy wdrażać poprzez GitlabCI do Kubernetes, .gitlab-ci.yml wygląda tak:

image: traherom/kustomize-docker

before_script:
   - printenv
   - kubectl version

stages:
 - deploy

deploy test:
   stage: deploy
   before_script:
     - echo $KUBECONFIG
   script:
     - kubectl get all
     - kubectl apply -f i/k8s

   only:
     - master

Aby uruchomić go samodzielnie, będziesz potrzebować klastra, możesz użyć Gcloud:

gcloud container clusters create canary --num-nodes 3 --zone europe-west3-b

gcloud compute firewall-rules create incoming-80 --allow tcp:80

Musisz rozwidlić https://gitlab.com/wuestkamp/k8s-deployment-example-canary-infrastructure i utwórz zmienną KUBECONFIG w GitlabCI, który będzie zawierał konfigurację dostępu kubectl do swojego klastra.

Możesz przeczytać o tym, jak uzyskać dane uwierzytelniające dla klastra (Gcloud) tutaj.

Infrastruktura Yaml

W repozytorium infrastruktury mamy usługę:

apiVersion: v1
kind: Service
metadata:
 labels:
   id: app
 name: app
spec:
 ports:
 - port: 80
   protocol: TCP
   targetPort: 5000
 selector:
   id: app
 type: LoadBalancer

I wdrożenie w deploy.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
 name: app
spec:
 replicas: 10
 selector:
   matchLabels:
     id: app
     type: main
 template:
   metadata:
     labels:
       id: app
       type: main
   spec:
     containers:
     - image: registry.gitlab.com/wuestkamp/k8s-deployment-example-app:v1
       name: app
       resources:
         limits:
           cpu: 100m
           memory: 100Mi

I kolejne wdrożenie w deploy-canary.yaml:

kind: Deployment
metadata:
 name: app-canary
spec:
 replicas: 0
 selector:
   matchLabels:
     id: app
     type: canary
 template:
   metadata:
     labels:
       id: app
       type: canary
   spec:
     containers:
     - image: registry.gitlab.com/wuestkamp/k8s-deployment-example-app:v2
       name: app
       resources:
         limits:
           cpu: 100m
           memory: 100Mi

Należy pamiętać, że aplikacja App-Deploy nie ma jeszcze zdefiniowanych żadnych replik.

Przeprowadzanie wstępnego wdrożenia

Aby rozpocząć wstępne wdrożenie, możesz ręcznie uruchomić potok GitlabCI w gałęzi głównej. Po tym kubectl powinien wypisać co następuje:

Widzimy app wdrożenie z 10 replikami i app-canary z 0. Istnieje również LoadBalancer, z którego możemy uzyskać dostęp poprzez curl poprzez zewnętrzny adres IP:

while true; do curl -s 35.198.149.232 | grep label; sleep 0.1; done

Widzimy, że nasza aplikacja testowa zwraca tylko „v1”.

Wykonywanie wdrożenia Canary

Krok 1: wypuść nową wersję dla niektórych użytkowników

W pliku Deploy-canary.yaml i obrazie nowej wersji ustawiamy liczbę replik na 1:

kind: Deployment
metadata:
 name: app-canary
spec:
 replicas: 1
 selector:
   matchLabels:
     id: app
     type: canary
 template:
   metadata:
     labels:
       id: app
       type: canary
   spec:
     containers:
     - image: registry.gitlab.com/wuestkamp/k8s-deployment-example-app:v2
       name: app
       resources:
         limits:
           cpu: 100m
           memory: 100Mi

W pliku deploy.yaml zmieniliśmy liczbę replik na 9:

kind: Deployment
metadata:
 name: app
spec:
 replicas: 9
 selector:
   matchLabels:
     id: app
...

Wrzucamy te zmiany do repozytorium, z którego rozpocznie się wdrożenie (poprzez GitlabCI) i zobaczymy w efekcie:

Nasza usługa wskaże oba wdrożenia, ponieważ oba mają selektor aplikacji. Ze względu na domyślną randomizację Kubernetesa powinniśmy zobaczyć różne odpowiedzi w przypadku ~10% żądań:

Obecny stan naszej aplikacji (GitOps, zaczerpnięty z Git as a Single Source Of Truth) to obecność dwóch wdrożeń z aktywnymi replikami, po jednym dla każdej wersji.

~10% użytkowników zapoznaje się z nową wersją i niechcący ją testuje. Nadszedł czas na sprawdzenie błędów w logach i monitorowanie danych w celu znalezienia problemów.

Krok 2: Wydaj nową wersję wszystkim użytkownikom

Zdecydowaliśmy, że wszystko poszło dobrze i teraz musimy udostępnić nową wersję wszystkim użytkownikom. Aby to zrobić, po prostu aktualizujemy deploy.yaml instalując nową wersję obrazu i liczbę replik równą 10. In deploy-canary.yaml ustawiamy liczbę replik z powrotem na 0. Po wdrożeniu wynik będzie następujący:

Reasumując

W moim przypadku ręczne uruchomienie wdrożenia w ten sposób pomaga zrozumieć, jak łatwo można je skonfigurować za pomocą k8s. Ponieważ Kubernetes umożliwia aktualizację wszystkiego za pośrednictwem interfejsu API, kroki te można zautomatyzować za pomocą skryptów.

Kolejną rzeczą wymagającą wdrożenia jest punkt wejścia testera (LoadBalancer lub poprzez Ingress), przez który można uzyskać dostęp tylko do nowej wersji. Można go używać do ręcznego przeglądania.

W przyszłych artykułach sprawdzimy inne zautomatyzowane rozwiązania, które realizują większość tego, co zrobiliśmy.

Przeczytaj także inne artykuły na naszym blogu:

• Do czego doprowadziła migracja z ClickHouse bez autoryzacji do ClickHouse z autoryzacją?
• Budowa dynamicznych modułów dla Nginx
• Zaktualizuj nxs-build-tools - asystenta w budowaniu pakietów deb i RPM
• Wprowadzenie do autoryzacji Kubernetes Konsula Hashicorp
• Z czym musieliśmy się zmierzyć korzystając z narzędzia Csync2
• Bot telegramowy dla Redmine. Jak uprościć życie sobie i innym

Źródło: www.habr.com