الجزء 1 نقوم بنشر البيئة للعمل مع microservices. الجزء 1 من تثبيت Kubernetes HA على المعدن العاري (دبيان)
مرحباً عزيزي القراء من هبر!
في منشور سابق ، تحدثت عن كيفية نشر مجموعة تجاوز فشل Kubernetes. ولكن الحقيقة هي أنه في Kubernetes ، من المريح نشر تطبيقات عديمة الجنسية لا تحتاج إلى الحفاظ على حالتها أو العمل مع البيانات. لكن في معظم الحالات ، نحتاج إلى حفظ البيانات وعدم فقدها عند إعادة تشغيل الموقد.
Kubernetes يستخدم مجلدات لهذه الأغراض. عندما نعمل مع حلول Kubernetes السحابية ، لا توجد مشاكل خاصة. نحتاج فقط إلى طلب وحدة التخزين المطلوبة من Google أو Amazon أو أي موفر سحابة آخر ، وبتوجيه من الوثائق ، قم بتوصيل وحدات التخزين المستلمة بالقرون.
عندما نتعامل مع المعادن العارية ، تكون الأمور أكثر تعقيدًا. اليوم أريد أن أتحدث عن أحد الحلول القائمة على استخدام ceph.
في هذا المنشور سأقول:
- كيفية نشر ceph الموزعة التخزين
- كيفية استخدام Ceph عند العمل مع Kubernetes
مقدمة
بادئ ذي بدء ، أود أن أوضح لمن ستكون هذه المقالة مفيدة. أولاً ، بالنسبة للقراء الذين نشروا المجموعة وفقًا لمنشورتي الأولى من أجل الاستمرار في بناء بنية الخدمات المصغرة. ثانياً ، بالنسبة للأشخاص الذين يرغبون في محاولة نشر مجموعة ceph بمفردهم وتقييم أدائها.
في هذا المنشور ، لن أتطرق إلى موضوع تخطيط المجموعات لأي احتياجات ، سأتحدث فقط عن المبادئ والمفاهيم العامة. لن أتطرق إلى "التوليف" والتوليف العميق ، فهناك العديد من المنشورات حول هذا الموضوع ، بما في ذلك على Habr. ستكون المقالة ذات طبيعة تمهيدية أكثر ، ولكن في الوقت نفسه ستسمح لك بالحصول على حل عملي يمكنك تكييفه وفقًا لاحتياجاتك في المستقبل.
- قائمة المضيفين ، موارد المضيف ، إصدارات نظام التشغيل والبرامج
- هيكل الكتلة Ceph
- تكوين عقد الكتلة قبل التثبيت
- تثبيت ceph نشر
- إنشاء كتلة ceph
- إعداد الشبكة
- تثبيت حزم ceph
- تركيب وتهيئة المراقبين
- مضيفا OSD
- ربط ceph إلى kubernetes
- إنشاء تجمع بيانات
- خلق سر العميل
- نشر مزود cbd rbd
- خلق فئة التخزين
- Kubernetes + اختبار الرباط ceph
- قائمة المواد المستخدمة في إعداد المقال
قائمة المضيف ومتطلبات النظام
عند كتابة مقال ، أستخدم أجهزة افتراضية مع هذا التكوين
كل منها لديه نظام تشغيل ديبيان 9.5 مثبت. هذه هي آلات اختبار ، لكل منها قرصان ، الأول لنظام التشغيل ، والثاني لنظام التشغيل OSD.
أنا سوف نشر الكتلة من خلال الأداة المساعدة نشر ceph. يمكنك نشر مجموعة ceph في الوضع اليدوي ، يتم شرح جميع الخطوات في الوثائق ، لكن الغرض من هذه المقالة هو معرفة مدى سرعة نشر ceph والبدء في استخدامه في kubernetes.
Ceph شراهة جدا للموارد ، وخاصة RAM. لسرعة جيدة ، فمن المستحسن استخدام محركات أقراص SSD.
يمكنك قراءة المزيد حول المتطلبات في وثائق ceph الرسمية.
هيكل الكتلة Ceph
MON
جهاز العرض هو برنامج خفي يعمل كمنسق تبدأ منه المجموعة. بمجرد أن لدينا شاشة واحدة تعمل على الأقل ، لدينا مجموعة Ceph. تقوم الشاشة بتخزين معلومات حول صحة وحالة الكتلة من خلال تبادل البطاقات المختلفة مع الشاشات الأخرى. يلجأ العملاء إلى الشاشات لمعرفة أي OSD لكتابة / قراءة البيانات إليه. عند نشر وحدة تخزين جديدة ، فإن أول شيء تفعله هو إنشاء جهاز (أو عدة أجهزة). يمكن أن تعيش المجموعة على شاشة واحدة ، لكن يوصى بإجراء 3 أو 5 شاشات لتجنب سقوط النظام بأكمله بسبب سقوط شاشة واحدة. الشيء الرئيسي هو أن عدد هذه يجب أن يكون غريبا من أجل تجنب حالات انقسام الدماغ. تعمل الشاشات في النصاب القانوني ، لذلك إذا سقط أكثر من نصف الشاشات ، فسيتم حظر المجموعة لمنع عدم تناسق البيانات.
MGR
يعمل برنامج Ceph Manager الخفي مع برنامج الخفي للشاشة لتوفير تحكم إضافي.
منذ الإصدار 12.x ، أصبح البرنامج الخفي لـ ceph-mgr ضروريًا للتشغيل العادي.
إذا لم يتم تشغيل البرنامج الخفي mgr ، فسترى تحذيرًا حول هذا الأمر.
OSD (جهاز تخزين الكائنات)
OSD هي وحدة تخزين تخزن البيانات نفسها وتعالج طلبات العميل من خلال تبادل البيانات مع أجهزة OSD الأخرى. هذا هو عادة القرص. عادةً ما يكون لكل OSD شيطان OSD منفصل يمكن تشغيله على أي جهاز مثبت عليه هذا القرص.
ستعمل الشياطين الثلاثة على كل جهاز في مجموعتنا. وفقًا لذلك ، قم بمراقبة وإدارة الشياطين كخدمة وشياطين OSD لمحرك واحد من الجهاز الظاهري.
تكوين عقد الكتلة قبل التثبيت
تحدد وثائق ceph سير العمل التالي:
سوف أعمل من العقدة الأولى من نظام اختبار ceph01 ، سيكون مسؤول العقدة ، وسوف يحتوي أيضًا على ملفات تهيئة للأداة المساعدة للنشر ceph. لكي تعمل الأداة المساعدة ceph-انتشار بشكل صحيح ، يجب الوصول إلى جميع عقد نظام المجموعة عبر ssh باستخدام عقدة المسؤول. للراحة ، سأكتب أسماء المضيفين القصيرة للمجموعة
10.73.88.52 ceph01-test 10.73.88.53 ceph02-test 10.73.88.54 ceph03-tset
وانسخ المفاتيح إلى المضيفين الآخرين. جميع الأوامر التي سأنفذها من الجذر.
ssh-copy-id ceph02-test ssh-copy-id ceph03-test
وثائق الإعداد
CEPH-نشرتثبيت ceph نشر
الخطوة الأولى هي تثبيت نشر ceph على جهاز اختبار ceph01
wget -q -O- 'https://download.ceph.com/keys/release.asc' | apt-key add -
بعد ذلك ، تحتاج إلى اختيار الإصدار الذي تريد وضعه. ولكن هنا توجد صعوبات ، فإن ceph لنظام التشغيل دبيان يدعم الحزم المضيئة فقط.
إذا كنت ترغب في وضع إصدار أحدث ، فسيتعين عليك استخدام مرآة ، على سبيل المثال
https://mirror.croit.io/debian-mimic/dists/
إضافة مستودع مع تقليد على جميع العقد الثلاثة
apt install curl apt-transport-https -y curl https://mirror.croit.io/keys/release.gpg > /usr/share/keyrings/croit-signing-key.gpg echo 'deb [signed-by=/usr/share/keyrings/croit-signing-key.gpg] https://mirror.croit.io/debian-mimic/ stretch main' > /etc/apt/sources.list.d/croit-ceph.list apt update apt install ceph-deploy
إذا كانت اللمعة كافية بالنسبة لك ، فيمكنك استخدام المستودعات الرسمية
echo deb https://download.ceph.com/debian-luminous/ $(lsb_release -sc) main | tee /etc/apt/sources.list.d/ceph.list apt-transport-https apt update apt install ceph-deploy
نحن أيضا تثبيت NTP على جميع العقد الثلاثة.
لأن هذه التوصية في وثائق cephنوصي بتثبيت NTP على العقد Ceph (خاصة على العقد Ceph Monitor) لمنع المشكلات الناشئة عن ساعة التوقيت.
apt install ntp
تأكد من تمكين خدمة NTP. تأكد من أن كل عقدة Ceph تستخدم نفس خادم NTP. تستطيع أن ترى المزيد من التفاصيل هنا
إنشاء كتلة ceph
إنشاء دليل لملفات التكوين والملفات نشر ceph
mkdir my-cluster cd my-cluster
لنقم بإنشاء تكوين كتلة جديد ، عند الإنشاء ، أشر إلى أنه سيكون هناك ثلاثة أجهزة عرض في نظامنا
ceph-deploy new ceph01-test ceph02-test ceph03-test
إعداد الشبكة
النقطة المهمة الآن ، لقد حان الوقت للحديث عن شبكة ceph. يستخدم Ceph شبكتين عامتين وشبكة كتلة للعمل
كما ترون من مخطط الشبكة العامة ، هذا هو مستوى المستخدم والتطبيق ، وشبكة الكتلة هي الشبكة التي يتم من خلالها نسخ البيانات.
من المرغوب فيه للغاية فصل هاتين الشبكتين عن بعضها البعض. أيضا ، شبكة الكتلة سرعة الشبكة مرغوب فيه على الأقل 10 جيجابايت.
بالطبع ، يمكنك الاحتفاظ بكل شيء على نفس الشبكة. ولكن هذا محفوف بحقيقة أنه بمجرد زيادة حجم النسخ المتماثل بين OSDs ، على سبيل المثال ، عندما تسقط أو تضاف OSDs جديدة (الأقراص) ، سيزداد التحميل على الشبكة. وبالتالي فإن سرعة واستقرار البنية التحتية الخاصة بك تعتمد إلى حد كبير على الشبكة المستخدمة بواسطة ceph.
لسوء الحظ ، ليس لدى مجموعة المحاكاة الافتراضية شبكة منفصلة ، وسوف أستخدم شريحة شبكة مشتركة.
يتم تكوين الشبكة للكتلة من خلال ملف التكوين ، الذي أنشأناه بالأمر السابق.
/my-cluster# cat ceph.conf [global] fsid = 2e0d92b0-e803-475e-9060-0871b63b6e7f mon_initial_members = ceph01-test, ceph02-test, ceph03-test mon_host = 10.73.88.52,10.73.88.53,10.73.88.54 auth_cluster_required = cephx auth_service_required = cephx auth_client_required = cephx
كما يمكننا أن نرى ، فإن cef نشر لم ينشئ إعدادات الشبكة الافتراضية بالنسبة لنا ، لذلك سأضيف معلمة الشبكة العامة = {public-network / netmask} إلى القسم العام من التهيئة. شبكتي هي 10.73.0.0/16 ، لذلك بعد إضافة التكوين الخاص بي سيبدو هكذا
[global] fsid = 2e0d92b0-e803-475e-9060-0871b63b6e7f mon_initial_members = ceph01-test, ceph02-test, ceph03-test mon_host = 10.73.88.52,10.73.88.53,10.73.88.54 public network = 10.73.0.0/16 auth_cluster_required = cephx auth_service_required = cephx auth_client_required = cephx
إذا كنت ترغب في فصل شبكة الكتلة عن عامة ، فأضف شبكة كتلة المعلمة = {cluster-network / netmask}
يمكنك قراءة المزيد عن الشبكات في الوثائق.
تثبيت حزم ceph
باستخدام ceph-publish ، نقوم بتثبيت جميع حزم ceph التي نحتاجها على العقد الثلاث لدينا.
للقيام بذلك ، في اختبار ceph01 ، تنفيذ
إذا كان الإصدار هو تقليد ذلك الحين
ceph-deploy install --release mimic ceph01-test ceph02-test ceph03-test
إذا كان الإصدار مضيئًا إذن
ceph-deploy install --release luminous ceph01-test ceph02-test ceph03-test
وانتظر حتى يتم تأسيس كل شيء.
تركيب وتهيئة المراقبين
بعد تثبيت جميع الحزم ، سنقوم بإنشاء وبدء تشغيل شاشات نظامنا.
اختبار C ceph01 القيام بما يلي
ceph-deploy mon create-initial
سيتم إنشاء الشاشات في هذه العملية ، وسيتم إطلاق الشياطين ، وسوف يتحقق نشر ceph من النصاب القانوني.
الآن مبعثر التكوينات على عقد الكتلة.
ceph-deploy admin ceph01-test ceph02-test ceph03-test
وتحقق من حالة مجموعتنا ، إذا فعلت كل شيء بشكل صحيح ، فينبغي أن تكون الحالة
HEALTH_OK
~/my-cluster# ceph status cluster: id: 2e0d92b0-e803-475e-9060-0871b63b6e7f health: HEALTH_OK services: mon: 3 daemons, quorum ceph01-test,ceph02-test,ceph03-test mgr: no daemons active osd: 0 osds: 0 up, 0 in data: pools: 0 pools, 0 pgs objects: 0 objects, 0 B usage: 0 B used, 0 B / 0 B avail pgs:
إنشاء المونسنيور
ceph-deploy mgr create ceph01-test ceph02-test ceph03-test
وتحقق من الحالة مرة أخرى
ceph -s
يجب أن يظهر الخط
mgr: ceph01-test(active), standbys: ceph02-test, ceph03-test
نكتب التكوين لجميع المضيفين في الكتلة
ceph-deploy admin ceph01-test ceph02-test ceph03-test
مضيفا OSD
في الوقت الحالي ، لدينا مجموعة عمل ، لكنها لا تحتوي على أقراص (osd في مصطلحات ceph) لتخزين المعلومات.
يمكن إضافة OSD مع الأمر التالي (عرض عام)
ceph-deploy osd create --data {device} {ceph-node}
في ملف الاختبار الخاص بي ، يتم تخصيص القرص / dev / sdb تحت osd ، لذلك في حالتي ستكون الأوامر كما يلي
ceph-deploy osd create --data /dev/sdb ceph01-test ceph-deploy osd create --data /dev/sdb ceph02-test ceph-deploy osd create --data /dev/sdb ceph03-test
تحقق من أن جميع OSDs تعمل.
ceph -s
استنتاج
cluster: id: 2e0d92b0-e803-475e-9060-0871b63b6e7f health: HEALTH_OK services: mon: 3 daemons, quorum ceph01-test,ceph02-test,ceph03-test mgr: ceph01-test(active) osd: 3 osds: 3 up, 3 in
يمكنك أيضًا تجربة بعض الأوامر المفيدة لـ OSD.
ceph osd df ID CLASS WEIGHT REWEIGHT SIZE USE AVAIL %USE VAR PGS 0 hdd 0.00490 1.00000 5.0 GiB 1.0 GiB 4.0 GiB 20.05 1.00 0 1 hdd 0.00490 1.00000 5.0 GiB 1.0 GiB 4.0 GiB 20.05 1.00 0 2 hdd 0.00490 1.00000 5.0 GiB 1.0 GiB 4.0 GiB 20.05 1.00 0 TOTAL 15 GiB 3.0 GiB 12 GiB 20.05
و
ceph osd tree ID CLASS WEIGHT TYPE NAME STATUS REWEIGHT PRI-AFF -1 0.01469 root default -3 0.00490 host ceph01-test 0 hdd 0.00490 osd.0 up 1.00000 1.00000 -5 0.00490 host ceph02-test 1 hdd 0.00490 osd.1 up 1.00000 1.00000 -7 0.00490 host ceph03-test 2 hdd 0.00490 osd.2 up 1.00000 1.00000
إذا كان كل شيء على ما يرام ، ثم لدينا مجموعة ceph العاملة. في الجزء التالي ، سأحدد كيفية استخدام ceph مع kubernetes
ربط ceph إلى kubernetes
لسوء الحظ ، لن أكون قادرًا على وصف عملية مجلدات Kubernetes بالتفصيل في هذه المقالة ، لذا سأحاول أن أتوافق مع فقرة واحدة.
تستخدم Kubernetes فئات التخزين للعمل مع وحدات تخزين بيانات البيانات ، ولكل فئة تخزين مزود خاص بها ، ويمكنك اعتبارها كنوع من "برنامج التشغيل" للعمل مع أحجام تخزين بيانات مختلفة. يمكن العثور على القائمة الكاملة التي تدعم kubernetes في الوثائق الرسمية .
تدعم Kubernetes نفسها أيضًا العمل مع rbd ، لكن صورة مسؤول kube-controller-manager لا تحتوي على عميل rbd مثبت ، لذلك تحتاج إلى استخدام صورة مختلفة.
تجدر الإشارة أيضًا إلى أن وحدات التخزين (pvc) التي تم إنشاؤها كـ rbd يمكن أن تكون ReadWriteOnce (RWO) فقط ، مما يعني أنه يمكنك تحميل وحدة التخزين التي تم إنشاؤها فقط لموقد واحد.
لكي تتمكن مجموعتنا من العمل مع وحدات تخزين ceph ، نحتاج إلى:
في كتلة Ceph:
- إنشاء تجمع البيانات في كتلة ceph
- إنشاء عميل ومفتاح الوصول إلى تجمع البيانات
- الحصول على سر المشرف ceph
لكي تتمكن مجموعتنا من العمل مع وحدات تخزين ceph ، نحتاج إلى:
في كتلة Ceph:
- إنشاء تجمع البيانات في كتلة ceph
- إنشاء عميل ومفتاح الوصول إلى تجمع البيانات
- الحصول على سر المشرف ceph
في كتلة Kubernetes:
- خلق سرية المشرف ومفتاح العميل
- قم بتثبيت مزود ceph rbd أو قم بتغيير صورة kube-controller-manager إلى صورة تدعم rbd
- إنشاء سر مع مفتاح عميل ceph
- إنشاء فئة التخزين
- تثبيت ceph-common على ملاحظات العامل kubernetes
إنشاء تجمع بيانات
في كتلة ceph ، قم بإنشاء تجمع لوحدات kubernetes
ceph osd pool create kube 8 8
سأقدم هنا شرحًا صغيرًا ، الأرقام 8 8 في النهاية هي أرقام pg و pg. تعتمد هذه القيم على حجم كتلة ceph. هناك الآلات الحاسبة الخاصة التي تحسب مقدار pg و pgs ، على سبيل المثال ، مسؤول من ceph
بادئ ذي بدء ، أوصي بتركه افتراضيًا ، إذا كان يمكن زيادة هذا المبلغ في المستقبل (يمكن تخفيضه فقط من إصدار Nautilus).
إنشاء عميل لتجمع البيانات
إنشاء عميل للتجمع الجديد
ceph auth add client.kube mon 'allow r' osd 'allow rwx pool=kube'
سوف نتلقى مفتاحًا للعميل ، في المستقبل سنحتاجه لإنشاء kubernetes سري
ceph auth get-key client.kube AQDd5aldka5KJRAAkpWTQYUMQi+5dfGDqSyxkg==
الحصول على مفتاح المسؤول
والحصول على مفتاح المسؤول
ceph auth get client.admin 2>&1 |grep "key = " |awk '{print $3'} AQAv+Itdx4DwKBAAKVhWRS3+eEPqV3Xrnlg9KA==
في نظام ceph ، اكتمل كل العمل والآن نحتاج إلى الانتقال إلى جهاز يمكنه الوصول إلى نظام kubernetes
سأعمل مع master01-test (10.73.71.25) من الكتلة التي نشرتها في المنشور الأول.
خلق سر العميل
قم بإنشاء ملف برمز العميل الذي تلقيناه (لا تنس استبداله برمزك المميز)
echo AQDd5aldka5KJRAAkpWTQYUMQi+5dfGDqSyxkg== > /tmp/key.client
وخلق سر سوف نستخدمه في المستقبل
kubectl create secret generic ceph-secret --from-file=/tmp/key.client --namespace=kube-system --type=kubernetes.io/rbd
إنشاء سر المشرف
إنشاء ملف برمز المشرف (لا تنسَ استبداله برمزك المميز)
echo AQAv+Itdx4DwKBAAKVhWRS3+eEPqV3Xrnlg9KA== > /tmp/key.admin
بعد ذلك إنشاء سر المسؤول
kubectl create secret generic ceph-admin-secret --from-file=/tmp/key.admin --namespace=kube-system --type=kubernetes.io/rbd
تحقق من أن الأسرار قد تم إنشاؤها
kubectl get secret -n kube-system | grep ceph ceph-admin-secret kubernetes.io/rbd 1 8m31s ceph-secret kubernetes.io/rbd 1 7m32s
الطريقة الأولى نشر مزود ceph rbd
نقوم باستنساخ مستودع kubernetes-incubator / التخزين الخارجي من github ، فهو يحتوي على كل ما تحتاجه لتكوين صداقات kubernetes مع مستودع ceph.
git clone https://github.com/kubernetes-incubator/external-storage.git cd external-storage/ceph/rbd/deploy/ NAMESPACE=kube-system sed -r -i "s/namespace: [^ ]+/namespace: $NAMESPACE/g" ./rbac/clusterrolebinding.yaml ./rbac/rolebinding.yaml
kubectl -n $NAMESPACE apply -f ./rbac
استنتاج
clusterrole.rbac.authorization.k8s.io/rbd-provisioner created clusterrolebinding.rbac.authorization.k8s.io/rbd-provisioner created deployment.extensions/rbd-provisioner created role.rbac.authorization.k8s.io/rbd-provisioner created rolebinding.rbac.authorization.k8s.io/rbd-provisioner created serviceaccount/rbd-provisioner created
الطريقة الثانية: استبدال صورة kube-controller-manager
لا يوجد أي دعم rbd في الصورة الرسمية kube-controller-manager ، لذلك سنحتاج إلى تغيير صورة مدير-الإدارة.
للقيام بذلك ، في كل من معالجات Kubernetes ، تحتاج إلى تحرير ملف kube-controller-manager.yaml واستبدال الصورة بـ gcr.io/google_containers/hyperkube:v1.15.2. انتبه إلى إصدار الصورة الذي يجب أن يتطابق مع إصدار نظام Kubernet.
vim /etc/kubernetes/manifests/kube-controller-manager.yaml
بعد ذلك ، ستحتاج إلى إعادة تشغيل kube-controller-manager
ubectl get pods -A | grep manager kube-system kube-controller-manager-master01-test 1/1 Running 0 5m54s kube-system kube-controller-manager-master02-test 1/1 Running 0 5m54s kube-system kube-controller-manager-master03-test 1/1 Running 9111 103d
يجب تحديث السنفات تلقائيًا ، ولكن إذا لم يحدث هذا لسبب ما ، يمكنك إعادة إنشائها يدويًا من خلال الحذف.
kubectl delete pod -n kube-system kube-controller-manager-master01-test kubectl delete pod -n kube-system kube-controller-manager-master02-test kubectl delete pod -n kube-system kube-controller-manager-master03-test
تأكد من أن كل شيء على ما يرام
kubectl describe pod -n kube-system kube-controller-manager-master02-test | grep Image: Image: gcr.io/google_containers/hyperkube:v1.15.2
-
خلق فئة التخزين
الطريقة الأولى - إذا استخدمت الموفر ceph.com/rbd
قم بإنشاء ملف yaml مع وصف لفئة التخزين الخاصة بنا. أيضًا ، يمكن تنزيل جميع الملفات المستخدمة أدناه في مستودع التخزين الخاص بي في دليل ceph
cat <<EOF >./storage-class.yaml kind: StorageClass apiVersion: storage.k8s.io/v1 metadata: name: ceph-rbd provisioner: ceph.com/rbd parameters: monitors: 10.73.88.52:6789, 10.73.88.53:6789, 10.73.88.54:6789 pool: kube adminId: admin adminSecretNamespace: kube-system adminSecretName: ceph-admin-secret userId: kube userSecretNamespace: kube-system userSecretName: ceph-secret imageFormat: "2" imageFeatures: layering EOF
ودمجه في مجموعتنا
kubectl apply -f storage-class.yaml
تأكد من أن كل شيء على ما يرام
kubectl get sc NAME PROVISIONER AGE ceph-rbd ceph.com/rbd 7s
الطريقة الثانية - إذا كنت تستخدم الموفر kubernetes.io/rbd
إنشاء فئة التخزين
cat <<EOF >./storage-class-hyperkube.yaml kind: StorageClass apiVersion: storage.k8s.io/v1 metadata: name: ceph-rbd provisioner: kubernetes.io/rbd allowVolumeExpansion: true parameters: monitors: 10.73.88.52:6789, 10.73.88.53:6789, 10.73.88.54:6789 pool: kube adminId: admin adminSecretNamespace: kube-system adminSecretName: ceph-admin-secret userId: kube userSecretNamespace: kube-system userSecretName: ceph-secret imageFormat: "2" imageFeatures: layering EOF
ودمجه في مجموعتنا
kubectl apply -f storage-class-hyperkube.yaml storageclass.storage.k8s.io/ceph-rbd created
تأكد من أن كل شيء على ما يرام
kubectl get sc NAME PROVISIONER AGE ceph-rbd kubernetes.io/rbd 107s
Kubernetes + اختبار الرباط ceph
قبل اختبار ceph + kubernetes ، يجب تثبيت الحزمة ceph-common على كل رمز عمل من الكتلة.
apt install curl apt-transport-https -y curl https://mirror.croit.io/keys/release.gpg > /usr/share/keyrings/croit-signing-key.gpg echo 'deb [signed-by=/usr/share/keyrings/croit-signing-key.gpg] https://mirror.croit.io/debian-mimic/ stretch main' > /etc/apt/sources.list.d/croit-ceph.list apt update apt install ceph-common
قم بإنشاء ملف yaml PersistentVolumeClaim
cat <<EOF >./claim.yaml kind: PersistentVolumeClaim apiVersion: v1 metadata: name: claim1 spec: accessModes: - ReadWriteOnce storageClassName: ceph-rbd resources: requests: storage: 1Gi EOF
قتله
kubectl apply -f claim.yaml
تحقق من إنشاء PersistentVolumeClaim.
bectl get pvc NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE claim1 Bound pvc-d1e47825-289c-4201-acb8-033e62a3fe81 1Gi RWO ceph-rbd 44m
وأيضا خلق تلقائيا PersistentVolume.
kubectl get pv NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE pvc-d1e47825-289c-4201-acb8-033e62a3fe81 1Gi RWO Delete Bound default/claim1 ceph-rbd 37m
دعنا ننشئ قرنة اختبار واحدة نضمن فيها pvc الذي تم إنشاؤه في دليل / mnt. قم بتشغيل هذا الملف /mnt/test.txt مع النص "Hello World!"
cat <<EOF >./create-file-pod.yaml kind: Pod apiVersion: v1 metadata: name: create-file-pod spec: containers: - name: test-pod image: gcr.io/google_containers/busybox:1.24 command: - "/bin/sh" args: - "-c" - "echo Hello world! > /mnt/test.txt && exit 0 || exit 1" volumeMounts: - name: pvc mountPath: "/mnt" restartPolicy: "Never" volumes: - name: pvc persistentVolumeClaim: claimName: claim1 EOF
سنقتله ونتحقق من أنه أكمل مهمته
kubectl apply -f create-file-pod.yaml kubectl get pods -w
دعنا ننتظر الوضع
create-file-pod 0/1 Completed 0 16s
فلنقم بإنشاء وحدة أخرى ، وقم بتوصيل وحدة التخزين الخاصة بنا به بالفعل / mnt / test ، وبعد ذلك تأكد من أن الملف الذي تم إنشاؤه بواسطة المجلد الأول في مكانه الصحيح
cat <<EOF >./test-pod.yaml kind: Pod apiVersion: v1 metadata: name: test-pod spec: containers: - name: test-pod image: gcr.io/google_containers/busybox:1.24 command: - "/bin/sh" args: - "-c" - "sleep 600" volumeMounts: - name: pvc mountPath: "/mnt/test" restartPolicy: "Never" volumes: - name: pvc persistentVolumeClaim: claimName: claim1 EOF
قم بتشغيل kubectl get po -w وانتظر حتى يتم تشغيل pod
بعد ذلك ، دعنا نذهب إليه ونتحقق من أن وحدة التخزين متصلة وملفنا في دليل / mnt / test
kubectl exec test-pod -ti sh cat /mnt/test/test.txt Helo world!
شكرا لك على القراءة حتى النهاية. آسف للتأخير في النشر.
أنا مستعد للإجابة على جميع الأسئلة في الرسائل الشخصية أو في الشبكات الاجتماعية المشار إليها في ملف التعريف الخاص بي.
في المنشور الصغير التالي ، سأخبرك بكيفية نشر تخزين S3 استنادًا إلى مجموعة ceph التي تم إنشاؤها ، ثم وفقًا للخطة الواردة في المنشور الأول.
المواد المستخدمة للنشر