🥇 Istio को साथ माइक्रोसर्भिसेसहरूमा फर्कनुहोस्। भाग ३

नोट। अनुवाद।: पहिलो भाग यो श्रृंखला Istio क्षमताहरू परिचय गर्न र तिनीहरूलाई कार्यमा प्रदर्शन गर्न समर्पित थियो। अब हामी यो सेवा जालको कन्फिगरेसन र प्रयोगको थप जटिल पक्षहरूको बारेमा कुरा गर्नेछौं, र विशेष गरी, राम्रोसँग ट्युन गरिएको रूटिङ र नेटवर्क ट्राफिक व्यवस्थापनको बारेमा।

हामी तपाईंलाई यो पनि सम्झाउँछौं कि लेखले भण्डारबाट कन्फिगरेसनहरू (कुबर्नेट्स र इस्टियोका लागि प्रकट गर्दछ) प्रयोग गर्दछ। istio-mastery.

ट्राफिक व्यवस्थापन

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 हेडर। गन्तव्य नियमहरू प्रयोग गरी लागू गरियो।

गन्तव्य नियमहरू

पछि भर्चुअल सेवा इच्छित सेवामा अनुरोध पठाइयो, गन्तव्य नियमहरू प्रयोग गरी हामी नीतिहरू परिभाषित गर्न सक्छौं जुन यस सेवाको उदाहरणहरूको लागि गन्तव्यमा ट्राफिकमा लागू हुनेछ:

Istio स्रोतहरु संग ट्राफिक व्यवस्थापन

भन्नु: नेटवर्क ट्राफिकमा Istio स्रोतहरूको प्रभावलाई बुझ्न सजिलो तरिकाले यहाँ प्रस्तुत गरिएको छ। सटीक हुनको लागि, कुन उदाहरणमा अनुरोध पठाउने निर्णय सीआरडीमा कन्फिगर गरिएको इनग्रेस गेटवेमा राजदूतद्वारा गरिन्छ।

गन्तव्य नियमहरूको साथ, हामी लगातार ह्यासहरू प्रयोग गर्न लोड ब्यालेन्सिङ कन्फिगर गर्न सक्छौं र सुनिश्चित गर्न सक्छौं कि उही सेवा उदाहरणले उही प्रयोगकर्तालाई प्रतिक्रिया दिन्छ। निम्न कन्फिगरेसनले तपाईंलाई यो प्राप्त गर्न अनुमति दिन्छ (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

भन्नु: हेडरमा विभिन्न मानहरू थप्न र ब्राउजरमा सीधा परिणामहरू परीक्षण गर्न, तपाइँ प्रयोग गर्न सक्नुहुन्छ यो विस्तार क्रोममा (वा यो संग फायरफक्सको लागि - लगभग। अनुवाद।).

सामान्यतया, गन्तव्य नियमहरूमा लोड सन्तुलनको क्षेत्रमा अधिक क्षमताहरू छन् - विवरणहरूको लागि जाँच गर्नुहोस् आधिकारिक दस्तावेज.

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 लाई कन्फिगर गर्न सक्छौं ताकि तिनीहरू:

उपसमूहमा रुट गरियो 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

Grafana मा नतिजाहरू हेरौं, जहाँ तपाइँ देख्न सक्नुहुन्छ कि बगहरूको साथ संस्करण (buggy) ~ 60% अनुरोधहरूको लागि असफलताको परिणाम हो, तर यी विफलताहरू मध्ये कुनैले पनि अन्तिम प्रयोगकर्ताहरूलाई असर गर्दैन किनभने तिनीहरू चलिरहेको सेवाद्वारा प्रतिक्रिया दिइन्छ।

sa-logic सेवाको विभिन्न संस्करणहरूको सफल प्रतिक्रियाहरू

यहाँ हामीले पहिले देख्यौं कि कसरी VirtualService हाम्रा सेवाहरूको दूतहरूमा लागू हुन्छ: कहिले sa-web-app गर्न अनुरोध गर्दछ sa-logic, यो साइडकार दूत मार्फत जान्छ, जुन - 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

भर्चुअल सेवाहरूले क्यानरी रोलआउटहरू सक्षम पार्छ: यस अवस्थामा, हामीले समस्याहरूको सम्भावित प्रभावलाई प्रयोगकर्ता आधारको २०% मा सीमित गरेका छौं। अद्भुत! अब, प्रत्येक अवस्थामा जब हामी हाम्रो कोड बारे निश्चित छैनौं (अर्को शब्दमा - सधैं...), हामी मिररिङ र क्यानरी रोलआउटहरू प्रयोग गर्न सक्छौं।

टाइमआउट र पुन: प्रयासहरू

तर बगहरू सधैं कोडमा समाप्त हुँदैन। सूचीमा बाट "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 र भर्चुअल सेवा निम्न आदेशहरू चलाएर:

$ 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

Istio संग microservices मा फर्कनुहोस्। भाग 2