ఇస్టియోతో మైక్రోసర్వీస్‌కి తిరిగి వెళ్ళు. 3 వ భాగము

గమనిక. అనువాదం.: మొదటి భాగం ఈ సిరీస్ ఇస్టియో యొక్క సామర్థ్యాలను తెలుసుకోవడం మరియు వాటిని చర్యలో ప్రదర్శించడం కోసం అంకితం చేయబడింది, రెండవ — చక్కగా ట్యూన్ చేయబడిన రూటింగ్ మరియు నెట్‌వర్క్ ట్రాఫిక్ నిర్వహణ. ఇప్పుడు మేము భద్రత గురించి మాట్లాడుతాము: దానికి సంబంధించిన ప్రాథమిక విధులను ప్రదర్శించడానికి, రచయిత Auth0 గుర్తింపు సేవను ఉపయోగిస్తాడు, అయితే ఇతర ప్రొవైడర్లను ఇదే విధంగా కాన్ఫిగర్ చేయవచ్చు.

మేము ఒక Kubernetes క్లస్టర్‌ను సెటప్ చేసాము, దీనిలో మేము Istio మరియు ఒక ఉదాహరణ మైక్రోసర్వీస్ అప్లికేషన్, సెంటిమెంట్ అనాలిసిస్, Istio యొక్క సామర్థ్యాలను ప్రదర్శించాము.

Istioతో, మేము మా సేవలను చిన్నవిగా ఉంచగలిగాము ఎందుకంటే వారు మళ్లీ ప్రయత్నించడం, గడువు ముగిసింది, సర్క్యూట్ బ్రేకర్లు, ట్రేసింగ్, మానిటరింగ్ వంటి లేయర్‌లను అమలు చేయాల్సిన అవసరం లేదు. అదనంగా, మేము అధునాతన పరీక్ష మరియు విస్తరణ పద్ధతులను ఉపయోగించాము: A/B పరీక్ష, మిర్రరింగ్ మరియు కానరీ రోల్‌అవుట్‌లు.

కొత్త మెటీరియల్‌లో, మేము వ్యాపార విలువకు మార్గంలో చివరి పొరలతో వ్యవహరిస్తాము: ప్రామాణీకరణ మరియు అధికారం - మరియు ఇస్టియోలో ఇది నిజమైన ఆనందం!

ఇస్టియోలో ప్రమాణీకరణ మరియు అధికారం

నేను ప్రమాణీకరణ మరియు అధికారం ద్వారా ప్రేరణ పొందుతానని నేను ఎప్పుడూ నమ్మను. ఈ విషయాలను సరదాగా మరియు మరింత ఎక్కువగా మీకు స్ఫూర్తినిచ్చేలా చేయడానికి సాంకేతిక కోణం నుండి ఇస్టియో ఏమి అందించగలదు?

సమాధానం చాలా సులభం: ఇస్టియో ఈ సామర్థ్యాల బాధ్యతను మీ సేవల నుండి ఎన్వోయ్ ప్రాక్సీకి మారుస్తుంది. అభ్యర్థనలు సేవలను చేరుకునే సమయానికి, అవి ఇప్పటికే ప్రామాణీకరించబడ్డాయి మరియు ప్రామాణీకరించబడ్డాయి, కాబట్టి మీరు చేయాల్సిందల్లా వ్యాపార-ఉపయోగకరమైన కోడ్‌ను వ్రాయడం.

వినడానికి బాగుంది? లోపలికి చూద్దాం!

Auth0తో ప్రమాణీకరణ

ఐడెంటిటీ మరియు యాక్సెస్ మేనేజ్‌మెంట్ కోసం సర్వర్‌గా, మేము Auth0ని ఉపయోగిస్తాము, ఇది ట్రయల్ వెర్షన్‌ను కలిగి ఉంది, ఇది ఉపయోగించడానికి సహజమైనది మరియు నేను దీన్ని ఇష్టపడుతున్నాను. అయితే, అదే సూత్రాలు మరేదైనా వర్తించవచ్చు OpenID కనెక్ట్ అమలులు: కీక్లోక్, ఐడెంటిటీ సర్వర్ మరియు అనేక ఇతరాలు.

ప్రారంభించడానికి, వెళ్ళండి Auth0 పోర్టల్ మీ ఖాతాతో, అద్దెదారుని సృష్టించండి (అద్దెదారు - “అద్దెదారు”, ఐసోలేషన్ యొక్క తార్కిక యూనిట్, మరిన్ని వివరాల కోసం చూడండి డాక్యుమెంటేషన్ - సుమారు అనువాదం.) మరియు వెళ్ళండి అప్లికేషన్లు > డిఫాల్ట్ యాప్ఎంచుకోవడం డొమైన్, దిగువ స్క్రీన్‌షాట్‌లో చూపిన విధంగా:

ఫైల్‌లో ఈ డొమైన్‌ను పేర్కొనండి resource-manifests/istio/security/auth-policy.yaml (మూలం):

apiVersion: authentication.istio.io/v1alpha1
kind: Policy
metadata:
  name: auth-policy
spec:
  targets:
  - name: sa-web-app
  - name: sa-feedback
  origins:
  - jwt:
      issuer: "https://{YOUR_DOMAIN}/"
      jwksUri: "https://{YOUR_DOMAIN}/.well-known/jwks.json"
  principalBinding: USE_ORIGIN

అటువంటి వనరుతో, పైలట్ (ఇస్టియోలోని మూడు ప్రాథమిక కంట్రోల్ ప్లేన్ భాగాలలో ఒకటి - సుమారుగా. అనువాదం.) అభ్యర్థనలను సేవలకు ఫార్వార్డ్ చేయడానికి ముందు వాటిని ప్రామాణీకరించడానికి రాయబారిని కాన్ఫిగర్ చేస్తుంది: sa-web-app и sa-feedback. అదే సమయంలో, సేవా ప్రతినిధులకు కాన్ఫిగరేషన్ వర్తించదు sa-frontend, ఫ్రంట్‌ఎండ్‌ను ప్రామాణీకరించకుండా వదిలివేయడానికి మమ్మల్ని అనుమతిస్తుంది. విధానాన్ని వర్తింపజేయడానికి, ఆదేశాన్ని అమలు చేయండి:

$ kubectl apply -f resource-manifests/istio/security/auth-policy.yaml
policy.authentication.istio.io “auth-policy” created

పేజీకి తిరిగి వెళ్లి అభ్యర్థన చేయండి - ఇది స్థితితో ముగుస్తుందని మీరు చూస్తారు అనధికార సంఖ్య. ఇప్పుడు Auth0తో ప్రామాణీకరించడానికి ఫ్రంటెండ్ వినియోగదారులను దారి మళ్లిద్దాం.

Auth0తో అభ్యర్థనలను ప్రామాణీకరించడం

తుది వినియోగదారు అభ్యర్థనలను ప్రామాణీకరించడానికి, మీరు ప్రామాణీకరించబడిన సేవలను (సమీక్షలు, వివరాలు మరియు రేటింగ్‌లు) సూచించే APIని Auth0లో సృష్టించాలి. APIని సృష్టించడానికి, దీనికి వెళ్లండి Auth0 పోర్టల్ > APIలు > APIని సృష్టించండి మరియు ఫారమ్‌ను పూరించండి:

ఇక్కడ ముఖ్యమైన సమాచారం గుర్తించేది, దీనిని మనం స్క్రిప్ట్‌లో తర్వాత ఉపయోగిస్తాము. దానిని ఇలా వ్రాస్దాము:

• ప్రేక్షకులు: {YOUR_AUDIENCE}

మనకు అవసరమైన మిగిలిన వివరాలు విభాగంలోని Auth0 పోర్టల్‌లో ఉన్నాయి అప్లికేషన్స్ - ఎంచుకోండి పరీక్ష అప్లికేషన్ (APIతో పాటు స్వయంచాలకంగా సృష్టించబడుతుంది).

ఇక్కడ మనం వ్రాస్తాము:

• డొమైన్: {YOUR_DOMAIN}
• క్లయింట్ Id: {YOUR_CLIENT_ID}

దీనికి స్క్రోల్ చేయండి పరీక్ష అప్లికేషన్ టెక్స్ట్ ఫీల్డ్‌కు అనుమతించబడిన కాల్‌బ్యాక్ URLలు (కాల్‌బ్యాక్ కోసం పరిష్కరించబడిన URLలు), దీనిలో ప్రామాణీకరణ పూర్తయిన తర్వాత కాల్ పంపాల్సిన URLని మేము పేర్కొంటాము. మా విషయంలో ఇది:

http://{EXTERNAL_IP}/callback

మరియు కోసం అనుమతించబడిన లాగ్అవుట్ URLలు (లాగ్ అవుట్ చేయడానికి అనుమతించబడిన URLలు) జోడించండి:

http://{EXTERNAL_IP}/logout

ఫ్రంట్‌కి వెళ్దాం.

ఫ్రంటెండ్ నవీకరణ

శాఖకు మారండి auth0 రెపోజిటోరియా [istio-mastery]. ఈ బ్రాంచ్‌లో, ప్రామాణీకరణ కోసం వినియోగదారులను Auth0కి మళ్లించడానికి మరియు ఇతర సేవలకు అభ్యర్థనలలో JWT టోకెన్‌ను ఉపయోగించడానికి ఫ్రంటెండ్ కోడ్ మార్చబడింది. తరువాతి క్రింది విధంగా అమలు చేయబడుతుంది (App.js):

analyzeSentence() {
    fetch('/sentiment', {
        method: 'POST',
        headers: {
            'Content-Type': 'application/json',
            'Authorization': `Bearer ${auth.getAccessToken()}` // Access Token
        },
        body: JSON.stringify({ sentence: this.textField.getValue() })
    })
        .then(response => response.json())
        .then(data => this.setState(data));
}

Auth0లో అద్దెదారు డేటాను ఉపయోగించడానికి ఫ్రంటెండ్‌ని మార్చడానికి, తెరవండి sa-frontend/src/services/Auth.js మరియు మేము పైన వ్రాసిన విలువలను దానిలో భర్తీ చేయండి (Auth.js):

const Config = {
    clientID: '{YOUR_CLIENT_ID}',
    domain:'{YOUR_DOMAIN}',
    audience: '{YOUR_AUDIENCE}',
    ingressIP: '{EXTERNAL_IP}' // Используется для редиректа после аутентификации
}

అప్లికేషన్ సిద్ధంగా ఉంది. చేసిన మార్పులను నిర్మించేటప్పుడు మరియు అమలు చేస్తున్నప్పుడు దిగువ ఆదేశాలలో మీ డాకర్ IDని పేర్కొనండి:

$ docker build -f sa-frontend/Dockerfile 
 -t $DOCKER_USER_ID/sentiment-analysis-frontend:istio-auth0 
 sa-frontend

$ docker push $DOCKER_USER_ID/sentiment-analysis-frontend:istio-auth0

$ kubectl set image deployment/sa-frontend 
 sa-frontend=$DOCKER_USER_ID/sentiment-analysis-frontend:istio-auth0

యాప్‌ని ప్రయత్నించండి! మీరు Auth0కి దారి మళ్లించబడతారు, అక్కడ మీరు లాగిన్ (లేదా నమోదు) చేయాలి, ఆ తర్వాత మీరు ఇప్పటికే ప్రామాణీకరించబడిన అభ్యర్థనలు చేయబడిన పేజీకి తిరిగి పంపబడతారు. మీరు వ్యాసం యొక్క మొదటి భాగాలలో పేర్కొన్న ఆదేశాలను కర్ల్తో ప్రయత్నించినట్లయితే, మీకు కోడ్ వస్తుంది 401 స్థితి కోడ్, అభ్యర్థనకు అధికారం లేదని సూచిస్తోంది.

తదుపరి దశను తీసుకుందాం - అభ్యర్థనలను ప్రామాణీకరించండి.

Auth0తో ఆథరైజేషన్

ప్రామాణీకరణ అనేది వినియోగదారు ఎవరో అర్థం చేసుకోవడానికి అనుమతిస్తుంది, కానీ వారు దేనికి యాక్సెస్ కలిగి ఉన్నారో తెలుసుకోవడానికి అధికారం అవసరం. ఇస్టియో దీని కోసం సాధనాలను కూడా అందిస్తుంది.

ఉదాహరణగా, రెండు వినియోగదారు సమూహాలను సృష్టిద్దాం (క్రింద ఉన్న రేఖాచిత్రాన్ని చూడండి):

• వినియోగదారులు (వినియోగదారులు) — SA-WebApp మరియు SA-Frontend సేవలకు మాత్రమే యాక్సెస్‌తో;
• మోడరేటర్లు (మోడరేటర్లు) - మూడు సేవలకు యాక్సెస్‌తో.

అధికార భావన

ఈ సమూహాలను సృష్టించడానికి, మేము Auth0 ఆథరైజేషన్ పొడిగింపును ఉపయోగిస్తాము మరియు వారికి వివిధ స్థాయిల యాక్సెస్‌ను అందించడానికి Istioని ఉపయోగిస్తాము.

Auth0 ఆథరైజేషన్ యొక్క ఇన్‌స్టాలేషన్ మరియు కాన్ఫిగరేషన్

Auth0 పోర్టల్‌లో, పొడిగింపులకు వెళ్లండి (పొడిగింపులు) మరియు ఇన్స్టాల్ చేయండి Auth0 ఆథరైజేషన్. సంస్థాపన తర్వాత, వెళ్ళండి అధికార పొడిగింపు, మరియు అక్కడ - ఎగువ కుడివైపున క్లిక్ చేసి తగిన మెను ఎంపికను ఎంచుకోవడం ద్వారా అద్దెదారు కాన్ఫిగరేషన్‌కు (ఆకృతీకరణ). సమూహాలను సక్రియం చేయండి (సమూహాలు) మరియు పబ్లిష్ రూల్ బటన్‌పై క్లిక్ చేయండి (పాలనను ప్రచురించు).

సమూహాలను సృష్టిస్తోంది

ఆథరైజేషన్ ఎక్స్‌టెన్షన్‌లో వెళ్ళండి గుంపులు మరియు ఒక సమూహాన్ని సృష్టించండి మధ్యవర్తులు. మేము ప్రామాణీకరించబడిన వినియోగదారులందరినీ సాధారణ వినియోగదారులుగా పరిగణిస్తాము కాబట్టి, వారి కోసం అదనపు సమూహాన్ని సృష్టించాల్సిన అవసరం లేదు.

సమూహాన్ని ఎంచుకోండి మధ్యవర్తులు, ప్రెస్ సభ్యులను జోడించండి, మీ ప్రధాన ఖాతాను జోడించండి. కొంతమంది వినియోగదారులకు యాక్సెస్ నిరాకరించబడిందని నిర్ధారించుకోవడానికి ఏ సమూహం లేకుండా వదిలివేయండి. (కొత్త వినియోగదారులను దీని ద్వారా మాన్యువల్‌గా సృష్టించవచ్చు Auth0 పోర్టల్ > వినియోగదారులు > వినియోగదారుని సృష్టించండి.)

యాక్సెస్ టోకెన్‌కు గ్రూప్ క్లెయిమ్‌ని జోడించండి

వినియోగదారులు సమూహాలకు జోడించబడ్డారు, అయితే ఈ సమాచారం తప్పనిసరిగా యాక్సెస్ టోకెన్‌లలో కూడా ప్రతిబింబించాలి. OpenID Connectకు అనుగుణంగా మరియు అదే సమయంలో మనకు అవసరమైన సమూహాలను తిరిగి ఇవ్వడానికి, టోకెన్ దాని స్వంతదానిని జోడించాలి కస్టమ్ దావా. Auth0 నియమాల ద్వారా అమలు చేయబడింది.

నియమాన్ని రూపొందించడానికి, Auth0 పోర్టల్‌కి వెళ్లండి రూల్స్, ప్రెస్ నియమాన్ని సృష్టించండి మరియు టెంప్లేట్‌ల నుండి ఖాళీ నియమాన్ని ఎంచుకోండి.

దిగువ కోడ్‌ను కాపీ చేసి, దాన్ని కొత్త నియమంగా సేవ్ చేయండి సమూహ దావాను జోడించండి (namespacedGroup.js):

function (user, context, callback) {
    context.accessToken['https://sa.io/group'] = user.groups[0];
    return callback(null, user, context);
}

వ్యాఖ్య: ఈ కోడ్ ఆథరైజేషన్ ఎక్స్‌టెన్షన్‌లో నిర్వచించబడిన మొదటి వినియోగదారు సమూహాన్ని తీసుకుంటుంది మరియు దానిని కస్టమ్ క్లెయిమ్‌గా యాక్సెస్ టోకెన్‌కు జోడిస్తుంది (దీని నేమ్‌స్పేస్ కింద, Auth0 ద్వారా అవసరం).

పేజీకి తిరిగి వెళ్ళు రూల్స్ మరియు మీరు క్రింది క్రమంలో వ్రాసిన రెండు నియమాలను కలిగి ఉన్నారో లేదో తనిఖీ చేయండి:

• auth0-authorization-extension
• సమూహ దావాను జోడించండి

సమూహ ఫీల్డ్ నియమాన్ని అసమకాలికంగా అందుకుంటుంది కాబట్టి ఆర్డర్ ముఖ్యమైనది auth0-authorization-extension మరియు ఆ తర్వాత అది రెండవ నియమం ద్వారా దావాగా జోడించబడుతుంది. ఫలితంగా యాక్సెస్ టోకెన్ ఇలా ఉంటుంది:

{
 "https://sa.io/group": "Moderators",
 "iss": "https://sentiment-analysis.eu.auth0.com/",
 "sub": "google-oauth2|196405271625531691872"
 // [сокращено для наглядности]
}

ఇప్పుడు మీరు వినియోగదారు యాక్సెస్‌ని తనిఖీ చేయడానికి ఎన్వోయ్ ప్రాక్సీని కాన్ఫిగర్ చేయాలి, దీని కోసం సమూహం దావా నుండి తీసివేయబడుతుంది (https://sa.io/group) తిరిగి వచ్చిన యాక్సెస్ టోకెన్‌లో. ఇది వ్యాసం యొక్క తదుపరి విభాగానికి సంబంధించిన అంశం.

ఇస్టియోలో ఆథరైజేషన్ కాన్ఫిగరేషన్

పని చేయడానికి అధికారం కోసం, మీరు తప్పనిసరిగా Istio కోసం RBACని ప్రారంభించాలి. దీన్ని చేయడానికి, మేము ఈ క్రింది కాన్ఫిగరేషన్‌ను ఉపయోగిస్తాము:

apiVersion: "rbac.istio.io/v1alpha1"
kind: RbacConfig
metadata:
  name: default
spec:
  mode: 'ON_WITH_INCLUSION'                     # 1
  inclusion:
    services:                                   # 2
    - "sa-frontend.default.svc.cluster.local"
    - "sa-web-app.default.svc.cluster.local"
    - "sa-feedback.default.svc.cluster.local" 

అర్థము:

• 1 — ఫీల్డ్‌లో జాబితా చేయబడిన సేవలు మరియు నేమ్‌స్పేస్‌ల కోసం మాత్రమే RBACని ప్రారంభించండి Inclusion;
• 2 — మేము మా సేవల జాబితాను జాబితా చేస్తాము.

కింది ఆదేశంతో కాన్ఫిగరేషన్‌ను వర్తింపజేద్దాం:

$ kubectl apply -f resource-manifests/istio/security/enable-rbac.yaml
rbacconfig.rbac.istio.io/default created

అన్ని సేవలకు ఇప్పుడు రోల్-బేస్డ్ యాక్సెస్ కంట్రోల్ అవసరం. మరో మాటలో చెప్పాలంటే, అన్ని సేవలకు ప్రాప్యత నిషేధించబడింది మరియు ప్రతిస్పందనకు దారి తీస్తుంది RBAC: access denied. ఇప్పుడు అధీకృత వినియోగదారులకు యాక్సెస్‌ని అనుమతిద్దాం.

సాధారణ వినియోగదారుల కోసం యాక్సెస్ కాన్ఫిగరేషన్

వినియోగదారులందరూ తప్పనిసరిగా SA-Frontend మరియు SA-WebApp సేవలకు ప్రాప్యత కలిగి ఉండాలి. కింది ఇస్టియో వనరులను ఉపయోగించి అమలు చేయబడింది:

• సర్వీస్ రోల్ - వినియోగదారు కలిగి ఉన్న హక్కులను నిర్ణయిస్తుంది;
• సర్వీస్ రోల్ బైండింగ్ — ఈ సర్వీస్ రోల్ ఎవరికి చెందినదో నిర్ణయిస్తుంది.

సాధారణ వినియోగదారుల కోసం మేము నిర్దిష్ట సేవలకు ప్రాప్యతను అనుమతిస్తాము (servicerole.yaml):

apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRole
metadata:
  name: regular-user
  namespace: default
spec:
  rules:
  - services: 
    - "sa-frontend.default.svc.cluster.local" 
    - "sa-web-app.default.svc.cluster.local"
    paths: ["*"]
    methods: ["*"]

మరియు ద్వారా regular-user-binding పేజీ సందర్శకులందరికీ సర్వీస్‌రోల్‌ని వర్తింపజేయండి (రెగ్యులర్-యూజర్-సర్వీస్-రోల్-బైండింగ్.yaml):

apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRoleBinding
metadata:
  name: regular-user-binding
  namespace: default
spec:
  subjects:
  - user: "*"
  roleRef:
    kind: ServiceRole
    name: "regular-user"

"అందరు వినియోగదారులు" అంటే ప్రమాణీకరించని వినియోగదారులు కూడా SA WebAppకి యాక్సెస్‌ను కలిగి ఉంటారని అర్థం? లేదు, పాలసీ JWT టోకెన్ యొక్క చెల్లుబాటును తనిఖీ చేస్తుంది.

కాన్ఫిగరేషన్‌లను వర్తింపజేద్దాం:

$ kubectl apply -f resource-manifests/istio/security/user-role.yaml
servicerole.rbac.istio.io/regular-user created
servicerolebinding.rbac.istio.io/regular-user-binding created

మోడరేటర్ల కోసం యాక్సెస్ కాన్ఫిగరేషన్

మోడరేటర్‌ల కోసం, మేము అన్ని సేవలకు ప్రాప్యతను ప్రారంభించాలనుకుంటున్నాము (mod-service-role.yaml):

apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRole
metadata:
  name: mod-user
  namespace: default
spec:
  rules:
  - services: ["*"]
    paths: ["*"]
    methods: ["*"]

అయితే యాక్సెస్ టోకెన్‌లో క్లెయిమ్ ఉన్న వినియోగదారులకు మాత్రమే మేము అలాంటి హక్కులను కోరుకుంటున్నాము https://sa.io/group అర్థంతో Moderators (mod-service-role-binding.yaml):

apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRoleBinding
metadata:
  name: mod-user-binding
  namespace: default
spec:
  subjects:
  - properties:
      request.auth.claims[https://sa.io/group]: "Moderators"
  roleRef:
    kind: ServiceRole
name: "mod-user" 

కాన్ఫిగరేషన్‌లను వర్తింపజేద్దాం:

$ kubectl apply -f resource-manifests/istio/security/mod-role.yaml
servicerole.rbac.istio.io/mod-user created
servicerolebinding.rbac.istio.io/mod-user-binding created

ఎన్వోయ్‌లలో కాషింగ్ కారణంగా, అధికార నియమాలు అమలులోకి రావడానికి కొన్ని నిమిషాలు పట్టవచ్చు. వినియోగదారులు మరియు మోడరేటర్‌లకు వివిధ స్థాయిల యాక్సెస్ ఉందని మీరు నిర్ధారించుకోవచ్చు.

ఈ భాగంలో తీర్మానం

అయితే తీవ్రంగా, మీరు ఎప్పుడైనా ప్రామాణీకరణ మరియు అధికారం కోసం సరళమైన, అప్రయత్నంగా, కొలవదగిన మరియు సురక్షితమైన విధానాన్ని చూశారా?

సేవలకు తుది వినియోగదారు యాక్సెస్ యొక్క ప్రమాణీకరణ మరియు అధికారంపై చక్కటి నియంత్రణను సాధించడానికి కేవలం మూడు Istio వనరులు (RbacConfig, ServiceRole మరియు ServiceRoleBinding) అవసరం.

అదనంగా, మేము మా రాయబారి సేవల నుండి ఈ సమస్యలను పరిష్కరించాము, వీటిని సాధించాము:

• భద్రతా సమస్యలు మరియు బగ్‌లను కలిగి ఉండే సాధారణ కోడ్ మొత్తాన్ని తగ్గించడం;
• ఒక ముగింపు బిందువు బయటి నుండి యాక్సెస్ చేయగలదని మరియు దానిని నివేదించడం మరచిపోయిన తెలివితక్కువ పరిస్థితుల సంఖ్యను తగ్గించడం;
• కొత్త పాత్ర లేదా హక్కు జోడించబడిన ప్రతిసారీ అన్ని సేవలను నవీకరించవలసిన అవసరాన్ని తొలగించడం;
• కొత్త సేవలు సరళంగా, సురక్షితంగా మరియు వేగంగా ఉంటాయి.

తీర్మానం

Istio సేవలకు ఓవర్‌హెడ్‌ని జోడించకుండా, వాటిని మైక్రో స్థితికి మార్చకుండా వ్యాపార-క్లిష్టమైన పనులపై తమ వనరులను కేంద్రీకరించడానికి టీమ్‌లను అనుమతిస్తుంది.

కథనం (మూడు భాగాలలో) నిజమైన ప్రాజెక్ట్‌లలో ఇస్టియోతో ప్రారంభించడానికి ప్రాథమిక జ్ఞానం మరియు సిద్ధంగా ఉన్న ఆచరణాత్మక సూచనలను అందించింది.

అనువాదకుని నుండి PS

మా బ్లాగులో కూడా చదవండి:

• "ఇస్టియోతో మైక్రోసర్వీసెస్‌కి తిరిగి వెళ్ళు": పార్ట్ 1 (ప్రధాన లక్షణాల పరిచయం), పార్ట్ 2 (రూటింగ్, ట్రాఫిక్ నియంత్రణ);
• «కండ్యూట్ - కుబెర్నెట్స్ కోసం తేలికపాటి సర్వీస్ మెష్";
• «సర్వీస్ మెష్ అంటే ఏమిటి మరియు నాకు ఇది ఎందుకు అవసరం [మైక్రో సర్వీసెస్‌తో కూడిన క్లౌడ్ అప్లికేషన్ కోసం]?".

మూలం: www.habr.com