🥇 اسٽيو سان مائڪرو سروسز ڏانهن واپس. حصو 2

نوٽ. ترجمو: پهريون حصو هي سلسلو Istio صلاحيتن کي متعارف ڪرائڻ ۽ انهن کي عمل ۾ ڏيکارڻ لاء وقف ڪيو ويو. هاڻي اسان هن سروس ميش جي ترتيب ۽ استعمال جي وڌيڪ پيچيده حصن بابت ڳالهائينداسين، ۽ خاص طور تي، مڪمل طور تي ٺهيل رستن ۽ نيٽورڪ ٽرئفڪ جي انتظام بابت.

اسان توهان کي اهو پڻ ياد ڏياريندا آهيون ته آرٽيڪل مخزن مان ترتيبن کي استعمال ڪري ٿو (Kubernetes ۽ Istio لاءِ ظاهر ٿئي ٿو) استقامت.

ٽرئفڪ جو انتظام

Istio سان، نئين صلاحيتون مهيا ڪرڻ لاء ڪلستر ۾ ظاهر ٿيندا آهن:

متحرڪ درخواست جو رستو: ڪينري رول آئوٽ، 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، ان جي سڀني مثالن ڏانهن منتقل ڪيو ويندو ۽ لوڊ ذريعي ورهايو ويندو گول رابن الگورتھم، جنهن جي ڪري هيٺين صورتحال پيدا ٿيندي:

گهربل فائلون نه مليون

اهي فائلون نه مليون آهن ڇاڪاڻ ته اهي ايپليڪيشن جي مختلف نسخن ۾ مختلف نالا رکيا ويا آهن. اچو ته ان ڳالهه کي يقيني بڻايون:

$ 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 هيڊر. DestinationRules استعمال ڪندي لاڳو ڪيو ويو.

منزل جا ضابطا

کان پوءِ ورچوئل سروس گهربل خدمت ڏانهن هڪ درخواست موڪلي، DestinationRules استعمال ڪندي اسان پاليسين جي وضاحت ڪري سگهون ٿا جيڪي هن خدمت جي مثالن لاءِ مقرر ڪيل ٽرئفڪ تي لاڳو ٿينديون:

Istio وسيلن سان ٽرئفڪ جو انتظام

ويچاري: نيٽ ورڪ ٽرئفڪ تي Istio وسيلن جو اثر هتي پيش ڪيو ويو آهي انهي طريقي سان جيڪو سمجهڻ آسان آهي. درست هجڻ لاءِ، اهو فيصلو جنهن مثال تي درخواست موڪلڻ لاءِ سي آر ڊي ۾ ترتيب ڏنل Ingress Gateway ۾ سفير طرفان ڪيو ويندو آهي.

منزلن جي ضابطن سان، اسان لاڳيتو هيش استعمال ڪرڻ لاءِ لوڊ بيلنس کي ترتيب ڏئي سگھون ٿا ۽ يقيني بڻائي سگھون ٿا ته ساڳئي خدمت جو مثال ساڳئي صارف کي جواب ڏئي ٿو. هيٺ ڏنل ترتيب توهان کي حاصل ڪرڻ جي اجازت ڏئي ٿي (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

ھاڻي ته ذيلي سيٽ بيان ڪيا ويا آھن، اسان اڳتي وڌي سگھون ٿا ۽ ترتيب ڏئي سگھون ٿا VirtualService ضابطن کي لاڳو ڪرڻ لاءِ درخواستن تي sa-logic ته جيئن اھي:

ھڪڙي ذيلي سيٽ ڏانھن روانو ٿيو 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 سروس جي مختلف نسخن جا ڪامياب جواب

هتي اسان پهريون ڀيرو ڏٺو ته ڪيئن VirtualService اسان جي خدمتن جي سفيرن تي لاڳو ٿئي ٿي: جڏهن sa-web-app جي درخواست ڪري ٿو sa-logic، اهو سائڊ ڪار اينوائي ذريعي وڃي ٿو، جيڪو - VirtualService ذريعي - ترتيب ڏنل آهي درخواست کي روٽ ڪرڻ لاءِ v1 سبسٽ ۽ درخواست کي آئيني طور تي خدمت جي v2 سبسيٽ ڏانهن. sa-logic.

مان ڄاڻان ٿو، توهان شايد اڳ ۾ ئي سوچيو ته مجازي خدمتون سادي آهي. ايندڙ حصي ۾، اسان انهي تي وڌندا سين اهو چوڻ سان ته اهي پڻ واقعي عظيم آهن.

ڪينري رول آئوٽ

Canary Deployment هڪ ننڍڙي تعداد ۾ استعمال ڪندڙن لاءِ ايپليڪيشن جي نئين ورجن کي رول آئوٽ ڪرڻ جو عمل آهي. اهو پڪ ڪرڻ لاءِ استعمال ڪيو ويو آهي ته رليز ۾ ڪو به مسئلو ناهي ۽ صرف ان کان پوءِ ، اڳ ۾ ئي ان جي (رليز جي) معيار تي يقين رکندي ، ان کي ٻين استعمال ڪندڙن ۾ ورهايو.оوڌيڪ سامعين.

ڪينري رول آئوٽ کي ظاهر ڪرڻ لاءِ، اسان هڪ ذيلي سيٽ سان ڪم جاري رکنداسين buggy у sa-logic.

اچو ته وقت ضايع نه ڪريون ۽ 20٪ صارفين کي فوري طور تي ورجن ڏانهن موڪليون بگز سان (اهو اسان جي ڪينري رول آئوٽ جي نمائندگي ڪندو) ۽ باقي 80٪ عام خدمت ڏانهن. ائين ڪرڻ لاءِ، ھيٺ ڏنل VirtualService استعمال ڪريو (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٪ صارف جي بنياد تي. عجيب! هاڻي، هر صورت ۾ جڏهن اسان کي اسان جي ڪوڊ جي پڪ نه آهي (ٻين لفظن ۾ - هميشه ...)، اسان استعمال ڪري سگهون ٿا mirroring ۽ canary rollouts.

وقت ختم ٿيڻ ۽ ٻيهر ڪوششون

پر ڪيڙا هميشه ڪوڊ ۾ ختم نه ٿيندا آهن. لسٽ ۾ "تقسيم ٿيل ڪمپيوٽنگ بابت 8 غلط فڪر"پهرين جڳهه تي غلط يقين آهي ته" نيٽ ورڪ قابل اعتماد آهي. حقيقت ۾ نيٽ ورڪ نه قابل اعتماد، ۽ انهي سبب لاء اسان کي وقت جي ضرورت آهي (وقت ختم ٿيڻ) ۽ ٻيهر ڪوشش ڪري ٿو (ٻيهر ڪوشش).

مظاهري لاءِ اسان ساڳيو مسئلو ورزن استعمال ڪندا رهنداسين sa-logic (buggy)، ۽ اسان بي ترتيب ناڪامين سان نيٽ ورڪ جي ناقابل اعتبار کي نقل ڪنداسين.

اچو ته اسان جي خدمت کي بگ سان گڏ جواب ڏيڻ ۾ تمام گهڻو وقت وٺڻ جو 1/3 موقعو، اندروني سرور جي غلطي سان ختم ٿيڻ جو 1/3 موقعو، ۽ صفحي کي ڪاميابيءَ سان واپس ڪرڻ جو 1/3 موقعو.

اهڙن مسئلن جي اثر کي گهٽائڻ ۽ صارفين لاءِ زندگي بهتر بڻائڻ لاءِ، اسان ڪري سگهون ٿا:

هڪ ٽائم آئوٽ شامل ڪريو جيڪڏهن خدمت جواب ڏيڻ ۾ 8 سيڪنڊن کان وڌيڪ وقت وٺي،
ٻيهر ڪوشش ڪريو جيڪڏهن درخواست ناڪام ٿي.

عمل درآمد لاءِ، اسان ھيٺ ڏنل وسيلن جي تعريف استعمال ڪنداسين (sa-logic-retry-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

۽ Grafana گراف ۾ چيڪ ڪريو ته ڪامياب جوابن جو تعداد مٿي وڌي ويو آهي:

ٽائم آئوٽ ۽ ٻيهر ڪوششون شامل ڪرڻ کان پوءِ ڪامياب جوابي انگن اکرن ۾ بهتري

ايندڙ سيڪشن تي وڃڻ کان اڳ (يا بلڪه، مضمون جي ايندڙ حصي ڏانهن، ڇاڪاڻ ته هن ۾ وڌيڪ عملي تجربا نه هوندا - تقريبا. ترجمو.)، حذف ڪريو 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

سرڪٽ برڪر ۽ بلڪ هيڊ پيٽرن

اسان microservice فن تعمير ۾ ٻه اهم نمونن بابت ڳالهائي رهيا آهيون جيڪي توهان کي خود بخود حاصل ڪرڻ جي اجازت ڏين ٿا (خود علاج) خدمتون.

سرڪٽ برنر ("سرڪٽ برڪر") خدمت جي مثال تي اچڻ واري درخواستن کي ختم ڪرڻ لاءِ استعمال ڪيو وڃي ٿو جيڪو غير صحتمند سمجهي وڃي ٿو ۽ ان کي بحال ڪيو وڃي ٿو جڏهن ته ڪلائنٽ جي درخواستن کي ان خدمت جي صحتمند مثالن ڏانهن منتقل ڪيو وڃي ٿو (جيڪو ڪامياب جوابن جو سيڪڙو وڌائي ٿو). (نوٽ: نموني جي وڌيڪ تفصيلي وضاحت ملي سگهي ٿي، مثال طور، هتي.)

بدمعاشي ("پارشن") سڄي سسٽم کي متاثر ڪرڻ کان سروس جي ناڪامي کي الڳ ڪري ٿو. مثال طور، سروس B ڀڄي وئي آهي ۽ ٻي خدمت (سروس B جو ڪلائنٽ) سروس B ڏانهن هڪ درخواست ڪري ٿي، جنهن جي ڪري اهو ان جي ٿريڊ پول کي ختم ڪري ٿو ۽ ٻين درخواستن جي خدمت ڪرڻ جي قابل ناهي (جيتوڻيڪ اهي سروس B کان نه آهن). (نوٽ: نموني جي وڌيڪ تفصيلي وضاحت ملي سگهي ٿي، مثال طور، هتي.)

مان انهن نمونن جي عمل درآمد جي تفصيل کي ختم ڪندس ڇو ته اهي ڳولڻ آسان آهن سرڪاري دستاويز، ۽ مان پڻ واقعي جي تصديق ۽ اختيار ڏيکارڻ چاهيان ٿو، جيڪو مضمون جي ايندڙ حصي ۾ بحث ڪيو ويندو.

پي ايس مترجم کان

اسان جي بلاگ تي پڻ پڙهو:

"Istio سان microservices ڏانهن واپس": حصو 1 (مکيه خصوصيتن جو تعارف), حصو 3 (تصديق ۽ اختيار);
«ڪنڊوٽ - ڪبرنيٽس لاءِ ٿلهي سروس ميش"؛
«سروس ميش ڇا آهي ۽ مون کي ان جي ضرورت ڇو آهي [مائڪرو سروسز سان ڪلائوڊ ايپليڪيشن لاءِ]؟».

جو ذريعو: www.habr.com

Istio سان microservices ڏانهن واپس. حصو 2