في الأيام التي كان فيها Kubernetes لا يزال v1.0.0 ، كانت الإضافات في الحجم موجودة. كانت هناك حاجة للاتصال بأنظمة Kubernetes لتخزين بيانات الحاوية الدائمة (الدائمة). كان عددهم ضئيلًا ، وكان من بين الأولين موفري التخزين مثل GCE PD و Ceph و AWS EBS وغيرها.
تم تسليم المكونات الإضافية مع Kubernetes ، والتي أطلقوا عليها اسمهم - داخل الشجرة. ومع ذلك ، لم يكن الكثير من مجموعة المكونات الإضافية الحالية كافية. أضاف الحرفيون ملحقات بسيطة إلى قلب Kubernetes باستخدام تصحيحات ، وبعد ذلك قاموا ببناء Kubernetes الخاصة بهم ووضعوها على خوادمهم. ولكن مع مرور الوقت ، أدرك مطورو Kubernetes أن
الأسماك لا يمكن حلها. الناس بحاجة إلى
قضيب الصيد . وفي إصدار Kubernetes v1.2.0 ، ظهر ...
Flexvolume المساعد: الحد الأدنى قصبة الصيد
قام مطورو Kubernetes بإنشاء المكون الإضافي FlexVolume ، والذي كان ربطًا منطقيًا للمتغيرات وطرق العمل مع برامج تشغيل Flexvolume الخارجية.
دعونا نتوقف ونلقي نظرة فاحصة على ما هو برنامج التشغيل FlexVolume. هذا
ملف قابل للتنفيذ معين (
ملف ثنائي ، برنامج نصي Python ، برنامج نصي Bash ، وما إلى ذلك) ، والذي عند تنفيذه ، يأخذ وسيطات سطر الأوامر ويعيد رسالة مع الحقول المعروفة سابقًا بتنسيق JSON. حسب الاصطلاح ، فإن وسيطة سطر الأوامر الأولى هي دائمًا الطريقة ، وبقية الوسائط هي معلماتها.
CIFS يشارك مخطط اتصال في OpenShift. برنامج Flexvolume Driver - مباشرة في المركزتبدو
مجموعة الحد الأدنى من الطرق كما يلي:
flexvolume_driver mount # pod' # : { "status": "Success"/"Failure"/"Not supported", "message": " ", } flexvolume_driver unmount # pod' # : { "status": "Success"/"Failure"/"Not supported", "message": " ", } flexvolume_driver init # # : { "status": "Success"/"Failure"/"Not supported", "message": " ", // , attach/deatach "capabilities":{"attach": True/False} }
سيحدد استخدام أساليب الإرفاق والفصل السيناريو الذي سيتم وفقًا لتصميم kubelet في المستقبل عند استدعاء برنامج التشغيل. هناك أيضًا
expandfs و
expandfs الخاصة المسؤولة عن تغيير حجم وحدة التخزين ديناميكيًا.
كمثال على التغييرات التي
expandvolume طريقة
expandvolume ، ومعها القدرة على القيام
expandvolume حجم الصوت في الوقت الفعلي ، يمكنك التحقق من
طلب السحب الخاص بنا في Rook Ceph Operator.
فيما يلي مثال لتطبيق برنامج التشغيل Flexvolume للعمل مع NFS:
usage() { err "Invalid usage. Usage: " err "\t$0 init" err "\t$0 mount <mount dir> <json params>" err "\t$0 unmount <mount dir>" exit 1 } err() { echo -ne $* 1>&2 } log() { echo -ne $* >&1 } ismounted() { MOUNT=`findmnt -n ${MNTPATH} 2>/dev/null | cut -d' ' -f1` if [ "${MOUNT}" == "${MNTPATH}" ]; then echo "1" else echo "0" fi } domount() { MNTPATH=$1 NFS_SERVER=$(echo $2 | jq -r '.server') SHARE=$(echo $2 | jq -r '.share') if [ $(ismounted) -eq 1 ] ; then log '{"status": "Success"}' exit 0 fi mkdir -p ${MNTPATH} &> /dev/null mount -t nfs ${NFS_SERVER}:/${SHARE} ${MNTPATH} &> /dev/null if [ $? -ne 0 ]; then err "{ \"status\": \"Failure\", \"message\": \"Failed to mount ${NFS_SERVER}:${SHARE} at ${MNTPATH}\"}" exit 1 fi log '{"status": "Success"}' exit 0 } unmount() { MNTPATH=$1 if [ $(ismounted) -eq 0 ] ; then log '{"status": "Success"}' exit 0 fi umount ${MNTPATH} &> /dev/null if [ $? -ne 0 ]; then err "{ \"status\": \"Failed\", \"message\": \"Failed to unmount volume at ${MNTPATH}\"}" exit 1 fi log '{"status": "Success"}' exit 0 } op=$1 if [ "$op" = "init" ]; then log '{"status": "Success", "capabilities": {"attach": false}}' exit 0 fi if [ $# -lt 2 ]; then usage fi shift case "$op" in mount) domount $* ;; unmount) unmount $* ;; *) log '{"status": "Not supported"}' exit 0 esac exit 1
لذلك ، بعد إعداد الملف القابل للتنفيذ الفعلي ، تحتاج إلى
وضع برنامج التشغيل في نظام Kubernetes . يجب أن يكون برنامج التشغيل موجودًا على كل عقدة من الكتلة وفقًا لمسار محدد مسبقًا. افتراضيا تم اختيار:
/usr/libexec/kubernetes/kubelet-plugins/volume/exec/__~_/... ولكن باستخدام توزيعات Kubernetes المختلفة (OpenShift ، Rancher ...) قد يكون المسار مختلفًا.
مشاكل Flexvolume: كيف يلقي قضيب الصيد؟
تحول تشغيل برنامج Flexvolume على عقد نظام المجموعة إلى مهمة لا نظير لها. بعد إجراء العملية مرة واحدة يدويًا ، من السهل مواجهة موقف عند ظهور عقد جديدة في الكتلة: بسبب إضافة عقدة جديدة أو تغيير حجم أفقي تلقائي أو ما هو أسوأ من استبدال العقدة بسبب حدوث خلل. في هذه الحالة ،
يستحيل العمل مع وحدة التخزين على هذه العقد حتى تضيف برنامج التشغيل Flexvolume يدويًا إليها بنفس الطريقة.
كان الحل لهذه المشكلة أحد البدائيين لـ Kubernetes -
DaemonSet . عندما تظهر عقدة جديدة في الكتلة ، فإنها تحصل تلقائيًا على قرنة من DaemonSet ، والتي يتم توصيل وحدة تخزين محلية بها على طول الطريق للعثور على برامج تشغيل Flexvolume. عند الإنشاء الناجح ، يقوم pod بنسخ الملفات الضرورية حتى يعمل برنامج التشغيل على القرص.
فيما يلي مثال لمثل DaemonSet لوضع المكون الإضافي Flexvolume:
apiVersion: extensions/v1beta1 kind: DaemonSet metadata: name: flex-set spec: template: metadata: name: flex-deploy labels: app: flex-deploy spec: containers: - image: <deployment_image> name: flex-deploy securityContext: privileged: true volumeMounts: - mountPath: /flexmnt name: flexvolume-mount volumes: - name: flexvolume-mount hostPath: path: <host_driver_directory>
... ومثال على البرنامج النصي Bash لوضع برنامج تشغيل Flexvolume:
من المهم ألا ننسى أن عملية النسخ
ليست ذرية . من المحتمل جدًا أن يبدأ kubelet في استخدام برنامج التشغيل قبل اكتمال عملية الإعداد ، مما سيؤدي إلى حدوث خطأ في النظام. ستكون الطريقة الصحيحة هي أولاً نسخ ملفات برنامج التشغيل تحت اسم مختلف ، ثم استخدام عملية إعادة التسمية الذرية.
مخطط العمل مع Ceph في بيان Rook: يوجد برنامج تشغيل Flexvolume في المخطط داخل وكيل Rook.المشكلة التالية عند استخدام برامج تشغيل Flexvolume هي أنه بالنسبة لمعظم التخزين
، يجب تثبيت البرنامج الضروري لذلك على عقدة نظام المجموعة (على سبيل المثال ، حزمة ceph-common لـ Ceph). في البداية ، لم يتم تصميم البرنامج المساعد Flexvolume لتنفيذ مثل هذه الأنظمة المعقدة.
يمكن رؤية حل أصلي لهذه المشكلة في تنفيذ برنامج التشغيل Flexvolume لمشغل Rook:
تم تصميم برنامج التشغيل نفسه كعميل RPC. يوجد مقبس IPC للاتصال في نفس الدليل مثل برنامج التشغيل نفسه. نتذكر جميعًا أنه لنسخ ملفات برنامج التشغيل ، سيكون من الجيد استخدام DaemonSet ، الذي يربط الدليل مع برنامج التشغيل كوحدة تخزين. بعد نسخ ملفات برنامج تشغيل الرخ اللازمة ، لا يموت هذا الجهاز ، ولكنه يتصل بمقبس IPC عبر وحدة التخزين المرفقة كملقم RPC كامل. الحزمة ceph-common مثبتة بالفعل داخل حاوية pod. يعطي مقبس IPC الثقة في أن kubelet سيتواصل مع السنف المحدد الموجود على نفس العقدة. كل شيء عبقري بسيط! ..
وداعا ، لدينا حنون ... الإضافات في شجرة!
وجد مطورو Kubernetes أن عدد مكوّنات التخزين داخل النواة يبلغ 20. والتغيير في كل منهما يمر بطريقة ما من خلال دورة إصدار Kubernetes الكاملة.
اتضح أنه لاستخدام الإصدار الجديد من المكون الإضافي للتخزين ،
تحتاج إلى تحديث المجموعة بالكامل . بالإضافة إلى ذلك ، قد تتفاجأ من أن الإصدار الجديد من Kubernetes يصبح فجأة غير متوافق مع Linux kernel المستخدم ... وبالتالي ، تمحو الدموع وتنثر أسنانك وتنسق مع السلطات والمستخدمين وقت تحديث مجموعة Linux kernel و Kubernetes. مع تعطل ممكن في تقديم الخدمات.
الموقف أكثر من كوميدي ، أليس كذلك؟ أصبح من الواضح للمجتمع بأكمله أن النهج لم ينجح. من خلال قرار قوي الإرادة ، أعلن مطورو Kubernetes أنه لن يتم قبول مكونات إضافية للتخزين في النواة. إلى كل شيء آخر ، كما نعلم بالفعل ، في تنفيذ البرنامج المساعد Flexvolume ، تم الكشف عن عدد من أوجه القصور ...
مرة واحدة وإلى الأبد ، تم استدعاء آخر ملحق إضافي لوحدات التخزين في Kubernetes ، CSI ، لإغلاق المشكلة مع مستودعات البيانات المستمرة. تم الإعلان عن إصدار ألفا الخاص به ، والذي يشار إليه أكثر باسم الإضافات
الخارجية لوحدة تخزين CSI ، في
Kubernetes 1.9 .
واجهة حاوية التخزين ، أو CSI 3000 الغزل!
بادئ ذي بدء ، أود أن أشير إلى أن CSI ليس مجرد مكون إضافي للصوت ، ولكنه
معيار حقيقي
لإنشاء مكونات مخصصة للعمل مع مستودعات البيانات . كان من المفترض أن أنظمة تزامن الحاويات ، مثل Kubernetes و Mesos ، يجب أن "تتعلم" كيفية التعامل مع المكونات المنفذة وفقًا لهذا المعيار. والآن Kubernetes تعلمت بالفعل.
ما هو الجهاز المساعد CSI في Kubernetes؟ يعمل المكون الإضافي لـ CSI مع برامج تشغيل خاصة (
برامج تشغيل CSI ) يكتبها مطورو الطرف الثالث. يجب أن يتألف برنامج تشغيل CSI في Kubernetes من مكونين (قرون) على الأقل:
- جهاز التحكم - يدير التخزين الثابت الخارجي. يتم تطبيقه كخادم gRPC والذي يستخدم
StatefulSet البدائي. - العقدة - هي المسؤولة عن تركيب المتاجر الدائمة على عقد الكتلة. يتم تطبيقه أيضًا كخادم gRPC ، ولكن يتم استخدام
DaemonSet البدائي لذلك.
Kubernetes CSI البرنامج المساعد سير العمليمكنك التعرف على بعض تفاصيل CSI الأخرى ، على سبيل المثال ، من مقالة "
فهم CSI " ، وهي
ترجمة نشرناها قبل عام.
مزايا مثل هذا التنفيذ
- بالنسبة للأشياء الأساسية - على سبيل المثال ، لتسجيل برنامج تشغيل لعقدة - قام مطورو Kubernetes بتطبيق مجموعة من الحاويات. لم تعد بحاجة إلى إنشاء استجابة JSON مع إمكانات بنفسك ، كما حدث مع المكون الإضافي Flexvolume.
- بدلاً من "الانزلاق" عقد الملفات القابلة للتنفيذ ، نضع الآن قرون في المجموعة. هذا ما توقعناه في الأصل من Kubernetes: تحدث جميع العمليات داخل حاويات تم نشرها باستخدام بدائل Kubernetes.
- لتنفيذ برامج التشغيل المعقدة ، لم تعد بحاجة إلى تطوير خادم RPC وعميل RPC. تم تنفيذ العميل لنا من قبل المطورين Kubernetes.
- يعد تمرير الوسائط للعمل مع بروتوكول gRPC أكثر ملاءمة ومرونة وأكثر موثوقية من تمريرها عبر وسيطات سطر الأوامر. لفهم كيفية إضافة دعم لمقاييس استخدام وحدة التخزين إلى CSI عن طريق إضافة طريقة gRPC موحدة ، تحقق من طلب السحب لبرنامج التشغيل vsphere-csi.
- يتم الاتصال عبر مآخذ IPC حتى لا يتم الخلط بين إرسال جراب kubelet أم لا.
هل تذكرك هذه القائمة بأي شيء؟ مزايا CSI هي
الحل للمشاكل التي لم تؤخذ بعين الاعتبار عند تطوير البرنامج المساعد Flexvolume.
النتائج
تم قبول CSI كمعيار لتنفيذ المكونات الإضافية المخصصة للتفاعل مع مستودعات البيانات بحرارة شديدة من قبل المجتمع. علاوة على ذلك ، نظرًا لمزاياها وبراعتها ، يتم إنشاء برامج تشغيل CSI حتى لمستودعات التخزين مثل Ceph أو AWS EBS ، وهي مكونات إضافية للعمل تمت إضافتها في الإصدار الأول من Kubernetes.
في أوائل عام 2019 ،
تم إهمال الإضافات الموجودة داخل الشجرة. من المخطط الاستمرار في دعم المكون الإضافي Flexvolume ، ولكن لن يكون هناك تطوير للوظائف الجديدة له.
لدينا أنفسنا بالفعل خبرة في استخدام ceph-csi و vsphere-csi ونحن مستعدون للإضافة إلى هذه القائمة! حتى الآن ، تتعامل CSI مع المهام المسندة إليها مع اثارة ضجة ، وهناك ننتظر ونرى.
لا تنسَ أن كل شيء جديد قديم جدًا!
PS
اقرأ أيضًا في مدونتنا: