العودة إلى الخدمات المصغرة مع Istio. الجزء 1

ملحوظة. ترجمة.: أصبحت الشبكات المتداخلة للخدمة بالتأكيد موضوعًا ساخنًا في البنية التحتية الحالية للتطبيقات التي تتبع بنية الخدمات المصغرة. على الرغم من أن Istio قد يكون على رادار العديد من مهندسي DevOps ، إلا أنه منتج جديد إلى حد ما ، على الرغم من كونه معقدًا من حيث الميزات التي يوفرها ، إلا أنه قد يستغرق وقتًا طويلاً للتعرف عليه. كتب المهندس الألماني رينور مالوكو ، المسؤول عن الحوسبة السحابية للعملاء الكبار في شركة الاتصالات Orange Networks ، سلسلة رائعة من المواد التي تتيح لك الغوص بسرعة وبعمق في Istio. يبدأ قصته بما يمكن أن يفعله Istio وكيف يمكنك رؤيته بسرعة بأم عينيك.

Istio - مشروع مفتوح المصدر ، تم تطويره بالتعاون مع فرق من Google و IBM و Lyft. إنه يحل التعقيدات التي تنشأ في التطبيقات القائمة على الخدمات المصغرة ، على سبيل المثال ، مثل:

• إدارة المرور: المهلات ، إعادة المحاولة ، موازنة التحميل ؛
• أمن: مصادقة المستخدم النهائي والترخيص ؛
• قابلية الملاحظة: تتبع ، رصد ، قطع الأشجار.

يمكن حلها جميعًا على مستوى التطبيق ، ولكن بعد ذلك لن تكون خدماتك "صغيرة". كل الجهد الإضافي لمعالجة هذه القضايا هو إهدار لموارد الشركة التي يمكن استخدامها مباشرة لقيمة الأعمال. فكر في مثال:

مدير المشروع: ما هي المدة التي تستغرقها إضافة ميزة الملاحظات؟
المطور: اثنان سباقات السرعة.

النائب: ماذا؟ .. انها مجرد خشونة!
R: القيام بـ CRUD هو الجزء السهل من المهمة ، لكننا ما زلنا بحاجة إلى مصادقة المستخدمين والخدمات وتفويضهم. نظرًا لأن الشبكة غير موثوقة ، فستحتاج إلى تنفيذ الطلبات المتكررة أيضًا نمط قاطع الدائرة في العملاء. أيضًا ، للتأكد من أن النظام بأكمله لم يتعطل ، فإن المهلات و حواجز (انظر لاحقًا في المقالة لمزيد من التفاصيل حول كلا النموذجين المذكورين.)، ومن أجل اكتشاف المشكلات ، والرصد ، والتتبع ، [...]

النائب: أوه ، دعنا فقط نضع هذه الميزة في خدمة المنتج بعد ذلك.

أعتقد أن الفكرة واضحة: مقدار الخطوات والجهد المطلوب لإضافة خدمة واحدة ضخم. في هذه المقالة ، سوف نلقي نظرة على كيفية قيام Istio بإزالة كل التعقيدات المذكورة أعلاه (غير مستهدفة من قبل منطق الأعمال) من الخدمات.

لاحظ: تفترض المقالة أن لديك معرفة عملية بـ Kubernetes. خلاف ذلك ، أوصي بالقراءة مقدمتي إلى Kubernetes وعندها فقط أكمل قراءة هذه المادة.

فكرة Istio

في عالم خالٍ من Istio ، تقدم إحدى الخدمات طلبات مباشرة إلى أخرى ، وفي حالة الفشل ، يجب على الخدمة التعامل معها بنفسها: القيام بمحاولة جديدة ، وتوفير مهلة ، وفتح قاطع الدائرة ، وما إلى ذلك.

حركة مرور الشبكة في Kubernetes

من ناحية أخرى ، يقدم Istio حلاً متخصصًا منفصل تمامًا عن الخدمات والوظائف عن طريق التداخل مع تفاعل الشبكة. وبالتالي فهي تنفذ:

• التسامح مع الخطأ: استنادًا إلى رمز الحالة في الاستجابة ، يتفهم ما إذا كان الطلب قد فشل ويعيد تقديمه.
• Canary Rollouts: يعيد توجيه نسبة مئوية ثابتة فقط من الطلبات إلى الإصدار الجديد من الخدمة.
• المراقبة والقياسات: كم من الوقت استغرقت استجابة الخدمة؟
• التتبع والملاحظة: يضيف رؤوسًا خاصة لكل طلب ويتتبعها عبر المجموعة.
• أمن: يسترجع رمز JWT ويصادق ويفوض المستخدمين.

هذه ليست سوى عدد قليل من الاحتمالات (في الحقيقة قليلة!) لإثارة اهتمامك. الآن دعنا نتعمق في التفاصيل الفنية!

بنيان

يعترض Istio جميع حركات مرور الشبكة ويطبق مجموعة من القواعد عليها ، ويدخل وكيلًا ذكيًا في شكل حاوية جانبية في كل جراب. تشكل الوكلاء الذين ينشطون جميع الاحتمالات أ طائرة البيانات، ويمكن تعديلها ديناميكيًا باستخدام طائرة مراقبة.

طائرة البيانات

تسمح الوكلاء التي يتم إدخالها في البودات لـ Istio بتحقيق المتطلبات التي نحتاجها بسهولة. على سبيل المثال ، دعنا نتحقق من وظائف إعادة المحاولة ووظائف قاطع الدائرة.

كيف يتم تنفيذ عمليات إعادة المحاولة وفصل الدائرة في Envoy

تلخيص:

1. مبعوث (نحن نتحدث عن وكيل موجود في حاوية جانبية ، يتم توزيعه وكيف منتج منفصل - تقريبا. ترجمة.) يرسل طلبًا إلى المثيل الأول من الخدمة B ويفشل.
2. المبعوث Sidecar يحاول مرة أخرى (أعد المحاولة). (1)
3. يتم إرجاع الطلب الفاشل إلى الوكيل الذي استدعاه.
4. هذا يفتح Circuit Breaker ويستدعي الخدمة التالية للطلبات اللاحقة. (2)

هذا يعني أنك لست مضطرًا إلى استخدام مكتبة إعادة المحاولة التالية ، ولا يتعين عليك إجراء التنفيذ الخاص بك لـ Circuit Breaking واكتشاف الخدمة في لغة البرمجة X أو Y أو Z. كل هذا وأكثر متاحًا من مربع في Istio ولا يتطلب لا تغييرات التعليمات البرمجية.

عظيم! الآن قد ترغب في الذهاب في رحلة مع Istio ، ولكن لا تزال هناك بعض الشكوك والأسئلة المفتوحة. إذا كان هذا حلاً شاملاً لجميع المناسبات في الحياة ، فلديك شك مشروع: بعد كل شيء ، كل هذه الحلول في الواقع ليست مناسبة لأي حالة.

وأخيرًا تسأل: "هل هي قابلة للتخصيص؟"

أنت الآن جاهز لرحلة بحرية - ودعنا نتعرف على طائرة التحكم.

طائرة مراقبة

يتكون من ثلاثة مكونات: تجريبي, خلاط и قلعة، والتي تعمل معًا على تكوين Envoys لتوجيه حركة المرور وفرض السياسات وجمع بيانات التتبع عن بُعد. من الناحية التخطيطية ، يبدو كل شيء كما يلي:

تفاعل مستوى التحكم مع مستوى البيانات

يتم تكوين المبعوثين (أي مستوى البيانات) باستخدام كوبيرنيتيس CRD (تعريفات الموارد المخصصة) التي حددتها Istio والمصممة خصيصًا لهذا الغرض. ما يعنيه هذا بالنسبة لك هو أنها مجرد مصدر آخر في Kubernetes مع بناء جملة مألوف. بمجرد إنشائه ، سيتم التقاط هذا المورد بواسطة مستوى التحكم وتطبيقه على Envoys.

علاقة الخدمات بـ Istio

لقد وصفنا علاقة Istio بالخدمات ، لكن ليس العكس: كيف ترتبط الخدمات بـ Istio؟

لكي نكون صادقين ، تعرف الخدمات عن وجود Istio وكذلك تعرف الأسماك عن المياه ، عندما يسألون أنفسهم: "ما هو الماء على أي حال؟".

توضيح فيكتوريا ديميتراكوبولوس: كيف تحب الماء؟ - ما هو الماء على أي حال؟

وبالتالي ، يمكنك أن تأخذ مجموعة عمل وبعد نشر مكونات Istio ، ستستمر الخدمات الموجودة فيها في العمل ، وبعد إزالة هذه المكونات ، سيكون كل شيء على ما يرام مرة أخرى. من الواضح أنك في هذه الحالة ستفقد الفرص التي يوفرها Istio.

نظرية كافية - دعنا نضع هذه المعرفة موضع التنفيذ!

Istio في الممارسة

يتطلب Istio مجموعة Kubernetes مع توفر 4 وحدات معالجة مركزية (vCPU) على الأقل و 8 جيجابايت من ذاكرة الوصول العشوائي. لرفع الكتلة بسرعة واتباع الإرشادات الواردة في المقالة ، أوصي باستخدام Google Cloud Platform ، الذي يوفر للمستخدمين الجدد 300 دولار مجانا.

بعد إنشاء المجموعة وإعداد الوصول إلى Kubernetes من خلال الأداة المساعدة لوحدة التحكم ، يمكنك تثبيت Istio من خلال مدير الحزم Helm.

تركيب خوذة

قم بتثبيت عميل Helm على جهاز الكمبيوتر الخاص بك كما هو موضح في الوثائق الرسمية. سنستخدمه لإنشاء قوالب لتثبيت Istio في القسم التالي.

تثبيت

تنزيل موارد Istio من أحدث إصدار (تم تغيير رابط المؤلف الأصلي للإصدار 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 في الكتلة! انتظر حتى تتواجد كل البودات في مساحة الاسم istio-system سيكون قادر Running أو Completedعن طريق تشغيل الأمر أدناه:

$ kubectl get pods -n istio-system

نحن الآن جاهزون للمتابعة إلى القسم التالي ، حيث سنقوم برفع التطبيق وتشغيله.

هندسة تطبيق تحليل المشاعر

دعنا نستخدم مثال تطبيق الخدمات المصغرة لتحليل المشاعر المستخدم في ما سبق ذكره مقالة مقدمة إلى Kubernetes. إنه معقد بما يكفي لإظهار إمكانيات Istio في الممارسة.

يتكون التطبيق من أربع خدمات مصغرة:

1. خدمة SA- الواجهة الأمامية، الذي يخدم تطبيق الواجهة الأمامية على Reactjs ؛
2. خدمة SA WebApp، والتي تقدم استعلامات تحليل المشاعر ؛
3. خدمة منطق SAالذي يؤدي نفسه تحليل المشاعر;
4. خدمة ملاحظات SA، والتي تتلقى تعليقات من المستخدمين حول دقة التحليل المنفذ.

في هذا المخطط ، بالإضافة إلى الخدمات ، نرى أيضًا وحدة التحكم في الدخول ، والتي تقوم في Kubernetes بتوجيه الطلبات الواردة إلى الخدمات المقابلة. يستخدم Istio مفهومًا مشابهًا كجزء من بوابة الدخول ، وستتبع تفاصيله.

بدء تشغيل تطبيق مع وكيل من Istio

لمزيد من العمليات المذكورة في المقالة ، قم باستنساخ المستودع الخاص بك إتقان 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

بصريا يبدو كالتالي:

وكيل المبعوث في إحدى الكبسولات

الآن وبعد أن تم تشغيل التطبيق ، نحتاج إلى السماح لحركة المرور الواردة بالدخول إلى التطبيق.

بوابة الدخول

أفضل ممارسة لتحقيق ذلك (السماح بحركة المرور في الكتلة) هي من خلال بوابة الدخول في Istio ، والذي يقع على "حافة" المجموعة ويسمح لك بتمكين ميزات Istio مثل التوجيه وموازنة الحمل والأمن ومراقبة حركة المرور الواردة.

تم تثبيت مكون بوابة الدخول والخدمة التي تقوم بإعادة توجيهها إلى الخارج على الكتلة أثناء تثبيت 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 لأنه بشكل افتراضي ، يحظر Istio كل حركة المرور الواردةحتى يتم تعريف البوابة.

مورد البوابة

البوابة عبارة عن 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. باستخدام هذا المحدد ، يمكننا تحديد بوابة الدخول التي سيتم تطبيق التكوين عليها. في حالتنا ، هذه هي وحدة التحكم في بوابة الدخول ، والتي تم تثبيتها افتراضيًا في Istio.

يتم تطبيق التكوين عن طريق استدعاء الأمر التالي:

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

تسمح البوابة الآن بالوصول إلى المنفذ 80 ولكن ليس لديها فكرة عن مكان توجيه الطلبات. لهذا سوف تحتاج الخدمات الافتراضية.

مورد الخدمة الافتراضية

تخبر VirtualService بوابة الدخول عن كيفية توجيه الطلبات المسموح بها داخل المجموعة.

يجب إرسال الطلبات الواردة إلى تطبيقنا عبر بوابة http إلى خدمات sa-frontend و sa-web-app و sa-feedback:

المسارات المراد تكوينها مع VirtualServices

ضع في اعتبارك الطلبات التي يجب إرسالها إلى SA-Frontend:

• تطابق تام على طول الطريق / يجب إرسالها إلى SA-Frontend للحصول على index.html ؛
• المسارات ذات البادئة /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 ، وبعد ذلك ، يتم تطبيق التكوين الجديد على وكيل Envoy الخاص بكل مجموعة. ويبدو أن وحدة التحكم في بوابة الدخول هي مبعوث آخر تم تكوينه في مستوى التحكم. كل هذا يبدو كما يلي في الرسم التخطيطي:


تكوين Istio-IngressGateway لتوجيه الطلب
تحليل المعنويات متاح الآن على http://{EXTERNAL-IP}/. لا تقلق إذا حصلت على حالة غير موجود: أحيانًا يستغرق الأمر وقتًا أطول قليلاً حتى تدخل التهيئة حيز التنفيذ ولكي يتم تحديث ذاكرة التخزين المؤقت Envoy.
قبل المتابعة ، العب مع التطبيق قليلاً لتوليد حركة المرور. (وجودها ضروري للتوضيح في الإجراءات اللاحقة - الترجمة تقريبًا.).
كيالي: قابلية الملاحظة
للوصول إلى واجهة مسؤول Kiali ، قم بتشغيل الأمر التالي:

… وفتح http://localhost:20001/عن طريق تسجيل الدخول كمسؤول / مشرف. ستجد هنا العديد من الميزات المفيدة ، على سبيل المثال ، للتحقق من تكوين مكونات Istio ، وتصور الخدمات من المعلومات التي تم جمعها عن طريق اعتراض طلبات الشبكة ، والحصول على إجابات للأسئلة "من يتصل بمن؟" ، "أي إصدار من الخدمة يواجه الفشل؟ " وما إلى ذلك وهلم جرا. بشكل عام ، استكشف إمكانيات Kiali قبل الانتقال إلى تصور المقاييس باستخدام Grafana.

غرافانا: تصور المقاييس
تنتهي المقاييس التي تم جمعها في Istio في Prometheus ويتم تصورها باستخدام Grafana. للوصول إلى واجهة مشرف Grafana ، قم بتشغيل الأمر أدناه ، ثم افتح http://localhost:3000/:

من خلال النقر على القائمة الصفحة الرئيسية أعلى اليسار وحدد لوحة معلومات خدمة Istio في الزاوية اليسرى العلوية ، ابدأ بالخدمة sa-web-appلعرض المقاييس التي تم جمعها:

نحن هنا ننتظر أداءً فارغًا ومملًا تمامًا - لن توافق الإدارة على ذلك أبدًا. لنقم بإنشاء حمل صغير بالأمر التالي:

الآن لدينا رسوم بيانية أجمل بكثير ، بالإضافة إلى الأدوات الرائعة بروميثيوس للمراقبة وجرافانا لتصور المقاييس ، والتي ستسمح لنا بالتعرف على الأداء والحالة الصحية والتحسينات / التدهور في الخدمات بمرور الوقت.
أخيرًا ، لنلقِ نظرة على تتبع الطلبات في الخدمات.
جايجر: البحث عن المفقودين
سنحتاج إلى البحث عن المفقودين ، لأنه كلما زاد عدد الخدمات التي لدينا ، زادت صعوبة الوصول إلى سبب الفشل. لنلقِ نظرة على حالة بسيطة من الصورة أدناه:


مثال نموذجي لطلب عشوائي فاشل
يأتي الطلب ، يقع - ماهو السبب؟ الخدمة الأولى؟ أو الثانية؟ هناك استثناءات في كليهما - فلنلق نظرة على سجلات كل منهما. كم مرة وجدت نفسك تفعل هذا؟ وظيفتنا هي أشبه بمحققين برمجيات أكثر من كونها مطورين ...
هذه مشكلة منتشرة في الخدمات المصغرة ويتم حلها عن طريق أنظمة التتبع الموزعة ، حيث تقوم الخدمات بتمرير رأس فريد لبعضها البعض ، وبعد ذلك يتم إعادة توجيه هذه المعلومات إلى نظام التتبع ، حيث تتم مقارنتها ببيانات الطلب. هنا توضيح:


يستخدم TraceId لتحديد الطلب
يستخدم Istio Jaeger Tracer ، الذي يطبق إطار عمل OpenTracing API مستقل عن البائع. يمكنك الوصول إلى واجهة مستخدم Jaeger بالأمر التالي:

اذهب الآن إلى http://localhost:16686/ واختر الخدمة sa-web-app. إذا لم تظهر الخدمة في القائمة المنسدلة ، فقم بإظهار / إنشاء نشاط على الصفحة وتحديث الواجهة. بعد ذلك اضغط على الزر البحث عن آثار، والتي ستظهر أحدث الآثار - حدد أي - ستظهر معلومات مفصلة عن جميع الآثار:

يظهر هذا التتبع:

 يأتي الطلب بوابة الدخول (هذا هو التفاعل الأول مع إحدى الخدمات ، ويتم إنشاء معرف تتبع للطلب) ، وبعد ذلك ترسل البوابة الطلب إلى الخدمة sa-web-app.
 في الخدمة sa-web-app يتم التقاط الطلب من قبل Envoy sidecar ، يتم إنشاء "طفل" في النطاق (لهذا السبب نراه في التتبع) وإعادة توجيهه إلى الحاوية sa-web-app. (امتداد - وحدة عمل منطقية في جايجر ولها اسم ووقت بدء العملية ومدتها. يمكن أن تتداخل الامتدادات وترتيبها. يشكل الرسم البياني غير الدوري الموجه للمسافات أثرًا. - تقريبا. ترجمة.)
 هنا تتم معالجة الطلب بالطريقة تحليل المشاعر. تم إنشاء هذه الآثار بالفعل بواسطة التطبيق ، أي طلبوا تغييرات التعليمات البرمجية.
 من هذه اللحظة ، يتم بدء طلب POST في سا منطق. يجب إعادة توجيه معرف التتبع من sa-web-app.
 ...

لاحظ: في الخطوة 4 ، يجب أن يرى التطبيق الرؤوس التي تم إنشاؤها بواسطة Istio وتمريرها إلى الطلبات اللاحقة ، كما هو موضح في الصورة أدناه:


(أ) إعادة توجيه العنوان هو مسؤولية Istio ؛ (ب) الخدمات مسؤولة عن الرؤوس
يقوم Istio بمعظم العمل بسبب يُنشئ رؤوس الطلبات الواردة ، ويُنشئ مسافات جديدة في كل رعاية جانبية ويعيد توجيهها. ومع ذلك ، بدون العمل مع الرؤوس داخل الخدمات ، سيتم فقد مسار تتبع الطلب الكامل.
يجب مراعاة (إعادة توجيه) الرؤوس التالية:

هذه مهمة بسيطة ، ولكن لتبسيط تنفيذها ، هناك بالفعل العديد من المكتبات - على سبيل المثال ، في خدمة تطبيق الويب sa-web-app ، يقوم عميل RestTemplate بإعادة توجيه هذه الرؤوس إذا قمت ببساطة بإضافة مكتبات Jaeger و OpenTracing إلى تبعياتها.
لاحظ أن تطبيق تحليل المشاعر يوضح عمليات التنفيذ في Flask و Spring و ASP.NET Core.
الآن بعد أن أصبح واضحًا ما الذي نخرجه من الصندوق (أو تقريبًا خارج الصندوق) ، فلنلقِ نظرة على ضبط التوجيه وإدارة حركة مرور الشبكة والأمان والمزيد!
ملحوظة. ترجمة.: اقرأ عن هذا في الجزء التالي من المواد الخاصة بـ Istio بواسطة Rinor Maloku ، والتي ستتبع ترجماتها على مدونتنا في المستقبل القريب. قم  (14 مارس): الجزء الثاني نشرت بالفعل.
PS من المترجم
اقرأ أيضًا على مدونتنا:

 "رجوع إلى الخدمات المصغرة مع Istio": الجزء 2 (التوجيه ، مراقبة حركة المرور), الجزء 3 (المصادقة والترخيص);
 «القناة - شبكة خدمة خفيفة الوزن لـ Kubernetes"؛
 «ما المقصود بشبكة الخدمة ولماذا أحتاجها [لتطبيق سحابي مزود بخدمات مصغرة]؟"؛
 «دليل مصور للتواصل في Kubernetes. الأجزاء 1 و 2"؛
 «كيف انتهى المطاف بهذه الحاوية الجانبية هنا [في Kubernetes]؟".

المصدر: www.habr.com