🥇 د اسټیو سره مایکرو خدماتو ته بیرته. دریمه برخه

نوټ. ژباړه: لومړۍ برخه دا لړۍ د اسټیو وړتیاو معرفي کولو او په عمل کې د دوی ښودلو لپاره وقف شوې وه. اوس به موږ د دې خدمت میش د ترتیب او کارولو د ډیرو پیچلو اړخونو په اړه وغږیږو، او په ځانګړې توګه، د ښه سمبال شوي روټینګ او د شبکې ترافیک مدیریت په اړه.

موږ تاسو ته دا هم یادونه کوو چې مقاله د ذخیره کولو څخه تشکیلات کاروي (د کوبرنیټس او اسټیو لپاره څرګندونه) istio-mastery.

د ترافیکو مدیریت

د اسټیو سره، نوي وړتیاوې په کلستر کې ښکاري چې چمتو کړي:

متحرک غوښتنه روټینګ: کانري رول آوټ، د A/B ازموینه؛
د بار توازن: ساده او ثابت، د هشونو پر بنسټ؛
له زوال وروسته بیا رغونه: مهال ویش، بیا هڅه، سرکټ ماتونکي؛
د تېروتنو داخلول: ځنډول، غوښتنې ردول، او داسې نور.

لکه څنګه چې مقاله دوام لري، دا وړتیاوې به د غوره شوي غوښتنلیک په کارولو سره د مثال په توګه روښانه شي او د لارې په اوږدو کې به نوي مفکورې معرفي شي. لومړی داسې مفهوم به وي DestinationRules (د بیلګې په توګه د ټرافیک/غوښتنو د ترلاسه کونکي په اړه مقررات - نږدې ژباړه.)، د کوم په مرسته چې موږ د A/B ازموینې فعالوو.

د A/B ازموینه: په عمل کې د منزل مقررات

د A/B ازموینه په هغه قضیو کې کارول کیږي چیرې چې د غوښتنلیک دوه نسخې شتون لري (معمولا دوی په لید کې توپیر لري) او موږ 100٪ ډاډه نه یو چې کوم یو به د کارونکي تجربه ښه کړي. له همدې امله، موږ دواړه نسخې په ورته وخت کې چلوو او میټریکونه راټولوو.

د فرنټ اینډ دوهم نسخه ځای په ځای کولو لپاره ، د A/B ازموینې ښودلو لپاره اړین ، لاندې کمانډ چل کړئ:

$ kubectl apply -f resource-manifests/kube/ab-testing/sa-frontend-green-deployment.yaml
deployment.extensions/sa-frontend-green created

د شنه نسخې لپاره د ګمارنې څرګندونه په دوه ځایونو کې توپیر لري:

انځور د یو بل ټګ پر بنسټ دی - istio-green,
پوډر یو لیبل لري version: green.

ځکه چې دواړه ګمارنې یو لیبل لري app: sa-frontend,د مجازی خدماتو لخوا لیږل شوي غوښتنې sa-external-services د خدمت لپاره sa-frontend، به د هغې ټولو مثالونو ته واستول شي او بار به له لارې توزیع شي round-robin algorithm، کوم چې به د لاندې حالت لامل شي:

غوښتل شوي فایلونه ونه موندل شول

دا فایلونه ونه موندل شول ځکه چې دوی د غوښتنلیک په مختلف نسخو کې په مختلف ډول نومول شوي. راځئ چې دا ډاډ ترلاسه کړو:

$ curl --silent http://$EXTERNAL_IP/ | tr '"' 'n' | grep main
/static/css/main.c7071b22.css
/static/js/main.059f8e9c.js
$ curl --silent http://$EXTERNAL_IP/ | tr '"' 'n' | grep main
/static/css/main.f87cd8c9.css
/static/js/main.f7659dbb.js

دا پدې مانا ده چې index.html، د جامد فایلونو د یوې نسخې غوښتنه کول ، د بار بیلنسر لخوا پوډونو ته لیږل کیدی شي چې مختلف نسخه لري ، چیرې چې د څرګند دلیلونو لپاره دا ډول فایلونه شتون نلري. له همدې امله، د غوښتنلیک د کار کولو لپاره، موږ باید یو محدودیت ترتیب کړو: "د غوښتنلیک ورته نسخه چې index.html یې وړاندې کړې باید د راتلونکو غوښتنو خدمت وکړي".

موږ به هلته د دوامداره هش پراساس بار توازن سره ورسیږو (مستقل هش لوډ توازن)... پدې حالت کې د ورته مراجعینو څخه غوښتنې ورته پس منظر مثال ته لیږل کیږي، د کوم لپاره چې دمخه تعریف شوی ملکیت کارول کیږي - د مثال په توګه ، د HTTP سرلیک. د Destination Rules په کارولو سره پلي کیږي.

د منزل مقررات

وروسته مجازی خدمت غوښتل شوي خدمت ته غوښتنه واستول شي، د DestinationRules په کارولو سره موږ کولی شو هغه پالیسۍ تعریف کړو چې د دې خدمت مثالونو لپاره ټاکل شوي ترافیک ته پلي کیږي:

د اسټیو سرچینو سره د ترافیک مدیریت

تبصره: د شبکې په ټرافیک باندې د اسټیو سرچینو اغیزې دلته په داسې طریقه وړاندې کیږي چې پوهیدل اسانه دي. د دقیقیت لپاره، پریکړه چې په کوم مثال کې غوښتنه لیږل کیږي د انګریس په دروازه کې د سفیر لخوا په CRD کې ترتیب شوي.

د منزل مقرراتو سره، موږ کولی شو د دوامداره هشونو کارولو لپاره د بار توازن تنظیم کړو او ډاډ ترلاسه کړو چې ورته خدمت مثال ورته کارونکي ته ځواب ورکوي. لاندې ترتیب تاسو ته اجازه درکوي چې دا ترلاسه کړئ (destinationrule-sa-frontend.yaml):

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: sa-frontend
spec:
  host: sa-frontend
  trafficPolicy:
    loadBalancer:
      consistentHash:
        httpHeaderName: version   # 1

1 - هش به د HTTP سرلیک مینځپانګې پراساس رامینځته شي version.

د لاندې کمانډ سره تشکیلات پلي کړئ:

$ kubectl apply -f resource-manifests/istio/ab-testing/destinationrule-sa-frontend.yaml
destinationrule.networking.istio.io/sa-frontend created

اوس لاندې کمانډ پرمخ وړئ او ډاډ ترلاسه کړئ چې تاسو سم فایلونه ترلاسه کوئ کله چې تاسو سرلیک مشخص کړئ version:

$ curl --silent -H "version: yogo" http://$EXTERNAL_IP/ | tr '"' 'n' | grep main

تبصره: په سرلیک کې د مختلف ارزښتونو اضافه کولو لپاره او پایلې په مستقیم ډول په براوزر کې معاینه کړئ، تاسو کولی شئ وکاروئ دا تمدید کروم ته (يا له دې سره د فایرفوکس لپاره - نږدې. ژباړه.).

په عموم کې، DestinationRules د بار توازن په ساحه کې ډیر وړتیاوې لري - د جزیاتو لپاره وګورئ رسمي اسناد.

مخکې لدې چې د VirtualService نور مطالعه وکړئ ، راځئ چې د لاندې کمانډونو په چلولو سره د غوښتنلیک "شنه نسخه" او د ورته ترافیک لارښود قاعده لرې کړو:

$ kubectl delete -f resource-manifests/kube/ab-testing/sa-frontend-green-deployment.yaml
deployment.extensions “sa-frontend-green” deleted
$ kubectl delete -f resource-manifests/istio/ab-testing/destinationrule-sa-frontend.yaml
destinationrule.networking.istio.io “sa-frontend” deleted

عکس العمل: په عمل کې مجازی خدمتونه

سیوري ("ژغورنه") یا منعکس کول ("عکس کول") په هغه قضیو کې کارول کیږي چیرې چې موږ غواړو د پای کاروونکو اغیزه کولو پرته په تولید کې بدلون ازموینه وکړو: د دې کولو لپاره ، موږ دوهم مثال ته د ("عکس") غوښتنې نقل کوو چیرې چې مطلوب بدلونونه رامینځته شوي ، او پایلې یې وګورو. په ساده ډول ووایاست، دا هغه وخت دی چې ستاسو همکار خورا مهم مسله غوره کوي او د دومره لوی کثافاتو په بڼه د ایستلو غوښتنه کوي چې هیڅوک یې په حقیقت کې بیاکتنه نشي کولی.

په عمل کې د دې سناریو ازموینې لپاره، راځئ چې د بګونو سره د SA-Logic دویمه بیلګه جوړه کړو (buggyد لاندې کمانډ په چلولو سره:

$ kubectl apply -f resource-manifests/kube/shadowing/sa-logic-service-buggy.yaml
deployment.extensions/sa-logic-buggy created

او اوس اجازه راکړئ کمانډ پرمخ بوځو ترڅو ډاډ ترلاسه کړئ چې ټول مثالونه سره app=sa-logic دوی د ورته نسخو سره لیبلونه هم لري:

$ kubectl get pods -l app=sa-logic --show-labels
NAME                              READY   LABELS
sa-logic-568498cb4d-2sjwj         2/2     app=sa-logic,version=v1
sa-logic-568498cb4d-p4f8c         2/2     app=sa-logic,version=v1
sa-logic-buggy-76dff55847-2fl66   2/2     app=sa-logic,version=v2
sa-logic-buggy-76dff55847-kx8zz   2/2     app=sa-logic,version=v2

خدمت sa-logic پوډونه د لیبل سره په نښه کوي app=sa-logicنو ټولې غوښتنې به په ټولو مواردو کې وویشل شي:

... مګر موږ غواړو چې غوښتنې د v1 مثالونو ته واستول شي او د v2 مثالونو ته منعکس شي:

موږ به دا د VirtualService له لارې د DestinationRule سره په ترکیب کې ترلاسه کړو، چیرې چې مقررات به یو ځانګړي فرعي سیټ ته د VirtualService فرعي سیټونه او لارې وټاکي.

د منزل په قواعدو کې د فرعي سیټونو تعریف

فرعي سیټونه (سبسیټونه) د لاندې تشکیلاتو لخوا ټاکل کیږي (sa-logic-subset-destinationrule.yaml):

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: sa-logic
spec:
  host: sa-logic    # 1
  subsets:
  - name: v1        # 2
    labels:
      version: v1   # 3
  - name: v2
    labels:
      version: v2

کوربه (host) تعریفوي چې دا قاعده یوازې په قضیو کې پلي کیږي کله چې لاره د خدماتو په لور ځي sa-logic;
عنوانونه (name) فرعي سیټونه کارول کیږي کله چې فرعي سیټ مثالونو ته لاره هواروي؛
لیبل (label) د کلیدي ارزښت جوړه تعریفوي چې مثالونه باید د فرعي سیټ برخه کیدو لپاره سره سمون ولري.

د لاندې کمانډ سره تشکیلات پلي کړئ:

$ kubectl apply -f resource-manifests/istio/shadowing/sa-logic-subsets-destinationrule.yaml
destinationrule.networking.istio.io/sa-logic created

اوس چې فرعي سیټونه تعریف شوي ، موږ کولی شو حرکت وکړو او مجازی خدمت تنظیم کړو ترڅو د سا - منطق غوښتنو ته قواعد پلي کړو ترڅو دوی:

یو سبسیټ ته لیږدول شوی v1,
یوه فرعي سیټ ته منعکس شوی v2.

لاندې منشور تاسو ته اجازه درکوي خپل پلانونه ترلاسه کړئ (sa-logic-subset-shadowing-vs.yaml):

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: sa-logic
spec:
  hosts:
    - sa-logic          
  http:
  - route:
    - destination:
        host: sa-logic  
        subset: v1      
    mirror:             
      host: sa-logic     
      subset: v2

دلته هیڅ وضاحت ته اړتیا نشته، نو راځئ چې دا په عمل کې وګورو:

$ kubectl apply -f resource-manifests/istio/shadowing/sa-logic-subsets-shadowing-vs.yaml
virtualservice.networking.istio.io/sa-logic created

راځئ چې د لاندې کمانډ په زنګ وهلو سره بار اضافه کړو:

$ while true; do curl -v http://$EXTERNAL_IP/sentiment 
    -H "Content-type: application/json" 
    -d '{"sentence": "I love yogobella"}'; 
    sleep .8; done

راځئ چې پایلې په ګرافانا کې وګورو ، چیرې چې تاسو لیدلی شئ چې د کیګونو سره نسخه (buggy) د ~ 60٪ غوښتنو لپاره د ناکامۍ پایله ده، مګر د دې ناکامیو څخه هیڅ یو په پای کاروونکو اغیزه نه کوي ځکه چې دوی ته د روان خدمت لخوا ځواب ویل کیږي.

د sa-logic خدمت د مختلفو نسخو بریالي ځوابونه

دلته موږ لومړی ولیدل چې څنګه مجازی خدمت زموږ د خدماتو سفیرانو ته پلي کیږي: کله sa-web-app غوښتنه کوي sa-logic، دا د sidecar Envoy له لارې تیریږي ، کوم چې - د VirtualService له لارې - د غوښتنې v1 سبسیټ ته د روټ کولو لپاره تنظیم شوی او غوښتنه د خدمت v2 سبسیټ ته عکس ورکوي. sa-logic.

زه پوهیږم، تاسو ممکن دمخه فکر وکړئ چې مجازی خدمتونه ساده دي. په راتلونکې برخه کې، موږ به د دې په ویلو سره پراخ کړو چې دوی هم واقعیا عالي دي.

کانري رول آؤټ

د کانري ګمارنه د یو لږ شمیر کاروونکو ته د غوښتنلیک نوې نسخه وړاندې کولو پروسه ده. دا د دې لپاره کارول کیږي چې ډاډ ترلاسه کړي چې په خوشې کولو کې کومه ستونزه شتون نلري او یوازې له هغې وروسته، مخکې له دې چې د هغې (د خوشې کولو) کیفیت باندې ډاډه وي، نورو کاروونکو ته یې وویشئ.оلوی لیدونکي.

د کانري رول آوټ ښودلو لپاره، موږ به د فرعي سیټ سره کار ته دوام ورکړو buggy у sa-logic.

راځئ چې په لنډو ټکو کې وخت ضایع نکړو او سمدلاسه 20٪ کارونکي د بګونو سره نسخې ته واستوو (دا به زموږ د کانري رول آوټ استازیتوب وکړي) او پاتې 80٪ نورمال خدمت ته. د دې کولو لپاره، لاندې مجازی خدمت وکاروئ (sa-logic-subset-canary-vs.yaml):

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: sa-logic
spec:
  hosts:
    - sa-logic    
  http:
  - route: 
    - destination: 
        host: sa-logic
        subset: v1
      weight: 80         # 1
    - destination: 
        host: sa-logic
        subset: v2
      weight: 20 # 1

1 وزن دی (weight)، کوم چې د غوښتنو فیصدي مشخصوي چې د ترلاسه کونکي یا د ترلاسه کونکي فرعي سیټ ته به لیږل کیږي.

راځئ چې د دې لپاره پخوانی VirtualService ترتیب تازه کړو sa-logic د لاندې کمانډ سره:

$ kubectl apply -f resource-manifests/istio/canary/sa-logic-subsets-canary-vs.yaml
virtualservice.networking.istio.io/sa-logic configured

... او موږ به سمدلاسه وګورو چې ځینې غوښتنې د ناکامۍ لامل کیږي:

$ while true; do 
   curl -i http://$EXTERNAL_IP/sentiment 
   -H "Content-type: application/json" 
   -d '{"sentence": "I love yogobella"}' 
   --silent -w "Time: %{time_total}s t Status: %{http_code}n" 
   -o /dev/null; sleep .1; done
Time: 0.153075s Status: 200
Time: 0.137581s Status: 200
Time: 0.139345s Status: 200
Time: 30.291806s Status: 500

VirtualServices د کانري رول آوټ فعالوي: پدې حالت کې، موږ د مسلو احتمالي اغیزه د کاروونکي بیس 20٪ ته محدوده کړې ده. په زړه پورې! اوس، په هر حالت کې کله چې موږ د خپل کوډ په اړه ډاډه نه یو (په بل عبارت - تل ...)، موږ کولی شو عکس العمل او کانري رول وکاروو.

مهال ویش او بیا هڅه کول

مګر کیګونه تل په کوډ کې پای ته نه رسیږي. په لیست کې له "8 د توزیع شوي کمپیوټري په اړه غلط فهمونه"په لومړي ځای کې دا غلط باور دی چې "شبکه د اعتبار وړ ده." په حقیقت کې شبکه نه د اعتبار وړ، او د دې دلیل لپاره موږ وخت پای ته اړتیا لرو (د وخت ختمېدل) او بیا هڅه کوي (بیا هڅه).

د ښودلو لپاره موږ به د ورته ستونزې نسخې کارولو ته دوام ورکړو sa-logic (buggy)، او موږ به د تصادفي ناکامیو سره د شبکې بې اعتباري تقلید کړو.

اجازه راکړئ چې د بګ سره زموږ خدمت 1/3 چانس ولري چې د ځواب ویلو لپاره ډیر وخت ونیسي، 1/3 د داخلي سرور غلطی سره پای ته رسیدو چانس، او په بریالیتوب سره د پاڼې بیرته راستنیدو 1/3 چانس.

د دې ډول ستونزو اغیزې کمولو او د کاروونکو لپاره ژوند ښه کولو لپاره، موږ کولی شو:

یو مهال ویش اضافه کړئ که چیرې خدمت د ځواب ویلو لپاره له 8 ثانیو څخه ډیر وخت ونیسي ،
بیا هڅه وکړئ که غوښتنه ناکامه شي.

د تطبیق لپاره، موږ به د لاندې سرچینو تعریف وکاروو (sa-logic-retries-timeouts-vs.yaml):

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: sa-logic
spec:
  hosts:
    - sa-logic
  http:
  - route: 
    - destination: 
        host: sa-logic
        subset: v1
      weight: 50
    - destination: 
        host: sa-logic
        subset: v2
      weight: 50
    timeout: 8s           # 1
    retries:
      attempts: 3         # 2
      perTryTimeout: 3s # 3

د غوښتنې وخت پای 8 ثانیو ته ټاکل شوی؛
غوښتنې 3 ځله بیا هڅه کیږي؛
او هره هڅه ناکامه ګڼل کیږي که چیرې د ځواب وخت د 3 ثانیو څخه زیات وي.

دا یو اصلاح دی ځکه چې کاروونکي به د 8 ثانیو څخه ډیر انتظار ونه کړي او موږ به د ناکامۍ په صورت کې د ځواب ترلاسه کولو لپاره درې نوې هڅې وکړو، د بریالي ځواب چانس زیات کړي.

د لاندې کمانډ سره تازه شوي تشکیلات پلي کړئ:

$ kubectl apply -f resource-manifests/istio/retries/sa-logic-retries-timeouts-vs.yaml
virtualservice.networking.istio.io/sa-logic configured

او د ګرافانا ګرافونو کې وګورئ چې د بریالي ځوابونو شمیر پورته پورته شوی دی:

د وخت پای ته رسیدو او بیا هڅو اضافه کولو وروسته د بریالي غبرګون احصایې کې پرمختګ

مخکې له دې چې بلې برخې ته لاړ شئ (یا بلکه، د مقالې بلې برخې ته، ځکه چې پدې کې به نور عملي تجربې شتون ونلري - نږدې ژباړه.)، ړنګول sa-logic-buggy او VirtualService د لاندې کمانډونو په چلولو سره:

$ kubectl delete deployment sa-logic-buggy
deployment.extensions “sa-logic-buggy” deleted
$ kubectl delete virtualservice sa-logic
virtualservice.networking.istio.io “sa-logic” deleted

د سرکټ بریکر او بلک هیډ نمونې

موږ د مایکرو سرویس معمارۍ کې د دوه مهم نمونو په اړه خبرې کوو چې تاسو ته اجازه درکوي د ځان بیا رغونه ترلاسه کړئ (د ځان درملنه) خدمتونه.

سرکټ بریکر ("سرکټ ماتونکی") د غوښتنې د پای ته رسولو لپاره کارول کیږي چې د یو خدمت مثال ته راځي چې غیر صحي ګڼل کیږي او بیا یې بحالوي پداسې حال کې چې د پیرودونکي غوښتنې د دې خدمت صحي مثالونو ته لیږل کیږي (کوم چې د بریالي ځوابونو سلنه زیاتوي). (یادونه: د نمونې نور تفصیلي توضیحات موندل کیدی شي، د بیلګې په توګه، دلته.)

بلک سر ("تقسیم") د خدماتو ناکامۍ د ټول سیسټم اغیزه کولو څخه جلا کوي. د مثال په توګه، خدمت B مات شوی او بل خدمت (د خدمت B پیرودونکي) د خدمت B څخه غوښتنه کوي، چې دا د دې د تار پول ختموي او د نورو غوښتنو خدمت کولو توان نلري (حتی که دوی د B خدمت نه وي). (یادونه: د نمونې نور تفصیلي توضیحات موندل کیدی شي، د بیلګې په توګه، دلته.)

زه به د دې نمونو پلي کولو توضیحات پریږدم ځکه چې دوی موندل اسانه دي رسمي اسناد، او زه هم واقعیا غواړم تصدیق او اختیار وښیم ، کوم چې به د مقالې په راتلونکي برخه کې بحث وشي.

PS د ژباړونکي څخه

زموږ په بلاګ کې هم ولولئ:

"د اسټیو سره مایکرو خدماتو ته بیرته": لومړۍ برخه (د اصلي ځانګړتیاوو پیژندنه), دریمه برخه (تصدیق او جواز);
«کنډیټ - د Kubernetes لپاره د لږ وزن خدمت میش»
«د خدمت میش څه شی دی او زه ولې اړتیا لرم [د مایکرو خدماتو سره د کلاوډ غوښتنلیک لپاره]؟".

سرچینه: www.habr.com

بیرته د اسټیو سره مایکرو خدماتو ته. دریمه برخه