Lasso هو إطار تحكم.
تتمتع اللاسو ببعض التكافؤ الوظيفي مع مشروع وقت تشغيل وحدة التحكم ويمكن استخدامها بدلاً من وقت تشغيل وحدة التحكم.
لاسو مستوى منخفض. إذا كنت تريد إدارة وحدات التحكم الخاصة بك، فيمكنك استخدامها. إذا كنت تبحث عن مزيد من الراحة والوظائف لإنشاء أنواع الموارد الخاصة بك، فنوصيك بمراجعة Wrangler.
إطار التحكم الأساسي الذي يستخدمه رانجلر ونورمان.
تمت كتابة هذه الوثيقة مع وضع جمهورين في الاعتبار: شخص جديد على وحدات تحكم Kubernetes وشخص ليس جديدًا على وحدات تحكم Kubernetes ولكنه جديد على اللاسو.
إذا كنت تندرج ضمن فئة "شخص ليس جديدًا على وحدات التحكم في Kubernetes"، فيمكنك التخطي إلى عرض قيمة Lasso.
إذا كنت مستخدمًا جديدًا لوحدات تحكم Kubernetes، فمن المستحسن عدم تخطي أي أقسام.
إذا كنت تفتقر إلى المعرفة الأساسية بـ Kubernetes، فمن المستحسن الرجوع إلى وثائق أخرى حول الأساسيات أولاً، مثل نظرة عامة على Kubernetes.
ملاحظة: ستكون هذه دورة تدريبية قصيرة جدًا. نحن نشجعك على البحث عن مصادر أخرى تتعلق بالموضوع، فهي كثيرة! هناك مصدران موصى بهما هما مشروع وحدة التحكم النموذجية ومقدمة لأطر عمل وحدة التحكم Kubernetes.
من وثائق Kubernetes
في Kubernetes، وحدة التحكم عبارة عن حلقة تحكم تراقب الحالة المشتركة للمجموعة من خلال خادم apiserver وتقوم بإجراء تغييرات في محاولة لتحريك الحالة الحالية نحو الحالة المطلوبة.
يتم استخدام كلمة "وحدة التحكم" بشكل فضفاض أكثر مما قد يجعلك تصدقه التعريف أعلاه. بكلماتنا الخاصة: وحدات التحكم هي معالجات حلقة تعمل استجابةً لأحداث موارد Kubernetes. في Lasso، نستخدم أيضًا كلمة "وحدة التحكم" للإشارة إلى البنية الكاملة المسؤولة عن تسجيل معالج الحلقة هذا وتزويده بالموارد التي يحتاجها. باختصار، وحدات التحكم هي هياكل تجمع كل ما هو ضروري للتفاعل مع أنواع Kubernetes والعمل عليها.
ولتحقيق الهدف المذكور أعلاه، لا بد من تحقيق بعض الأهداف الفرعية:
هناك العديد من الأطر للمساعدة في تحقيق الأهداف المذكورة أعلاه. لاسو هو واحد منهم. ما تشترك فيه معظم هذه الأطر، بما في ذلك اللاسو، هو أنها تستخدم وظائف العميل لتحقيق هذه الأهداف. يمكنك تحقيق هذه الأهداف باستخدام خدمة العميل فقط. بالنسبة لبقية هذا القسم، سنتناول كيفية تجميع وحدة التحكم باستخدام مفاهيم العميل.
يتم استخدام المخبر لتحقيق الأهداف المذكورة أعلاه اللازمة لوحدة تحكم Kubernetes. يمتلك المخبر معالج الأحداث والمفهرس. يمتلك المفهرس وظائف مخزن وخريطة لفهرسة الكائنات داخل المتجر تسمى المفهرسات. تختلف البنيات الأساسية، ولكن يتم عرض بنية زائفة أدناه لتوضيح ذلك:
Informer
EventHandler
Indexer
Store
Indexers
يمكن أن يكون لدى EventHandler منطق مختلف لإنشاء الأحداث وتحديثها وحذفها. معالج الأحداث هو المكان الذي تأتي فيه وحدة التحكم. يمكنك استخدامه لتكوين معالجات الأحداث الإنشاء والتحديث والحذف.
يتم استخدام المفهرس كذاكرة تخزين مؤقت.
المتجر هو المكان الذي يحتفظ فيه المفهرس بالكائنات.
المفهرسات هي وظائف يمكن للمفهرس استخدامها لفهرسة الكائنات الدائمة. بمجرد فهرستها باستخدام مفهرس، يمكن استرجاع الكائنات باستخدام سلاسل تصف خاصية يهتم بها المفهرس.
غالبًا ما يتم استخدام المفهرس لاسترداد كائن من خلال بيانات تعريف بسيطة مثل مساحة الاسم والاسم.
يقوم المخبر أولاً بملء المفهرس عن طريق سرد جميع الموارد التي تم إرجاعها من العميل. ثم يراقب المخبر مورد Kubernetes المخصص له. عندما يأتي حدث ما، فإنه يستخدم هذا الحدث لتحديث مفهرسه وتنفيذ معالجات الأحداث الخاصة به.
عادةً ما يحتاج التطبيق إلى وحدات تحكم متعددة. ومع ذلك، قد لا يكون من المفيد أن يكون لكل وحدة تحكم مخبرها الخاص وبالتالي مفهرسها الخاص. يمكن استخدام SharedIndexerInformer من Client-go لإضافة وحدات تحكم متعددة تستخدم جميعها نفس المفهرسات.
هناك صورة رائعة لكيفية عمل وحدة تحكم Kubernetes الموجودة في مستودع kubernetes/sample-controller.
ملاحظة: تم تبسيط المخبرين من أجل الاختصار. إذا كنت مهتمًا بكيفية عملها بالضبط، فمن المستحسن أن تقرأ رمز Client-go.
تقوم Lasso بتوحيد ماهية وحدة التحكم من خلال حزمة وحدة التحكم الخاصة بها. تقدم Lasso مصانع لإدارة ذاكرات التخزين المؤقت ووحدات التحكم والعملاء داخل المشروع. يعد هذا أمرًا ضروريًا لمربي الماشية الذي يدير العديد من الحالات من العديد من الأنواع.
تستخدم وحدة التحكم اللاسو قائمة انتظار عمل العميل. يقوم Lasso بتسجيل معالج الأحداث الذي يعالج قائمة انتظار العمل. يجعل المعالج الموجه لقائمة انتظار العمل من الضروري إضافة معالج حدث واحد فقط لكل نوع من أنواع Kubernetes. الآن، يؤدي تسجيل المعالج إلى إضافته إلى قائمة معالجات وحدة التحكم الخاصة بالنوع. يؤدي وضع الكائنات في قائمة الانتظار إلى إضافتها إلى قائمة انتظار العمل. سيتم بعد ذلك معالجة كل كائن في قائمة انتظار العمل بواسطة العمال الذين يعملون في goroutines. سيقوم معالج الأحداث الخاص بوحدة التحكم بإعادة إدراج أي كائن يتسبب في قيام واحد أو أكثر من معالجات وحدة التحكم بإرجاع خطأ ليس من النوع ErrIgnore . يمكن أن تحتوي قائمة انتظار العمل هذه أيضًا على كائنات مدرجة في قائمة الانتظار من مصادر أخرى. يتم عرض هذه الوظيفة من خلال وظيفة Enqueue الخاصة بوحدة التحكم. يؤدي هذا إلى تحويل وحدات التحكم من كونها تتفاعل فقط مع موارد Kubernetes وعمليات إعادة مزامنة ذاكرة التخزين المؤقت، إلى كونها قابلة للاستدعاء أيضًا بواسطة التعليمات البرمجية.
يقوم نوع SharedController بتضمين واجهة وحدة التحكم لعرض وظائف وحدة التحكم الخاصة به. يعرض ShareController أيضًا وظيفة RegisterHandler مع وظيفة العميل. يضيف RegisterHandler المعالج الذي تم تمريره إلى قائمة معالجات وحدة التحكم ويقوم العميل بإرجاع عميل لنوع المورد المقابل لوحدة التحكم المشتركة؛ يحتوي ShareController على حقل GVK (نوع إصدار المجموعة) والذي يشير إلى النوع المخصص له.
يبدأ الجانب "المشترك" عند وحدة تحكم Lasso الأكثر بدائية. يسمح استخدام قائمة انتظار العمل بمشاركة مجموعة واحدة من معالجات الأحداث على سبيل المثال. ثم تضيف وحدة التحكم المشتركة Lasso إلى ذلك من خلال الاحتفاظ بعميل قابل لإعادة الاستخدام لـ GVK وإضافة طريقة لتسجيل المعالجات بسهولة إلى وحدة التحكم الموجودة أسفلها باستخدام RegisterHandler.
يمكن لوحدة التحكم المشتركة إنشاء وحدة التحكم الأساسية الخاصة بها. لن يتم ذلك إلا بعد تسجيل المعالج في SharedController.
يلتف عميل Kubernetes. يحتوي على حقول GVK لإدارة العميل في البنية الرئيسية مثل SharedClientFactory. يعرض بعض الوظائف الإضافية مثل تكوين رأس وكيل المستخدم لعميل REST الأساسي.
إن lasso Cache عبارة عن غلاف خفيف حول SharedIndexInformer من عملية العميل.
الميزة الرئيسية لـ Lasso Cache هي أنه يمكن تعيين مصنع ذاكرة التخزين المؤقت، الذي يدير SharedIndexInformer في الذاكرة بواسطة GVK حتى يمكن إعادة استخدامها. عند استخدام وظائف Lasso Cache، فإنه سيدير نفسه داخل CacheFactory الذي تم تمريره لإنشائه.
يقوم مصنع ذاكرة التخزين المؤقت المشترك بتخزين ذاكرات التخزين المؤقت ويسمح بإدارتها عبر بنيات GVK. بمجرد إنشاء ذاكرة التخزين المؤقت، يمكن إعادة استخدامها مرة واحدة.
يوجد Shared Client Factory بحيث يمكن إعادة استخدام عميل GVK بعد إنشائه.
يربط SharedControllerFactory كل شيء أعلاه معًا. فهو يسمح بنقطة دخول واحدة للوصول إلى العملاء وذاكرة التخزين المؤقت والمعالجات - والتي يديرها جميعًا نيابةً عنك. من الممكن التفاعل بشكل أساسي مع مصنع وحدات التحكم المشتركة. سيقوم بإنشاء جميع وحدات التحكم والعملاء وذاكرة التخزين المؤقت الأساسية التي تحتاجها. سيضمن عدم وجود نسخ مكررة من هذه الكائنات. وسوف يمنع ظروف السباق.
بمجرد استخدام ForObject، أو ForKind، أو ForResource، أو ForResourceKind، سيقوم SharedControllerFactory بما يلي: 
إن deferredController هي دالة، بمجرد تنفيذها، ستقوم بإنشاء وحدة تحكم وإعادتها. سيتم إنشاء وحدة التحكم باستخدام ذاكرة التخزين المؤقت من SharedCacheFactory. الغرض من وظيفة deferredController هو تأجيل ملء ذاكرة التخزين المؤقت حتى الضرورة القصوى. يضمن هذا فقط تخزين موارد Kubernetes التي تحتوي على معالجات مسجلة، أو تم وضعها في قائمة الانتظار، أو تم طلب ذاكرة التخزين المؤقت لوحدة التحكم الخاصة بها، في الذاكرة.
عندما تحصل على وحدة تحكم مشتركة من SharedControllerFactory، فلن يتم إنشاء وحدة تحكم أساسية لها بعد. سيتم بدلاً من ذلك استدعاء أسلوب deferredController لإنشاء واحدة بمجرد تنفيذ إحدى العمليات المذكورة.
فيما يلي الخطوات للحصول على طريقة مباشرة لتسجيل المعالجات وتشغيلها في الحبل:
package main
import (
"context"
"github.com/rancher/lasso/pkg/controller"
appsv1 "k8s.io/api/apps/v1"
metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"
"k8s.io/apimachinery/pkg/runtime"
"k8s.io/client-go/rest"
)
func main () {
config , err := clientcmd . BuildConfigFromFlags ( "" , os . Getenv ( "KUBECONFIG" ))
if err != nil {
panic ( err )
}
// Setup types you want to work with
scheme := runtime . NewScheme ()
appsv1 . AddToScheme ( scheme )
controllerFactory , err := controller . NewSharedControllerFactoryFromConfig ( config , scheme )
if err != nil {
panic ( err )
}
// ForObject, ForKind, ForResource, and ForResourceKind can all be used to retrieve the controller.
// They all accept different parameters but the first three all eventually call ForResourceKind.
// Refer to [How to use Lasso](#how-to-use-lasso) for more information on how ForResourceKind works.
sharedController , err := controllerFactory . ForObject ( & appsv1. Deployment {})
if err != nil {
panic ( err )
}
// Register a handler on a shared controller. If you need a dedicated queue then use controller.New()
sharedController . RegisterHandler ( context . TODO (), "my-handler" , controller . SharedControllerHandlerFunc ( func ( key string , obj runtime. Object ) (runtime. Object , error ) {
// obj is the latest version of this obj in the cache and MAY BE NIL when an object is finally deleted
dep , ok := obj .( * appsv1. Deployment )
if ! ok {
return obj , nil
}
// Do some stuff ...
// Get stuff from the cache
sharedController . Informer (). GetStore (). Get ( key )
result := & appsv1. Deployment {}
err := sharedController . Client (). Update ( ctx , dep . Namespace , dep , result , metav1. UpdateOptions {})
// return the latest version of the object
return result , err
}))
// the second, int parameter is the number of workers to be used for EACH controller.
err = controllerFactory . Start ( context . TODO (), 5 )
if err != nil {
panic ( err )
}
}تستخدم بعض اختبارات اللاسو envtest للتشغيل. يسمح Envtest بإجراء الاختبارات على خادم kubernetes "المزيف" مع القليل/بدون حمل.
لتثبيت الملف الثنائي setup-envtest المطلوب، استخدم الأمر التالي:
go install sigs.k8s.io/controller-runtime/tools/setup-envtest@latestقبل إجراء الاختبارات، يجب عليك تشغيل الأمر التالي لإعداد الخادم المزيف:
# note that this will use a new/latest version of k8s. Our CI will run against the version of k8s that corresponds to lasso's
# current client-go version, as seen in scripts/test.sh
export KUBEBUILDER_ASSETS= $( setup-envtest use -p path )كانت الموارد التالية مفيدة في كتابة هذه المستندات. يوصى بها بشدة لتعلم أكثر مما هو معروض هنا:
