نظرة أولى على Kubernetes Service APIs

مقدمة

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

من أجل توحيد تطبيقات Ingress المختلفة وتسهيل الإدارة الموحدة على Kubernetes، أطلقت مجتمع SIG-NETWORK Kubernetes Service APIs، وهي مجموعة من التطبيقات القياسية تُعرف باسم الجيل الثاني من Ingress.

وصف الموضوع

تقدم هذه المقالة مقدمة عن المفاهيم الأساسية لـ Kubernetes Service APIs، بدءًا من بعض الأسئلة.

مقدمة

تُعرف Kubernetes Service APIs بأنها الجيل الثاني من تقنية Ingress، ولكن بأي طرق تكون أفضل من الجيل الأول

لم يتم تصميم Kubernetes Service APIs لتقتصر على Ingress، بل لتعزيز شبكة الخدمات مع التركيز على التعبيرية، القابلية للتوسع، وRBAC.

1. المزيد من الميزات، مثل إدارة حركة المرور بناءً على الرأس، الوزن.

kind: HTTPRoute
apiVersion: networking.x-k8s.io/v1alpha1
---
matches:
  - path:
      value: "/foo"
    headers:
      values:
        version: "2"
  - path:
      value: "/v2/foo"

2. تعزيز القابلية للتوسع، تقدم Service APIs مفهوم API متعدد الطبقات، حيث تعرض كل طبقة واجهتها الخاصة، مما يسمح للموارد المخصصة الأخرى بالتفاعل مع API للتحكم الأكثر دقة (API-grained).

3. RBAC الموجه نحو الأدوار: تحقيق API متعدد الطبقات، إحدى الأفكار هي تصميم كائنات الموارد من منظور المستخدمين. ستتم تعيين هذه الموارد في النهاية مع الأدوار الشائعة لتشغيل التطبيقات على Kubernetes.

ما هي كائنات الموارد التي تم تجريدها بواسطة Kubernetes Service APIs

بناءً على أدوار المستخدمين، ستحدد Kubernetes Service APIs الموارد التالية:

GatewayClass, Gateway, Route

1. GatewayClass يحدد مجموعة من أنواع البوابات ذات التكوين والسلوك المشترك:

• العلاقة مع Gateway، مشابهة لـ ingess.class annotation في ingress؛
• يحدد GatewayClass مجموعة من البوابات التي تشترك في نفس التكوين والسلوك. سيتم التعامل مع كل GatewayClass بواسطة وحدة تحكم واحدة، مع وجود علاقة واحد إلى كثير بين وحدة التحكم وGatewayClass؛
• GatewayClass هو مورد عنقودي. يجب تعريف GatewayClass واحد على الأقل من أجل وجود بوابة وظيفية.

2. Gateway يطلب نقطة يمكن عندها تحويل حركة المرور إلى خدمات داخل الكتلة:

• ما يفعله: يجلب حركة المرور من خارج الكتلة إلى داخلها. هذا هو كيان ingress الحقيقي؛
• يحدد طلبًا لتكوين LB محدد وهو أيضًا تنفيذ لتكوين وسلوك GatewayClass؛
• يمكن إنشاء موارد Gateway مباشرة من قبل المشغل أو بواسطة وحدة التحكم التي تتعامل مع GatewayClass؛
• Gateway وRoute في علاقة كثير إلى كثير.

3. Route يصف كيف يتم تعيين حركة المرور التي تمر عبر بوابة إلى خدمة.

بالإضافة إلى ذلك، تحدد Kubernetes Service APIs كائن مورد BackendPolicy من أجل تمكين التكوين المرن لخدمات الخلفية.

يسمح كائن BackendPolicy بتكوين TLS، فحوصات الصحة وتحديد نوع خدمة الخلفية، مثل service أو pod.

ما هي التغييرات التي ستجلبها إدخال Kubernetes Service APIs

Kubernetes Service APIs، كمعيار تنفيذ، تجلب التغييرات التالية.

1. العمومية: يمكن أن يكون هناك تنفيذات متعددة، تمامًا كما يوجد تنفيذات متعددة لـ ingress. يمكن تخصيص وحدات تحكم ingress وفقًا لخصائص البوابة، ولكن جميعها لديها بنية تكوين متسقة. يمكن استخدام بنية بيانات واحدة لتكوين وحدات تحكم ingress متعددة.
2. مفهوم الفئات: تسمح GatewayClasses بتكوين أنواع مختلفة من تنفيذات موازنة الحمل. تسمح هذه الفئات للمستخدم بفهم بسهولة ووضوح الوظائف التي يمكن استخدامها كنماذج موارد نفسها.
3. البوابات المشتركة: من خلال السماح لموارد التوجيه المستقلة HTTPRoute بالارتباط بنفس GatewayClass، يمكنها مشاركة موازنات الحمل وVIPs. يتم تقسيمها حسب المستخدم، مما يسمح للفرق بمشاركة البنية التحتية بأمان دون الحاجة إلى الاهتمام بالتنفيذ المحدد للبوابة الأقل مستوى.
4. مراجع الخلفية مع الأنواع: مع مراجع الخلفية مع الأنواع، يمكن أن تشير المسارات إلى خدمات Kubernetes، أو أي نوع من موارد Kubernetes المصممة كخلفية للبوابة، مثل pod، أو statefulset مثل DB، أو حتى مورد خارجي يمكن الوصول إليه من الكتلة.
5. المراجع عبر الأسماء: يمكن ربط المسارات عبر أسماء مختلفة ببوابة، مما يسمح بالوصول إلى بعضها البعض عبر الأسماء. يمكن أيضًا تقييد نطاق الأسماء التي يمكن لمسار تحت بوابة الوصول إليها.

ما هي تنفيذات ingress لـ Kubernetes Service APIs المتاحة حاليًا

الـ Ingress المعروفة التي تدعم كائنات موارد Kubernetes Service APIs على مستوى الكود هي Contour, ingress-gce.

كيف تدير Kubernetes Service APIs أذونات قراءة وكتابة الموارد

تنقسم Kubernetes Service APIs إلى 3 أدوار بناءً على بُعد المستخدم:

1. موفر البنية التحتية GatewayClass؛
2. مشغل الكتلة Gateway؛
3. مطور التطبيقات Route.

RBAC (التحكم في الوصول القائم على الأدوار) هو المعيار المستخدم للتفويض في Kubernetes. يسمح للمستخدمين بتكوين من يمكنه تنفيذ العمليات على نطاق محدد من الموارد. يمكن استخدام RBAC لتمكين كل من الأدوار المحددة أعلاه.

في معظم الحالات، من المتوقع أن يتمكن جميع الأدوار من قراءة جميع الموارد.

نموذج الطبقات الثلاث لديه أذونات الكتابة التالية.

ما هي نقاط التوسع لـ Kubernetes Service APIs

متطلبات البوابات غنية جدًا، وهناك العديد من الطرق لتنفيذ نفس السيناريو، لكل منها مزاياها وعيوبها. قامت Kubernetes Service APIs باستخراج كائنات موارد متعددة الطبقات، كما حجزت بعض نقاط التوسع.

تركز Kubernetes Service APIs حاليًا على Route:

• RouteMatch يوسع قواعد مطابقة Route.
• تحديد Backend يوسع أنواع محددة من خدمات الخلفية، مثل أنظمة الملفات، تعبيرات الوظائف، إلخ، بالإضافة إلى موارد Kubernetes المذكورة أعلاه.
• مرشح Route يضيف توسعات لدورة حياة Route لمعالجة الطلبات/الاستجابات.
• إذا لم يتم تلبية أي من التوسعات المذكورة أعلاه بواسطة Route مخصص، يمكن تخصيص Route بالكامل.

الخلاصة

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