فرص وتحديات التطور التكنولوجي في Cloud Native

في الوقت الحاضر، أصبحت الحوسبة السحابية الأصلية (Cloud Native) تحظى بشعبية متزايدة، وتعرفها CNCF على النحو التالي:

• تعتمد على بيئة حديثة وديناميكية، أي البيئة السحابية.
• تستخدم تقنية الحاويات كتقنية أساسية، بما في ذلك Service Mesh، البنية التحتية الثابتة، واجهات برمجة التطبيقات التصريحية، وغيرها.
• تشمل الميزات الرئيسية التوسع التلقائي، القابلية للإدارة، القابلية للمراقبة، الأتمتة، التغييرات المتكررة، وغيرها.

وفقًا لاستطلاع CNCF لعام 2021، هناك عدد كبير جدًا (أكثر من 62,000) من المساهمين في مجتمع Kubernetes. مع الاتجاه الحالي للتكنولوجيا، تستثمر المزيد من الشركات المزيد من التكاليف في الحوسبة السحابية الأصلية وتنضم إلى المسار مبكرًا للنشر السحابي النشط. لماذا تتبنى الشركات الحوسبة السحابية الأصلية أثناء التطوير، وماذا تعني الحوسبة السحابية الأصلية بالنسبة لها؟

المزايا التقنية للحوسبة السحابية الأصلية

تأتي شعبية الحوسبة السحابية الأصلية من مزاياها على المستوى التقني. هناك جانبين رئيسيين لتكنولوجيا الحوسبة السحابية الأصلية، بما في ذلك تقنية الحاويات التي تقودها Docker، وتنسيق الحاويات التي تقودها Kubernetes.

أدخل Docker صور الحاويات إلى عالم التكنولوجيا، مما جعل صور الحاويات وحدة تسليم موحدة. في الواقع، قبل Docker، كانت تقنية الحاويات موجودة بالفعل. دعونا نتحدث عن تقنية أكثر حداثة، LXC (Linux Containers) في عام 2008. مقارنةً بـ Docker، فإن LXC أقل شعبية حيث أن Docker توفر صور الحاويات، والتي يمكن أن تكون أكثر توحيدًا وأكثر ملاءمة للهجرة. أيضًا، أنشأت Docker خدمة DockerHub العامة، والتي أصبحت أكبر مستودع لصور الحاويات في العالم. بالإضافة إلى ذلك، يمكن أن تحقق تقنية الحاويات أيضًا درجة معينة من عزل الموارد، بما في ذلك ليس فقط عزل وحدة المعالجة المركزية والذاكرة، ولكن أيضًا عزل مكدس الشبكة، مما يجعل من السهل نشر نسخ متعددة من التطبيقات على نفس الجهاز.

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

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

مزايا تقنية الحاويات

1. التسليم الموحد

أصبحت صور الحاويات الآن وحدة تسليم موحدة. من خلال تقنية الحاويات، يمكن للمستخدمين إكمال التسليم مباشرة من خلال صورة حاوية بدلاً من الثنائيات أو الكود المصدري. بالاعتماد على آلية التغليف لصورة الحاوية، يمكنك استخدام نفس الصورة لبدء خدمة وإنتاج نفس السلوك في أي وقت تشغيل حاوية.

2. قابلية النقل والخفة، توفير التكاليف

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

يمكن لجميع التطبيقات مشاركة النواة، مما يوفر التكاليف. وكلما كان التطبيق أكبر، كانت وفورات التكلفة أكبر.

3. سهولة إدارة الموارد

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

مزايا تنسيق الحاويات

1. تبسيط سير العمل

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

2. تحسين الكفاءة وتوفير التكاليف

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

مع صعود Docker وKubernetes، ستلاحظ أن ظهورهما قد أتى بابتكارات وفرص كبيرة لتسليم التطبيقات. صور الحاويات، كوحدات تسليم قياسية، تقصر عملية التسليم وتجعلها أسهل للدمج مع أنظمة CI/CD.

بالنظر إلى أن تسليم التطبيقات أصبح أسرع، كيف يتبع ذلك تطور بنية التطبيقات لمواكبة اتجاه الحوسبة السحابية الأصلية؟

تطور بنية التطبيقات: من البنية الأحادية، إلى الخدمات الصغيرة، إلى Service Mesh

نقطة البداية لتطور بنية التطبيقات لا تزال من البنية الأحادية. مع زيادة حجم ومتطلبات التطبيقات، لم تعد البنية الأحادية تلبي احتياجات تطوير الفريق التعاوني، وبالتالي تم إدخال البنى الموزعة تدريجيًا.

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

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

نمط آخر هو بوابة API، والذي يستقبل حركة المرور الواردة للعنقود أو بنية الخدمات الصغيرة بأكملها من خلال بوابة ويتم توزيع حركة المرور عبر واجهات برمجة التطبيقات. هذا واحد من أكثر الأنماط استخدامًا، ويمكن تطبيق منتجات البوابة مثل Spring Cloud Gateway أو Apache APISIX.

البنى الشائعة تتوسع تدريجيًا إلى بنى الحوسبة السحابية الأصلية. هل يمكن لبنية الخدمات الصغيرة تحت الحوسبة السحابية الأصلية ببساطة بناء الخدمة الصغيرة الأصلية كصورة حاوية وتهجيرها مباشرة إلى Kubernetes؟

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

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

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

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

لتجنب المشاهد المعقدة للتكوين المنفصل وإعادة بناء العجلة عند إدخال Sidecar لكل خدمة صغيرة، يمكن تنفيذ العملية عن طريق إدخال مستوى تحكم أو عن طريق حقن مستوى التحكم، مما يشكل تدريجيًا Service Mesh الحالي.

عادةً ما يتطلب Service Mesh مكونين، أي مستوى التحكم + مستوى البيانات. يكمل مستوى التحكم توزيع التكوين وتنفيذ المنطق المرتبط، مثل Istio، وهو الأكثر شعبية حاليًا. على مستوى البيانات، يمكنك اختيار بوابة API مثل Apache APISIX لتوجيه حركة المرور واتصال الخدمات. بفضل الأداء العالي وقابلية التوسع لـ APISIX، يمكن أيضًا تنفيذ بعض المتطلبات المخصصة والمنطق المخصص. يوضح ما يلي بنية حل Service Mesh مع Istio+APISIX.

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

التحديات التقنية للحوسبة السحابية الأصلية

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

المشاكل الناجمة عن تقنية الحاويات وK8s

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

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

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

أيضًا، في بنية Kubernetes، يعتبر apiserver المكون الأساسي للعنقود ويحتاج إلى التعامل مع كل حركة المرور الداخلية والخارجية. لذلك، لتجنب مشاكل أمان الحدود، كيف يتم حماية apiserver يصبح سؤالًا رئيسيًا. على سبيل المثال، يمكننا استخدام Apache APISIX لحمايته.

الأمان

يتطلب استخدام التقنيات الجديدة اهتمامًا إضافيًا على مستوى الأمان:

• على مستوى أمان الشبكة، يمكن تنفيذ التحكم الدقيق في حركة المرور من خلال Network Policy، أو طرق تشفير الاتصال الأخرى مثل mTLS لتشكيل شبكة عدم الثقة.

• على مستوى أمان البيانات، يوفر K8s مورد secret لمعالجة البيانات السرية، ولكن في الواقع، ليس آمنًا. يتم ترميز محتويات مورد secret في Base64، مما يعني أنه يمكنك الوصول إلى المحتويات من خلال فك ترميز Base64، خاصة إذا تم وضعها في etcd، والتي يمكن قراءتها مباشرة إذا كان لديك وصول إلى etcd.

• على مستوى أمان الصلاحيات، هناك أيضًا حالة حيث تكون إعدادات RBAC غير معقولة، مما يؤدي إلى استخدام المهاجم للـ Token ذي الصلة للتواصل مع apiserver لتحقيق هدف الهجوم. هذا النوع من إعداد الصلاحيات يُرى غالبًا في سيناريوهات المتحكم والمشغل.

القابلية للمراقبة

معظم سيناريوهات الحوسبة السحابية الأصلية تتضمن بعض العمليات المتعلقة بالمراقبة مثل التسجيل، المراقبة، إلخ.

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

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

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

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

بالإضافة إلى ذلك، هناك حالة أخرى في عنقود K8s حيث يتم استنفاد الموارد بالكامل للعنقود أو العقدة، مما يؤدي إلى طرد الموارد، مما يعني أن الموارد التي تعمل بالفعل على عقدة يتم طردها إلى عقد أخرى. إذا كانت موارد العنقود ضيقة، يمكن أن تسبب عاصفة العقد انهيار العنقود بأكمله.

تطور التطبيقات ونمط العناقيد المتعددة

على مستوى تطور بنية التطبيقات، فإن القضية الأساسية هي اكتشاف الخدمات.

يوفر K8s آلية اكتشاف الخدمات المبنية على DNS بشكل افتراضي، ولكن إذا كانت الأعمال تتضمن التعايش بين الأعمال السحابية والأعمال المخزنة، فسيكون استخدام آلية اكتشاف الخدمات المبنية على DNS أكثر تعقيدًا للتعامل مع الوضع.

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

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

كيف تمكّن APISIX التحول الرقمي

Apache APISIX هي بوابة API للحوسبة السحابية الأصلية تحت مؤسسة Apache Software Foundation، وهي ديناميكية، في الوقت الفعلي، وعالية الأداء، توفر ميزات إدارة حركة المرور الغنية مثل موازنة الحمل، المنبع الديناميكي، الإصدار التدريجي، كسر الدائرة، المصادقة، المراقبة، إلخ. يمكنك استخدام Apache APISIX للتعامل مع حركة المرور الشمالية الجنوبية التقليدية، وكذلك حركة المرور الشرقية الغربية بين الخدمات.

حاليًا، بناءً على تطور البنية والتغييرات التطبيقية الموصوفة أعلاه، تم اشتقاق حلول Ingress controller وService Mesh القائمة على APISIX في Apache APISIX لمساعدة الشركات على تنفيذ التحول الرقمي بشكل أفضل.

حل APISIX Ingress

Apache APISIX Ingress Controller هو تنفيذ لـ Kubernetes Ingress Controller يعمل بشكل أساسي كبوابة حركة مرور للتعامل مع حركة المرور الشمالية الجنوبية لـ Kubernetes.

تشبه بنية APISIX Ingress Controller بنية APISIX في أنها بنية منفصلة لمستوى التحكم ومستوى البيانات. في هذه الحالة، يتم استخدام APISIX كمستوى البيانات لمعالجة حركة المرور الفعلية.

حاليًا، يدعم APISIX Ingress Controller الطرق الثلاث التالية للتكوين وهو متوافق مع جميع إضافات APISIX بشكل افتراضي:

• دعم موارد Ingress الأصلية لـ K8s. تسمح هذه الطريقة لـ APISIX Ingress Controller بأن يكون لديه مستوى أعلى من التكيف. حتى الآن، APISIX Ingress Controller هو الإصدار الأكثر دعمًا لأي منتج Ingress controller مفتوح المصدر وذي تأثير.

• دعم استخدام الموارد المخصصة. الموارد المخصصة الحالية لـ APISIX Ingress Controller هي مجموعة من مواصفات CRD المصممة وفقًا لمعاني APISIX. استخدام الموارد المخصصة يجعل التكامل مع APISIX أسهل وأكثر أصالة.

• دعم Gateway API. كجيل التالي من معيار Ingress، بدأ APISIX Ingress Controller في دعم Gateway API (مرحلة Beta). مع تطور Gateway API، من المحتمل أن تصبح موردًا مدمجًا لـ K8s مباشرة.

يتمتع APISIX Ingress Controller بالمزايا التالية مقارنةً بـ Ingress NGINX:

• فصل البنية. في APISIX Ingress، يتم فصل بنية مستوى البيانات ومستوى التحكم. عندما يكون ضغط معالجة حركة المرور مرتفعًا وتريد توسيع السعة، يمكنك ببساطة توسيع مستوى البيانات، مما يسمح بتقديم المزيد من مستويات البيانات للخارج دون الحاجة إلى إجراء أي تعديلات على مستوى التحكم.

• قابلية التوسع العالية ودعم الإضافات المخصصة.

• كاختيار لمستوى البيانات، مع أداء عالي وميزات ديناميكية كاملة. بفضل الميزة الديناميكية الكاملة لـ APISIX، يمكن حماية حركة مرور الأعمال قدر الإمكان باستخدام APISIX Ingress.

حاليًا، يستخدم APISIX Ingress Controller العديد من الشركات حول العالم، مثل China Mobile Cloud Open Platform (منتج API مفتوح وIDE سحابي)، Upyun، وCopernicus (جزء من Europe's Eyes on Earth).

APISIX Ingress Controller لا يزال في تطور مستمر، ونخطط لتحسين المزيد من الوظائف بالطرق التالية:

1. إكمال دعم Gateway API لتمكين تكوينات المزيد من السيناريوهات.
2. دعم وكيل الخدمات الخارجية.
3. دعم متعدد للسجلات لجعل APISIX Ingress Controller أكثر تنوعًا.
4. تحديثات البنية لإنشاء نموذج بنية جديد؛
5. التكامل مع أدوات GitOps مثل Argo CD/Flux لإنشاء نظام بيئي غني.

إذا كنت مهتمًا بحل APISIX Ingress، يرجى متابعة تحديثات المجتمع لتطور المنتج واتجاهات المجتمع.

حل APISIX Service Mesh

حاليًا، بالإضافة إلى بوابة API وحل Ingress، فإن حل Service Mesh القائم على APISIX أيضًا في تطور نشط.

يتكون حل Service Mesh القائم على APISIX من مكونين رئيسيين، وهما مستوى التحكم ومستوى البيانات. تم اختيار Istio لمستوى التحكم لأنه قائد الصناعة مع مجتمع نشط ومدعوم من قبل عدة بائعين. تم اختيار APISIX لتحل محل Envoy على جانب البيانات، مما يسمح لأداء APISIX العالي وقابلية التوسع بالظهور.

لا يزال APISIX's Service Mesh في طور التطوير النشط، مع خطط للتطورات اللاحقة في الاتجاهات التالية:

• تنفيذ تسريع eBPF لتحسين الفعالية العامة.

• تنفيذ تكامل قدرات الإضافات للسماح باستخدام أفضل لقدرات APISIX Ingress داخل بنية Service Mesh.

• إنشاء أداة هجرة سلسة لتوفير أدوات أسهل وتبسيط العملية للمستخدمين.

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