🥇Wdrożenie Canary w Kubernetes #2: Wdrożenia Argo

Będziemy używać kontrolera wdrażania Argo Rollouts natywnego dla k8s i GitlabCI do uruchamiania wdrożeń Canary w Kubernetes

https://unsplash.com/photos/V41PulGL1z0

Artykuły z tej serii

Wdrożenie Canary w Kubernetes nr 1: Gitlab CI
(Ten artykuł)
Wdrożenie Canary przy użyciu Istio
Wdrożenie Canary przy użyciu Jenkins-X Istio Flagger

Wdrożenie na Wyspach Kanaryjskich

Mamy nadzieję, że czytasz pierwsza część, gdzie pokrótce wyjaśniliśmy, czym są wdrożenia Canary. Pokazaliśmy także, jak to wdrożyć, korzystając ze standardowych zasobów Kubernetesa.

Wdrożenia Argo

Argo Rollouts to natywny kontroler wdrażania Kubernetes. Zapewnia CRD (niestandardową definicję zasobów) dla Kubernetes. Dzięki niemu możemy skorzystać z nowego podmiotu: Rollout, który zarządza wdrożeniami blue-green i canary z różnymi opcjami konfiguracji.

Kontroler Argo Rollouts używany przez zasób niestandardowy Rollout, Umożliwia dodatkowe strategie wdrażania, takie jak niebiesko-zielony i kanarkowy dla Kubernetes. Ratunek Rollout zapewnia równoważną funkcjonalność Deployment, tylko z dodatkowymi strategiami wdrażania.
zasób Deployments ma dwie strategie wdrażania: RollingUpdate и Recreate. Chociaż strategie te są odpowiednie w większości przypadków, w przypadku wdrażania na serwerach na bardzo dużą skalę stosowane są dodatkowe strategie, takie jak niebiesko-zielony lub kanarkowy, które nie są dostępne w kontrolerze wdrażania. Aby skorzystać z tych strategii w Kubernetes, użytkownicy musieli napisać skrypty na swoich wdrożeniach. Kontroler Argo Rollouts udostępnia te strategie jako proste, deklaratywne i konfigurowalne parametry.
https://argoproj.github.io/argo-rollouts

Istnieje również Argo CI, który zapewnia wygodny interfejs sieciowy do użytku z Rolloutami, przyjrzymy się temu w następnym artykule.

Instalowanie wdrożeń Argo

Po stronie serwera

kubectl create namespace argo-rolloutskubectl apply -n argo-rollouts -f https://raw.githubusercontent.com/argoproj/argo-rollouts/stable/manifests/install.yaml

W naszej infrastrukturze rzepa (patrz poniżej) dodaliśmy już install.yaml jako i/k8s/argo-rollouts/install.yaml. W ten sposób GitlabCI zainstaluje go w klastrze.

Strona klienta (wtyczka kubectl)

https://argoproj.github.io/argo-rollouts/features/kubectl-plugin

Przykładowe zastosowanie

Dobrą praktyką jest posiadanie oddzielnych repozytoriów dla kodu aplikacji i infrastruktury.

Repozytorium aplikacji

Kim Wuestkamp/k8s-przykładowa aplikacja-wdrożeniowa

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

wuestkamp/k8s-przykładowa-aplikacja-wdrożenia:v1
wuestkamp/k8s-przykładowa-aplikacja-wdrożenia:v2

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

Repozytorium infrastruktury

W tym repozytorium będziemy używać GitlabCI do wdrożenia w Kubernetesie, plik .gitlab-ci.yml wygląda następująco:

image: traherom/kustomize-dockerbefore_script:
   - printenv
   - kubectl versionstages:
 - deploydeploy 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.

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

Infrastruktura Yaml

Wewnątrz repozytorium infrastruktury mamy usługę:

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

i rollout.yaml :

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
 name: rollout-canary
spec:
 replicas: 10
 revisionHistoryLimit: 2
 selector:
   matchLabels:
     id: rollout-canary
 template:
   metadata:
     labels:
       id: rollout-canary
   spec:
     containers:
     - name: rollouts-demo
       image: registry.gitlab.com/wuestkamp/k8s-deployment-example-app:v1
       imagePullPolicy: Always
 strategy:
   canary:
     steps:
     - setWeight: 10
     # Rollouts can be manually resumed by running `kubectl argo rollouts promote ROLLOUT`
     - pause: {}
     - setWeight: 50
     - pause: { duration: 120 } # two minutes

Rollout działa tak samo jak Deployment. Jeśli nie ustawimy strategii aktualizacji (jak tutaj Canary), będzie ona zachowywać się jak domyślne wdrożenie aktualizacji stopniowej.

Definiujemy dwa kroki w YAML dla wdrożenia Canary:

10% ruchu na Kanarek (poczekaj na ręczne OK)
50% ruchu do Canary (odczekaj 2 minuty, a następnie przejdź do 100%)

Przeprowadzanie wstępnego wdrożenia

Po pierwszym wdrożeniu nasze zasoby będą wyglądać następująco:

A odpowiedź dostajemy dopiero z pierwszej wersji aplikacji:

Przeprowadzanie wdrożenia Canary

Krok 1: 10% ruchu

Aby rozpocząć wdrożenie Canary, wystarczy zmienić wersję obrazu, jak to zwykle robimy w przypadku wdrożeń:

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
 name: rollout-canary
spec:
...
 template:
   metadata:
     labels:
       id: rollout-canary
   spec:
     containers:
     - name: rollouts-demo
       image: registry.gitlab.com/wuestkamp/k8s-deployment-example-app:v2
...

Wprowadzamy zmiany, więc Gitlab CI zostaje wdrożony i widzimy zmiany:

Teraz, jeśli uzyskamy dostęp do usługi:

Świetnie! Jesteśmy w trakcie rozmieszczania kanarek. Postęp możemy zobaczyć uruchamiając:

kubectl argo rollouts get rollout rollout-canary

Krok 2: 50% ruchu:

Przejdźmy teraz do kolejnego kroku: przekierowania 50% ruchu. Skonfigurowaliśmy ten krok tak, aby był uruchamiany ręcznie:

kubectl argo rollouts promote rollout-canary # continue to step 2

A nasza aplikacja zwróciła 50% odpowiedzi z nowych wersji:

I recenzja wdrożenia:

рекрасно.

Krok 3: 100% ruchu:

Ustawiliśmy to tak, aby po 2 minutach krok 50% kończył się automatycznie i rozpoczynał się krok 100%:

I wynik aplikacji:

I recenzja wdrożenia:

Wdrożenie Canary zostało zakończone.

Więcej przykładów z Argo Rollouts

Tutaj znajduje się więcej przykładów, takich jak konfigurowanie podglądów i porównań środowisk w oparciu o kanarek:

https://github.com/argoproj/argo-rollouts/tree/master/examples

Film o wdrożeniach Argo i Argo CI

Naprawdę polecam ten film, pokazuje on współpracę Argo Rollouts i Argo CI:

Łączny

Bardzo podoba mi się pomysł wykorzystania CRD, które zarządzają tworzeniem dodatkowych typów wdrożeń czy zestawów replik, przekierowują ruch itp. Współpraca z nimi przebiega sprawnie. Następnie chciałbym przetestować integrację z Argo CI.

Wydaje się jednak, że nadchodzi duża fuzja Argo CI i Flux CI, więc mogę poczekać, aż pojawi się nowa wersja: Strumień Argo.

Czy miałeś jakieś doświadczenia z Argo Rollouts lub Argo CI?

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

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

Wdrożenie Canary w Kubernetes nr 2: Wdrożenia Argo