قصة قصيرة حول مزايا ومساوئ الخدمات الصغيرة ومفهوم شبكة الخدمة وأدوات Google التي تسمح لك بتشغيل تطبيقات الخدمات المصغرة دون انسداد رأسك بإعدادات لا نهاية لها من السياسات والوصول والشهادات والعثور بسرعة على أخطاء مخفية ليس في التعليمات البرمجية ، ولكن في منطق الخدمات الصغيرة.
تستند المقالة إلى
تقرير Craig Box في مؤتمر DevOops 2017 الذي عقدناه في العام الماضي.
Craig Box (Craig Box،
Twitter ) - DevRel من Google المسؤول عن الخدمات الصغيرة وأدوات Kubernetes و Istio. تدور قصته الحالية حول إدارة الخدمات الصغيرة على هذه المنصات.
لنبدأ بمفهوم جديد نسبيًا يسمى Service Mesh. يستخدم هذا المصطلح لوصف شبكة الخدمات الصغيرة المتفاعلة التي تشكل التطبيق.
على مستوى عال ، نرى الشبكة كأنبوب يتحرك ببساطة القطع. لا نريد أن نقلق بشأنهم أو ، على سبيل المثال ، بشأن عناوين MAC في التطبيقات ، لكننا نسعى جاهدين للتفكير في الخدمات والاتصالات التي يحتاجونها. إذا نظرت من وجهة نظر
OSI ، فلدينا شبكة من المستوى الثالث (مع وظائف لتحديد المسار والعنونة المنطقية) ، لكننا نريد أن نفكر من حيث السابع (مع وظيفة الوصول إلى خدمات الشبكة).
كيف يجب أن تبدو شبكة المستوى السابع الحقيقية؟ ربما نريد أن نرى شيئًا مثل أثر حركة المرور حول الخدمات الإشكالية. بحيث يمكنك الاتصال بالخدمة ، وفي نفس الوقت تم رفع مستوى النموذج من المستوى الثالث. نريد الحصول على فكرة عما يحدث في المجموعة ، والعثور على تبعيات غير مقصودة ، ومعرفة الأسباب الجذرية للفشل. نحتاج أيضًا إلى تجنب النفقات العامة غير الضرورية ، على سبيل المثال ، الاتصال بوقت استجابة مرتفع أو الاتصال بالخوادم التي تحتوي على ذاكرة تخزين مؤقت باردة أو غير دافئة بالكامل.
يجب أن نتأكد من أن حركة المرور بين الخدمات محمية من الهجمات التافهة. مطلوب مصادقة TLS المتبادلة ، ولكن دون تضمين الوحدات المناسبة في كل تطبيق نكتبه. من المهم أن تكون قادرًا على التحكم في ما يحيط بتطبيقاتنا ليس فقط على مستوى الاتصال ، ولكن أيضًا على مستوى أعلى.
Service Mesh عبارة عن طبقة تسمح لنا بحل المشكلات المذكورة أعلاه في بيئة خدمة صغيرة.
المونوليث والخدمات الصغيرة: إيجابيات وسلبيات
لكن أولاً نسأل أنفسنا ، لماذا يجب أن نحل هذه المشاكل على الإطلاق؟ كيف فعلنا تطوير البرمجيات من قبل؟ كان لدينا تطبيق يشبه شيئًا كهذا - متآلف.
إنه أمر رائع: كل الشفرة في العرض الكامل. لماذا لا تستمر في استخدام هذا النهج؟
نعم ، لأن المونوليث له مشاكله الخاصة. الصعوبة الرئيسية هي أنه إذا أردنا إعادة بناء هذا التطبيق ، فيجب علينا إعادة نشر كل وحدة نمطية ، حتى لو لم يتغير شيء. نحن مضطرون لإنشاء تطبيق بنفس اللغة أو بلغات متوافقة ، حتى إذا كانت فرق مختلفة تعمل عليه. في الواقع ، لا يمكن اختبار الأجزاء الفردية بشكل مستقل عن بعضها البعض. حان الوقت لتغييره ، حان الوقت لتقديم الخدمات الصغيرة.
لذا ، قمنا بتقسيم المونوليث إلى أجزاء. قد تلاحظ أننا في هذا المثال أزلنا بعض التبعيات غير الضرورية وتوقفنا عن استخدام الطرق الداخلية التي تم استدعاؤها من الوحدات الأخرى. أنشأنا خدمات من النماذج التي تم استخدامها سابقًا ، وخلق تجريد في الحالات التي نحتاج فيها للحفاظ على الحالة. على سبيل المثال ، يجب أن يكون لكل خدمة دولة مستقلة بحيث لا داعي للقلق بشأن ما يحدث في باقي بيئتنا عند الوصول إليها.
ما هي النتيجة؟
تركنا عالم التطبيقات العملاقة للحصول على ما يبدو رائعًا حقًا. قمنا بتسريع التطوير ، وتوقفنا عن استخدام الأساليب الداخلية ، وأنشأنا الخدمات ، والآن يمكننا توسيع نطاقها بشكل مستقل ، وجعل الخدمة أكبر بدون الحاجة إلى دمج كل شيء آخر. ولكن ما هو ثمن التغيير الذي فقدناه؟
كان لدينا مكالمات موثوقة داخل التطبيقات لأنك ببساطة تسمى وظيفة أو وحدة. لقد استبدلنا المكالمة الموثوقة داخل الوحدة باستدعاء إجراء بعيد غير موثوق به. لكن الخدمة على الجانب الآخر ليست متاحة دائمًا.
كنا بأمان ، باستخدام نفس العملية داخل نفس الجهاز. نحن الآن بصدد الاتصال بالخدمات التي قد تكون على أجهزة مختلفة وعلى شبكة غير موثوق بها.
في النهج الجديد على الشبكة ، من الممكن وجود مستخدمين آخرين يحاولون الاتصال بالخدمات. زادت التأخيرات ، وفي الوقت نفسه ، انخفضت قدرات القياس. الآن لدينا اتصالات خطوة بخطوة في جميع الخدمات التي تنشئ مكالمة وحدة واحدة ، ولم يعد بإمكاننا فقط النظر إلى التطبيق في مصحح الأخطاء ومعرفة سبب بالضبط الفشل. ويجب حل هذه المشكلة بطريقة أو بأخرى. من الواضح أننا بحاجة إلى مجموعة جديدة من الأدوات.
ما الذي يمكن فعله؟
هناك عدة خيارات. يمكننا أن نأخذ طلبنا ونقول أنه إذا لم يعمل
RPC في المرة الأولى ، فيجب عليك المحاولة مرة أخرى ، ثم مرة تلو الأخرى. انتظر قليلاً وحاول مرة أخرى أو أضف Jitter. يمكننا أيضًا إضافة آثار دخول - خروج لقول أن المكالمة بدأت وانتهت ، وهو ما يعادل بالنسبة لي تصحيح الأخطاء. يمكنك إضافة بنية أساسية لتوفير مصادقة الاتصالات وتعليم جميع تطبيقاتنا كيفية العمل مع تشفير TLS. سيتعين علينا أن نتحمل عبء محتوى الفرق الفردية ونضع في اعتبارنا باستمرار المشاكل المختلفة التي قد تنشأ في مكتبات SSL.
يعد الحفاظ على الاتساق عبر منصات متعددة مهمة جاحدة. أود أن تصبح المسافة بين التطبيقات معقولة ، بحيث توجد إمكانية التتبع. نحتاج أيضًا إلى القدرة على تغيير التكوينات في وقت التشغيل حتى لا يتم إعادة ترجمة التطبيقات أو إعادة تشغيلها للترحيل. قائمة الرغبات هذه وتنفذ شبكة الخدمة.
Isstio
تحدث عن
Istio .
Istio هو إطار عمل كامل لتوصيل وإدارة ومراقبة هيكل الخدمات الصغيرة. تم تصميم Istio للعمل على Kubernetes. هو نفسه لا ينشر البرنامج ولا يهتم بإتاحته على الأجهزة التي نستخدمها لهذا الغرض مع حاويات في Kubernetes.
في الشكل ، نرى ثلاثة أقسام مختلفة من الآلات والكتل التي تشكل خدماتنا الصغيرة. لدينا طريقة لتجميعها معًا باستخدام الآليات التي توفرها Kubernetes. يمكننا أن نستهدف ونقول أن مجموعة معينة ، والتي قد يكون لها مقياس تلقائي ، مرتبطة بخدمة ويب أو قد تكون لها طرق نشر أخرى ، ستحتوي على خدمة الويب الخاصة بنا. في هذه الحالة ، لا نحتاج إلى التفكير في الأجهزة ، فنحن نعمل من حيث مستوى الوصول إلى خدمات الشبكة.
يمكن تمثيل هذا الموقف في شكل رسم بياني. فكر في مثال عندما يكون لدينا آلية تقوم ببعض معالجة الصور. المستخدم على اليسار هو حركة المرور التي تأتي إلينا في الخدمات الصغيرة.
لقبول الدفع من المستخدم ، لدينا خدمة دفع صغيرة منفصلة تستدعي واجهة برمجة تطبيقات خارجية تقع خارج المجموعة.
لمعالجة تسجيل دخول المستخدم ، نقدم خدمة مصادقة مصغرة ، ولديها حالات مخزنة مرة أخرى خارج مجموعتنا في
قاعدة بيانات Cloud SQL .
ماذا تفعل Istio؟ يحسن Istio Kubernetes. يمكنك تثبيته باستخدام وظيفة ألفا في Kubernetes تسمى Initializer. عند نشر البرنامج ، ستلاحظه kubernetes وتسأل عما إذا كنا نريد تغيير وإضافة حاوية أخرى داخل كل kubernetes. ستتعامل هذه الحاوية مع المسارات والتوجيه ، كن على دراية بكل تغييرات التطبيق.
هكذا تبدو الدائرة مع Istio.
لدينا أجهزة خارجية توفر بروكسيات واردة وصادرة لحركة المرور في خدمة معينة. يمكننا تفريغ الوظائف التي تحدثنا عنها بالفعل. لسنا بحاجة إلى تعليم التطبيق كيفية إجراء القياس عن بعد أو التتبع باستخدام TLS. ولكن يمكننا إضافة أشياء أخرى في الداخل: المقاطعة التلقائية ، حد السرعة ،
إطلاق الكناري .
ستنتقل جميع الزيارات الآن عبر خوادم الوكيل على أجهزة خارجية ، وليس مباشرة إلى الخدمات. تقوم Kubernetes بكل شيء على نفس عنوان IP. سنكون قادرين على اعتراض حركة المرور التي ستذهب إلى الخدمات الأمامية أو النهائية.
يسمى الوكيل الخارجي الذي يستخدمه Istio
Envoy .
المبعوث هو في الواقع أقدم من Istio ، تم تطويره في Lyft. تعمل في الإنتاج منذ أكثر من عام ، حيث أطلقت البنية التحتية الكاملة للخدمات الصغيرة. لقد اخترنا Envoy لمشروع Istio بالتعاون مع المجتمع. وبالتالي ، فإن Google و IBM و LYFT هي الشركات الثلاث التي لا تزال تعمل عليها.
المبعوث مكتوب في C ++ 11. وقد تم إنتاجه لأكثر من 18 شهرًا قبل أن يصبح مشروعًا مفتوح المصدر. لن يتطلب الأمر الكثير من الموارد عند توصيله بخدماتك.
فيما يلي بعض الأشياء التي يمكن للمبعوث القيام بها. هذا هو إنشاء خادم وكيل لـ HTTP ، بما في ذلك HTTP / 2 والبروتوكولات القائمة عليه ، مثل gRPC. يمكن أيضًا إعادة التوجيه إلى بروتوكولات أخرى على المستوى الثنائي. يتحكم المبعوث في منطقة البنية التحتية الخاصة بك حتى تتمكن من جعل الجزء الخاص بك مستقلاً. يمكنه التعامل مع عدد كبير من اتصالات الشبكة مع إعادة المحاولة والانتظار. يمكنك تعيين عدد معين من المحاولات للاتصال بالخادم قبل إيقاف المكالمة وإرسال المعلومات إلى الخوادم التي لا تستجيب لها الخدمة.
لا داعي للقلق بشأن إعادة تحميل التطبيق لإضافة التكوين إليه. يمكنك ببساطة الاتصال به باستخدام واجهة برمجة تطبيقات تشبه إلى حد كبير kubernetes وتغيير التكوين في وقت التشغيل.
قدم فريق Istio مساهمة كبيرة لمنصة UpStream Envoy Platform. على سبيل المثال ، تنبيه خطأ حقن. لقد جعلنا من الممكن معرفة كيفية تصرف التطبيق في حالة تجاوز عدد الطلبات للعنصر الذي فشل. كما تم تنفيذ وظائف العرض الرسومي وفصل الحركة للتعامل مع الحالات عند استخدام الكناري.
يوضح الشكل كيف تبدو بنية نظام Istio. سوف نأخذ خدمتين صغيرتين فقط تم ذكرهما سابقًا. في النهاية ، في الرسم التخطيطي ، كل شيء مشابه جدًا للشبكة المعرفة بالبرمجيات. من خادم وكيل Envoy ، الذي نشرناه مع التطبيقات ، يتم نقل حركة المرور باستخدام جداول IP في مساحة الاسم. لوحة التحكم مسؤولة عن إدارة وحدة التحكم ، لكنها لا تعالج حركة المرور نفسها.
لدينا ثلاثة مكونات. يقوم Pilot ، الذي يقوم بإنشاء التكوين ، بالنظر في القواعد التي يمكن تغييرها باستخدام واجهة برمجة التطبيقات الخاصة بلوحة تحكم Istio ، ثم يقوم بتحديث Envoy بحيث يتصرف مثل خدمة اكتشاف الكتلة. يعمل Istio-Auth كمرجع مصدق ويرسل شهادات TLS إلى الوكلاء. لا يتطلب التطبيق طبقة المقابس الآمنة (SSL) ، ويمكنهم الاتصال عبر HTTP ، وسيتعامل الوكلاء مع كل هذا نيابة عنك.
يعالج Mixer الطلبات للتأكد من التزامك بسياسة الأمان ، ثم ينقل معلومات القياس عن بُعد. بدون إجراء أي تغييرات على التطبيق ، يمكننا رؤية كل ما يحدث داخل مجموعتنا.
فوائد Istio
لذا ، دعونا نتحدث بمزيد من التفصيل عن الأشياء الخمسة التي سنحصل عليها من Istio. بادئ ذي بدء ، خذ بعين الاعتبار
إدارة حركة المرور . يمكننا فصل التحكم في حركة المرور عن توسيع البنية التحتية ، لذلك في وقت سابق يمكننا القيام بشيء مثل 20 مثيلًا للتطبيق وستكون 19 منها في الإصدار القديم ، وواحدة في النسخة الجديدة ، أي 5 ٪ من حركة المرور ستكون في الإصدار الجديد. مع Istio ، يمكننا نشر أي عدد من الحالات التي نحتاجها ، وفي نفس الوقت تحديد النسبة المئوية للزيارات التي يجب إرسالها إلى الإصدارات الجديدة. قاعدة بسيطة للانفصال.
يمكن برمجة كل شيء على الطاير باستخدام القواعد. سيتم تحديث المبعوث بشكل دوري مع تغير التكوين ، وهذا لن يؤدي إلى انقطاع الخدمة. نظرًا لأننا نعمل على مستوى الوصول إلى خدمات الشبكة ، يمكننا عرض الحزم ، وفي هذه الحالة هناك فرصة للدخول إلى وكيل المستخدم ، والذي يقع في المستوى الثالث من الشبكة.
على سبيل المثال ، يمكننا القول أن أي حركة مرور من جهاز iPhone تتبع قاعدة مختلفة ، وسنوجه جزءًا معينًا من حركة المرور إلى الإصدار الجديد ، والذي نريد اختباره لجهاز معين. يمكن أن تحدد خدمة الاتصال الداخلي الصغيرة الإصدار المحدد الذي تحتاج إلى الاتصال به ، ويمكنك نقله إلى إصدار آخر ، على سبيل المثال ، 2.0.
الميزة الثانية هي
الشفافية . عندما يكون لديك طريقة عرض داخل الكتلة ، يمكنك أن تفهم كيف يتم ذلك. لسنا بحاجة إلى إنشاء أدوات للمقاييس في عملية التطوير. المقاييس موجودة بالفعل في كل مكون.
يعتقد البعض أنه يكفي الاحتفاظ بسجل للمراقبة. ولكن في الحقيقة ، كل ما نحتاجه هو الحصول على مجموعة عالمية من المؤشرات التي يمكن إطعامها لأي خدمة مراقبة.
هذه هي الطريقة التي يبدو بها شريط أدوات Istio الذي تم إنشاؤه باستخدام خدمة Prometheus. تذكر أن تنشره داخل الكتلة.
في المثال ، تعرض لقطة الشاشة عددًا من المعلمات المراقبة الخاصة بالمجموعة بأكملها. يمكن استخلاص أشياء أكثر إثارة للاهتمام ، على سبيل المثال ، ما هي النسبة المئوية للتطبيقات التي تعطي أكثر من 500 خطأ ، مما يعني فشل. يتم تجميع وقت الاستجابة في جميع مثيلات خدمة الاتصال والاستجابة داخل المجموعة ؛ ولا تتطلب هذه الوظيفة إعدادات. يعرف Istio ما يدعمه Prometheus ، وهو يعرف ما هي الخدمات المتاحة في مجموعتك ، لذا يمكن لـ Istio-Mixer إرسال المقاييس إلى Prometheus دون أي إعدادات إضافية.
دعونا نرى كيف يعمل. إذا قمت بالاتصال بخدمة معينة ، ترسل خدمة الوكيل معلومات حول هذه المكالمة إلى Mixer ، والتي تلتقط معلمات مثل وقت الانتظار للاستجابة وحالة الرمز و IP. يقوم بتطبيعها وإرسالها إلى أي خوادم قمت بتكوينها. خاصة لعرض المؤشرات الرئيسية ، هناك خدمة Prometheus ومحولات FLUX DB ، ولكن يمكنك أيضًا كتابة المحول الخاص بك وعرض البيانات بأي تنسيق لأي تطبيق آخر. ولا يتعين عليك تغيير أي شيء في البنية التحتية إذا كنت ترغب في إضافة مقياس جديد.
إذا كنت ترغب في إجراء المزيد من البحث المتعمق ، استخدم
نظام التتبع الموزع
Zipkin . يمكن إرسال معلومات حول جميع المكالمات التي يتم توجيهها عبر Istio-Mixer إلى Zipkin. هناك سترى سلسلة مكالمات الخدمة الصغيرة بالكامل عند الرد على المستخدم وستجد بسهولة خدمة تؤخر وقت المعالجة.
على مستوى التطبيق ، لا داعي للقلق بشأن إنشاء تتبع. يقوم المبعوث نفسه بتمرير جميع المعلومات اللازمة إلى Mixer ، الذي يرسلها إلى التتبع ، على سبيل المثال ، إلى Zipkin ،
تتبع مكدس stackdriver من Google أو أي تطبيق مستخدم آخر.
دعونا نتحدث عن
التسامح مع الخطأ والكفاءة .
هناك حاجة إلى مهلات بين مكالمات الخدمة لاختبار صحة موازين التحميل ، أولاً وقبل كل شيء. نقدم أخطاء في هذا الاتصال ونرى ما سيحدث. تأمل في مثال. افترض أن هناك اتصال بين الخدمة أ والخدمة ب. ننتظر استجابة من خدمة الفيديو لمدة 100 مللي ثانية ونقدم 3 محاولات فقط إذا لم يتم تلقي النتيجة. في الجوهر ، سنأخذها لمدة 300 مللي ثانية قبل أن تبلغ عن محاولة اتصال فاشلة.
علاوة على ذلك ، على سبيل المثال ، يجب أن تنظر خدمة الفيلم لدينا في تصنيف الفيلم من خلال خدمة مايكرو أخرى. التصنيف لديه مهلة 200 مللي ثانية ويتم إعطاء محاولتي اتصال. يمكن أن يؤدي الاتصال بخدمة الفيديو إلى الانتظار 400 مللي ثانية إذا كان تصنيف النجوم بعيدًا عن متناول اليد. ولكن ، نتذكر أنه بعد 300 مللي ثانية ، ستبلغ خدمة الفيلم بأنها خاملة ، ولن نعرف أبدًا السبب الحقيقي للفشل. يعد استخدام المهلات واختبار ما يحدث في هذه الحالات طريقة رائعة للعثور على جميع أنواع الأخطاء الذكية في بنية الخدمات الدقيقة.
دعنا نرى الآن ما هي الكفاءة. يعمل موازن kubernetes نفسه فقط على مستوى الطبقة الرابعة. اخترعنا مُنشئ إدخال لموازنة الحمل من الطبقة الثانية إلى الطبقة السابعة. يتم تطبيق Istio كموازن لطبقة الشبكة مع الوصول إلى خدمات الشبكة.
نحن نقوم بإلغاء تحميل TLS ، لذلك نستخدم SSL حديث مخدر جيدًا في Envoy ، لذلك لا داعي للقلق بشأن نقاط الضعف.
ميزة أخرى لـ Istio هي
الأمان .
ما هي ميزات الأمان الأساسية في Istio؟ تعمل خدمة Istio-Auth في عدة اتجاهات. ويستخدم إطارًا عامًا ومجموعة من معايير المصادقة لخدمات
SPIFFE . إذا كنا نتحدث عن تدفق حركة المرور ، فلدينا سلطة شهادة Istio التي تصدر شهادات لحسابات الخدمة التي نقوم بتشغيلها داخل الكتلة. تتوافق هذه الشهادات مع معيار SPIFFE ويتم توزيعها بواسطة Envoy باستخدام آلية kubernetes الأمنية. يستخدم Envoy المفاتيح لمصادقة TLS ثنائية الاتجاه. وبالتالي ، تتلقى تطبيقات الواجهة الخلفية معرفات يمكن على أساسها بالفعل تنظيم سياسة.
تحتفظ Istio بشهادات الجذر بمفردها ، لذا لا داعي للقلق بشأن تواريخ الإلغاء وانتهاء الصلاحية. سيستجيب النظام للتحجيم التلقائي ، لذلك عند تقديم كيان جديد ، تحصل على شهادة جديدة. لا توجد إعدادات يدوية. لا تحتاج إلى تكوين جدار حماية. سيستخدم المستخدمون سياسة الشبكة و kubernetes لتنفيذ جدران الحماية بين الحاويات.
وأخيرا
تطبيق السياسات . Mixer هي نقطة تكامل مع خلفية البنية التحتية التي يمكنك توسيعها باستخدام Service Mesh. يمكن أن تنتقل الخدمات بسهولة داخل مجموعة ، ويتم نشرها في بيئات متعددة ، في السحابة أو محليًا. تم تصميم كل شيء للتحكم التشغيلي في المكالمات التي تمر عبر المبعوث.
يمكننا السماح بمكالمات معينة وحظرها ، وتعيين شروط مسبقة للمكالمات الفائتة ، والحد من سرعتها وعددها. على سبيل المثال ، أنت تسمح بـ 20 طلبًا مجانيًا يوميًا لبعض الخدمات. إذا قدم المستخدم 20 طلبًا ، فلن تتم معالجة الطلبات اللاحقة.قد تتضمن المتطلبات الأساسية أشياء مثل ، على سبيل المثال ، الخادم الذي تتم مصادقته و ICL ووجوده في القائمة البيضاء. يمكن استخدام إدارة الحصص في الحالات التي يكون فيها من المطلوب أن يكون لكل من يستخدم الخدمة نفس سرعة الوصول. وأخيرًا ، يجمع Mixer نتائج الطلبات والاستجابة الجاهزة للقياس عن بُعد. يسمح هذا للمصنعين والمستخدمين بمشاهدة القياس عن بعد باستخدام الخدمات.
هل تذكر الشريحة الأولى مع تطبيق صور بدأنا في تعلم Istio؟ كل ما سبق مخفي تحت هذا الشكل البسيط. في المستوى الأعلى ، سيتم تنفيذ كل ما تحتاجه تلقائيًا. ستنشر التطبيق ولن تقلق بشأن كيفية تحديد سياسة أمان أو تكوين بعض قواعد التوجيه. سيعمل التطبيق تمامًا كما تتوقع.كيف تبدأ مع Istio
يدعم Istio الإصدارات السابقة من kubernetes ، ولكن ميزة المُهيئ الجديدة التي تحدثت عنها هي في الإصدارات 1.7 والإصدارات الأحدث. هذه دالة ألفا في kubernetes. أوصي باستخدام مجموعات Google Container Engine Alpha. لدينا مجموعات يمكنك تمكينها لعدد معين من الأيام وفي نفس الوقت تستخدم جميع إمكانات الإنتاج فيها.بادئ ذي بدء ، Istio هو مشروع مفتوح المصدر على جيثب. أصدرنا للتو الإصدار 0.2. في الإصدار 0.1 ، يمكنك إدارة الكائنات داخل مساحة اسم kubernetes التي تحمل الاسم نفسه. منذ الإصدار 0.2 ، ندعم العمل في مساحة الاسم الخاصة بنا وفي مجموعة kubernetes. أضفنا أيضًا إمكانية الوصول إلى القدرة على إدارة الخدمات التي تعمل على الأجهزة الافتراضية. يمكنك نشر Envoy في جهاز افتراضي وتأمين الخدمات التي تعمل عليه. في المستقبل ، ستدعم Istio الأنظمة الأساسية الأخرى ، مثل Cloud Foundry .دليل التثبيت السريع للإطار هنا.. إذا كان لديك مجموعة تعمل بنظام Google Container Engine 1.8 مع تمكين ميزات ألفا ، فإن تثبيت Istio هو أمر واحد فقط.إذا أعجبك هذا التقرير ، فانتقل إلى مؤتمر DevOops 2018 (Peter) في 14 أكتوبر : هناك لا يمكنك الاستماع إلى التقارير فحسب ، بل أيضًا الدردشة مع أي متحدث في منطقة المناقشة.