‫حتى الآن مع Kubernetes ، لم نناقش حقًا التخزين أو وحدات
‫التخزين.
‫لقد تعاملت مع ذلك مع Docker ، ثم مع
‫Compose و Swarm وإلى حد ما ، إنه نفس الشيء في
‫Kubernetes.
‫لديك حاويات ، ونفترض أن الحاويات عديمة الجنسية
‫، مما يعني أنه عندما ترمي الحاوية بعيدًا
‫، يختفي كل شيء بداخلها.
‫عندما تستبدل الحاوية بتحديث ، أو تقوم بتغيير
‫شيء ما وتقوم بتطبيقه بتطبيق kubectl ، تفقد الحاوية ، وتفقد كل
‫شيء بداخلها.
‫من الواضح ، أن Kubernetes ، تمامًا مثل غيره من
‫المنسقين ، يجب أن يكون لديهم طريقة للبقاء
‫على البيانات الدائمة. إنها أكثر من الأحجام نفسها.
‫حتى الحاويات وعمليات النشر يمكن أن تكون مختلفة في Kubernetes
‫بشيء يسمى StatefulSets.
‫هذه موارد مختلفة عن عمليات
‫النشر.
‫تم تصميمها أساسًا حول قواعد البيانات والأشياء التي تتطلب قدرًا
‫أكبر من المثابرة ، بما في ذلك نفس الاسم
‫، ونفس عناصر IP من هذا القبيل.
‫لم نحصل على هذا الأمر خارج البوابة مع Swarm أو
‫مع Docker بالضرورة.
‫لم يكن لديك حقًا طريقة للاحتفاظ بهذه السمات
‫المختلفة بين الحاويات.
‫StatefulSets هي ميزة جديدة في Kubernetes
‫لم تنفد إلا قليلاً من الوقت هنا.
‫هذا ما ستنظر إليه إذا كنت ستفكر في قواعد
‫البيانات أو شيء حساس للغاية للتغييرات مثل الأسماء وعناوين
‫IP والأحجام والبيانات الثابتة.
‫وهناك كلمة تحذير هنا.
‫السبب في أننا لن نخوض في الكثير من التفاصيل
‫لأنني لا أوصي بأن يتضمن نشرك الأول لـ Kubernetes
‫الكثير من مجموعات StatefulSets
‫فيه. في الواقع ، من الناحية المثالية
‫، فإن نشرك الأول لمنسق ، من أي منسق ، سواء كان Swarm
‫أو Kubernetes ، لا يتعلق إلا بعديمي الجنسية وأنت تعلم
‫، اجعل الأمر بسيطًا. ربما تقوم فقط بواجهات الويب الخاصة
‫بك أو بعض واجهات برمجة التطبيقات ، أو بعض ميزات العاملين ، أو شيء
‫لا يتضمن قواعد البيانات. في الواقع ، إذا كان بإمكانك استخدام قواعد
‫البيانات السحابية ، فافعل ذلك.
‫أوصي دائمًا بالاستعانة بمصادر خارجية لقواعد البيانات
‫الخاصة بك ما لم تكن لديك متطلبات محددة لا يمكنك تجنبها
‫لتشغيل نفسك. تم تصميم Orchestration ، في
‫البداية ، حقًا حول كون الحاويات غير قابلة للتغيير ، وموزعة
‫، وقابلة للاستبدال.
‫ستضيف فكرة الالتزام بالحالة هذه مزيدًا من
‫العمل والتعقيد والمزيد من
‫الاختبارات لك. من الناحية المثالية ، خارج البوابة
‫، لا داعي للقلق بشأن هذا.
‫في وقت لاحق ، بمجرد أن تشعر براحة أكبر مع جميع الأشياء الأخرى حول Kubernetes
‫، يمكنك حينئذٍ العودة والقول ، الآن أريد أن أفكر
‫في قواعد البيانات الخاصة بي.
‫لا يعني ذلك أنه لا يجب عليك تشغيل قواعد البيانات في مجموعات.
‫إنه مجرد عمل أكثر. إنه أصعب.
‫قواعد البيانات والتخزين الدائم أصعب دائمًا ومزيد من التفاصيل
‫للعمل معها. هناك نصيحتي الاحترافية.
‫مع أي حاوية ، يمكنك إضافة حجم مشابه
‫جدًا لما فعلته في Swarm وفي Docker
‫و Docker Compose. يمكنك فقط إضافة بيان الحجم في القالب
‫داخل المواصفات. إذا كنت تفكر في ملف YAML ، يمكننا
‫فقط وضع وحدة تخزين هناك كما تتوقع ، والتنسيق
‫الدقيق والتفاصيل موجودة في الموارد.
‫على
‫عكس Docker and Swarm حيث يكون الحجم مع حاوية ، في هذه الحالة
‫، يكون من الناحية الفنية مع الكبسولة. تتصل بكل حاوية ، أو حاوية واحدة فقط ،
‫في الكبسولة إذا طلبت ذلك.
‫لذا ، فأنت تتحكم فيه على مستوى الحاوية ، لكن ثباته يكون على مستوى
‫الكبسولة. هناك ميزة أحدث
‫وهي الأحجام الدائمة.
‫هذا يعمل مع شيء آخر يسمى المطالبة.
‫الفكرة المثيرة للاهتمام في هذا
‫هي أنك تستخدمه ، أو تحدده ، خارج
‫البودات. أنت تقوم بإنشاء هذا المورد
‫من تلقاء نفسه ، ثم تقوم بتقديم مطالبة ضد هذا المورد
‫داخل مواصفات البود الخاص بك.
‫السبب الأكثر إثارة للاهتمام هو أن Kubernetes تستحوذ على
‫المؤسسة ، فغالبًا ما يكون لديك أشخاص يهتمون بالتخزين
‫، وغالبًا ما يكون تخزين تابع لجهة خارجية ، وهذا ليس نفس الفريق الذي يدير
‫Kubernetes.
‫سيكونون هم الذين يشاركون في إدارة وإنشاء
‫هذه المجلدات الثابتة.
‫بعد ذلك ، سيقول القائمون على نشر التطبيق
‫، أحتاج إلى وحدة
‫تخزين من هذا النوع. لذلك ، سأقوم بتقديم مطالبة
‫SSD أو قد نحتاج إلى تخزين RAM ، أو ربما أحتاج إلى NFS ، أو
‫أي شيء آخر. سيتم توفير هذا التخزين
‫تلقائيًا لأن فريق التخزين قام بإعداده بالفعل
‫في Kubernetes.
‫هذا نوع من الفكرة حول الأحجام الثابتة.
‫إذا كنت تحتاج فقط إلى بعض التخزين البسيط على خادم
‫واحد مؤقتًا للحجرة ، فما عليك سوى استخدام سمة وحدات التخزين
‫القياسية.
‫آخر شيء هنا هو إنشاء مكونات
‫إضافية لـ CSI. في محفوظات Kubernetes
‫، تمت إضافة أي شيء كان تخزينًا تابعًا لجهة
‫خارجية ، سواء كان تخزينًا سحابيًا أو تخزينًا
‫لمورد تابع لجهة خارجية ، أو أي شيء مخصص ، في الشجرة.
‫هذا يعني أنه تمت إضافته إلى ثنائيات Kubernetes
‫وشحنه مع Kubernetes.
‫هذا يعني أن Kubernetes جاء مع تخزين Amazon و
‫Azure الذي تم إنشاؤه فورًا.
‫كان ذلك مناسبًا جدًا ، لكنه أضاف الكثير
‫من التحديات.
‫كان معظمها مرتبطًا بحقيقة أن بائعي وحدات
‫التخزين كانوا يساهمون الآن برمز في جوهر نظامك ربما لم
‫تكن بحاجة إليه لأنك قد تستخدم بائع تخزين واحد فقط ، فلماذا
‫تمتلكهم جميعًا؟
‫أيضًا ، كان على بائعي التخزين التحكم في دورات الإصدار الخاصة
‫بهم حول دورة إصدار Kubernetes ، ولم يكن نموذجًا
‫مرنًا للغاية.
‫لذلك ، اجتمعت الصناعة معًا ، وكما
‫فعلت مع الشبكات ومع Dockerfiles والصور نفسها
‫، فقد أنشأت معيارًا. هذا المعيار هو CSI.
‫هذا يعني واجهة تخزين الحاوية.
‫سيوفر ذلك المكونات الإضافية الآن بحيث يمكن لأي بائع
‫تخزين إنشاء مكون إضافي تقوم بتثبيته على جميع
‫العقد ، وسيكون ذلك مختلفًا بناءً على المكون
‫الإضافي وتعليماته.
‫بعد ذلك ، سيعملون على واجهة برمجة تطبيقات قياسية توفرها CSI بحيث
‫يمكن لأي من حاوياتك استخدام هذا المكون
‫الإضافي للوصول إلى وحدات التخزين الخاصة بهم.
‫هذا نموذج أفضل بكثير وأكثر مرونة.
‫هذا نوع من مستقبل Kubernetes ، لكنه
‫لا يزال جديدًا جدًا. في كثير من الأحيان في الأمثلة ، وحتى
‫بائعي وحدات التخزين لديك قد يوصون ، بناءً على نضج CSI
‫، باستخدام المكون الإضافي التقليدي الخاص بهم ، والذي تم تضمينه
‫في Kubernetes وخرج من الصندوق.