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

Анхаарна уу. орчуулга.: Үйлчилгээний тор нь микро үйлчилгээний архитектурыг дагаж мөрддөг хэрэглээний орчин үеийн дэд бүтцэд тохирох шийдэл болсон нь гарцаагүй. Istio нь DevOps-ийн олон инженерүүдийн амнаас гарсан байж болох ч энэ нь нэлээн шинэ бүтээгдэхүүн бөгөөд боломжийн хувьд иж бүрэн боловч танилцахад ихээхэн цаг хугацаа шаардагддаг. Харилцаа холбооны Orange Networks компанийн томоохон үйлчлүүлэгчдэд зориулсан үүлэн тооцоолол хариуцсан Германы инженер Ринор Малоку Istio руу хурдан, гүн гүнзгий шумбах боломжийг олгодог гайхалтай цуврал материалыг бичжээ. Тэрээр Истио ерөнхийдөө юу хийж чадах, та үүнийг өөрийн нүдээр хэрхэн хурдан харж чадах вэ гэдгээс түүхээ эхэлдэг.

Истио — Google, IBM, Lyft-ийн багуудтай хамтран боловсруулсан Нээлттэй эхийн төсөл. Энэ нь микро үйлчилгээнд суурилсан програмуудад үүсдэг нарийн төвөгтэй асуудлуудыг шийддэг, тухайлбал:

Замын хөдөлгөөний менежмент: завсарлага, дахин оролдлого, ачааллыг тэнцвэржүүлэх;
Аюулгүй байдал: эцсийн хэрэглэгчийн баталгаажуулалт ба зөвшөөрөл;
Ажиглах чадвар: мөрдөх, хянах, бүртгэл хөтлөх.

Эдгээрийг бүгдийг нь хэрэглээний түвшинд шийдэж болох боловч үүний дараа таны үйлчилгээ "микро" байхаа болино. Эдгээр асуудлыг шийдвэрлэх нэмэлт хүчин чармайлт нь компанийн нөөцийг шууд бизнесийн үнэ цэнийн төлөө ашиглаж болох үр ашиг юм. Нэг жишээг харцгаая:

Төслийн менежер: Санал хүсэлтийг нэмэхэд хэр хугацаа шаардагдах вэ?
Хөгжүүлэгч: Хоёр спринт.

УИХ-ын гишүүн: Юу?.. Энэ бол зүгээр л CRUD!
R: CRUD хийх нь хялбар хэсэг боловч бид хэрэглэгчид болон үйлчилгээг баталгаажуулах, зөвшөөрөл олгох шаардлагатай хэвээр байна. Сүлжээ нь найдваргүй тул та давтан хүсэлтийг хэрэгжүүлэх шаардлагатай болно Хэлхээ таслагчийн загвар үйлчлүүлэгчдэд. Түүнчлэн, систем бүхэлдээ гацахгүй байхын тулд танд завсарлага болон хананууд (дурдагдсан хоёр хэв маягийн талаар дэлгэрэнгүй мэдээллийг өгүүллийн дараа үзнэ үү - ойролцоогоор орчуулга.), мөн асуудлыг илрүүлэхийн тулд хяналт тавих, мөрдөх, […]
УИХ-ын гишүүн: Өө, энэ функцийг Бүтээгдэхүүний үйлчилгээнд оруулъя.

Санаа нь ойлгомжтой гэж бодож байна: нэг үйлчилгээг нэмэхэд шаардагдах алхам, хүчин чармайлт асар их юм. Энэ нийтлэлд бид Istio үйлчилгээнүүдээс дээр дурдсан бүх нарийн төвөгтэй байдлыг (энэ нь бизнесийн логик биш) хэрхэн арилгахыг авч үзэх болно.

тайлбар: Энэ нийтлэл нь таныг Kubernetes-ийн талаар мэдлэгтэй гэж үзэж байна. Үгүй бол би уншихыг зөвлөж байна миний Kubernetes-ийн танилцуулга Үүний дараа л энэ материалыг үргэлжлүүлэн уншаарай.

Istio санаа

Istio-гүй ертөнцөд нэг үйлчилгээ нөгөө рүү шууд хүсэлт гаргадаг бөгөөд бүтэлгүйтсэн тохиолдолд үйлчилгээ өөрөө үүнийг зохицуулах ёстой: шинэ оролдлого хийх, завсарлага өгөх, таслуур нээх гэх мэт.

Кубернетес дэх сүлжээний траффик

Istio нь үйлчилгээнээс бүрэн тусгаарлагдсан тусгай шийдлийг санал болгож, сүлжээний харилцаанд саад учруулж ажилладаг. Тиймээс энэ нь хэрэгжүүлдэг:

алдааг тэсвэрлэх чадвар: Хариулт дахь статусын код дээр үндэслэн хүсэлт амжилтгүй болсон эсэхийг ойлгож, дахин гүйцэтгэнэ.
Канарын өнхрөлт: үйлчилгээний шинэ хувилбарт хүсэлтийн зөвхөн тодорхой хувийг дахин чиглүүлдэг.
Хяналт ба хэмжүүр: Үйлчилгээ хариу өгөхөд хэр удсан бэ?
Мөшгих ба ажиглах чадвар: Хүсэлт бүрт тусгай гарчиг нэмж, кластер даяар тэмдэглэнэ.
Аюулгүй байдал: JWT токеныг татаж, хэрэглэгчдийг баталгаажуулж, зөвшөөрөл өгдөг.

Эдгээр нь таны сонирхлыг татах цөөн хэдэн боломжууд юм (үнэхээр хэдхэн!). Одоо техникийн нарийн ширийн зүйлийг авч үзье!

Архитектур

Istio нь бүх сүлжээний траффикийг таслан зогсоож, түүнд хэд хэдэн дүрмийг мөрддөг бөгөөд под тус бүрт хажуугийн сав хэлбэрээр ухаалаг прокси оруулдаг. Бүх чадварыг идэвхжүүлдэг прокси a Өгөгдлийн хавтгай, мөн тэдгээрийг ашиглан динамикаар тохируулж болно Хяналтын онгоц.

Өгөгдлийн хавтгай

Pod-д оруулсан прокси нь Istio-д бидэнд шаардлагатай шаардлагыг хялбархан хангах боломжийг олгодог. Жишээлбэл, дахин оролдох, таслагчийн функцийг шалгая.

Envoy-д дахин оролдох болон хэлхээг таслах үйлдлийг хэрхэн хэрэгжүүлдэг вэ

Дүгнэлт:

элч (бид хажуугийн саванд байрладаг проксины тухай ярьж байна тусдаа бүтээгдэхүүн - ойролцоогоор. орчуул.) Б үйлчилгээний эхний ээлжинд хүсэлт илгээж амжилтгүй болсон.
Элч Сайдкар дахин оролдов (дахин оролдох). (1)
Хүсэлт амжилтгүй болж, түүнийг дуудсан прокси руу буцна.
Энэ нь Circuit Breaker-ийг нээж, дараагийн хүсэлтийг авахын тулд дараагийн үйлчилгээг дууддаг. (2)

Энэ нь та өөр дахин оролдох номын сан ашиглах шаардлагагүй, X, Y эсвэл Z програмчлалын хэл дээр Хэлхээ таслах болон Үйлчилгээний нээлтийг өөрөө хийх шаардлагагүй гэсэн үг. Энэ болон бусад олон зүйлийг хайрцагнаас авах боломжтой. Istio-д байгаа бөгөөд шаарддаггүй Үгүй кодын өөрчлөлт.

Агуу их! Одоо та Истиотой хамт аялалд гарахыг хүсч магадгүй ч танд эргэлзээтэй, нээлттэй асуултууд байсаар байна. Хэрэв энэ нь амьдралын бүх тохиолдлуудад зориулсан бүх нийтийн шийдэл юм бол танд байгалийн сэжиг төрж байна: эцсийн эцэст ийм бүх шийдэл нь бодит байдал дээр ямар ч тохиолдолд тохиромжгүй болж хувирдаг.

Эцэст нь та: "Үүнийг өөрчлөх боломжтой юу?"

Одоо та далайн аялалд бэлэн боллоо, Удирдлагын онгоцтой танилцацгаая.

Хяналтын онгоц

Энэ нь гурван бүрэлдэхүүн хэсгээс бүрдэнэ: Туршилт, Холигч и Citadel, эдгээр нь элч нарыг замын хөдөлгөөнийг чиглүүлэх, бодлогыг хэрэгжүүлэх, телеметрийн өгөгдөл цуглуулах зорилгоор тохируулахад хамтран ажилладаг. Схемийн хувьд бүх зүйл дараах байдлаар харагдаж байна.

Удирдлагын хавтгай ба мэдээллийн хавтгайн харилцан үйлчлэл

Элчийг (өөрөөр хэлбэл өгөгдлийн онгоц) ашиглан тохируулсан Kubernetes CRD (Захиалгат нөөцийн тодорхойлолтууд) Istio тодорхойлсон бөгөөд энэ зорилгоор тусгайлан зориулагдсан. Энэ нь таны хувьд юу гэсэн үг вэ гэвэл тэдгээр нь Кубернетес дэх танил синтакс бүхий өөр нэг нөөц юм. Нэгэнт бий болгосны дараа энэ нөөцийг хяналтын онгоц авч, элч нарт хэрэглэнэ.

Үйлчилгээний Istio-тэй харилцах харилцаа

Бид Istio-ийн үйлчилгээтэй харилцах харилцааг тодорхойлсон боловч эсрэгээр нь биш: үйлчилгээ нь Istio-тэй хэрхэн холбоотой вэ?

Үнэнийг хэлэхэд, үйлчилгээнүүд "Ус гэж юу вэ?" гэж өөрөөсөө асуухад загас устай адил Истиогийн оршихуйг мэддэг.

Уран зураг Виктория Димитракопулос: - Та усанд ямар дуртай вэ? -Ус гэж юу вэ?

Тиймээс та ажлын кластер авч, Istio бүрэлдэхүүн хэсгүүдийг байрлуулсны дараа түүн дээр байрлах үйлчилгээнүүд үргэлжлүүлэн ажиллах бөгөөд эдгээр бүрэлдэхүүн хэсгүүдийг устгасны дараа бүх зүйл дахин хэвийн болно. Энэ тохиолдолд та Istio-ийн өгсөн чадвараа алдах нь тодорхой байна.

Хангалттай онол - энэ мэдлэгээ практикт хэрэгжүүлцгээе!

Istio практик дээр

Istio-д дор хаяж 4 vCPU, 8 ГБ RAM-тай Kubernetes кластер шаардлагатай. Кластерийг хурдан үүсгэж, нийтлэлийн зааврыг дагахын тулд шинэ хэрэглэгчдэд санал болгодог Google Cloud Platform-ийг ашиглахыг зөвлөж байна. 300 доллар үнэгүй.

Кластер үүсгэж, консолын хэрэгслээр дамжуулан Kubernetes-д хандах хандалтыг тохируулсны дараа та Helm багц менежерээр дамжуулан Istio-г суулгаж болно.

Дуулга суурилуулах

-д тайлбарласны дагуу Helm клиентийг компьютер дээрээ суулгана уу албан ёсны баримт бичиг. Бид үүнийг дараагийн хэсэгт Istio суулгах загваруудыг үүсгэхэд ашиглах болно.

Istio суулгаж байна

Isio эх сурвалжийг эндээс татаж авна уу хамгийн сүүлийн хувилбар (1.0.5 хувилбарын анхны зохиогчийн холбоосыг одоогийнх болгон өөрчилсөн, өөрөөр хэлбэл 1.0.6 - ойролцоогоор орчуулга), агуулгыг нэг директор руу задлах бөгөөд би үүнийг цаашид дуудах болно [istio-resources].

Istio нөөцийг хялбархан тодорхойлохын тулд K8s кластерт нэрийн орон зай үүсгэ istio-system:

$ kubectl create namespace istio-system

Лавлах руу очиж суулгацыг дуусгана уу [istio-resources] мөн тушаалыг ажиллуулж байна:

$ helm template install/kubernetes/helm/istio 
  --set global.mtls.enabled=false 
  --set tracing.enabled=true 
  --set kiali.enabled=true 
  --set grafana.enabled=true 
  --namespace istio-system > istio.yaml

Энэ команд нь Istio-ийн гол бүрэлдэхүүн хэсгүүдийг файл руу гаргах болно istio.yaml. Бид дараах параметрүүдийг зааж өгсөн стандарт загварыг өөрсдөдөө тохируулан өөрчилсөн.

global.mtls.enabled суулгасан false (жишээ нь mTLS нэвтрэлт танилт идэвхгүй болсон - ойролцоогоор.)бидний болзох үйл явцыг хялбарчлах;
tracing.enabled Jaeger ашиглан хүсэлтийг мөрдөх;
kiali.enabled үйлчилгээ болон урсгалыг дүрслэн харуулахын тулд Kiali-г кластерт суулгадаг;
grafana.enabled цуглуулсан хэмжигдэхүүнийг дүрслэн харуулахын тулд Grafana суулгана.

Үүсгэсэн нөөцийг дараах тушаалаар ашиглацгаая.

$ kubectl apply -f istio.yaml

Istio-г кластер дээр суулгаж дууслаа! Бүх pods нэрийн талбарт орох хүртэл хүлээнэ үү istio-system боломжтой байх болно Running буюу Completedдоорх тушаалыг ажиллуулснаар:

$ kubectl get pods -n istio-system

Одоо бид програмыг ажиллуулж эхлэх дараагийн хэсэгт үргэлжлүүлэхэд бэлэн боллоо.

Мэдрэмжийн шинжилгээний програмын архитектур

Өмнө дурьдсан зүйлд хэрэглэгдэж буй мэдрэмжийн анализын микро үйлчилгээний програмын жишээг авч үзье Kubernetes-ийн танилцуулга нийтлэл. Энэ нь Истиогийн чадавхийг практикт харуулах хангалттай төвөгтэй юм.

Энэхүү програм нь дөрвөн микро үйлчилгээнээс бүрдэнэ:

үйлчилгээ SA-Фронтенд, энэ нь Reactjs програмын урд хэсэгт үйлчилдэг;
үйлчилгээ SA-WebApp, мэдрэмжийн шинжилгээний асуулгад үйлчилдэг;
үйлчилгээ SA-Логик, энэ нь өөрөө гүйцэтгэдэг мэдрэмжийн шинжилгээ;
үйлчилгээ SA-санал хүсэлт, энэ нь шинжилгээний үнэн зөв байдлын талаар хэрэглэгчдийн санал хүсэлтийг хүлээн авдаг.

Энэ диаграммд үйлчилгээнүүдээс гадна бид Кубернетес дэх ирж буй хүсэлтийг зохих үйлчилгээ рүү чиглүүлдэг Ingress Controller-ийг харж байна. Istio нь Ingress Gateway-ийн хүрээнд ижил төстэй ойлголтыг ашигладаг бөгөөд дэлгэрэнгүй мэдээллийг дараа нь авч үзэх болно.

Istio-ийн прокси ашиглан програм ажиллуулж байна

Өгүүлэлд дурдсан бусад үйлдлүүдийг хийхийн тулд өөрийн агуулахыг клон хийнэ үү төгс эзэмших. Энэ нь Kubernetes болон Istio-д зориулсан програм, манифест агуулдаг.

Хажуугийн тэрэг оруулах

Оруулга хийх боломжтой автоматаар буюу гараар. Хажуугийн савыг автоматаар оруулахын тулд та нэрийн талбарт шошго тавих хэрэгтэй istio-injection=enabled, үүнийг дараах тушаалаар гүйцэтгэнэ.

$ kubectl label namespace default istio-injection=enabled
namespace/default labeled

Одоо өгөгдмөл нэрийн талбарт байршуулах pod бүр (default) хажуугийн саваа хүлээн авна. Үүнийг шалгахын тулд репозиторын үндсэн лавлах руу очиж туршилтын програмыг байрлуулцгаая [istio-mastery] мөн дараах тушаалыг ажиллуулна:

$ kubectl apply -f resource-manifests/kube
persistentvolumeclaim/sqlite-pvc created
deployment.extensions/sa-feedback created
service/sa-feedback created
deployment.extensions/sa-frontend created
service/sa-frontend created
deployment.extensions/sa-logic created
service/sa-logic created
deployment.extensions/sa-web-app created
service/sa-web-app created

Үйлчилгээг байрлуулсны дараа командыг ажиллуулж, хонхорцог нь хоёр савтай (үйлчилгээ нь өөрөө болон хажуугийн тэрэгтэй) байгаа эсэхийг шалгацгаая. kubectl get pods мөн баганын доор байгаа эсэхийг шалгах READY утгыг тодорхойлсон 2/2, хоёр контейнер ажиллаж байгааг илтгэнэ:

$ kubectl get pods
NAME                           READY     STATUS    RESTARTS   AGE
sa-feedback-55f5dc4d9c-c9wfv   2/2       Running   0          12m
sa-frontend-558f8986-hhkj9     2/2       Running   0          12m
sa-logic-568498cb4d-2sjwj      2/2       Running   0          12m
sa-logic-568498cb4d-p4f8c      2/2       Running   0          12m
sa-web-app-599cf47c7c-s7cvd    2/2       Running   0          12m

Харааны хувьд энэ нь иймэрхүү харагдаж байна:

Элч төлөөлөгчийн аль нэгэнд байгаа

Одоо програм ажиллаж байгаа тул бид ирж буй урсгалыг програм руу оруулахыг зөвшөөрөх шаардлагатай болно.

Нэвтрэх гарц

Үүнд хүрэх хамгийн сайн туршлага бол (кластер доторх хөдөлгөөнийг зөвшөөрөх) юм Нэвтрэх гарц кластерын "ирмэг" дээр байрлах Istio-д чиглүүлэлт, ачаалал тэнцвэржүүлэх, аюулгүй байдал, ирж буй урсгалыг хянах зэрэг Istio функцуудыг идэвхжүүлэх боломжийг олгодог.

Ingress Gateway бүрэлдэхүүн хэсэг болон түүнийг гадагш дамжуулах үйлчилгээг Istio суулгацын үед кластерт суулгасан. Үйлчилгээний гадаад IP хаягийг мэдэхийн тулд дараахыг ажиллуулна уу:

$ kubectl get svc -n istio-system -l istio=ingressgateway
NAME                   TYPE           CLUSTER-IP     EXTERNAL-IP
istio-ingressgateway   LoadBalancer   10.0.132.127   13.93.30.120

Бид энэ IP-г ашиглан програм руу үргэлжлүүлэн хандах болно (би үүнийг ГАДААД-IP гэж нэрлэх болно), тиймээс хялбар болгох үүднээс утгыг хувьсагч болгон бичнэ:

$ EXTERNAL_IP=$(kubectl get svc -n istio-system 
  -l app=istio-ingressgateway 
  -o jsonpath='{.items[0].status.loadBalancer.ingress[0].ip}')

Хэрэв та одоо хөтөчөөр дамжуулан энэ IP хаяг руу нэвтрэхийг оролдвол "Үйлчилгээний боломжгүй" гэсэн алдаа гарах болно анхдагчаар Istio нь ирж буй бүх урсгалыг хаадаг, Гарц хараахан тодорхойлогдоогүй байна.

Гарцын нөөц

Gateway нь Kubernetes дахь CRD (Захиалгат нөөцийн тодорхойлолт) бөгөөд кластерт Istio суулгасны дараа тодорхойлогдсон бөгөөд бидний ирж буй траффикийг зөвшөөрөхийг хүссэн порт, протокол болон хостуудыг зааж өгөх боломжийг олгодог.

Манай тохиолдолд бид бүх хостуудад 80-р порт дээр HTTP урсгалыг зөвшөөрөхийг хүсч байна. Даалгаврыг дараах тодорхойлолтоор хэрэгжүүлнэ (http-gateway.yaml):

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: http-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
- "*"

Энэ тохиргоонд сонгогчоос бусад тайлбар шаардлагагүй istio: ingressgateway. Энэ сонгогчоор бид тохиргоог аль Ingress Gateway-д хэрэглэхийг зааж өгч болно. Манай тохиолдолд энэ нь Istio-д анхдагчаар суулгасан Ingress Gateway хянагч юм.

Дараах командыг дуудаж тохиргоог хийнэ.

$ kubectl apply -f resource-manifests/istio/http-gateway.yaml gateway.networking.istio.io/http-gateway created

Уг гарц нь одоо 80-р порт руу нэвтрэх боломжийг олгодог боловч хүсэлтийг хаашаа чиглүүлэх талаар мэдэхгүй байна. Үүний тулд танд хэрэгтэй болно Виртуал үйлчилгээ.

Виртуал үйлчилгээний нөөц

VirtualService нь Ingress Gateway-д кластер дотор зөвшөөрөгдсөн хүсэлтийг хэрхэн чиглүүлэхийг хэлж өгдөг.

http-gateway-ээр дамжуулан манай програмын хүсэлтийг sa-frontend, sa-web-app болон sa-feedback үйлчилгээнд илгээх ёстой.

VirtualServices-тэй тохируулах шаардлагатай маршрутууд

SA-Frontend рүү илгээх хүсэлтүүдийг харцгаая:

Замдаа яг таарч байна / index.html авахын тулд SA-Frontend руу илгээгдэх ёстой;
Урьдчилсан замууд /static/* SA-Frontend руу CSS болон JavaScript зэрэг урд хэсэгт хэрэглэгддэг статик файлуудыг хүлээн авахын тулд илгээсэн байх ёстой;
Тогтмол илэрхийлэлтэй таарсан замууд '^.*.(ico|png|jpg)$', SA-Frontend руу илгээсэн байх ёстой, учир нь Эдгээр нь хуудсан дээрх зургууд юм.

Хэрэгжилтийг дараах тохиргоогоор хангана (sa-virtualservice-external.yaml):

kind: VirtualService metadata: name: sa-external-services spec: hosts: - "*" gateways: - http-gateway # 1 http: - match: - uri: exact: / - uri: exact: /callback - uri: prefix: /static - uri: regex: '^.*.(ico|png|jpg) Важные моменты: Этот VirtualService относится к запросам, приходящим через http-gateway; В destination определяется сервис, куда отправляются запросы. Примечание: Конфигурация выше хранится в файле sa-virtualservice-external.yaml, который также содержит настройки для маршрутизации в SA-WebApp и SA-Feedback, но был сокращён здесь в статье для лаконичности. Применим VirtualService вызовом: $ kubectl apply -f resource-manifests/istio/sa-virtualservice-external.yaml virtualservice.networking.istio.io/sa-external-services created Примечание: Когда мы применяем ресурсы Istio, Kubernetes API Server создаёт событие, которое получает Istio Control Plane, и уже после этого новая конфигурация применяется к прокси-серверам Envoy каждого pod'а. А контроллер Ingress Gateway представляется очередным Envoy, сконфигурированным в Control Plane. Всё это на схеме выглядит так: Конфигурация Istio-IngressGateway для маршрутизации запросов Приложение Sentiment Analysis стало доступным по http://{EXTERNAL-IP}/. Не переживайте, если вы получаете статус Not Found: иногда требуется чуть больше времени для того, чтобы конфигурация вступила в силу и кэши Envoy обновились. Перед тем, как продолжить, поработайте немного с приложением, чтобы сгенерировать трафик (его наличие необходимо для наглядности в последующих действиях — прим. перев.). Kiali : наблюдаемость Чтобы попасть в административный интерфейс Kiali, выполните следующую команду: $ kubectl port-forward $(kubectl get pod -n istio-system -l app=kiali -o jsonpath='{.items[0].metadata.name}') -n istio-system 20001 … и откройте http://localhost:20001/, залогинившись под admin/admin. Здесь вы найдете множество полезных возможностей, например, для проверки конфигурации компонентов Istio, визуализации сервисов по информации, собранной при перехвате сетевых запросов, получения ответов на вопросы «Кто к кому обращается?», «У какой версии сервиса возникают сбои?» и т.п. В общем, изучите возможности Kiali перед тем, как двигаться дальше — к визуализации метрик с Grafana. Grafana: визуализация метрик Собранные в Istio метрики попадают в Prometheus и визуализируются с Grafana. Чтобы попасть в административный интерфейс Grafana, выполните команду ниже, после чего откройте http://localhost:3000/: $ kubectl -n istio-system port-forward $(kubectl -n istio-system get pod -l app=grafana -o jsonpath={.items[0].metadata.name}) 3000 Кликнув на меню Home слева сверху и выбрав Istio Service Dashboard в левом верхнем углу, начните с сервиса sa-web-app, чтобы посмотреть на собранные метрики: Здесь нас ждёт пустое и совершенно скучное представление — руководство никогда такое не одобрит. Давайте же создадим небольшую нагрузку следующей командой: $ while true; do curl -i http://$EXTERNAL_IP/sentiment -H "Content-type: application/json" -d '{"sentence": "I love yogobella"}'; sleep .8; done Вот теперь у нас гораздо более симпатичные графики, а в дополнение к ним — замечательные инструменты Prometheus для мониторинга и Grafana для визуализации метрик, что позволят нам узнать о производительности, состоянии здоровья, улучшениях/деградации в работе сервисов на протяжении времени. Наконец, посмотрим на трассировку запросов в сервисах. Jaeger : трассировка Трассировка нам потребуется, потому что чем больше у нас сервисов, тем сложнее добраться до причины сбоя. Посмотрим на простой случай из картинки ниже: Типовой пример случайного неудачного запроса Запрос приходит, падает — в чём же причина? Первый сервис? Или второй? Исключения есть в обоих — давайте посмотрим на логи каждого. Как часто вы ловили себя за таким занятием? Наша работа больше похожа на детективов программного обеспечения, а не разработчиков… Это широко распространённая проблема в микросервисах и решается она распределёнными системами трассировки, в которых сервисы передают друг другу уникальный заголовок, после чего эта информация перенаправляется в систему трассировки, где она сопоставляется с данными запроса. Вот иллюстрация: Для идентификации запроса используется TraceId В Istio используется Jaeger Tracer, который реализует независимый от вендоров фреймворк OpenTracing API. Получить доступ к пользовательского интерфейсу Jaeger можно следующей командой: $ kubectl port-forward -n istio-system $(kubectl get pod -n istio-system -l app=jaeger -o jsonpath='{.items[0].metadata.name}') 16686 Теперь зайдите на http://localhost:16686/ и выберите сервис sa-web-app. Если сервис не показан в выпадающем меню — проявите/сгенерируйте активность на странице и обновите интерфейс. После этого нажмите на кнопку Find Traces, которая покажет самые последние трейсы — выберите любой — покажется детализированная информация по всем трейсам: Этот трейс показывает: Запрос приходит в istio-ingressgateway (это первое взаимодействие с одним из сервисов, и для запроса генерируется Trace ID), после чего шлюз направляет запрос в сервис sa-web-app. В сервисе sa-web-app запрос подхватывается Envoy sidecar'ом, создаётся «ребёнок» в span'е (поэтому мы видим его в трейсах) и перенаправляется в контейнер sa-web-app. (Span — логическая единица работы в Jaeger, имеющая название, время начало операции и её продолжительность. Span'ы могут быть вложенными и упорядоченными. Ориентированный ациклический граф из span'ов образует trace. — прим. перев.) Здесь запрос обрабатывается методом sentimentAnalysis. Эти трейсы уже сгенерированы приложением, т.е. для них потребовались изменения в коде. С этого момента инициируется POST-запрос в sa-logic. Trace ID должен быть проброшен из sa-web-app. … Примечание: На 4 шаге приложение должно увидеть заголовки, сгенерированные Istio, и передать их в последующие запросы, как показано на изображении ниже: (A) За проброс заголовков отвечает Istio; (B) За заголовки отвечают сервисы Istio делает основную работу, т.к. генерирует заголовки для входящих запросов, создаёт новые span'ы в каждом sidecare'е и пробрасывает их. Однако без работы с заголовками внутри сервисов полный путь трассировки запроса будет утерян. Необходимо учитывать (пробрасывать) следующие заголовки: x-request-id x-b3-traceid x-b3-spanid x-b3-parentspanid x-b3-sampled x-b3-flags x-ot-span-context Это несложная задача, однако для упрощения её реализации уже существует множество библиотек — например, в сервисе sa-web-app клиент RestTemplate пробрасывает эти заголовки, если просто добавить библиотеки Jaeger и OpenTracing в его зависимости. Заметьте, что приложение Sentiment Analysis демонстрирует реализации на Flask, Spring и ASP.NET Core. Теперь, когда стало ясно, что мы получаем из коробки (или почти «из коробки»), рассмотрим вопросы тонко настраиваемой маршрутизации, управления сетевым трафиком, безопасности и т.п.! Прим. перев.: об этом читайте в следующей части материалов по Istio от Rinor Maloku, переводы которых последуют в нашем блоге в ближайшее время. UPDATE (14 марта): Вторая часть уже опубликована. P.S. от переводчика Читайте также в нашем блоге: «Назад к микросервисам вместе с Istio»: часть 2 (маршрутизация, управление трафиком), часть 3 (аутентификация и авторизация); «Conduit — легковесный service mesh для Kubernetes»; «Что такое service mesh и почему он мне нужен [для облачного приложения с микросервисами]?»; «Иллюстрированное руководство по устройству сети в Kubernetes. Части 1 и 2»; «Как этот sidecar-контейнер оказался здесь [в Kubernetes]?». Источник: habr.com

route: - destination: host: sa-frontend # 2 port: number: 80
Чухал цэгүүд:

Энэхүү ВиртуалҮйлчилгээ нь ирж буй хүсэлтийг хэлнэ http-гарц;
В destination Хүсэлт илгээх үйлчилгээ тодорхойлогддог.

тайлбар: Дээрх тохиргоог файлд хадгалсан sa-virtualservice-external.yaml, энэ нь SA-WebApp болон SA-Feedback-д чиглүүлэлтийн тохиргоог агуулж байгаа боловч энд өгүүлэлд товч тайлбарлах үүднээс товчилсон болно.

VirtualService-г залгаж ашиглацгаая:

тайлбар: Бид Istio нөөцийг ашиглах үед Kubernetes API Сервер нь Istio Control Plane-д хүлээн авсан үйл явдлыг үүсгэдэг бөгөөд үүний дараа шинэ тохиргоог pod's Envoy прокси-д хэрэглэнэ. Мөн Ingress Gateway хянагч нь Удирдлагын хавтгайд тохируулагдсан өөр Элч бололтой. Энэ бүхэн диаграммд иймэрхүү харагдаж байна.

Хүсэлтийн чиглүүлэлтийн хувьд Istio-IngressGateway тохиргоо

Мэдрэмжийн шинжилгээний програмыг одоо ашиглах боломжтой http://{EXTERNAL-IP}/. Хэрэв та олдсонгүй статустай бол санаа зовох хэрэггүй: Заримдаа тохиргоо хүчин төгөлдөр болох ба Envoy кэшийг шинэчлэх хүртэл бага зэрэг хугацаа шаардагддаг.

Үргэлжлүүлэхийн өмнө замын хөдөлгөөн үүсгэхийн тулд програмтай бага зэрэг тоглоорой. (дараагийн үйлдлүүдийг тодорхой болгохын тулд түүний оршихуй зайлшгүй шаардлагатай - ойролцоогоор.).

Киали: ажиглах чадвар

Kiali захиргааны интерфейс рүү орохын тулд дараах тушаалыг ажиллуулна уу.

... мөн нээх http://localhost:20001/, админ/админаар нэвтэрнэ үү. Эндээс та олон ашигтай функцуудыг олох болно, жишээлбэл, Istio бүрэлдэхүүн хэсгүүдийн тохиргоог шалгах, сүлжээний хүсэлтийг тасалдуулахаас цуглуулсан мэдээллийг ашиглан үйлчилгээг дүрслэн харуулах, "Хэн хэнтэй холбогдож байна вэ?", "Үйлчилгээний аль хувилбарт тулгарч байна вэ?" Гэсэн асуултуудад хариулт авах боломжтой. бүтэлгүйтэл үү?" гэх мэт. Ерөнхийдөө Grafana ашиглан хэмжүүрийг дүрслэн харуулахын өмнө Kiali-ийн чадавхийг судалж үзээрэй.

Графана: хэмжүүрийн дүрслэл

Istio-д цуглуулсан хэмжүүрүүд Прометей руу орж, Графанагийн тусламжтайгаар дүрслэгддэг. Grafana захиргааны интерфейс рүү орохын тулд доорх командыг ажиллуулаад дараа нь нээнэ үү http://localhost:3000/:

Цэс дээр дарна уу Нүүр хуудас зүүн дээд ба сонгох Isio үйлчилгээний хяналтын самбар зүүн дээд буланд, үйлчилгээг эхлүүлнэ үү вэб програмцуглуулсан хэмжигдэхүүнийг харахын тулд:

Биднийг энд хүлээж байгаа зүйл бол хоосон, уйтгартай гүйцэтгэл юм - удирдлага үүнийг хэзээ ч зөвшөөрөхгүй. Дараах тушаалаар жижиг ачааллыг үүсгэцгээе.

Одоо бидэнд илүү сайхан графикууд байгаа бөгөөд тэдгээрээс гадна гүйцэтгэл, эрүүл мэнд, үйлчилгээний сайжруулалт / доройтлын талаар суралцах боломжийг бидэнд олгодог хяналтын гайхалтай Prometheus хэрэгслүүд ба хэмжигдэхүүнийг дүрслэн харуулах Графана.

Эцэст нь, үйлчилгээн дэх хүсэлтийг хянах талаар авч үзье.

Жэйгер: мөшгих

Бидэнд олон үйлчилгээ байх тусам бүтэлгүйтлийн шалтгааныг олоход илүү хэцүү байдаг тул бид мөрдөх шаардлагатай болно. Доорх зурган дээрээс энгийн тохиолдлыг харцгаая.

Санамсаргүй бүтэлгүйтсэн хүсэлтийн ердийн жишээ

Хүсэлт ирдэг, унадаг - шалтгаан нь юу вэ? Анхны үйлчилгээ? Эсвэл хоёр дахь нь? Аль алинд нь үл хамаарах зүйлүүд байдаг - тус бүрийн бүртгэлийг харцгаая. Та хэр олон удаа ингэж байгаад өөрийгөө барьж байсан бэ? Бидний ажил бол хөгжүүлэгч гэхээсээ илүү программ хангамжийн мөрдөгчтэй адилхан...

Энэ нь микро үйлчилгээний нийтлэг асуудал бөгөөд үйлчилгээнүүд бие биедээ өвөрмөц толгойг дамжуулж, дараа нь энэ мэдээллийг мөрдөх систем рүү дамжуулж, хүсэлтийн өгөгдөлтэй харьцуулдаг хуваарилагдсан мөрдөх системээр шийдэгддэг. Энд жишээ байна:

TraceId нь хүсэлтийг тодорхойлоход хэрэглэгддэг

Istio нь борлуулагчаас хараат бус OpenTracing API хүрээг хэрэгжүүлдэг Jaeger Tracer-ийг ашигладаг. Та Jaeger хэрэглэгчийн интерфэйс рүү дараах тушаалаар хандаж болно:

Одоо оч http://localhost:16686/ болон үйлчилгээг сонгоно уу вэб програм. Хэрэв үйлчилгээ унждаг цэсэнд харагдахгүй бол хуудсан дээрх үйл ажиллагааг харуулах/үүсгэх, интерфэйсийг шинэчилнэ үү. Үүний дараа товчлуур дээр дарна уу Мөр хайх, хамгийн сүүлийн үеийн ул мөрийг харуулах - дурын зүйлийг сонгох - бүх ул мөрийн дэлгэрэнгүй мэдээлэл гарч ирнэ:

Энэ ул мөр нь:

Хүсэлт орж ирдэг istio-ingressgateway (энэ нь аль нэг үйлчилгээтэй хийсэн анхны харилцан үйлчлэл бөгөөд хүсэлтэд Trace ID үүсгэгддэг), үүний дараа гарц нь хүсэлтийг үйлчилгээ рүү илгээдэг. вэб програм.
Үйлчилгээнд вэб програм Хүсэлтийг элчийн хажуугийн тэрэг авч, "хүүхэд" нь зайнд үүсгэгдэж (тиймээс бид үүнийг ул мөр дээр хардаг) сав руу дахин чиглүүлэв. вэб програм. (Span - Jaeger дахь ажлын логик нэгж, нэр, үйл ажиллагааны эхлэх цаг, түүний үргэлжлэх хугацаа. Спансыг үүрлэж, захиалж болно. Эргэлтийн чиглэлтэй ациклик график нь ул мөр үүсгэдэг. - ойролцоогоор. орчуул.)
Энд хүсэлтийг аргаар боловсруулдаг мэдрэмжийн шинжилгээ. Эдгээр ул мөрийг программ аль хэдийн үүсгэсэн, i.e. Тэд кодын өөрчлөлтийг шаарддаг.
Энэ мөчөөс эхлэн POST хүсэлтийг эхлүүлнэ са-логик. Trace ID-г дараахаас дамжуулах ёстой вэб програм.
...

тайлбар: 4-р алхамд програм нь Istio-ийн үүсгэсэн толгой хэсгийг харж, доорх зурагт үзүүлсэн шиг дараагийн хүсэлтүүд рүү дамжуулах ёстой.

(A) Istio нь толгой хэсгийг дамжуулах үүрэгтэй; (B) Үйлчилгээнүүд нь толгойн хэсгийг хариуцдаг

Истио ихэнх ажлыг хийдэг, учир нь... ирж буй хүсэлтийн толгойг үүсгэж, хажуугийн тусламж үйлчилгээ бүрт шинэ зай үүсгэж, дамжуулдаг. Гэсэн хэдий ч, үйлчилгээний дотор толгойтой ажиллахгүй бол хүсэлтийг бүрэн хянах зам алга болно.

Дараах толгойнуудыг анхаарч үзэх хэрэгтэй.

Энэ бол тийм ч хэцүү ажил биш, гэхдээ түүний хэрэгжилтийг хялбарчлах нь аль хэдийн бий олон номын сан - жишээ нь, sa-web-app үйлчилгээнд, хэрэв та Jaeger болон OpenTracing сангуудыг зүгээр л нэмбэл RestTemplate клиент эдгээр толгойг дамжуулдаг. түүний донтолт.

Мэдрэмжийн шинжилгээний програм нь Flask, Spring болон ASP.NET Core дахь хэрэгжилтийг харуулдаг болохыг анхаарна уу.

Одоо бид хайрцагнаас (эсвэл бараг л хайрцагнаас) юу авах нь тодорхой болсон тул нарийн тохируулсан чиглүүлэлт, сүлжээний хөдөлгөөний менежмент, аюулгүй байдал гэх мэт зүйлсийг харцгаая!

Анхаарна уу. орчуулга.: Энэ тухай Ринор Малокугийн Istio-ийн материалын дараагийн хэсгээс уншина уу, орчуулгыг нь ойрын хугацаанд манай блогт оруулах болно. UPDATE (14-р сарын XNUMX): Хоёрдугаар хэсэг аль хэдийн нийтлэгдсэн байна.

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

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

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

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