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


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


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


يوجد أدناه دليل تفصيلي حول كيفية تكوين واستخدام أداة Flagger في Google Kubernetes Engine (GKE).


تكوين Kubernetes الكتلة


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


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


PROJECT_ID المشروع الافتراضي ومنطقة الحساب والمنطقة ( 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 

سيقوم الأمر أعلاه بإنشاء تجمع عقدة افتراضي يشتمل على جهازي VMs n1-standard-2 (vCPU: 2، RAM 7.5 GB، disk: 30 GB). من الناحية المثالية ، يجدر عزل مكونات Istio عن أعباء العمل الخاصة بها ، ولكن لا توجد طريقة سهلة لتشغيل حافظات Istio في تجمع مخصص للعقدة. تُعتبر قوائم 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)" 

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


 brew install kubernetes-helm 

Homebrew 2.0 متوفر الآن لنظام التشغيل Linux .


إنشاء حساب خدمة وربط دور نظام المجموعة لـ 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 

لا ينبغي أن يوفر أي نظام إنتاج خدمات على الإنترنت بدون طبقة المقابس الآمنة. لحماية بوابة Istio مع مدير الشهادات ، CloudDNS ، و Let's Encrypt ، يرجى قراءة وثائق Flagger GKE.


تركيب الراية


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


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

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


 helm repo add flagger 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 في 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


ينشر 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) . تم توثيق حقول الكناري 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 إلى app.istio.example.com ، سترى رقم إصدار التطبيق التجريبي .


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


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



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


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

بدء نشر الكناري عند تحديث صورة الحاوية:


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

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


 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:



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


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


 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 ، فستتلقى الرسائل التالية:



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


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


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


 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 

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


يتم تسجيل أخطاء الكناري وقمم التأخير كأحداث 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 ، إلى توفير مقاييس وسجلات وبروتوكولات تلقائية ، ولكن نشر أحمال العمل لا يزال يعتمد على الأدوات الخارجية. تسعى شركة Flagger إلى تغيير هذا من خلال إضافة إمكانات التسليم التدريجي لـ Istio.


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


يتم دعم Flagger بواسطة Weaveworks ويوفر نشرات الكناري إلى Weave Cloud . يتم اختبار المشروع على GKE ، EX والمعادن العارية مع kubeadm.


إذا كان لديك أي اقتراحات لتحسين Flagger ، فيرجى إرسال سؤال أو PR إلى GitHub على stefanprodan / flagger . المساهمات أكثر من موضع ترحيب!


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

Source: https://habr.com/ru/post/ar444808/


All Articles