خيارات التخزين للتطبيقات في خدمة Azure Kubernetes (AKS)

قد تحتاج التطبيقات التي تعمل في خدمة Azure Kubernetes (AKS) إلى تخزين البيانات واستردادها. في حين أن بعض أحمال عمل التطبيقات يمكن أن تستخدم تخزينًا محليًا وسريعًا على عقد غير ضرورية ومفرغة، يتطلب البعض الآخر تخزينًا يستمر على وحدات تخزين بيانات أكثر انتظامًا داخل نظام Azure الأساسي.

قد تحتاج الحاويات المتعددة إلى:

• مشاركة نفس أحجام البيانات.
• أعد إرفاق وحدات تخزين البيانات إذا تمت إعادة جدولة الكبسولة على عقدة مختلفة.

قد تحتاج أيضا إلى جمع وتخزين البيانات الحساسة أو معلومات تكوين التطبيق في pods.

تقدم هذه المقالة المفاهيم الأساسية التي توفر التخزين لتطبيقاتك في AKS:

• وحدات التخزين
• وحدات التخزين الثابتة
• فئات التخزين
• مطالبات الحجم المستمرة

تغيير حجم قرص نظام التشغيل الافتراضي في AKS

أقراص نظام التشغيل الزائل

إذا اخترت وحدة تخزين لجهاز افتراضي (VM) تدعم أقراص نظام التشغيل المؤقتة دون تحديد حجم قرص نظام التشغيل، فإن AKS يوفر افتراضيا قرص نظام تشغيل Ephemeral بحجم يتدرج وفقا لإجمالي التخزين المؤقتة للوحدة الافتراضية طالما أن درجة الحرارة لا تقل عن 128 جيجابايت. على سبيل المثال، Standard_D8ds_v5 وحدة تخزين التخزين التي يبلغ حجم قرص مؤقتة 300 جيجابايت تستقبل قرص نظام تشغيل مؤقت بسعة 300 جيجابايت افتراضيا إذا لم تكن معلمات القرص محددة.

إذا كنت ترغب في استخدام التخزين المؤقت ل VM SKU، تحتاج إلى تحديد حجم قرص نظام التشغيل أثناء النشر، وإلا يتم استهلاكه بشكل افتراضي.

هام

يتم استخدام تغيير حجم قرص نظام التشغيل المؤقت الافتراضي فقط على مجموعات جديدة أو تجمعات عقدة حيث يتم دعم أقراص نظام التشغيل المؤقتة ولا يتم تحديد حجم قرص نظام التشغيل الافتراضي. قد يؤثر حجم قرص نظام التشغيل الافتراضي على أداء نظام المجموعة أو تكلفته. لا يمكنك تغيير حجم قرص نظام التشغيل بعد إنشاء المجموعة أو تجمع العقدة. يؤثر هذا التحجيم المؤقت الافتراضي على المجموعات أو تجمعات العقد التي تم إنشاؤها في مارس 2025 أو أحدث.

أقراص نظام التشغيل المدارة

عندما تنشئ عنقودا جديدا أو تضيف مجموعة عقد جديدة إلى عنقود موجود، يحدد رقم وحدات vCPU حجم قرص نظام التشغيل بشكل افتراضي. يعتمد عدد وحدات vCPUs على VM SKU. يسرد الجدول التالي حجم قرص نظام التشغيل الافتراضي لكل وحدة SKU للجهاز الظاهري:

أنوية وحدة معالجة المفاتيح الافتراضية (vCPUs)	طبقة قرص نظام التشغيل الافتراضية	IOPS المتوفر	معدل النقل المقدم (Mbps)
1 - 7	P10/128G	500	100
8 - 15	P15/256G	1100	125
16 - 63	P20/512G	2300	150
64+	P30/1024G	5000	200

هام

يتم استخدام تغيير حجم قرص نظام التشغيل المدار الافتراضي فقط على مجموعات أو تجمعات عقد جديدة عندما لا يتم دعم أقراص نظام التشغيل المؤقتة ولا يتم تحديد حجم قرص نظام التشغيل الافتراضي. قد يؤثر حجم قرص نظام التشغيل الافتراضي على أداء نظام المجموعة أو تكلفته. لا يمكنك تغيير حجم قرص نظام التشغيل بعد إنشاء المجموعة أو تجمع العقدة. نوصي بحجم قرص لا يقل عن 512 جيجابايت إذا لم يكن بالإمكان استخدام أقراص نظام التشغيل المؤقت. يؤثر هذا الحجم الافتراضي المدار على العناقيد أو مجموعات العقد التي تم إنشاؤها في يوليو 2022 أو بعده.

أقراص نظام التشغيل سريعة الزوال في AKS

بشكل افتراضي، يقوم Azure تلقائيا بنسخ قرص نظام التشغيل لجهاز ظاهري إلى تخزين Azure لتجنب فقدان البيانات عند نقل الجهاز الظاهري إلى مضيف آخر. ومع ذلك، نظرا لأن الحاويات غير مصممة لتستمر الحالة المحلية، يوفر هذا السلوك قيمة محدودة مع توفير بعض العيوب. تتضمن هذه العيوب، على سبيل المثال لا الحصر، توفير عقدة أبطأ وزمن انتقال أعلى للقراءة/الكتابة.

على النقيض من ذلك ، يتم تخزين أقراص نظام التشغيل سريع الزوال فقط على الجهاز المضيف ، تماما مثل القرص المؤقت. باستخدام هذا التكوين، يمكنك الحصول على زمن انتقال أقل للقراءة/الكتابة مع تحجيم العقدة وترقيات نظام المجموعة بشكل أسرع. لذلك ، نوصي بشدة باستخدام أقراص نظام التشغيل سريع الزوال كلما أمكن ذلك.

إشعار

عندما لا تطلب صراحة أقراص Azure المدارة لنظام التشغيل، يتم تعيين AKS افتراضيا على نظام التشغيل المؤقت إذا كان ذلك ممكنا لتكوين تجمع عقدة معين.

يمكنك العثور على متطلبات الحجم والتوصيات لأقراص نظام التشغيل المؤقتة في وثائق Azure VM. ضع في اعتبارك الاعتبارات التالية عند استخدام أقراص نظام التشغيل المؤقتة:

الجيل الأخير من سلسلة VM لا يحتوي على ذاكرة تخزين مؤقتة مخصصة، فقط تخزين مؤقت. على سبيل المثال، إذا اخترت حجم Standard_E2bds_v5 جهاز افتراضي مع حجم قرص نظام التشغيل الافتراضي 100 جيجابايت، فإنه يدعم أقراص نظام التشغيل المؤقتة، لكنه يحتوي فقط على 75 جيجابايت من التخزين المؤقت. هذا التكوين يفرض بشكل افتراضي على أقراص نظام التشغيل المدارة إذا لم تحدده صراحة. إذا طلبت قرص نظام تشغيل سريع الزوال، فستتلقى خطأ في التحقق من الصحة.

• إذا طلبت نفس حجم Standard_E2bds_v5 جهاز افتراضي مع قرص نظام تشغيل بسعة 60 جيجابايت، فإن هذا التكوين يفرض بشكل افتراضي أقراص نظام التشغيل المؤقتة. الحجم المطلوب وهو 60 جيبي بايت أصغر من الحد الأقصى للتخزين المؤقت وهو 75 جيبي بايت.
• إذا اخترت وحدة تخزين Standard_E4bds_v5 مع قرص OS بسعة 100 جيجابايت، فإن حجم هذه الآلة الافتراضية يدعم نظام التشغيل المؤقت، ويحتوي على 150 جيجابايت من التخزين المؤقت. إذا لم تحدد نوع قرص نظام التشغيل، يقوم Azure بتوفير قرص نظام تشغيل مؤقت إلى مجموعة العقد بشكل افتراضي.

الجيل السابق من الأجهزة الافتراضية والأحجام المتقاعدة تحتوي على مساحة ذاكرة تخزين مؤقت مخصصة بالإضافة إلى مساحة القرص المؤقت. ومع ذلك، يستخدم مساحة قرص الذاكرة المؤقتة عند تقييم الوضع المؤقت، بدلا من التخزين المؤقت.

المفاتيح التي يديرها العميل

يمكنك إدارة التشفير لقرص نظام التشغيل المؤقت باستخدام المفاتيح الخاصة بك على نظام مجموعة AKS. لمزيد من المعلومات، راجع استخدام المفتاح المدار بواسطة العميل مع قرص Azure على AKS.

أقراص بيانات NVMe سريعة الزوال

توفر أقراص بيانات NVMe سريعة الزوال تخزينا عالي الأداء وزمن انتقال منخفض متصلة مباشرة بالمضيف الفعلي لجهاز Azure الظاهري. هذه الأقراص مثالية لأحمال العمل التي تتطلب تخزينا سريعا ومؤقتا (تخزين غير مستمر ومرفق بالمضيف يتم فقدانه إذا تم إلغاء تخصيص الجهاز الظاهري) لمعالجة البيانات الوسيطة، مثل التخزين المؤقت أو مساحة الصفر أو التحليلات عالية الإنتاجية.

كانت أقراص بيانات NVMe سريعة الزوال متوفرة في البداية فقط على أجهزة Azure VM L-series وE-series وGPU الظاهرية. مع تقديم أجيال Azure VM v6 وv7، توسع دعم أقراص بيانات NVMe المؤقتة ليشمل مجموعة أوسع من أحجام الآلات الافتراضية، بما في ذلك سلسلة D، سلسلة F، سلسلة H، والمزيد. توفر أقراص NVMe عمليات IOPS ومعدل نقل بيانات أعلى مقارنة بخيارات الأقراص الصلبة التقليدية أو SSD. ومع ذلك، فإن البيانات المخزنة على هذه الأقراص مؤقتة وسيتم فقدها إذا تم إلغاء تخصيص الجهاز الظاهري أو إعادة نشره.

لتبسيط إدارة وتوفير أقراص بيانات NVMe سريعة الزوال في AKS، استخدم Azure Container Storage. يمكن ل Azure Container Storage اكتشاف أقراص بيانات NVMe وتنسيقها تلقائيا، مما يسمح لك بإنشاء وحدات تخزين ثابتة وإدارتها لأحمال عمل Kubernetes بأقل قدر من التكوين. يوصى بهذا الأسلوب للسيناريوهات التي تتطلب تخزينا مؤقتا عالي الأداء، مثل:

• طبقات التخزين المؤقت عالية السرعة ، مثل مجموعات البيانات ونقاط التفتيش للتدريب على الذكاء الاصطناعي ، أو ملفات النماذج المستخدمة لاستدلال الذكاء الاصطناعي
• قواعد بيانات عالية الأداء ومستضافة ذاتيا تتضمن ميزات النسخ المتماثل والنسخ الاحتياطي المضمنة
• التحليلات كثيفة البيانات ومسارات المعالجة التي تتطلب تخزينا سريعا ومؤقتا
• مساحة خدش مؤقتة للمهام الدفعية

هام

أقراص بيانات NVMe المؤقتة غير مناسبة لتخزين البيانات الحرجة أو الدائمة. تأكد من أن تطبيقك يمكنه تحمل فقدان البيانات وتخزين البيانات المهمة على وحدات تخزين ثابتة مدعومة بقرص Azure أو ملفات Azure أو خيارات تخزين دائمة أخرى.

لمزيد من المعلومات حول استخدام Azure Container Storage مع أقراص بيانات NVMe سريعة الزوال، راجع استخدام Azure Container Storage مع AKS.

الأحجام

عادةً ما تتعامل Kubernetes مع القرون الفردية باعتبارها موارد سريعة الزوال يمكن التخلص منها. التطبيقات لها طرق مختلفة متاحة لهم لاستخدام واستمرار البيانات. تمثل وحدة التخزين طريقة لتخزين واسترداد البيانات واستردادها والحفاظ عليها عبر الحجيرات خلال دورة حياة التطبيق.

يتم إنشاء وحدات التخزين التقليدية كموارد Kubernetes مدعومة بواسطة تخزين Azure. يمكنك إنشاء وحدات تخزين البيانات يدويا لتعيينها إلى pods مباشرة أو أن تقوم Kubernetes بإنشائها تلقائيا. يمكن أن تستخدم وحدات تخزين البيانات: Azure Disk أو ملفات Azure أو ملفات Azure NetApp أو Azure Blobs.

إشعار

اعتمادا على VM SKU الذي تستخدمه، قد يكون لبرنامج تشغيل Azure Disk CSI حد وحدة تخزين لكل عقدة. بالنسبة لبعض الأجهزة الظاهرية عالية الأداء (على سبيل المثال، 16 ذاكرة أساسية)، الحد هو 64 وحدة تخزين لكل عقدة. لتحديد الحد لكل وحدة SKU للجهاز الظاهري، راجع عمود Max data disks لكل وحدة SKU VM معروضة. للحصول على قائمة بوحدات SKU للأجهزة الظاهرية المقدمة وحدود السعة التفصيلية المقابلة لها، راجع أحجام الجهاز الظاهري للأغراض العامة.

للمساعدة في تحديد الأنسب لحمل العمل الخاص بك بين ملفات Azure وملفات Azure NetApp، راجع المعلومات المقدمة في المقالة ملفات Azure ومقارنة ملفات Azure NetApp.

قرص Azure

استخدم قرص Azure لإنشاء مورد Kubernetes DataDisk . تتضمن أنواع الأقراص ما يلي:

• Premium SSDs (مستحسن لمعظم أحمال العمل)
• Ultra Disks
• محركات الأقراص الثابتة القياسية (Standard SSDs)
• محركات الأقراص الصلبة القياسية (Standard HDDs)

تلميح

بالنسبة لمعظم أحمال عمل الإنتاج والتطوير، استخدم Premium SSDs.

نظرا لأنه يتم تحميل قرص Azure على أنه ReadWriteOnce، فهو متاح فقط لعقدة واحدة. بالنسبة إلى وحدات التخزين التي يمكن الوصول إليها بواسطة pods على عقد متعددة في وقت واحد، استخدم ملفات Azure.

ملفات Azure

استخدم ملفات Azure لتحميل مشاركة Server Message Block (SMB) الإصدار 3.1.1 أو مشاركة نظام ملفات الشبكة (NFS) الإصدار 4.1. تتيح لك ملفات Azure مشاركة البيانات عبر عقد وقرون متعددة ويمكنها استخدام:

• تخزين Azure Premium، المدعوم بمحركات أقراص صلبة عالية الأداء
• تخزين Azure Standard، مدعوم بمحركات أقراص ثابتة عادية

ملفات Azure NetApp

استخدم ملفات Azure NetApp لتوفير وحدات تخزين NFS أو SMB عالية الأداء لأحمال عمل AKS. اختر من بين خمسة مستويات خدمة استنادا إلى متطلبات معدل النقل والأداء لحمل العمل الخاص بك:

• التخزين المرن (معاينة)
• التخزين المرن
• تخزين Standard
• تخزين متميز
• تخزين Ultra

مساحة تخزين Azure Blob

استخدم مساحة تخزين Azure Blob لإنشاء حاوية تخزين blob وإدخالها باستخدام بروتوكول NFS v3.0 أو BlobFuse.

أنواع الأحجام

تمثل مجلدات Kubernetes أكثر من مجرد قرص تقليدي لتخزين المعلومات واسترجاعها. يمكن أيضا استخدام وحدات تخزين Kubernetes كطريقة لإدخال البيانات في حاوية لاستخدامها من قبل حاوياتها.

تشمل أنواع الأحجام الشائعة في Kubernetes ما يلي:

emptyDir

يشيع استخدامها كمساحة مؤقتة لحجرة. يمكن لجميع الحاويات الموجودة داخل الكبسولة الوصول إلى البيانات الموجودة على وحدة التخزين. تستمر البيانات المكتوبة إلى هذا النوع من المجلد فقط طوال عمر الكبسولة. بمجرد حذف الحجيرة، يتم حذف وحدة التخزين. يستخدم هذا الحجم عادةً تخزين قرص العقدة المحلي الأساسي، على الرغم من أنه يمكن أن يوجد أيضًا في ذاكرة العقدة فقط.

سري

يمكنك استخدام وحدات التخزين السرية لإدخال البيانات الحساسة في البودات، مثل كلمات المرور.

1. إنشاء سر باستخدام واجهة برمجة تطبيقات Kubernetes.
2. حدد الجراب أو النشر الخاص بك واطلب سرا محددا.
   • يتم توفير البيانات السرية فقط للعقد ذات الجراب المجدول الذي يحتاجها.
   • يتم تخزين السر في tmpfs، وليس مكتوبا على القرص.
3. عند حذف آخر جراب على عقدة تتطلب بيانات سرية، يتم حذف السر من tmpfs للعقدة.
   • يتم تخزين الأسرار داخل مساحة اسم معينة ويتم الوصول إليها فقط بواسطة pods داخل نفس مساحة الاسم.

configMap

يمكنك استخدام configMap لإدخال خصائص زوج قيم المفاتيح والقيمة في وحدات الجراب، مثل معلومات تكوين التطبيق. حدد معلومات تكوين التطبيق كمورد Kubernetes، يمكن تحديثه بسهولة وتطبيقه على الطبعات الجديدة من البودات في توزيع.

مثل استخدام بيانات سرية:

1. إنشاء ConfigMap باستخدام Kubernetes API.
2. طلب ConfigMap عند تحديد جهاز أو توزيع.
   • يتم تخزين ConfigMaps داخل مساحة اسم معينة ويتم الوصول إليها فقط بواسطة pods داخل نفس مساحة الاسم.

وحدات تخزين دائمة.

الكميات التي تم تحديدها وإنشاؤها كجزء من دورة حياة الكبسولة موجودة فقط حتى تقوم بحذف الكبسولة. غالبا ما تتوقع الحجيرات استمرار مركز تخزينها إذا تم إعادة جدولتها لمضيف مختلف أثناء حدث الصيانة، خاصة في “StatefulSets”. وحدة التخزين الدائمة (PV) هي مورد تخزين تم إنشاؤه وإدارته بواسطة واجهة برمجة تطبيقات Kubernetes التي يمكن أن تستمر بعد مدة بقاء حجيرة فردية.

يمكنك استخدام خدمات تخزين Azure التالية لتوفير وحدة التخزين الدائمة:

• قرص Azure
• ملفات Azure
• تخزين حاويات Azure

كما هو ملاحظ في قسم وحدات التخزين، يعتمد الاختيار بين الأقراص Azure ملفات Azure عادة على الحاجة إلى الوصول المتزامن (يدعم ملفات Azure عقدا متعددة في وقت واحد؛ يدعم Azure Disk عقدة واحدة فقط) أو مستوى الأداء المطلوب.

يمكن لمسؤول نظام المجموعة إنشاء وحدة تخزين ثابتة بشكل ثابت، أو يمكن إنشاء وحدة تخزين ديناميكيا بواسطة خادم Kubernetes API. إذا تم جدولة جراب وطلب تخزين غير متوفر حاليا، يمكن ل Kubernetes إنشاء قرص Azure الأساسي أو تخزين الملف وإرفاقه بالجراب. يستخدم التوفير الديناميكي فئة تخزين لتحديد نوع المورد الذي يجب إنشاؤه.

هام

لا يمكن مشاركة وحدات التخزين الثابتة من قبل Windows وLinux pods بسبب الاختلافات في دعم نظام الملفات بين نظامي التشغيل.

إذا كنت تريد حلا مدارا بالكامل للوصول إلى البيانات على مستوى الكتلة، ففكر في استخدام Azure Container Storage. يتكامل Azure Container Storage مع Kubernetes، بحيث يمكنك توفير وحدات تخزين ثابتة ديناميكيا وتلقويا. يعتمد تخزين الدعم المدعوم على الإصدار الرئيسي. يدعم Azure Container Storage الإصدار 2 أقراص NVMe المحلية Azure Elastic SAN. يدعم الإصدار 1 Azure الأقراص والأقراص المؤقتة (NVMe المحلي وSSD المؤقت) Azure Elastic SAN.

فئات التخزين.

لتحديد مستويات مختلفة من التخزين، مثل متميزة أو قياسية ، يمكنك إنشاء فئة تخزين.

تحدد فئة التخزين أيضا نهج الاسترداد. عند حذف وحدة التخزين الثابتة، يتحكم نهج الاسترداد في سلوك مورد تخزين Azure الأساسي. يمكن حذف المورد الأساسي أو الاحتفاظ به للاستخدام مع جراب مستقبلي.

بالنسبة للمجموعات التي تستخدم Azure Container Storage، تعتمد فئات التخزين على الإصدار الرئيسي والتخزين المدعوم. يستخدم local-csi الإصدار 2 لأقراص NVMe المحلية ول azuresan-csi Azure Elastic SAN. ينشئ الإصدار 1 فئة تخزين تسمى acstor-<storage-pool-name> وفئة تخزين داخلية.

بالنسبة للمجموعات التي تستخدم برامج تشغيل واجهة تخزين الحاوية (CSI)، يتم إنشاء فئات التخزين الإضافية التالية:

فئة التخزين	‏‏الوصف
managed-csi	يستخدم تخزين Azure Standard SSD المكرر محليا (LRS) لإنشاء قرص مدار. تضمن سياسة الاستردام حذف قرص Azure الأساسي عند حذف المجلد الدائم المستخدم. تقوم فئة التخزين أيضا بتكوين وحدات التخزين الثابتة لتكون قابلة للتوسيع. يمكنك تحرير مطالبة وحدة التخزين الثابتة لتحديد الحجم الجديد. بدءا من الإصدار 1.29 من Kubernetes، في مجموعات خدمة Azure Kubernetes ‏(AKS) الموزعة عبر مناطق توفر متعددة، تستخدم فئة التخزين هذه التخزين المتكرر لمنطقة Azure Standard SSD (ZRS) لإنشاء أقراص مدارة.
managed-csi-premium	يستخدم Azure Premium التخزين المتكرر محليا (LRS) لإنشاء قرص مدار. تضمن سياسة الاستردام مرة أخرى حذف Azure Disk الأساسي عند حذف المحجم الدائم المستخدم. وبالمثل، تسمح فئة التخزين هذه بتوسيع الأحجام الثابتة. بدءا من الإصدار 1.29 من Kubernetes، في مجموعات خدمة Azure Kubernetes ‏(AKS) المنتشرة عبر مناطق توفر متعددة، تستخدم فئة التخزين هذه التخزين المتكرر في منطقة Azure Premium (ZRS) لإنشاء أقراص مدارة.
managed-csi-premium-v2	يستخدم Azure Premium SSD v2 للتخزين المحلي الزائد (LRS) لإنشاء قرص مدار. تضمن سياسة الاستردام مرة أخرى حذف Azure Disk الأساسي عند حذف المحجم الدائم المستخدم. تتوفر هذه الفئة من التخزين بدءا من الإصدار 1.35 من Kubernetes.
azurefile-csi	يستخدم تخزين Azure Standard لإنشاء مشاركة ملف Azure. تضمن سياسة الاسترجاع حذف مشاركة ملف Azure الأساسية عند حذف المجلد الدائم المستخدم.
azurefile-csi-premium	يستخدم تخزين Azure Premium لإنشاء مشاركة ملف Azure. تضمن سياسة الاسترجاع حذف مشاركة ملف Azure الأساسية عند حذف المجلد الدائم المستخدم.
azureblob-nfs-premium	يستخدم تخزين Azure Premium لإنشاء حاوية تخزين Azure Blob والاتصال باستخدام بروتوكول NFS v3. تضمن سياسة الاستردام حذف حاوية تخزين Azure Blob الأساسية عند حذف المحجم الدائم المستخدم.
azureblob-fuse-premium	يستخدم تخزين Azure Premium لإنشاء حاوية تخزين Azure Blob والاتصال باستخدام BlobFuse. تضمن سياسة الاستردام حذف حاوية تخزين Azure Blob الأساسية عند حذف المحجم الدائم المستخدم.

ما لم تحدد فئة تخزين لوحدات تخزين ثابتة، يتم استخدام فئة التخزين الافتراضية. تأكد من استخدام الأحجام للتخزين المناسب الذي تحتاجه عند طلب وحدات تخزين ثابتة.

هام

بدءا من Kubernetes الإصدار 1.21، تستخدم AKS برامج تشغيل CSI بشكل افتراضي، ويتم تمكين ترحيل CSI. بينما تستمر المجلدات الدائمة الموجودة في الشجرة في العمل، بدءا من الإصدار 1.26، لن تدعم AKS بعد الآن الأحجام التي يتم إنشاؤها باستخدام برنامج تشغيل وتخزين مدمج للملفات والأقراص.

default ستكون الفئة هي نفسها managed-csi.

بدءا من الإصدار 1.29 من Kubernetes، عند نشر مجموعات خدمة Azure Kubernetes ‏(AKS) عبر مناطق توفر متعددة، تستخدم AKS الآن التخزين المتكرر للمنطقة (ZRS) لإنشاء أقراص مدارة ضمن فئات التخزين المضمنة. يضمن ZRS النسخ المتماثل المتزامن للأقراص المدارة من Azure عبر مناطق توفر Azure المتعددة في المنطقة التي اخترتها. تعزز استراتيجية التكرار هذه مرونة تطبيقاتك وتحمي بياناتك من فشل مركز البيانات.

ومع ذلك، من المهم ملاحظة أن التخزين المتكرر في المنطقة (ZRS) يأتي بتكلفة أعلى مقارنة بالتخزين الزائد محليا (LRS). إذا كان تحسين التكلفة أولوية، يمكنك إنشاء فئة تخزين جديدة مع تعيين المعلمة skuname إلى LRS. يمكنك بعد ذلك استخدام فئة التخزين الجديدة في مطالبة وحدة التخزين الثابتة (PVC).

يمكنك إنشاء فئة تخزين لاحتياجات أخرى باستخدام kubectl. يستخدم المثال التالي أقراصا مدارة متميزة ويحدد أنه يجب الاحتفاظ Azure Disk الأساسي عند حذف مطالبة وحدة التخزين الثابتة:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: managed-premium-retain
provisioner: disk.csi.azure.com
parameters:
  skuName: Premium_ZRS
reclaimPolicy: Retain
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true

يستخدم disk.csi.azure.com هذا البيان كموفر Azure Disk CSI و Premium_ZRS كموفر skuName Premium SSD متكرر في المنطقة. Retain يحافظ نهج الاسترداد على القرص الأساسي بعد حذف مطالبة وحدة التخزين الدائمة الخاصة به، ويؤخر WaitForFirstConsumer ربط وحدة التخزين وتوفيرها حتى يتم إنشاء جراب يستخدم المطالبة بحيث يتم توفير القرص وفقا لقيود الجدولة الخاصة بالجراب.

إشعار

يوفق AKS بين فئات التخزين الافتراضية وسيحل محل أي تغييرات تجريها على فئات التخزين هذه.

لمزيد من المعلومات حول فئات التخزين، راجع StorageClass في Kubernetes.

المطالبة بوحدات التخزين الدائمة.

تطلب مطالبة وحدة التخزين الدائمة (PVC) تخزين فئة تخزين معينة ووضع الوصول وحجمها. يمكن لخادم Kubernetes API توفير مورد تخزين Azure الأساسي ديناميكيا إذا لم يتمكن أي مورد موجود من تلبية المطالبة استنادا إلى فئة التخزين المحددة.

يتضمن تعريف الحجيرة تحميل وحدة التخزين بمجرد توصيل وحدة التخزين إلى حجيرة.

بمجرد تعيين مورد تخزين متوفر إلى الجراب الذي يطلب التخزين، يتم ربط وحدة التخزين الدائمة بمطالبة وحدة تخزين ثابتة. يتم تعيين وحدات التخزين الدائمة إلى المطالبات في تعيين 1:1.

المثال التالي يظهر بيان YAML ادعاء حجم مستمر يستخدم فئة التخزين managed-premium-retain ويطلب قرص Azure بحجم 5 Gi:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: azure-managed-disk
spec:
  accessModes:
  - ReadWriteOnce
  storageClassName: managed-premium-retain
  resources:
    requests:
      storage: 5Gi

تستخدم هذه المطالبة ReadWriteOnce وضع الوصول، الذي يسمح بتحميل وحدة التخزين للقراءة والكتابة بواسطة عقدة واحدة في كل مرة، وتعيين storage الطلب إلى 5Gi (5 غيغابايت) كحجم مثال. storage اضبط القيمة لمطابقة متطلبات حمل العمل.

عندما تنشئ تعريف جهاز، فإنك تحدد أيضًا:

• المطالبة بالحجم الثابت لطلب التخزين المطلوب.
• تحميل وحدة التخزين لتطبيقاتك لقراءة البيانات وكتابتها.

يوضح المثال التالي بيان YAML كيف يمكن استخدام مطالبة وحدة التخزين الثابتة السابقة لإدخال وحدة تخزين على / mnt / azure :

kind: Pod
apiVersion: v1
metadata:
  name: nginx
spec:
  containers:
    - name: myfrontend
      image: mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine
      volumeMounts:
      - mountPath: "/mnt/azure"
        name: volume
  volumes:
    - name: volume
      persistentVolumeClaim:
        claimName: azure-managed-disk

لتركيب وحدة تخزين في حاوية Windows، حدد حرف محرك الأقراص والمسار. على سبيل المثال:

...      
      volumeMounts:
      - mountPath: "d:"
        name: volume
      - mountPath: 'c:\k'
        name: k-dir
...

الخطوات التالية

للحصول على أفضل الممارسات المرتبطة، راجع أفضل الممارسات للتخزين والنسخ الاحتياطية في اعتبارات تخزين AKS وAKS.

لمزيد من المعلومات حول Azure Container Storage، راجع المقالات التالية:

• ما هو Azure Container Storage؟
• استخدام Azure Container Storage مع AKS

لمزيد من المعلومات حول استخدام برامج تشغيل CSI، راجع المقالات التالية:

• برامج تشغيل واجهة تخزين الحاويات (CSI) لقرص Azure وملفات Azure وتخزين Azure Blob على خدمة Azure Kubernetes
• استخدام برنامج تشغيل Azure Disk CSI في خدمة Azure Kubernetes
• استخدام برنامج تشغيل ملفات Azure CSI في Azure Kubernetes Service
• استخدام برنامج تشغيل CSI لتخزين Azure Blob في خدمة Azure Kubernetes
• تكوين ملفات Azure NetApp باستخدام Azure Kubernetes Service

لمزيد من المعلومات حول مفاهيم Kubernetes وAKS الأساسية، راجع المقالات التالية:

• مجموعات Kubernetes / AKS وأعباء العمل
• هوية Kubernetes / AKS
• أمن Kubernetes / AKS
• شبكات Kubernetes / AKS الظاهرية
• تغيير السعة في Kubernetes / AKS