🥇Kubernetes'te Canary Dağıtımı #1: Gitlab CI

Kubernetes'te Canary dağıtımını uygulamak ve kullanmak için Gitlab CI'yı ve manuel GitOps'u kullanacağız

Bu serideki makaleler:

(Bu makale)
ArgoCI kullanarak Canary Dağıtımı
Istio kullanarak Canary Dağıtımı
Jenkins-X Istio Flagger'ı kullanarak Canary Dağıtımı

Canary dağıtımını GitOps aracılığıyla manuel olarak gerçekleştireceğiz ve ana Kubernetes kaynaklarını oluşturacağız/değiştireceğiz. Bu makale öncelikle tanıtım amaçlıdır Aşağıdaki makalelerde ele alacağımız daha etkili otomasyon yöntemleri olduğundan Kubernetes Canary'de dağıtımın nasıl çalıştığı hakkında bilgi edinin.

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

Kanarya Dağıtımı

Canary stratejisinde güncellemeler öncelikle kullanıcıların yalnızca bir alt kümesine uygulanır. Sürüm, tüm kullanıcılara yayınlanmadan önce izleme, günlük verileri, manuel test veya diğer geri bildirim kanalları aracılığıyla test edilir.

Kubernetes Dağıtımı (sürekli güncelleme)

Kubernetes Dağıtımı için varsayılan strateji, belirli sayıda bölmenin görüntülerin yeni sürümleriyle başlatıldığı sürekli güncellemedir. Sorunsuz bir şekilde oluşturulduysa, görüntülerin eski versiyonlarını içeren bölmeler sonlandırılır ve paralel olarak yeni bölmeler oluşturulur.

GitOps

Bu örnekte GitOps'u kullanıyoruz çünkü:

Git'i tek bir gerçek kaynağı olarak kullanma
derleme ve dağıtım için Git Operasyonlarını kullanıyoruz (git tag/merge dışında hiçbir komuta gerek yok)

Örnek

Uygulama kodu için bir havuza ve altyapı için bir havuza sahip olmak gibi iyi bir uygulamayı ele alalım.

Uygulama deposu

Bu, JSON olarak yanıt döndüren çok basit bir Python+Flask API'sidir. Paketi GitlabCI aracılığıyla oluşturacağız ve sonucu Gitlab Registry'ye aktaracağız. Kayıt defterinde iki farklı yayın sürümümüz var:

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

Aralarındaki tek fark, döndürülen JSON dosyasındaki değişikliktir. Hangi sürümle iletişim kurduğumuzu mümkün olduğunca kolay görselleştirmek için bu uygulamayı kullanıyoruz.

Altyapı deposu

Bu şalgamda GitlabCI aracılığıyla Kubernetes'e dağıtacağız, .gitlab-ci.yml выглядит следующим образом:

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

Kendiniz çalıştırmak için bir kümeye ihtiyacınız olacak, Gcloud'u kullanabilirsiniz:

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

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

Çatallaman gerekiyor https://gitlab.com/wuestkamp/k8s-deployment-example-canary-infrastructure ve bir değişken oluştur KUBECONFIG erişim için yapılandırmayı içerecek olan GitlabCI'da kubectl kümenize.

Bir küme için kimlik bilgilerinin nasıl alınacağını okuyabilirsiniz (Gcloud) burada.

Altyapı Yaml

Altyapı deposunda hizmetimiz var:

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

Ve dağıtım 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

Ve başka bir dağıtım 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

App-deploy'un henüz tanımlanmış herhangi bir kopyaya sahip olmadığını unutmayın.

İlk dağıtımın gerçekleştirilmesi

İlk dağıtımı başlatmak için GitlabCI işlem hattını ana dalda manuel olarak başlatabilirsiniz. daha sonrasında kubectl aşağıdaki çıktıyı vermelidir:

Görüyoruz app 10 kopya ile dağıtım ve 0 ile uygulama kanaryası. Ayrıca, üzerinden erişebileceğimiz bir LoadBalancer da var. curl Harici IP aracılığıyla:

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

Test uygulamamızın sadece “v1” döndürdüğünü görüyoruz.

Canary dağıtımını yürütme

1. Adım: Bazı kullanıcılar için yeni bir sürüm yayınlayın

Deploy-canary.yaml dosyasında ve yeni sürüm görüntüsünde replika sayısını 1 olarak ayarladık:

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

Dosyada deploy.yaml kopya sayısını 9 olarak değiştirdik:

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

Bu değişiklikleri dağıtımın başlayacağı depoya (GitlabCI aracılığıyla) gönderiyoruz ve sonucu görüyoruz:

Her ikisinde de uygulama seçici bulunduğundan Hizmetimiz her iki dağıtıma da işaret edecektir. Kubernetes'in varsayılan rastgele seçimi nedeniyle isteklerin yaklaşık %10'u için farklı yanıtlar görmeliyiz:

Uygulamamızın mevcut durumu (GitOps, Tek Kaynak Gerçeği olarak Git'ten alınmıştır), her sürüm için bir tane olmak üzere aktif replikalara sahip iki dağıtımın varlığıdır.

Kullanıcıların ~%10'u yeni bir sürüme aşina oluyor ve istemeden onu test ediyor. Artık günlüklerdeki hataları kontrol etmenin ve sorunları bulmak için verileri izlemenin zamanı geldi.

2. Adım: Yeni sürümü tüm kullanıcılara yayınlayın

Her şeyin yolunda gittiğine karar verdik ve şimdi yeni sürümü tüm kullanıcılara sunmamız gerekiyor. Bunu yapmak için basitçe güncelliyoruz deploy.yaml görüntünün yeni bir sürümünün yüklenmesi ve kopya sayısı 10'a eşittir. deploy-canary.yaml replika sayısını tekrar 0'a ayarladık. Dağıtımdan sonra sonuç aşağıdaki gibi olacaktır:

Özetleme

Bana göre dağıtımı bu şekilde manuel olarak çalıştırmak, k8s kullanılarak ne kadar kolay yapılandırılabileceğini anlamaya yardımcı oluyor. Kubernetes her şeyi bir API aracılığıyla güncellemenize izin verdiği için bu adımlar komut dosyaları aracılığıyla otomatikleştirilebilir.

Uygulanması gereken diğer bir şey de, yalnızca yeni sürüme erişilebilen bir test cihazı giriş noktasıdır (LoadBalancer veya Ingress aracılığıyla). Manuel tarama için kullanılabilir.

Gelecek makalelerde, yaptıklarımızın çoğunu uygulayan diğer otomatik çözümlere göz atacağız.

Ayrıca blogumuzdaki diğer makaleleri de okuyun:

Kaynak: habr.com

Kubernetes'te Canary Dağıtımı #1: Gitlab CI