🥇 عمليات النشر التلقائي لطائر الكناري مع Flagger و Istio

يتم التعرف على القرص المضغوط كممارسة برمجيات مؤسسية وهو نتيجة للتطور الطبيعي لمبادئ CI الراسخة. ومع ذلك ، لا يزال القرص المضغوط نادرًا جدًا ، ربما بسبب تعقيد الإدارة والخوف من عمليات النشر الفاشلة التي تؤثر على توفر النظام.

المُخبر هو مشغل Kubernetes مفتوح المصدر يهدف إلى القضاء على العلاقات المربكة. إنه يعمل على أتمتة ترويج عمليات النشر الكناري باستخدام Istio traffic offset and Prometheus metrics لتحليل سلوك التطبيق أثناء الطرح المُدار.

يوجد أدناه دليل تفصيلي خطوة بخطوة لإعداد واستخدام Flagger على Google Kubernetes Engine (GKE).

إنشاء مجموعة Kubernetes

تبدأ بإنشاء مجموعة GKE باستخدام الوظيفة الإضافية Istio (إذا لم يكن لديك حساب GCP ، فيمكنك الاشتراك هنا - للحصول على ائتمانات مجانية).

سجّل الدخول إلى Google Cloud ، وأنشئ مشروعًا ، وقم بتمكين الفوترة له. قم بتثبيت الأداة المساعدة لسطر الأوامر com.gcloud وقم بإعداد مشروعك باستخدام gcloud init.

تعيين المشروع الافتراضي ومنطقة الحساب والمنطقة (استبدال PROJECT_ID لمشروعك):

gcloud config set project PROJECT_ID
gcloud config set compute/region us-central1
gcloud config set compute/zone us-central1-a

قم بتمكين خدمة GKE وأنشئ مجموعة باستخدام إضافات HPA و Istio:

gcloud services enable container.googleapis.com
K8S_VERSION=$(gcloud beta container get-server-config --format=json | jq -r '.validMasterVersions[0]')
gcloud beta container clusters create istio 
--cluster-version=${K8S_VERSION} 
--zone=us-central1-a 
--num-nodes=2 
--machine-type=n1-standard-2 
--disk-size=30 
--enable-autorepair 
--no-enable-cloud-logging 
--no-enable-cloud-monitoring 
--addons=HorizontalPodAutoscaling,Istio 
--istio-config=auth=MTLS_PERMISSIVE

سيقوم الأمر أعلاه بإنشاء تجمع عقدة افتراضي يشتمل على جهازي ظاهريين n1-standard-2 (وحدة المعالجة المركزية: 2 ، ذاكرة الوصول العشوائي 7,5 جيجابايت ، القرص: 30 جيجابايت). من الناحية المثالية ، يجب عزل مكونات Istio عن أحمال العمل لديك ، ولكن لا توجد طريقة سهلة لتشغيل Istio Pods في مجموعة مخصصة من العقد. تعتبر بيانات Istio للقراءة فقط وسيقوم GKE بالتراجع عن أي تغييرات ، مثل الارتباط بعقدة أو الانفصال عن الكبسولة.

قم بإعداد أوراق الاعتماد لـ kubectl:

gcloud container clusters get-credentials istio

إنشاء ارتباط دور مسؤول نظام المجموعة:

kubectl create clusterrolebinding "cluster-admin-$(whoami)" 
--clusterrole=cluster-admin 
--user="$(gcloud config get-value core/account)"

قم بتثبيت أداة سطر الأوامر قاد:

brew install kubernetes-helm

Homebrew 2.0 متاح الآن أيضًا لـ لينكس.

إنشاء حساب خدمة وربط دور المجموعة لـ Tiller:

kubectl -n kube-system create sa tiller && 
kubectl create clusterrolebinding tiller-cluster-rule 
--clusterrole=cluster-admin 
--serviceaccount=kube-system:tiller

قم بتوسيع Tiller في مساحة الاسم kube-system:

helm init --service-account tiller

يجب أن تفكر في استخدام SSL بين Helm و Tiller. لمزيد من المعلومات حول حماية تثبيت Helm ، راجع docs.helm.sh

تأكيد الإعدادات:

kubectl -n istio-system get svc

بعد بضع ثوانٍ ، يجب على GCP تعيين عنوان IP خارجي للخدمة istio-ingressgateway.

تكوين بوابة دخول Istio

قم بإنشاء عنوان IP ثابت باسم istio-gatewayباستخدام عنوان IP الخاص ببوابة Istio:

export GATEWAY_IP=$(kubectl -n istio-system get svc/istio-ingressgateway -ojson | jq -r .status.loadBalancer.ingress[0].ip)
gcloud compute addresses create istio-gateway --addresses ${GATEWAY_IP} --region us-central1

أنت الآن بحاجة إلى مجال إنترنت والوصول إلى مسجل DNS الخاص بك. أضف سجلين من سجلات A (استبدل example.com إلى المجال الخاص بك):

istio.example.com   A ${GATEWAY_IP}
*.istio.example.com A ${GATEWAY_IP}

تحقق من عمل حرف البدل DNS:

watch host test.istio.example.com

قم بإنشاء بوابة Istio عامة لتقديم خدمات خارج شبكة الخدمة عبر HTTP:

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: public-gateway
  namespace: istio-system
spec:
  selector:
    istio: ingressgateway
  servers:
    - port:
        number: 80
        name: http
        protocol: HTTP
      hosts:
        - "*"

احفظ المورد أعلاه باسم public-gateway.yaml ثم قم بتطبيقه:

kubectl apply -f ./public-gateway.yaml

لا ينبغي أن يوفر أي نظام إنتاج خدمات على الإنترنت بدون SSL. لتأمين بوابة دخول Istio مع مدير الشهادات و CloudDNS و Let's Encrypt ، يرجى القراءة الوثائق Flagger G.K.E.

تثبيت المُخبر

لا تتضمن الوظيفة الإضافية GKE Istio مثيل Prometheus الذي ينظف خدمة Istio للقياس عن بُعد. نظرًا لأن Flagger يستخدم مقاييس Istio HTTP لإجراء تحليل كناري ، فأنت بحاجة إلى نشر تكوين Prometheus التالي ، على غرار التكوين الذي يأتي مع مخطط Istio Helm الرسمي.

REPO=https://raw.githubusercontent.com/stefanprodan/flagger/master
kubectl apply -f ${REPO}/artifacts/gke/istio-prometheus.yaml

أضف مستودع Flagger Helm:

helm repo add flagger [https://flagger.app](https://flagger.app/)

قم بتوسيع المُخبر إلى مساحة الاسم istio-systemمن خلال تمكين إشعارات Slack:

helm upgrade -i flagger flagger/flagger 
--namespace=istio-system 
--set metricsServer=http://prometheus.istio-system:9090 
--set slack.url=https://hooks.slack.com/services/YOUR-WEBHOOK-ID 
--set slack.channel=general 
--set slack.user=flagger

يمكنك تثبيت Flagger في أي مساحة اسم طالما أنه يمكنه الاتصال بخدمة Istio Prometheus على المنفذ 9090.

يحتوي Flagger على لوحة تحكم Grafana لتحليل الكناري. قم بتثبيت Grafana في مساحة الاسم istio-system:

helm upgrade -i flagger-grafana flagger/grafana 
--namespace=istio-system 
--set url=http://prometheus.istio-system:9090 
--set user=admin 
--set password=change-me

اكتشف Grafana من خلال بوابة مفتوحة عن طريق إنشاء خدمة افتراضية (استبدل example.com إلى المجال الخاص بك):

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: grafana
  namespace: istio-system
spec:
  hosts:
    - "grafana.istio.example.com"
  gateways:
    - public-gateway.istio-system.svc.cluster.local
  http:
    - route:
        - destination:
            host: flagger-grafana

احفظ المورد أعلاه باسم grafana-virtual-service.yaml ثم قم بتطبيقه:

kubectl apply -f ./grafana-virtual-service.yaml

عند الانتقال إلى http://grafana.istio.example.com في المتصفح ، يجب أن يتم توجيهك إلى صفحة تسجيل الدخول إلى Grafana.

نشر تطبيقات الويب باستخدام المُخبر

ينشر Flagger Kubernetes ويتوسع اختياريًا (HPA) ، ثم ينشئ سلسلة من الكائنات (عمليات نشر Kubernetes ، وخدمات ClusterIP ، وخدمات Istio الافتراضية). تعرض هذه الكائنات التطبيق إلى شبكة الخدمة والتحكم في تحليل الكناري والتقدم.

أنشئ مساحة اسم اختبارية مع تمكين إدخال Istio Sidecar:

REPO=https://raw.githubusercontent.com/stefanprodan/flagger/master
kubectl apply -f ${REPO}/artifacts/namespaces/test.yaml

قم بإنشاء نشر وأداة تدريجية تلقائية للجراب:

kubectl apply -f ${REPO}/artifacts/canaries/deployment.yaml
kubectl apply -f ${REPO}/artifacts/canaries/hpa.yaml

انشر خدمة تحميل اختباري لتوليد حركة المرور أثناء تحليل الكناري:

helm upgrade -i flagger-loadtester flagger/loadtester 
--namepace=test

قم بإنشاء مورد كناري مخصص (استبدل example.com إلى المجال الخاص بك):

apiVersion: flagger.app/v1alpha3
kind: Canary
metadata:
  name: podinfo
  namespace: test
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: podinfo
  progressDeadlineSeconds: 60
  autoscalerRef:
    apiVersion: autoscaling/v2beta1
    kind: HorizontalPodAutoscaler
    name: podinfo
  service:
    port: 9898
    gateways:
    - public-gateway.istio-system.svc.cluster.local
    hosts:
    - app.istio.example.com
  canaryAnalysis:
    interval: 30s
    threshold: 10
    maxWeight: 50
    stepWeight: 5
    metrics:
    - name: istio_requests_total
      threshold: 99
      interval: 30s
    - name: istio_request_duration_seconds_bucket
      threshold: 500
      interval: 30s
    webhooks:
      - name: load-test
        url: http://flagger-loadtester.test/
        timeout: 5s
        metadata:
          cmd: "hey -z 1m -q 10 -c 2 http://podinfo.test:9898/"

احفظ المورد أعلاه باسم podinfo-canary.yaml ثم قم بتطبيقه:

kubectl apply -f ./podinfo-canary.yaml

التحليل أعلاه ، في حالة نجاحه ، سيتم تشغيله لمدة خمس دقائق ، والتحقق من مقاييس HTTP كل نصف دقيقة. يمكنك تحديد الحد الأدنى من الوقت المطلوب للتحقق من صحة نشر الكناري وترقيته باستخدام الصيغة التالية: interval * (maxWeight / stepWeight). تم توثيق حقول Canary CRD هنا.

بعد بضع ثوانٍ ، سينشئ Flagger كائنات الكناري:

# applied 
deployment.apps/podinfo
horizontalpodautoscaler.autoscaling/podinfo
canary.flagger.app/podinfo
# generated 
deployment.apps/podinfo-primary
horizontalpodautoscaler.autoscaling/podinfo-primary
service/podinfo
service/podinfo-canary
service/podinfo-primary
virtualservice.networking.istio.io/podinfo

افتح المتصفح وانتقل إلى app.istio.example.com، يجب أن ترى رقم الإصدار تطبيقات تجريبية.

التحليل التلقائي للكناري والترويج

ينفذ المُخبر حلقة تحكم تنقل تدريجيًا حركة المرور إلى الكناري أثناء قياس مقاييس الأداء الرئيسية مثل معدل نجاح طلب HTTP ومتوسط مدة الطلب وسلامة حافظة البيانات. بناءً على تحليل KPI ، يتم ترقية الكناري أو مقاطعته ، ويتم نشر نتائج التحليل على Slack.

يتم تشغيل نشر Canary عندما يتغير أحد الكائنات التالية:

نشر PodSpec (صورة حاوية ، أمر ، منافذ ، بيئة ، إلخ.)
يتم تحميل ConfigMaps كوحدات تخزين أو تعيينها لمتغيرات البيئة
يتم تثبيت الأسرار كوحدات تخزين أو تحويلها إلى متغيرات البيئة

قم بتشغيل نشر canary عند تحديث صورة حاوية:

kubectl -n test set image deployment/podinfo 
podinfod=quay.io/stefanprodan/podinfo:1.4.1

اكتشف المُخبر أن إصدار النشر قد تغير ويبدأ في تحليله:

kubectl -n test describe canary/podinfo

Events:

New revision detected podinfo.test
Scaling up podinfo.test
Waiting for podinfo.test rollout to finish: 0 of 1 updated replicas are available
Advance podinfo.test canary weight 5
Advance podinfo.test canary weight 10
Advance podinfo.test canary weight 15
Advance podinfo.test canary weight 20
Advance podinfo.test canary weight 25
Advance podinfo.test canary weight 30
Advance podinfo.test canary weight 35
Advance podinfo.test canary weight 40
Advance podinfo.test canary weight 45
Advance podinfo.test canary weight 50
Copying podinfo.test template spec to podinfo-primary.test
Waiting for podinfo-primary.test rollout to finish: 1 of 2 updated replicas are available
Promotion completed! Scaling down podinfo.test

أثناء التحليل ، يمكن تتبع نتائج الكناري باستخدام Grafana:

يرجى ملاحظة أنه إذا تم تطبيق تغييرات جديدة على عملية النشر أثناء تحليل الكناري ، فسيقوم المُعلم بإعادة تشغيل مرحلة التحليل.

قم بعمل قائمة بجميع جزر الكناري في مجموعتك:

watch kubectl get canaries --all-namespaces
NAMESPACE   NAME      STATUS        WEIGHT   LASTTRANSITIONTIME
test        podinfo   Progressing   15       2019-01-16T14:05:07Z
prod        frontend  Succeeded     0        2019-01-15T16:15:07Z
prod        backend   Failed        0        2019-01-14T17:05:07Z

إذا قمت بتمكين إشعارات Slack ، فستتلقى الرسائل التالية:

التراجع التلقائي

أثناء تحليل canary ، يمكنك إنشاء أخطاء HTTP 500 الاصطناعية وزمن استجابة مرتفع لمعرفة ما إذا كان المُخبر سيوقف النشر.

قم بإنشاء جراب اختبار وقم بما يلي فيه:

kubectl -n test run tester 
--image=quay.io/stefanprodan/podinfo:1.2.1 
-- ./podinfo --port=9898
kubectl -n test exec -it tester-xx-xx sh

إنشاء أخطاء HTTP 500:

watch curl http://podinfo-canary:9898/status/500

جيل التأخير:

watch curl http://podinfo-canary:9898/delay/1

عندما يصل عدد عمليات التحقق الفاشلة إلى الحد الأدنى ، يتم توجيه حركة المرور مرة أخرى إلى القناة الأساسية ، ويتم تحجيم الكناري إلى الصفر ، ويتم وضع علامة على النشر على أنه فشل.

يتم تسجيل أخطاء Canary وارتفاعات وقت الاستجابة كأحداث Kubernetes ويتم تسجيلها بواسطة Flagger بتنسيق JSON:

kubectl -n istio-system logs deployment/flagger -f | jq .msg

Starting canary deployment for podinfo.test
Advance podinfo.test canary weight 5
Advance podinfo.test canary weight 10
Advance podinfo.test canary weight 15
Halt podinfo.test advancement success rate 69.17% < 99%
Halt podinfo.test advancement success rate 61.39% < 99%
Halt podinfo.test advancement success rate 55.06% < 99%
Halt podinfo.test advancement success rate 47.00% < 99%
Halt podinfo.test advancement success rate 37.00% < 99%
Halt podinfo.test advancement request duration 1.515s > 500ms
Halt podinfo.test advancement request duration 1.600s > 500ms
Halt podinfo.test advancement request duration 1.915s > 500ms
Halt podinfo.test advancement request duration 2.050s > 500ms
Halt podinfo.test advancement request duration 2.515s > 500ms
Rolling back podinfo.test failed checks threshold reached 10
Canary failed! Scaling down podinfo.test

إذا قمت بتمكين إشعارات Slack ، فستتلقى رسالة عند تجاوز الموعد النهائي أو الوصول إلى الحد الأقصى لعدد عمليات التحقق الفاشلة في التحليل:

في الختام

سيؤدي تشغيل شبكة خدمة مثل Istio بالإضافة إلى Kubernetes إلى توفير مقاييس وسجلات وبروتوكولات تلقائية ، لكن نشر عبء العمل لا يزال يعتمد على الأدوات الخارجية. يهدف المُخبر إلى تغيير ذلك عن طريق إضافة قدرات Istio التسليم التدريجي.

يتوافق Flagger مع أي حل Kubernetes CI / CD ، ويمكن توسيع نطاق تحليل الكناري بسهولة باستخدامه webhooks لإجراء اختبارات تكامل / قبول النظام أو اختبارات التحميل أو أي فحوصات مخصصة أخرى. نظرًا لأن Flagger إعلاني ويستجيب لأحداث Kubernetes ، فيمكن استخدامه في خطوط أنابيب GitOps جنبًا إلى جنب مع نسج الجريان أو جينكينز. إذا كنت تستخدم JenkinsX ، فيمكنك تثبيت Flagger مع إضافات jx.

دعم المُخبر نسج ويوفر عمليات نشر الكناري في نسج سحابة. يتم اختبار المشروع على GKE و EKS والمعدن العاري مع kubeadm.

إذا كانت لديك اقتراحات لتحسين المُخبر ، فالرجاء إرسال مشكلة أو العلاقات العامة على GitHub على stefanprodan / فلاغر. المساهمات أكثر من موضع ترحيب!

شكرا راي تسانج.

المصدر: www.habr.com

عمليات النشر التلقائي لطائر الكناري باستخدام Flagger و Istio