🥇Istio-тэй бичил үйлчилгээ рүү буцах. 2-р хэсэг

Анхаарна уу. орчуулга.: Нэгдүгээр хэсэг Энэ цуврал нь Istio-ийн чадавхийг танилцуулж, үйл ажиллагаандаа үзүүлэхэд зориулагдсан болно. Одоо бид энэхүү үйлчилгээний сүлжээний тохиргоо, ашиглалтын нарийн төвөгтэй талууд, ялангуяа нарийн тохируулсан чиглүүлэлт, сүлжээний хөдөлгөөний удирдлагын талаар ярих болно.

Мөн нийтлэлд репозитороос тохиргоог (Kubernetes болон Istio-д зориулсан манифест) ашигладаг болохыг бид танд сануулж байна. төгс эзэмших.

Замын хөдөлгөөний менежмент

Istio-ийн тусламжтайгаар кластерт дараах шинэ боломжууд гарч ирнэ:

Динамик хүсэлтийн чиглүүлэлт: canary rollouts, A/B тест;
Ачааллыг тэнцвэржүүлэх: энгийн бөгөөд тууштай, хэш дээр суурилсан;
Унасаны дараа сэргээх: завсарлага, дахин оролдлого, таслуур;
Алдаа оруулах: саатал, татгалзсан хүсэлт гэх мэт.

Өгүүллийг үргэлжлүүлэх явцад эдгээр чадваруудыг сонгосон программыг жишээ болгон тайлбарлаж, шинэ ойлголтуудыг танилцуулах болно. Эхний ийм үзэл баримтлал байх болно DestinationRules (өөрөөр хэлбэл траффик/хүсэлт хүлээн авагчийн тухай дүрэм - ойролцоогоор орчуулга), үүний тусламжтайгаар бид A/B тестийг идэвхжүүлдэг.

A/B тест: Практикт байгаа Destination Rules

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,
Pods нь шошготой байдаг 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, статик файлуудын нэг хувилбарыг хүссэн тохиолдолд ачааллын тэнцвэржүүлэгч өөр хувилбартай, тодорхой шалтгааны улмаас ийм файл байхгүй байгаа pods руу илгээж болно. Тиймээс, програм ажиллахын тулд бид хязгаарлалт тавих хэрэгтэй: "index.html-д үйлчилсэн програмын ижил хувилбар нь дараагийн хүсэлтүүдэд үйлчлэх ёстой".

Бид хэш-д суурилсан ачаалал тэнцвэржүүлэлтийг тогтмол хийснээр хүрэх болно (Тогтвортой хэш ачааллыг тэнцвэржүүлэх)Байна. Энэ тохиолдолд ижил үйлчлүүлэгчийн хүсэлтийг ижил backend instance рүү илгээдэг, үүнд урьдчилан тодорхойлсон шинж чанарыг ашигладаг - жишээлбэл, HTTP толгой. DestinationRules ашиглан хэрэгжүүлсэн.

Очих газрын дүрэм

дараа Виртуал үйлчилгээ Хүссэн үйлчилгээ рүү хүсэлт илгээсэн бол DestinationRules-ийг ашиглан бид энэ үйлчилгээний тохиолдлуудад зориулагдсан урсгалд хэрэглэх бодлогыг тодорхойлж болно:

Istio нөөц бүхий замын хөдөлгөөний менежмент

тайлбар: Сүлжээний урсгалд Istio нөөцийн үзүүлэх нөлөөг ойлгоход хялбар байдлаар энд үзүүлэв. Нарийвчилж хэлэхэд, хүсэлтийг аль инстант руу илгээх тухай шийдвэрийг CRD-д тохируулсан 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

тайлбар: Толгой хэсэгт өөр утгыг нэмж, үр дүнг шууд хөтөч дээр шалгахын тулд та ашиглаж болно энэ өргөтгөл Chrome руу (эсвэл үүнтэй хамт Firefox-д - ойролцоогоор. орчуул.).

Ерөнхийдөө 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 инстанцуудад толин тусгал болгохыг хүсэж байна:

Бид үүнийг DestinationRule-тэй хослуулан VirtualService-ээр дамжуулан хийх бөгөөд үүнд дүрмүүд нь ВиртуалҮйлчилгээний дэд багцууд болон тодорхой дэд бүлэгт хүрэх маршрутуудыг тодорхойлох болно.

Очих газрын дүрмийн дэд бүлгүүдийг тодорхойлох

Дэд олонлогууд (дэд олонлогууд) дараах тохиргоогоор тодорхойлогддог (sa-логик-дэд олонлогууд-зориулалтын дүрэм.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-дэд олонлогууд-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-web-app -д хүсэлт гаргадаг sa-logic, энэ нь VirtualService-ээр дамжуулан хүсэлтийг v1 дэд багц руу чиглүүлж, үйлчилгээний v2 дэд олонлогт хүсэлтийг тусгахаар тохируулсан хажуугийн элчээр дамждаг. sa-logic.

Виртуал үйлчилгээ нь энгийн зүйл гэж та бодож магадгүй гэдгийг би мэднэ. Дараагийн хэсэгт бид энэ талаар дэлгэрэнгүй ярих бөгөөд тэд үнэхээр гайхалтай гэдгийг хэлэх болно.

Канарын өнхрөлт

Canary Deployment нь програмын шинэ хувилбарыг цөөн тооны хэрэглэгчдэд хүргэх үйл явц юм. Энэ нь хувилбарт ямар ч асуудал гарахгүй байхын тулд ашиглагддаг бөгөөд үүний дараа (хувилбарын) чанарт аль хэдийн итгэлтэй байгаа тул бусад хэрэглэгчдэд тараана.оилүү том үзэгчид.

Канарын өнгийг харуулахын тулд бид дэд хэсэгтэй үргэлжлүүлэн ажиллах болно buggy у sa-logic.

Өчүүхэн зүйлд цаг үрэхгүй, хэрэглэгчдийн 20% -ийг алдаатай хувилбар руу нэн даруй илгээцгээе (энэ нь манай канарийн хувилбарыг харуулах болно), үлдсэн 80% -ийг ердийн үйлчилгээ рүү илгээцгээе. Үүнийг хийхийн тулд дараах VirtualService (sa-logic-дэд олонлогууд-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

Хэлхээ таслагч ба тусгаарлах байгууламжийн загвар

Бичил үйлчилгээний архитектурт өөрийгөө сэргээх боломжийг олгодог хоёр чухал хэв маягийн талаар бид ярьж байна (өөрийгөө эдгээх) үйлчилгээ.

Цахилгаан хэлхээг таслагч ("хэлхээ таслагч") Энэ нь эрүүл бус гэж тооцогддог үйлчилгээний тохиолдол руу ирж буй хүсэлтийг зогсоож, үйлчлүүлэгчийн хүсэлтийг тухайн үйлчилгээний эрүүл тохиолдол руу дахин чиглүүлэх үед (энэ нь амжилттай хариултын хувийг нэмэгдүүлдэг) сэргээхэд ашиглагддаг. (Тэмдэглэл: Загварын дэлгэрэнгүй тайлбарыг олж болно, жишээлбэл, энд.)

Булш толгой ("хуваалт") үйлчилгээний доголдлыг бүхэлд нь системд нөлөөлөхөөс тусгаарладаг. Жишээлбэл, В үйлчилгээ эвдэрсэн бөгөөд өөр үйлчилгээ (В үйлчилгээний үйлчлүүлэгч) В үйлчилгээнд хүсэлт гаргаснаар энэ нь өөрийн урсгалын нөөцөө шавхаж, бусад хүсэлтэд (Тэдгээр нь В үйлчилгээ биш байсан ч) үйлчлэх боломжгүй болно. (Тэмдэглэл: Загварын дэлгэрэнгүй тайлбарыг олж болно, жишээлбэл, энд.)

Эдгээр хэв маягийн хэрэгжилтийн нарийн ширийн зүйлийг олоход хялбар тул би орхих болно албан ёсны баримт бичиг, мөн би мөн нийтлэлийн дараагийн хэсэгт хэлэлцэх баталгаажуулалт, зөвшөөрлийг харуулахыг үнэхээр хүсч байна.

Орчуулагчийн жич

Мөн манай блог дээрээс уншина уу:

"Istio-тэй микро үйлчилгээ рүү буцах": 1-р хэсэг (үндсэн шинж чанаруудын танилцуулга), 3-р хэсэг (баталгаажуулалт ба зөвшөөрөл);
«Conduit - Kubernetes-д зориулсан хөнгөн үйлчилгээний тор";
«Үйлчилгээний сүлжээ гэж юу вэ, яагаад надад хэрэгтэй байна вэ [микро үйлчилгээ бүхий үүлэн программд]?".

Эх сурвалж: www.habr.com

Istio ашиглан микро үйлчилгээ рүү буцах. 2-р хэсэг