ਇਸਟੀਓ ਦੇ ਨਾਲ ਮਾਈਕ੍ਰੋ ਸਰਵਿਸਿਜ਼ 'ਤੇ ਵਾਪਸ ਜਾਓ। ਭਾਗ 2

ਨੋਟ ਕਰੋ। ਅਨੁਵਾਦ: ਪਹਿਲਾ ਹਿੱਸਾ ਇਹ ਲੜੀ Istio ਸਮਰੱਥਾਵਾਂ ਨੂੰ ਪੇਸ਼ ਕਰਨ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਕਾਰਵਾਈ ਵਿੱਚ ਪ੍ਰਦਰਸ਼ਿਤ ਕਰਨ ਲਈ ਸਮਰਪਿਤ ਸੀ। ਹੁਣ ਅਸੀਂ ਇਸ ਸੇਵਾ ਜਾਲ ਦੀ ਸੰਰਚਨਾ ਅਤੇ ਵਰਤੋਂ ਦੇ ਹੋਰ ਗੁੰਝਲਦਾਰ ਪਹਿਲੂਆਂ ਬਾਰੇ ਗੱਲ ਕਰਾਂਗੇ, ਅਤੇ ਖਾਸ ਤੌਰ 'ਤੇ, ਬਾਰੀਕ ਟਿਊਨਡ ਰੂਟਿੰਗ ਅਤੇ ਨੈਟਵਰਕ ਟ੍ਰੈਫਿਕ ਪ੍ਰਬੰਧਨ ਬਾਰੇ।

ਅਸੀਂ ਤੁਹਾਨੂੰ ਇਹ ਵੀ ਯਾਦ ਦਿਵਾਉਂਦੇ ਹਾਂ ਕਿ ਲੇਖ ਰਿਪੋਜ਼ਟਰੀ ਤੋਂ ਸੰਰਚਨਾਵਾਂ (ਕੁਬਰਨੇਟਸ ਅਤੇ ਇਸਟੀਓ ਲਈ ਮੈਨੀਫੈਸਟ) ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ 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

ਹਰੇ ਸੰਸਕਰਣ ਲਈ ਡਿਪਲਾਇਮੈਂਟ ਮੈਨੀਫੈਸਟ ਦੋ ਥਾਵਾਂ 'ਤੇ ਵੱਖਰਾ ਹੈ:

1. ਚਿੱਤਰ ਇੱਕ ਵੱਖਰੇ ਟੈਗ 'ਤੇ ਅਧਾਰਤ ਹੈ - istio-green,
2. ਫਲੀਆਂ ਦਾ ਇੱਕ ਲੇਬਲ ਹੁੰਦਾ ਹੈ 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 ਸਿਰਲੇਖ। Destination Rules ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਲਾਗੂ ਕੀਤਾ ਗਿਆ।

ਮੰਜ਼ਿਲ ਦੇ ਨਿਯਮ

ਬਾਅਦ ਵਰਚੁਅਲ ਸੇਵਾ ਨੇ ਲੋੜੀਂਦੀ ਸੇਵਾ ਨੂੰ ਬੇਨਤੀ ਭੇਜੀ ਹੈ, DestinationRules ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਅਸੀਂ ਅਜਿਹੀਆਂ ਨੀਤੀਆਂ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰ ਸਕਦੇ ਹਾਂ ਜੋ ਇਸ ਸੇਵਾ ਦੀਆਂ ਉਦਾਹਰਣਾਂ ਲਈ ਨਿਯਤ ਟ੍ਰੈਫਿਕ 'ਤੇ ਲਾਗੂ ਕੀਤੀਆਂ ਜਾਣਗੀਆਂ:

Istio ਸਰੋਤਾਂ ਨਾਲ ਟ੍ਰੈਫਿਕ ਪ੍ਰਬੰਧਨ

ਟਿੱਪਣੀ: ਨੈੱਟਵਰਕ ਟ੍ਰੈਫਿਕ 'ਤੇ Istio ਸਰੋਤਾਂ ਦੇ ਪ੍ਰਭਾਵ ਨੂੰ ਇੱਥੇ ਇਸ ਤਰੀਕੇ ਨਾਲ ਪੇਸ਼ ਕੀਤਾ ਗਿਆ ਹੈ ਜੋ ਸਮਝਣਾ ਆਸਾਨ ਹੈ। ਸਟੀਕ ਹੋਣ ਲਈ, ਇਹ ਫੈਸਲਾ ਕਿ ਕਿਸ ਉਦਾਹਰਨ 'ਤੇ ਬੇਨਤੀ ਭੇਜਣੀ ਹੈ, 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 ਵਿੱਚ ਲੋਡ ਸੰਤੁਲਨ ਦੇ ਖੇਤਰ ਵਿੱਚ ਵਧੇਰੇ ਸਮਰੱਥਾਵਾਂ ਹਨ - ਵਿੱਚ ਵੇਰਵਿਆਂ ਲਈ ਜਾਂਚ ਕਰੋ ਅਧਿਕਾਰਤ ਦਸਤਾਵੇਜ਼.

ਵਰਚੁਅਲ ਸਰਵਿਸ ਦਾ ਹੋਰ ਅਧਿਐਨ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਆਓ ਹੇਠਾਂ ਦਿੱਤੀਆਂ ਕਮਾਂਡਾਂ ਨੂੰ ਚਲਾ ਕੇ ਐਪਲੀਕੇਸ਼ਨ ਦੇ "ਹਰੇ ਸੰਸਕਰਣ" ਅਤੇ ਸੰਬੰਧਿਤ ਟ੍ਰੈਫਿਕ ਦਿਸ਼ਾ ਨਿਯਮ ਨੂੰ ਮਿਟਾ ਦੇਈਏ:

$ 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 ਮੌਕਿਆਂ 'ਤੇ ਪ੍ਰਤੀਬਿੰਬ ਕੀਤਾ ਜਾਵੇ:

ਅਸੀਂ 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

1. ਮੇਜ਼ਬਾਨ (host) ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ ਕਿ ਇਹ ਨਿਯਮ ਸਿਰਫ਼ ਉਹਨਾਂ ਮਾਮਲਿਆਂ 'ਤੇ ਲਾਗੂ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਰੂਟ ਸੇਵਾ ਵੱਲ ਜਾਂਦਾ ਹੈ sa-logic;
2. ਸਿਰਲੇਖ (name) ਉਪ-ਸੈੱਟਾਂ ਦੀ ਵਰਤੋਂ ਸਬਸੈੱਟ ਮੌਕਿਆਂ 'ਤੇ ਰੂਟ ਕਰਨ ਵੇਲੇ ਕੀਤੀ ਜਾਂਦੀ ਹੈ;
3. ਲੇਬਲ (label) ਕੁੰਜੀ-ਮੁੱਲ ਦੇ ਜੋੜਿਆਂ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ ਜੋ ਸਬਸੈੱਟ ਦਾ ਹਿੱਸਾ ਬਣਨ ਲਈ ਉਦਾਹਰਨਾਂ ਦਾ ਮੇਲ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।

ਹੇਠ ਦਿੱਤੀ ਕਮਾਂਡ ਨਾਲ ਸੰਰਚਨਾ ਨੂੰ ਲਾਗੂ ਕਰੋ:

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

ਹੁਣ ਜਦੋਂ ਸਬਸੈੱਟ ਪਰਿਭਾਸ਼ਿਤ ਕੀਤੇ ਗਏ ਹਨ, ਅਸੀਂ ਅੱਗੇ ਵਧ ਸਕਦੇ ਹਾਂ ਅਤੇ ਸਾ-ਤਰਕ ਦੀਆਂ ਬੇਨਤੀਆਂ ਲਈ ਨਿਯਮਾਂ ਨੂੰ ਲਾਗੂ ਕਰਨ ਲਈ ਵਰਚੁਅਲ ਸਰਵਿਸ ਨੂੰ ਕੌਂਫਿਗਰ ਕਰ ਸਕਦੇ ਹਾਂ ਤਾਂ ਜੋ ਉਹ:

1. ਇੱਕ ਸਬਸੈੱਟ ਲਈ ਰੂਟ ਕੀਤਾ ਗਿਆ v1,
2. ਇੱਕ ਸਬਸੈੱਟ ਲਈ ਪ੍ਰਤੀਬਿੰਬਿਤ ਕੀਤਾ ਗਿਆ 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-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

ਵਰਚੁਅਲ ਸੇਵਾਵਾਂ ਕੈਨਰੀ ਰੋਲਆਉਟਸ ਨੂੰ ਸਮਰੱਥ ਬਣਾਉਂਦੀਆਂ ਹਨ: ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਅਸੀਂ ਮੁੱਦਿਆਂ ਦੇ ਸੰਭਾਵੀ ਪ੍ਰਭਾਵ ਨੂੰ ਉਪਭੋਗਤਾ ਅਧਾਰ ਦੇ 20% ਤੱਕ ਸੀਮਤ ਕਰ ਦਿੱਤਾ ਹੈ। ਸ਼ਾਨਦਾਰ! ਹੁਣ, ਹਰ ਮਾਮਲੇ ਵਿੱਚ ਜਦੋਂ ਅਸੀਂ ਆਪਣੇ ਕੋਡ ਬਾਰੇ ਯਕੀਨੀ ਨਹੀਂ ਹੁੰਦੇ (ਦੂਜੇ ਸ਼ਬਦਾਂ ਵਿੱਚ - ਹਮੇਸ਼ਾ...), ਅਸੀਂ ਮਿਰਰਿੰਗ ਅਤੇ ਕੈਨਰੀ ਰੋਲਆਊਟਸ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹਾਂ।

ਸਮਾਂ ਸਮਾਪਤ ਅਤੇ ਮੁੜ ਕੋਸ਼ਿਸ਼ਾਂ

ਪਰ ਬੱਗ ਹਮੇਸ਼ਾ ਕੋਡ ਵਿੱਚ ਖਤਮ ਨਹੀਂ ਹੁੰਦੇ ਹਨ। ਤੋਂ ਸੂਚੀ ਵਿੱਚ "ਡਿਸਟਰੀਬਿਊਟਿਡ ਕੰਪਿਊਟਿੰਗ ਬਾਰੇ 8 ਗਲਤ ਧਾਰਨਾਵਾਂ"ਪਹਿਲਾਂ ਸਥਾਨ ਵਿੱਚ ਇਹ ਗਲਤ ਵਿਸ਼ਵਾਸ ਹੈ ਕਿ "ਨੈੱਟਵਰਕ ਭਰੋਸੇਯੋਗ ਹੈ।" ਅਸਲ ਵਿੱਚ ਨੈੱਟਵਰਕ ਨਾ ਭਰੋਸੇਮੰਦ, ਅਤੇ ਇਸ ਕਾਰਨ ਕਰਕੇ ਸਾਨੂੰ ਸਮਾਂ ਸਮਾਪਤੀ ਦੀ ਲੋੜ ਹੈ (ਸਮਾਂ ਸਮਾਪਤ) ਅਤੇ ਮੁੜ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ (ਮੁੜ ਕੋਸ਼ਿਸ਼).

ਪ੍ਰਦਰਸ਼ਨ ਲਈ ਅਸੀਂ ਉਸੇ ਸਮੱਸਿਆ ਵਾਲੇ ਸੰਸਕਰਣ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਜਾਰੀ ਰੱਖਾਂਗੇ sa-logic (buggy), ਅਤੇ ਅਸੀਂ ਬੇਤਰਤੀਬੇ ਅਸਫਲਤਾਵਾਂ ਦੇ ਨਾਲ ਨੈਟਵਰਕ ਦੀ ਭਰੋਸੇਯੋਗਤਾ ਦੀ ਨਕਲ ਕਰਾਂਗੇ।

ਬੱਗਾਂ ਵਾਲੀ ਸਾਡੀ ਸੇਵਾ ਨੂੰ ਜਵਾਬ ਦੇਣ ਵਿੱਚ ਬਹੁਤ ਸਮਾਂ ਲੱਗਣ ਦੀ 1/3 ਸੰਭਾਵਨਾ, ਅੰਦਰੂਨੀ ਸਰਵਰ ਗਲਤੀ ਨਾਲ ਖਤਮ ਹੋਣ ਦੀ 1/3 ਸੰਭਾਵਨਾ, ਅਤੇ ਪੇਜ ਨੂੰ ਸਫਲਤਾਪੂਰਵਕ ਵਾਪਸ ਕਰਨ ਦੀ 1/3 ਸੰਭਾਵਨਾ ਹੈ।

ਅਜਿਹੀਆਂ ਸਮੱਸਿਆਵਾਂ ਦੇ ਪ੍ਰਭਾਵ ਨੂੰ ਘਟਾਉਣ ਅਤੇ ਉਪਭੋਗਤਾਵਾਂ ਲਈ ਜੀਵਨ ਨੂੰ ਬਿਹਤਰ ਬਣਾਉਣ ਲਈ, ਅਸੀਂ ਇਹ ਕਰ ਸਕਦੇ ਹਾਂ:

1. ਇੱਕ ਸਮਾਂ ਸਮਾਪਤ ਜੋੜੋ ਜੇਕਰ ਸੇਵਾ ਨੂੰ ਜਵਾਬ ਦੇਣ ਵਿੱਚ 8 ਸਕਿੰਟਾਂ ਤੋਂ ਵੱਧ ਸਮਾਂ ਲੱਗਦਾ ਹੈ,
2. ਜੇਕਰ ਬੇਨਤੀ ਅਸਫਲ ਹੋ ਜਾਂਦੀ ਹੈ ਤਾਂ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰੋ।

ਲਾਗੂ ਕਰਨ ਲਈ, ਅਸੀਂ ਹੇਠਾਂ ਦਿੱਤੀ ਸਰੋਤ ਪਰਿਭਾਸ਼ਾ ਦੀ ਵਰਤੋਂ ਕਰਾਂਗੇ (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

1. ਬੇਨਤੀ ਲਈ ਸਮਾਂ ਸਮਾਪਤ 8 ਸਕਿੰਟ ਲਈ ਸੈੱਟ ਕੀਤਾ ਗਿਆ ਹੈ;
2. ਬੇਨਤੀਆਂ ਦੀ 3 ਵਾਰ ਮੁੜ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ ਜਾਂਦੀ ਹੈ;
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 ਅਤੇ ਹੇਠ ਲਿਖੀਆਂ ਕਮਾਂਡਾਂ ਚਲਾ ਕੇ ਵਰਚੁਅਲ ਸਰਵਿਸ:

$ 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 ਤੋਂ ਨਾ ਹੋਣ)। (ਨੋਟ: ਪੈਟਰਨ ਦਾ ਵਧੇਰੇ ਵਿਸਤ੍ਰਿਤ ਵੇਰਵਾ ਪਾਇਆ ਜਾ ਸਕਦਾ ਹੈ, ਉਦਾਹਰਨ ਲਈ, ਇੱਥੇ.)

ਮੈਂ ਇਹਨਾਂ ਪੈਟਰਨਾਂ ਦੇ ਲਾਗੂਕਰਨ ਵੇਰਵਿਆਂ ਨੂੰ ਛੱਡ ਦੇਵਾਂਗਾ ਕਿਉਂਕਿ ਉਹਨਾਂ ਨੂੰ ਲੱਭਣਾ ਆਸਾਨ ਹੈ ਅਧਿਕਾਰਤ ਦਸਤਾਵੇਜ਼, ਅਤੇ ਮੈਂ ਅਸਲ ਵਿੱਚ ਪ੍ਰਮਾਣਿਕਤਾ ਅਤੇ ਪ੍ਰਮਾਣਿਕਤਾ ਦਿਖਾਉਣਾ ਚਾਹੁੰਦਾ ਹਾਂ, ਜਿਸ ਬਾਰੇ ਲੇਖ ਦੇ ਅਗਲੇ ਹਿੱਸੇ ਵਿੱਚ ਚਰਚਾ ਕੀਤੀ ਜਾਵੇਗੀ।

ਅਨੁਵਾਦਕ ਤੋਂ ਪੀ.ਐਸ

ਸਾਡੇ ਬਲੌਗ 'ਤੇ ਵੀ ਪੜ੍ਹੋ:

• "ਇਸਟੀਓ ਨਾਲ ਮਾਈਕ੍ਰੋ ਸਰਵਿਸਿਜ਼ 'ਤੇ ਵਾਪਸ ਜਾਓ": ਭਾਗ 1 (ਮੁੱਖ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦੀ ਜਾਣ ਪਛਾਣ), ਭਾਗ 3 (ਪ੍ਰਮਾਣਿਕਤਾ ਅਤੇ ਅਧਿਕਾਰ);
• «ਕੰਡਿਊਟ - ਕੁਬਰਨੇਟਸ ਲਈ ਹਲਕਾ ਸੇਵਾ ਜਾਲ";
• «ਇੱਕ ਸੇਵਾ ਜਾਲ ਕੀ ਹੈ ਅਤੇ ਮੈਨੂੰ [ਮਾਈਕ੍ਰੋਸਰਵਿਸਿਜ਼ ਦੇ ਨਾਲ ਕਲਾਉਡ ਐਪਲੀਕੇਸ਼ਨ ਲਈ] ਇਸਦੀ ਕਿਉਂ ਲੋੜ ਹੈ?".

ਸਰੋਤ: www.habr.com