لطالما كان من الصعب استضافة أعداد كبيرة من المستخدمين بأمان على مجموعة Kubernetes واحدة. السبب الرئيسي هو أن جميع المؤسسات تستخدم Kubernetes بشكل مختلف ، لذلك من غير المرجح أن يعمل نموذج واحد متعدد المستخدمين مع الجميع. بدلاً من ذلك ، تقدم Kubernetes مكونات لبناء الحل الخاص بك ، مثل التحكم في الوصول المستند إلى الدور (RBAC) و NetworkPolicies ؛ كلما كانت هذه المكونات أفضل ، كان من الأسهل بناء مجموعة آمنة متعددة المستخدمين.
مساحات الأسماء تندفع للإنقاذ
إلى حد بعيد ، فإن أهم هذه المكونات هي مساحات الأسماء . إنها تشكل أساس جميع سياسات مشاركة طائرة الأمن والتحكم تقريبًا في Kubernetes. على سبيل المثال ، تدعم RBAC و NetworkPolicies و ResourceQuotas مساحات الأسماء افتراضيًا ، في حين أن كائنات مثل Secret و ServiceAccount و Ingress متاحة مجانًا داخل مساحة واحدة ولكنها معزولة تمامًا عن الآخرين .
تحتوي مساحات الأسماء على ميزتين رئيسيتين تجعلها مثالية لتطبيق السياسة. أولاً ، يمكن استخدامها لتمثيل الممتلكات . يجب أن تكون معظم كائنات Kubernetesتكون في أي مساحة اسم. باستخدام مساحات الأسماء لتمثيل الملكية ، يمكنك دائمًا الاعتماد على هذه الكائنات للحصول على مالك.
ثانيًا ، يمكن فقط للمستخدمين الذين لديهم الحقوق المناسبة إنشاء مساحات الأسماء واستخدامها . أنت بحاجة إلى امتيازات مرتفعة لإنشاء مساحات الأسماء ، ويحتاج المستخدمون الآخرون إلى إذن صريح للعمل معهم - أي لإنشاء كائنات أو عرضها أو تعديلها في مساحات الأسماء هذه. وبالتالي ، يتم إنشاء مساحة اسم أولاً بمجموعة معقدة من السياسات ، وبعد ذلك فقط يمكن للمستخدمين غير المتميزين إنشاء كائنات "عادية" مثل الكبسولات والخدمات.
قيود مساحة الاسم
لسوء الحظ ، من الناحية العملية ، فإن مساحات الأسماء ليست مرنة بدرجة كافية ولا تتناسب بشكل جيد مع بعض حالات الاستخدام الشائعة. على سبيل المثال ، يمتلك فريق معين عدة خدمات مصغرة بأسرار وحصص مختلفة. من الناحية المثالية ، ينبغي عليهم تقسيم هذه الخدمات إلى مساحات أسماء منفصلة لعزلها عن بعضها البعض ، ولكن هذا يمثل مشكلتين.
أولاً ، تفتقر مساحات الأسماء هذه إلى مفهوم واحد للملكية ، على الرغم من أن كلاهما مملوك من قبل نفس الفريق. هذا يعني أن Kubernetes ليس فقط لا يعرف شيئًا عن حقيقة أن مساحات الأسماء هذه لها مالك واحد ، ولكنها تفتقر أيضًا إلى القدرة على تطبيق السياسات العالمية على جميع مساحات الأسماء الخاضعة للرقابة مرة واحدة.
ثانيًا ، كما تعلم ، الاستقلالية هي مفتاح العمل الجماعي الفعال. نظرًا لأن إنشاء مساحات الأسماء يتطلب امتيازات عالية ، فمن غير المرجح أن يتمتع أي شخص في فريق التطوير بهذه الامتيازات. بعبارة أخرى ، عندما يقرر الفريق إنشاء مساحة اسم جديدة ، يجب عليهم الاتصال بمسؤول المجموعة. قد يكون هذا مقبولًا تمامًا لشركة صغيرة ، ولكن مع نموها ، تصبح الآثار السلبية لمثل هذه المنظمة أكثر وضوحًا.
إدخال مساحات الأسماء الهرمية
تعد مساحات الأسماء الهرمية مفهومًا جديدًا تم تطويره بواسطة مجموعة عمل Kubernetes متعددة المستأجرين ( wg-multitenancy ) لمعالجة هذه المشكلات. في شكل مبسط ، فإن مساحة الاسم الهرمية هي مساحة اسم Kubernetes عادية مع مورد مخصص صغير مضمن يشير إلى مساحة اسم رئيسية واحدة (اختيارية). هذا يمتد مفهوم الملكية إلى مساحات الأسماء نفسها ، وليس فقط الكائنات الموجودة داخلها.
ينفذ مفهوم الملكية أيضًا نوعين إضافيين من العلاقات:
- : namespace' . : subnamespaces, .
هذا يحل كلا من مشاكل فريق التطوير النموذجي. يمكن لمسؤول المجموعة إنشاء مساحة "جذر" واحدة لها جنبًا إلى جنب مع السياسات الضرورية وتفويض السلطة لإنشاء مساحات فرعية لأعضاء الفريق. بهذه الطريقة ، يمكن للمطورين إنشاء مساحات أسماء فرعية لاستخدامهم الخاص دون انتهاك السياسات التي وضعها مسؤولو المجموعة.
القليل من الممارسة
يتم تنفيذ مساحات الأسماء الهرمية باستخدام امتداد Kubernetes يسمى Hierarchical Namespace Controller أو HNC . تتكون HNC من مكونين:
- يعمل المدير في مجموعة ، ويدير مساحات الأسماء الفرعية ، ويوزع كائنات السياسة ، ويضمن أن التسلسلات الهرمية صالحة ، ويدير نقاط الامتداد.
- يسمح البرنامج المساعد kubectl المسمى
kubectl-hnsأنه يسمح للمستخدمين بالتفاعل مع المدير.
يمكن العثور على دليل تثبيت المكون في صفحة الإصدارات في مستودع المشروع.
دعونا نلقي نظرة على كيفية عمل HNC. لنفترض أنه ليس لدي امتيازات لإنشاء مساحات أسماء ، لكن يمكنني تصفح مساحة الاسم
team-aوإنشاء مساحات أسماء فرعية فيها *. يسمح لي المكون الإضافي بإدخال الأمر التالي:
$ kubectl hns create svc1-team-a -n team-a
* من الناحية الفنية ، تقوم بإنشاء كائن صغير يسمى "subnamespace anchor" في المساحة الأصلية ثم تقوم HNC بإنشاء مساحة اسم فرعية.
سيؤدي هذا إلى إنشاء مساحة اسم
svc1-team-a. يرجى ملاحظة أن مساحات الأسماء الفرعية لا تختلف عن مساحات أسماء Kubernetes العادية ، لذلك يجب أن تكون أسمائها فريدة.
يمكنك عرض الهيكل الناتج باستخدام الأمر
tree:
$ kubectl hns tree team-a
# Output:
team-a
└── svc1-team-a
إذا كانت هناك أي سياسات في المساحة الأصلية ، فسيتم نسخها إلى الطفل *. على سبيل المثال ، افترض أن
team-aلديك رابط دور RBAC يسمى sres. سيظهر رابط الدور هذا أيضًا في مساحة الاسم المقابلة:
$ kubectl describe rolebinding sres -n svc1-team-a
# Output:
Name: sres
Labels: hnc.x-k8s.io/inheritedFrom=team-a # inserted by HNC
Annotations: <none>
Role:
Kind: ClusterRole
Name: admin
Subjects: …
* بشكل افتراضي ، يتم إعادة توزيع الأدوار و RoleBindings في RBAC فقط ، ولكن يمكنك تكوين HNC لنشر أي كائن Kubernetes.
أخيرًا ، يضيف HNC تسميات إلى مساحات الأسماء هذه بمعلومات مفيدة حول التسلسل الهرمي. يمكن استخدامها لفرض سياسات أخرى. على سبيل المثال ، يمكنك إنشاء NetworkPolicy التالية:
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
name: allow-team-a
namespace: team-a
spec:
ingress:
- from:
- namespaceSelector:
matchExpressions:
- key: 'team-a.tree.hnc.x-k8s.io/depth' # Label created by HNC
operator: Exists
سيتم نشر هذه السياسة إلى أحفاد
team-aوسوف أيضا تسمح حركة دخول بين كل هذه النطاقات. يمكن فقط HNC تعيين التسمية "شجرة". إنه مضمون لعكس التسلسل الهرمي الحالي.
يمكن العثور على تفاصيل حول وظيفة HNC في دليل المستخدم .
الخطوات التالية والمشاركة في العملية
إذا كنت تعتقد أن مساحة الاسم الهرمية مفيدة في مؤسستك ، فإن الإصدار HNC v0.5.1 متاح على GitHub (متاح من 28 أغسطس لإصدار v0.5.2 - ca. Perevi ..) . نود أن نعرف رأيك في ذلك ، وما هي المشاكل التي تحلها بها وما هي الميزات التي ترغب في إضافتها إليها. كما هو الحال مع أي برنامج في المراحل الأولى من التطوير ، يجب توخي الحذر عند استخدام HNC في الإنتاج. وكلما حصلنا على المزيد من التعليقات ، زادت سرعة وصولنا إلى HNC 1.0.
نرحب أيضًا بمساهمات المساهمين الخارجيين ، سواء كانت إصلاحات أخطاء / معلومات عنها أو تساعد في وضع نماذج أولية لميزات جديدة مثل الاستثناءات أو المراقبة المحسّنة أو اقتباس الموارد الهرمية أو تحسين التكوين.
يمكنك الاتصال بنا في المستودع أو النشرة الإخبارية أو Slack . ونحن نتطلع إلى التعليقات الخاصة بك!
تم الإعلان عن الإعلان الأصلي بواسطة Adrian Ludwin ، مهندس البرمجيات والقائد الفني لوحدة التحكم الهرمية Namespace.
علاوة! خارطة الطريق والقضايا
يرجى نشر المشكلات - كلما زادت المتعة! سيتم تحليل الأخطاء أولاً ، وسيتم تحديد أولويات طلبات الميزات ، وبعد ذلك سيتم تضمينها في خطة العمل أو تراكم.
لم تصل HNC بعد إلى حالة GA ، لذا كن حذرًا عند استخدامها على مجموعات بها كائنات تكوين لا يمكنك تحمل خسارتها (على سبيل المثال ، تلك التي لم يتم تخزينها في مستودع Git).
يتم تضمين جميع قضايا HNC في خطة العمل المقابلة. في الوقت الحالي ، تم تنفيذ أو التخطيط للمراحل الرئيسية التالية من هذه الخطة:
- الإصدار 1.0: نهاية الأول - بداية الربع الثاني من عام 2021 ؛ يوصى باستخدام HNC للإنتاج.
- الإصدار 0.8: أوائل عام 2021 ؛ قد تظهر وظائف حرجة جديدة.
- الإصدار 0.7: نهاية عام 2020 ؛ على الأرجح ستظهر v1beta1 API.
- v0.6: 2020-; v1alpha2 API .
- v0.5: 2020-; , .
- v0.4: 2020-; API production-.
- v0.3: 2020-; UX subnamespace'.
- v0.2: 2019-; non-production.
- v0.1: 2019-; . , - .
- : .
PS من المترجم
اقرأ أيضًا على مدونتنا: