مشكلة البنية التحتية لسطح المكتب التي حلها kubernetes أخيرًا

مقدم من تقنيات قاسم

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

باستثناء أجهزة الكمبيوتر المكتبية.

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

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

والمسألة الأكثر جوهرية هي أن هذا الانقسام غير ضروري. يعد تسليم مساحة العمل الآمنة والمعبأة في حاوية عبء عمل يعتبر Kubernetes مناسبًا من الناحية المعمارية لتشغيله. الجلسات عبارة عن حاويات. التوسع يعتمد على الطلب. يجب أن يكون التكوين تصريحيًا. الشيء الوحيد المفقود هو النظام الأساسي المصمم للاستفادة من هذا التوافق.

لماذا التوقيت مناسب

لقد زادت الرغبة في تسليم مساحة العمل الأصلية لـ Kubernetes بشكل ملحوظ مع قيام المؤسسات بتطوير استثماراتها في منصات الحاويات. فرق النظام الأساسي التي أمضت سنوات في توحيد معايير سير عمل Helm وGitOps وقابلية المراقبة الأصلية في Kubernetes، أصبحت غير راغبة بشكل متزايد في إجراء استثناء للبنية التحتية لسطح المكتب. لقد تحول السؤال من "هل يمكننا تشغيل هذا على Kubernetes؟" ل "لماذا لا يتم تشغيل هذا على Kubernetes بالفعل؟"

وفي الوقت نفسه، أصبحت الحالة الأمنية المتعلقة بتسليم مساحة العمل في حاويات أكثر إلحاحًا. توفر مساحات العمل المُقدمة من خلال المتصفح عزلًا للجلسة لا يمكن لأجهزة الكمبيوتر المكتبية المستندة إلى VM مطابقتها – كل جلسة سريعة الزوال، ومعزولة عند حدود الحاوية، وتنتهي بشكل نظيف بدون حالة مستمرة. بالنسبة للمؤسسات التي تدير البيانات الحساسة، أو المخاطر الداخلية، أو سيناريوهات وصول الطرف الثالث، يعد نموذج العزل هذا بمثابة تحكم أمني مفيد، وليس مجرد وسيلة راحة للنشر.

إن التقارب بين هذين الاتجاهين – توقعات البنية التحتية الأصلية لـ Kubernetes وأمن الجلسة المضمنة في حاوية – يخلق فرصة واضحة للمنصات التي يمكنها معالجة كلا الاتجاهين في وقت واحد.

كيف يبدو النشر الأصلي لـ Kubernetes

يستخدم النشر الأصلي لـ Kubernetes Kubernetes كمستوى تحكم للبنية التحتية لمساحة العمل – حيث يتعامل مع التنسيق والقياس وإدارة دورة الحياة من خلال نفس النموذج التعريفي المستخدم عبر بقية النظام الأساسي. بدلاً من الاعتماد على أجهزة الإدارة المخصصة أو مجموعات سطح المكتب المتوفرة مسبقًا، تتم إدارة البنية التحتية من خلال نفس CI/CD وGitOps وقابلية المراقبة وسير العمل الأمني ​​الذي يعمل عليه فريق النظام الأساسي بالفعل. وهذا يمنح فرق النظام الأساسي نموذجًا تشغيليًا متسقًا بدلاً من الاحتفاظ بمجموعة أدوات منفصلة للبنية التحتية لسطح المكتب.

تم تصميم Kasm Workspaces، وهي منصة مساحة العمل التي يتم تسليمها عبر المتصفح، خصيصًا لاستخدام Kubernetes كمستوى تحكم لتنسيق مساحة العمل وتسليمها. تم تصميم نموذج النشر الخاص به لبيئات المؤسسات الحقيقية – وليس العروض التوضيحية المبسطة – مع مخططات Helm على مستوى الإنتاج التي تتبع اصطلاحات Kubernetes، ومسارات الترقية المختبرة بين الإصدارات، وبنية خلفية موحدة تم التحقق من صحتها عبر عمليات نشر الإنتاج. يتيح مكون بوابة RDP المصمم خصيصًا لهيكل Kubernetes إمكانية الوصول إلى الأجهزة الافتراضية التي تعمل بنظامي التشغيل Windows وLinux من خلال نفس النظام الأساسي.

تشمل القدرات الرئيسية ما يلي:

• تحجيم الجلسة الأفقية مدفوعًا بالطلب الفعلي، وبتنسيق من Kubernetes – لا حاجة إلى مجموعات VM مُجهزة مسبقًا.

• التكوين التعريفي من خلال قيم Helm، مما يتيح تكامل GitOps وCI/CD للبنية التحتية لمساحة العمل.

• العزل على مستوى مساحة الاسم والتوافق مع سياسات RBAC الحالية ووحدات التحكم في الدخول وتكاملات إدارة الأسرار.

• تصدير المقاييس للتكامل مع Prometheus ومكدسات إمكانية المراقبة الحالية.

• يتم إنشاء الإصدارات المتدرجة بشكل افتراضي، مما يقلل من فترات الصيانة ويتيح إدارة إصدار أكثر قابلية للتنبؤ بها.

تطبيقات العالم الحقيقي

الوصول عن بعد للصناعة الخاضعة للتنظيم. يمكن لمؤسسة الخدمات المالية التي تقوم بتشغيل نظام أساسي للتطبيقات المستندة إلى Kubernetes نشر Kasm في نفس المجموعة، باستخدام نفس الأدوات التشغيلية، لتقديم جلسات متصفح وتطبيقات معزولة للمحللين والمستشارين. تكون الجلسات سريعة الزوال، ويتم التحكم في خروج الشبكة، وتتم إدارة النشر بالكامل من خلال نفس خط أنابيب GitOps مثل أحمال عمل التطبيقات الخاصة بهم.

المقاول ووصول الطرف الثالث. يمكن للمؤسسات التي تتعاقد بشكل منتظم مع المقاولين أو البائعين الخارجيين – مع مخاطر الوصول المتميزة المرتبطة بها – توفير جلسات Kasm على Kubernetes التي يتم توسيع نطاقها خلال فترات المشاركة وتقليصها خلال فترات الطلب المنخفض. لا يوجد وصول مستمر. لا يوجد امتداد VPN لأطراف خارجية. عزل الحاويات عند حدود كل جلسة.

بيئات تطوير الذكاء الاصطناعي/تعلم الآلة. تحتاج الفرق التي تقوم ببناء نماذج الذكاء الاصطناعي وتشغيلها إلى بيئات تطوير ممكّنة لوحدة معالجة الرسومات مع عناصر تحكم أمنية نادرًا ما توفرها أجهزة سطح المكتب السحابية ذات الأغراض العامة. يتيح نشر Kasm على Kubernetes مع دعم NVIDIA MiG Multi-Instance GPU لفرق النظام الأساسي توفير موارد GPU الجزئية في جلسات مساحة عمل معزولة – مما يمنح علماء البيانات الحوسبة التي يحتاجون إليها دون التعرض لأمان البنية التحتية المشتركة.

التحول التشغيلي

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

يعمل هذا الدمج التشغيلي على تقليل النفقات العامة وتحسين الاتساق ويلغي تكلفة تبديل السياق التي جعلت البنية التحتية لسطح المكتب نقطة ضعف مستمرة للمؤسسات السحابية الأصلية.

بالنسبة للمؤسسات التي لا تزال تقوم بتشغيل VDI القديم إلى جانب البنية التحتية السحابية الحديثة، لم يعد السؤال هو ما إذا كان هناك بديل أصلي لـ Kubernetes. إنه كذلك. السؤال هو متى يتم الانتقال.

يمكن للمنظمات المهتمة بتقييم تسليم مساحة عمل Kubernetes الأصلية استكشاف النظام الأساسي على kasm.com وتجربة إصدار المجتمع بنفسك.

دانييل بن تشيتريت هو المدير التنفيذي للمنتجات في تقنيات قاسم.

المقالات الدعائية هي محتوى تنتجه شركة تدفع مقابل المنشور أو لديها علاقة عمل مع VentureBeat، ويتم تمييزها دائمًا بشكل واضح. لمزيد من المعلومات، اتصل sales@venturebeat.com.