بازگشت به میکروسرویس ها با ایستیو. قسمت 1

توجه داشته باشید. ترجمه: مش های سرویس قطعاً به موضوعی داغ در زیرساخت های امروزی برای برنامه های کاربردی پس از معماری میکروسرویس تبدیل شده اند. در حالی که ایستیو ممکن است در رادار بسیاری از مهندسان DevOps قرار داشته باشد، این محصول نسبتاً جدیدی است که اگرچه از نظر ویژگی‌هایی که ارائه می‌کند پیچیده است، اما زمان قابل توجهی برای آشنایی با آن نیاز دارد. مهندس آلمانی رینور مالوکو، که مسئول محاسبات ابری برای مشتریان بزرگ در شرکت مخابراتی Orange Networks است، مجموعه‌ای از مواد فوق‌العاده نوشته است که به شما امکان می‌دهد سریع و عمیق در ایستیو فرو بروید. او داستان خود را با آنچه ایستیو می تواند انجام دهد و چگونه می توانید به سرعت آن را با چشمان خود ببینید آغاز می کند.

ایستیو — پروژه منبع باز، که با همکاری تیم هایی از Google، IBM و Lyft توسعه یافته است. این پیچیدگی‌هایی را که در برنامه‌های کاربردی مبتنی بر میکروسرویس‌ها به وجود می‌آیند را حل می‌کند، به عنوان مثال:

• مدیریت ترافیک: بازه زمانی، تلاش مجدد، تعادل بار.
• امنیت: احراز هویت و مجوز کاربر نهایی؛
• قابلیت مشاهده: ردیابی، نظارت، ثبت.

همه آنها را می توان در سطح برنامه حل کرد، اما پس از آن خدمات شما دیگر "میکرو" نخواهد بود. تمام تلاش اضافی برای پرداختن به این مسائل اتلاف منابع شرکت است که می تواند مستقیماً برای ارزش تجاری استفاده شود. به یک مثال توجه کنید:

مدیر پروژه: چه مدت طول می کشد تا یک ویژگی بازخورد اضافه شود؟
توسعه دهنده: دو سرعت.

MP: چی؟.. این فقط خام است!
R: انجام CRUD بخش آسان کار است، اما ما همچنان نیاز به احراز هویت و مجوز کاربران و سرویس‌ها داریم. از آنجایی که شبکه غیرقابل اعتماد است، باید درخواست های مکرر را نیز پیاده سازی کنید الگوی قطع کننده مدار در مشتریان همچنین برای اطمینان از عدم خرابی کل سیستم، تایم اوت و سرهای بزرگ (برای جزئیات بیشتر در مورد هر دو الگوی ذکر شده در ادامه مقاله را ببینید.)و به منظور شناسایی مشکلات، نظارت، ردیابی، […]

MP: اوه، اجازه دهید این ویژگی را در سرویس محصول قرار دهیم.

فکر می‌کنم ایده واضح است: مقدار مراحل و تلاش لازم برای افزودن یک سرویس واحد بسیار زیاد است. در این مقاله، نگاهی خواهیم داشت به اینکه چگونه ایستیو تمام پیچیدگی های ذکر شده در بالا (که توسط منطق تجاری هدف قرار نمی گیرد) را از سرویس ها حذف می کند.

یادداشت: در این مقاله فرض بر این است که شما دانش کاری Kubernetes دارید. در غیر این صورت خواندن را توصیه می کنم معرفی من به Kubernetes و تنها پس از آن به خواندن این مطالب ادامه دهید.

ایده ایستیو

در دنیای بدون ایستیو، یک سرویس مستقیماً از سرویس دیگری درخواست می‌کند و در صورت شکست، سرویس باید خودش آن را مدیریت کند: تلاش جدیدی انجام دهد، تایم اوت را فراهم کند، قطع کننده مدار را باز کند و غیره.

ترافیک شبکه در Kubernetes

از طرف دیگر ایستیو با تداخل در تعامل شبکه، راه حلی تخصصی ارائه می دهد که کاملاً جدا از خدمات و عملکردها است. و بدین ترتیب اجرا می کند:

• تحمل خطا: بر اساس کد وضعیت موجود در پاسخ، می‌فهمد که آیا درخواست ناموفق بوده است و دوباره آن را ارسال می‌کند.
• عرضه قناری: تنها درصد ثابتی از درخواست ها را به نسخه جدید سرویس هدایت می کند.
• مانیتورینگ و متریک: چه مدت طول کشید تا سرویس پاسخ دهد؟
• ردیابی و قابلیت مشاهده: سرصفحه های خاصی را به هر درخواست اضافه می کند و آنها را در سراسر خوشه ردیابی می کند.
• امنیت: یک توکن JWT را بازیابی می کند، کاربران را احراز هویت می کند و مجوز می دهد.

اینها تنها تعدادی از احتمالات (واقعاً فقط چند مورد!) هستند که شما را مجذوب خود می کند. حالا بیایید به جزئیات فنی شیرجه بزنیم!

معماری

ایستیو تمام ترافیک شبکه را رهگیری می کند و مجموعه ای از قوانین را برای آن اعمال می کند و یک پروکسی هوشمند را به شکل یک محفظه کناری در هر پاد قرار می دهد. پراکسی هایی که همه احتمالات را فعال می کنند، الف را تشکیل می دهند صفحه داده، و می توان آنها را به صورت پویا تنظیم کرد کنترل هواپیما.

صفحه داده

پراکسی های قرار داده شده در پادها، ایستیو را آسان می کند تا نیازهای مورد نیاز ما را برآورده کند. به عنوان مثال، بیایید تلاش های مجدد و عملکردهای قطع کننده مدار را بررسی کنیم.

نحوه اجرای مجدد و قطع مدار در Envoy

خلاصه کردن:

1. فرستاده (ما در مورد یک پروکسی صحبت می کنیم که در یک ظرف کناری قرار دارد که توزیع و نحوه توزیع آن چگونه است محصول جداگانه - تقریبا ترجمه.) درخواستی را به اولین نمونه سرویس B ارسال می کند و با شکست مواجه می شود.
2. سفیر سایدکار دوباره تلاش می کند (تلاش مجدد). (1)
3. درخواست ناموفق به پروکسی که آن را فراخوانی کرده برگردانده می شود.
4. با این کار Circuit Breaker باز می شود و سرویس بعدی برای درخواست های بعدی فراخوانی می شود. (2)

این بدان معنی است که شما مجبور نیستید از کتابخانه بعدی Retry استفاده کنید، نیازی نیست که Circuit Breaking و Service Discovery خود را در زبان برنامه نویسی X، Y یا Z پیاده سازی کنید. جعبه در ایستیو و نیازی ندارد هیچ کد تغییر می کند

عالی! حالا ممکن است بخواهید با ایستیو به سفر بروید، اما هنوز شک و تردیدهایی وجود دارد، سوالات باز. اگر این یک راه حل جهانی برای همه موارد در زندگی است، پس شما یک سوء ظن موجه دارید: از این گذشته، همه این راه حل ها در واقع برای هیچ موردی مناسب نیستند.

و در نهایت می‌پرسید: "آیا قابل تنظیم است؟"

اکنون برای یک سفر دریایی آماده هستید - و بیایید با Control Plane آشنا شویم.

کنترل هواپیما

از سه جزء تشکیل شده است: خلبان, مخلوط کن и دژ، که مجموعاً فرستادگان را برای مسیریابی ترافیک، اجرای خط مشی ها و جمع آوری داده های تله متری پیکربندی می کنند. از نظر شماتیک، همه چیز به این صورت است:

تعامل صفحه کنترل با صفحه داده

فرستادگان (به عنوان مثال صفحه داده) با پیکربندی شده اند Kubernetes CRD (تعریف منابع سفارشی) توسط Istio تعریف شده و به طور خاص برای این منظور طراحی شده است. معنی این برای شما این است که آنها فقط یک منبع دیگر در Kubernetes با نحو آشنا هستند. پس از ایجاد، این منبع توسط صفحه کنترل انتخاب شده و برای فرستادگان اعمال می شود.

ارتباط خدمات با ایستیو

ما رابطه ایستیو با خدمات را توضیح دادیم، اما نه برعکس: خدمات چگونه با ایستیو ارتباط دارد؟

راستش را بخواهید، سرویس‌ها همان‌طور که ماهی‌ها از آب خبر دارند، وقتی از خود می‌پرسند: «آب چیست؟»

تصوير ویکتوریا دیمیتراکوپولوس: آب را چگونه دوست داری؟ - اصلاً آب چیست؟

بدین ترتیب می‌توانید یک کلاستر کاری بگیرید و پس از استقرار کامپوننت‌های ایستیو، سرویس‌های موجود در آن به کار خود ادامه می‌دهند و پس از حذف این مؤلفه‌ها همه چیز دوباره درست می‌شود. واضح است که در این صورت فرصت های ایستیو را از دست خواهید داد.

تئوری بس است - بیایید این دانش را در عمل پیاده کنیم!

ایستیو در عمل

ایستیو به یک کلاستر Kubernetes با حداقل 4 vCPU و 8 گیگابایت رم نیاز دارد. برای بالا بردن سریع خوشه و پیروی از دستورالعمل‌های مقاله، توصیه می‌کنم از Google Cloud Platform استفاده کنید که به کاربران جدید ارائه می‌کند. 300 دلار رایگان.

پس از ایجاد کلاستر و راه اندازی دسترسی به Kubernetes از طریق ابزار کنسول، می توانید Istio را از طریق مدیریت بسته Helm نصب کنید.

نصب هلم

کلاینت Helm را همانطور که در توضیح داده شده در رایانه خود نصب کنید اسناد رسمی. ما از آن برای تولید قالب هایی برای نصب ایستیو در قسمت بعدی استفاده خواهیم کرد.

نصب و راه اندازی

دانلود منابع ایستیو از آخرین نسخه (پیوند نویسنده اصلی به نسخه 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.yaml. ما با تعیین پارامترهای زیر، الگوی استاندارد را برای خود تغییر داده ایم:

• global.mtls.enabled نصب شده در false (یعنی احراز هویت mTLS غیرفعال است - تقریباً ترجمه)برای ساده کردن روند دوستیابی ما؛
• tracing.enabled ردیابی درخواست را با Jaeger فعال می کند.
• kiali.enabled Kiali را در یک کلاستر برای تجسم خدمات و ترافیک نصب می کند.
• grafana.enabled Grafana را برای تجسم معیارهای جمع آوری شده نصب می کند.

منابع تولید شده را با دستور اعمال کنید:

$ kubectl apply -f istio.yaml

نصب ایستیو در کلاستر تمام شد! صبر کنید تا همه غلاف ها در فضای نام قرار گیرند istio-system قادر خواهد بود Running یا Completedبا اجرای دستور زیر:

$ kubectl get pods -n istio-system

اکنون آماده هستیم تا به بخش بعدی ادامه دهیم، جایی که برنامه را بالا می بریم و اجرا می کنیم.

معماری کاربردی تحلیل احساسات

بیایید از مثال برنامه میکروسرویس تجزیه و تحلیل احساسات استفاده شده در موارد ذکر شده استفاده کنیم مقاله معرفی Kubernetes. این به اندازه کافی پیچیده است که بتوان امکانات ایستیو را در عمل نشان داد.

این برنامه از چهار میکروسرویس تشکیل شده است:

1. سرویس SA-Frontend، که برنامه front-end را در Reactjs ارائه می کند.
2. سرویس برنامه وب SA، که در خدمت پرس و جوهای تحلیل احساسات است.
3. سرویس SA منطقکه خود را اجرا می کند تحلیل احساسات;
4. سرویس بازخورد SA، که بازخورد کاربران را در مورد صحت تجزیه و تحلیل انجام شده دریافت می کند.

در این نمودار علاوه بر سرویس ها، Ingress Controller را نیز مشاهده می کنیم که در Kubernetes درخواست های دریافتی را به سرویس های مربوطه هدایت می کند. ایستیو از مفهوم مشابهی به عنوان بخشی از دروازه ورودی استفاده می کند که جزئیات آن در ادامه خواهد آمد.

راه اندازی برنامه با پروکسی از ایستیو

برای عملیات بیشتر ذکر شده در مقاله، مخزن خود را شبیه سازی کنید تسلط istio. این شامل برنامه و مانیفست برای Kubernetes و Istio است.

قرار دادن کرکره های جانبی

درج می توان انجام داد به طور خودکار یا با دست. برای درج خودکار محفظه های کناری، باید برچسب را روی فضای نام تنظیم کنید istio-injection=enabled، که با دستور زیر انجام می شود:

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

اکنون هر غلافی که در فضای نام پیش‌فرض مستقر می‌شود (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

از نظر بصری به نظر می رسد:

پروکسی فرستاده در یکی از پادها

اکنون که برنامه راه اندازی شده است، باید اجازه دهیم ترافیک ورودی وارد برنامه شود.

دروازه ورود

بهترین روش برای رسیدن به این هدف (اجازه دادن به ترافیک در خوشه) از طریق است دروازه ورود در ایستیو، که در "لبه" خوشه قرار دارد و به شما امکان می دهد ویژگی های ایستیو مانند مسیریابی، تعادل بار، امنیت و نظارت بر ترافیک ورودی را فعال کنید.

مؤلفه 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 ادامه خواهیم داد (از آن به عنوان EXTERNAL-IP یاد می کنم)، بنابراین برای راحتی، مقدار را روی یک متغیر می نویسیم:

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

اگر اکنون سعی کنید از طریق مرورگر به این IP دسترسی پیدا کنید، با خطای Service Unavailable مواجه خواهید شد، زیرا به طور پیش فرض ایستیو تمام ترافیک ورودی را مسدود می کندتا زمانی که یک Gateway تعریف شود.

منبع دروازه

Gateway یک CRD (تعریف منابع سفارشی) در Kubernetes است که پس از نصب Istio در یک کلاستر تعریف شده و توانایی تعیین پورت‌ها، پروتکل‌ها و میزبان‌هایی را می‌دهد که می‌خواهیم به ترافیک ورودی اجازه دهیم.

در مورد ما، می‌خواهیم به ترافیک HTTP در پورت 80 برای همه میزبان‌ها اجازه دهیم. مشکل با تعریف زیر مشخص می شود (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 است که به طور پیش فرض در ایستیو نصب شده است.

پیکربندی با فراخوانی دستور زیر اعمال می شود:

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

گیت‌وی اکنون اجازه دسترسی به پورت 80 را می‌دهد، اما هیچ ایده‌ای برای مسیریابی درخواست‌ها ندارد. برای این شما نیاز خواهید داشت خدمات مجازی.

منبع سرویس مجازی

VirtualService به دروازه ورودی می گوید که چگونه درخواست هایی را که در داخل خوشه مجاز هستند مسیریابی کند.

درخواست‌هایی که از طریق http-gateway به برنامه ما ارسال می‌شوند باید به سرویس‌های sa-frontend، sa-web-app و sa-feedback ارسال شوند:

مسیرهایی که باید با VirtualServices پیکربندی شوند

درخواست هایی که باید به SA-Frontend ارسال شوند را در نظر بگیرید:

• مطابقت دقیق در طول مسیر / برای دریافت index.html باید به SA-Frontend ارسال شود.
• مسیرهای با پیشوند /static/* باید به SA-Frontend فرستاده شود تا فایل های استاتیک مورد استفاده در فرانت اند، مانند CSS و جاوا اسکریپت را دریافت کند.
• مسیرهایی که با عبارت منظم مطابقت دارند '^.*.(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-gateway;
 В destination سرویسی که درخواست ها به آن ارسال می شود را مشخص می کند.

یادداشت: پیکربندی بالا در یک فایل ذخیره می شود sa-virtualservice-external.yaml، که شامل تنظیمات مسیریابی به SA-WebApp و SA-Feedback نیز می باشد، اما برای اختصار در اینجا در مقاله کوتاه شده است.
با تماس با VirtualService تماس بگیرید:

یادداشت: هنگامی که منابع Istio را اعمال می کنیم، سرور Kubernetes API رویدادی را اجرا می کند که Istio Control Plane دریافت می کند و پس از آن، پیکربندی جدید بر روی پروکسی Envoy هر pod اعمال می شود. و به نظر می‌رسد که کنترل‌کننده دروازه ورودی، فرستاده دیگری است که در صفحه کنترل پیکربندی شده است. همه اینها در نمودار به صورت زیر است:


پیکربندی Istio-IngressGateway برای مسیریابی درخواست
تجزیه و تحلیل احساسات اکنون در دسترس است http://{EXTERNAL-IP}/. اگر وضعیت یافت نشد را دریافت کردید نگران نباشید: گاهی اوقات برای اعمال پیکربندی و به روز رسانی کش های Envoy کمی بیشتر طول می کشد.
قبل از ادامه، کمی با برنامه بازی کنید تا ترافیک ایجاد شود. (وجود آن برای وضوح در اقدامات بعدی ضروری است - تقریباً ترجمه.).
کیالی: مشاهده پذیری
برای دسترسی به رابط مدیریت کیالی، دستور زیر را اجرا کنید:

… و باز کنید http://localhost:20001/با ورود به عنوان admin/admin. در اینجا می توانید بسیاری از ویژگی های مفید را پیدا کنید، به عنوان مثال، برای بررسی پیکربندی اجزای Istio، تجسم خدمات از اطلاعات جمع آوری شده توسط رهگیری درخواست های شبکه، دریافت پاسخ به سؤالات "چه کسی با چه کسی تماس می گیرد؟"، "کدام نسخه از سرویس را تجربه می کند". شکست ها؟» و غیره به طور کلی، قبل از اینکه به سراغ تجسم معیارها با Grafana بروید، احتمالات کیالی را بررسی کنید.

گرافانا: تجسم معیارها
معیارهای جمع آوری شده در ایستیو به Prometheus ختم می شود و با Grafana تجسم می شود. برای دسترسی به رابط مدیریت Grafana، دستور زیر را اجرا کنید، سپس باز کنید http://localhost:3000/:

با کلیک بر روی منو صفحه اصلی بالا سمت چپ و انتخاب کنید داشبورد سرویس ایستیو در گوشه بالا سمت چپ، با سرویس شروع کنید sa-web-appبرای مشاهده معیارهای جمع آوری شده:

در اینجا ما منتظر یک عملکرد خالی و کاملا خسته کننده هستیم - مدیریت هرگز این را تایید نخواهد کرد. بیایید یک بار کوچک با دستور زیر ایجاد کنیم:

اکنون نمودارهای بسیار زیباتری داریم، و علاوه بر آنها، ابزارهای شگفت‌انگیز Prometheus برای نظارت و Grafana برای تجسم معیارها، که به ما امکان می‌دهد در مورد عملکرد، وضعیت سلامت، بهبود / کاهش خدمات در طول زمان بیاموزیم.
در نهایت، بیایید به ردیابی درخواست در خدمات نگاه کنیم.
جیگر: ردیابی
ما نیاز به ردیابی خواهیم داشت، زیرا هر چه خدمات بیشتری داشته باشیم، رسیدن به علت شکست دشوارتر است. بیایید به یک مورد ساده از تصویر زیر نگاه کنیم:


مثال معمولی از یک درخواست ناموفق تصادفی
درخواست می آید، سقوط می کند - دلیل ش چیه؟ اولین سرویس؟ یا دوم؟ در هر دو استثنا وجود دارد - بیایید به گزارش های هر یک نگاه کنیم. چند بار خود را در حال انجام این کار گرفتار کرده اید؟ شغل ما بیشتر شبیه کارآگاهان نرم افزار است تا توسعه دهندگان…
این یک مشکل گسترده در میکروسرویس ها است و با سیستم های ردیابی توزیع شده حل می شود، که در آن سرویس ها یک هدر منحصر به فرد را به یکدیگر ارسال می کنند و پس از آن این اطلاعات به سیستم ردیابی هدایت می شود و در آنجا با داده های درخواست مقایسه می شود. در اینجا یک تصویر است:


TraceId برای شناسایی درخواست استفاده می شود
ایستیو از Jaeger Tracer استفاده می کند که یک چارچوب OpenTracing API مستقل از فروشنده را پیاده سازی می کند. با دستور زیر می توانید به رابط کاربری Jaeger دسترسی پیدا کنید:

حالا برو به http://localhost:16686/ و یک سرویس را انتخاب کنید sa-web-app. اگر سرویس در منوی کشویی نشان داده نشد، فعالیت را در صفحه نشان دهید/ایجاد کنید و رابط را به روز کنید. پس از آن بر روی دکمه کلیک کنید ردیابی را پیدا کنید، که جدیدترین ردیابی ها را نشان می دهد - انتخاب هر کدام - اطلاعات دقیق روی همه ردیابی ها ظاهر می شود:

این ردیابی نشان می دهد:

 درخواست وارد می شود istio-ingressgateway (این اولین تعامل با یکی از سرویس ها است و یک Trace ID برای درخواست ایجاد می شود) پس از آن دروازه درخواست را به سرویس ارسال می کند. sa-web-app.
 در خدمت sa-web-app درخواست توسط کرکره جانبی Envoy انتخاب می شود، یک "فرزند" در این فاصله ایجاد می شود (به همین دلیل است که ما آن را در ردیابی می بینیم) و به کانتینر هدایت می شود. sa-web-app. (محدوده - یک واحد منطقی کار در جیگر با نام، زمان شروع عملیات و مدت آن. دهانه ها را می توان تو در تو و سفارش داد. نمودار غیر چرخه ای جهت دهی ها یک ردیابی را تشکیل می دهد. - تقریبا ترجمه.)
 در اینجا درخواست توسط روش پردازش می شود تحلیل احساسات. این ردیابی ها قبلاً توسط برنامه ایجاد شده اند. آنها نیاز به تغییر کد داشتند.
 از این لحظه، یک درخواست POST در آغاز می شود منطقی. شناسه ردیابی باید از آن ارسال شود sa-web-app.
 ...

یادداشت: در مرحله 4، برنامه باید هدرهای تولید شده توسط Istio را ببیند و مانند تصویر زیر آنها را به درخواست های بعدی ارسال کند:


(الف) ارسال سربرگ به عهده ایستیو است. (ب) سرویس ها مسئول هدرها هستند
ایستیو بیشتر کار را انجام می دهد زیرا هدرهایی را برای درخواست‌های دریافتی ایجاد می‌کند، دهانه‌های جدیدی را در هر sidecare ایجاد می‌کند و آنها را فوروارد می‌کند. با این حال، بدون کار با هدرهای داخل سرویس ها، مسیر ردیابی درخواست کامل از بین خواهد رفت.
سرفصل های زیر باید در نظر گرفته شوند (ارسال شده):

این یک کار ساده است، اما برای ساده کردن اجرای آن، در حال حاضر وجود دارد بسیاری از کتابخانه ها - به عنوان مثال، در سرویس sa-web-app، مشتری RestTemplate این هدرها را ارسال می کند اگر شما به سادگی کتابخانه های Jaeger و OpenTracing را به آن اضافه کنید. وابستگی های آن.
توجه داشته باشید که اپلیکیشن Sentiment Analysis پیاده سازی ها را در Flask، Spring و ASP.NET Core نشان می دهد.
اکنون که مشخص شده است که چه چیزی را از جعبه (یا تقریباً خارج از جعبه) دریافت می کنیم، بیایید به مسیریابی دقیق، مدیریت ترافیک شبکه، امنیت و موارد دیگر نگاه کنیم!
توجه داشته باشید. ترجمه: در قسمت بعدی مطالب مربوط به ایستیو توسط رینور مالوکو در این مورد بخوانید که ترجمه آن در آینده نزدیک در وبلاگ ما منتشر خواهد شد. بروزرسانی (14 مارس): قسمت دوم قبلا منتشر شده است.
PS از مترجم
در وبلاگ ما نیز بخوانید:

 "بازگشت به میکروسرویس با ایستیو": بخش 2 (مسیریابی، کنترل ترافیک), بخش 3 (احراز هویت و مجوز);
 «لوله - مش سرویس سبک وزن برای Kubernetes"؛
 «سرویس مش چیست و چرا [برای یک برنامه ابری با میکروسرویس ها] به آن نیاز دارم؟"؛
 «راهنمای مصور شبکه سازی در Kubernetes. قسمت 1 و 2"؛
 «چگونه این کانتینر ماشین کناری به اینجا [در Kubernetes] ختم شد؟'.

منبع: www.habr.com