استخدام برنامج تشغيل Azure Disk Container Storage Interface (CSI) في خدمة Azure Kubernetes (AKS)
برنامج تشغيل Azure Disks Container Storage Interface (CSI) هو برنامج تشغيل متوافق مع مواصفات CSI تستخدمه خدمة Azure Kubernetes (AKS) لإدارة دورة حياة قرص Azure.
منظمة التضامن المسيحي الدولية هو معيار لفضح كتلة التعسفي وأنظمة تخزين الملفات لأعباء العمل في حاويات على Kubernetes. من خلال اعتماد واستخدام CSI، يمكن لـ AKS الآن كتابة وتوزيع وتكرار المكونات الإضافية لكشف أنظمة التخزين الجديدة أو تحسين أنظمة التخزين الحالية في Kubernetes. يؤدي استخدام برامج تشغيل CSI في AKS إلى تجنب الاضطرار إلى لمس التعليمات البرمجية الأساسية لـ Kubernetes وانتظار دورات الإصدار الخاصة به.
لإنشاء مجموعة AKS مع دعم برنامج تشغيل CSI، راجع تمكين برنامج تشغيل CSI على AKS. توضح هذه المقالة كيفية استخدام الإصدار 1 من برنامج تشغيل Azure Disk CSI.
إشعار
يحسن برنامج تشغيل Azure Disk CSI الإصدار 2 (معاينة) من قابلية التوسع ويقلل من زمن انتقال تجاوز فشل الجراب. يستخدم الأقراص المشتركة لتوفير النسخ المتماثلة للمرفقات على عقد نظام المجموعة المتعددة ويدمج مع مجدول الجراب لضمان اختيار عقدة مع نسخة متماثلة لمرفق على تجاوز فشل الجراب. يوفر برنامج تشغيل Azure Disk CSI الإصدار 2 (معاينة) أيضا القدرة على ضبط الأداء. إذا كنت مهتماً بالمشاركة في المعاينة، فأرسل طلباً: https://aka.ms/DiskCSIv2Preview. يتم توفير إصدار المعاينة هذا بدون اتفاقية مستوى الخدمة، ويمكنك أحياناً توقع تغييرات عاجلة أثناء المعاينة. لا يُنصح بإصدار المعاينة لأحمال عمل الإنتاج. لمزيد من المعلومات، راجع شروط الاستخدام التكميلية لمعاينات Microsoft Azure.
إشعار
تشير برامج التشغيل في شجرة إلى برامج تشغيل التخزين الحالية التي هي جزء من تعليمة برمجية لـ Kubernetes أساسية مقابل برامج تشغيل CSI الجديدة، وهي مكونات إضافية.
ميزات برنامج تشغيل Azure Disk CSI
بالإضافة إلى ميزات برنامج التشغيل داخل الشجرة، يدعم برنامج تشغيل Azure Disk CSI الميزات التالية:
- تحسينات الأداء أثناء إرفاق القرص المتزامن وفصله
- تقوم برامج التشغيل داخل الشجرة بإرفاق أو فصل الأقراص بالتسلسل، بينما تقوم برامج تشغيل CSI بإرفاق أو فصل الأقراص دفعة واحدة. هناك تحسن كبير عند وجود أقراص متعددة متصلة بعقدة واحدة.
- يتم دعم Premium SSD v1 وv2.
PremiumV2_LRS
يدعمNone
وضع التخزين المؤقت فقط
- دعم قرص التخزين المتكرر في المنطقة (ZRS)
Premium_ZRS
،StandardSSD_ZRS
أنواع الأقراص مدعومة. يمكن جدولة قرص ZRS على عقدة المنطقة أو غير المنطقة، دون تقييد أن وحدة تخزين القرص يجب أن تكون في نفس المنطقة كعقدة معينة. لمزيد من المعلومات، بما في ذلك المناطق المدعومة، راجع التخزين المتكرر للمنطقة للأقراص المدارة.
- لقطه
- استنساخ حجم الصوت
- تغيير حجم القرص PV دون وقت تعطل
إشعار
اعتمادا على VM SKU الذي يتم استخدامه، قد يكون لبرنامج تشغيل Azure Disk CSI حد وحدة تخزين لكل عقدة. بالنسبة لبعض الأجهزة الظاهرية القوية (على سبيل المثال، 16 نواة)، الحد الأقصى هو 64 وحدة تخزين لكل عقدة. لتحديد الحد لكل وحدة SKU للجهاز الظاهري، راجع عمود Max data disks لكل وحدة SKU VM معروضة. للحصول على قائمة بوحدات SKU للأجهزة الظاهرية المقدمة وحدود السعة التفصيلية المقابلة لها، راجع أحجام الجهاز الظاهري للأغراض العامة.
استخدم وحدات التخزين الثابتة لـ CSI مع أقراص Azure
تمثل وحدة التخزين الثابتة (PV) قطعة تخزين يتم توفيرها للاستخدام مع قرون Kubernetes. يمكن استخدام PV من قبل واحد أو العديد من القرون ويمكن توفيرها ديناميكيا أو ثابتا. توضح لك هذه المقالة كيفية إنشاء PVs بشكل ديناميكي باستخدام قرص Azure للاستخدام بواسطة جراب واحد في مجموعة AKS. للتزويد الثابت، راجع إنشاء وحدة تخزين ثابتة باستخدام أقراص Azure.
لمزيد من المعلومات حول وحدات تخزين Kubernetes، راجع خيارات التخزين للتطبيقات في AKS .
قم بإنشاء Azure Disks PVs ديناميكيًا باستخدام فئات التخزين المضمنة
يتم استخدام فئة تخزين لتعريف كيفية إنشاء وحدة تخزين بشكل حيوي مع وحدة تخزين ثابتة. لمزيد من المعلومات حول فئات التخزين Kubernetes، راجع فئات تخزين Kubernetes .
عند استخدام برنامج تشغيل Azure Disk CSI على AKS، هناك اثنان إضافيان مضمنان StorageClasses
يستخدمان برنامج تشغيل تخزين Azure Disk CSI. يتم إنشاء فئات تخزين CSI الأخرى باستخدام الكتلة جنبًا إلى جنب مع فئات التخزين الافتراضية داخل الشجرة.
managed-csi
يستخدم Azure Standard SSD تخزين مكرر محليا (LRS) لإنشاء قرص مدار. بدءا من الإصدار 1.29 من Kubernetes، في مجموعات Azure Kubernetes Service (AKS) الموزعة عبر مناطق توفر متعددة، تستخدم فئة التخزين هذه التخزين المتكرر لمنطقة Azure Standard SSD (ZRS) لإنشاء أقراص مدارة.managed-csi-premium
: يستخدم Azure Premium LRS لإنشاء قرص مدار. بدءا من الإصدار 1.29 من Kubernetes، في مجموعات Azure Kubernetes Service (AKS) المنتشرة عبر مناطق توفر متعددة، تستخدم فئة التخزين هذه التخزين المتكرر في منطقة Azure Premium (ZRS) لإنشاء أقراص مدارة.
تضمن سياسة الاسترداد في كلا فئتي التخزين حذف أقراص Azure الأساسية عند حذف PV ذات الصلة. فئات التخزين أيضا تكوين أجهزة التلفاز لتكون قابلة للتوسيع. تحتاج فقط إلى تحرير المطالبة حجم المستمر (PVC) مع حجم جديد.
لاستخدام فئات التخزين هذه، قم بإنشاء PVC والحجرة الخاصة التي تشير إليها واستخدمها. يتم استخدام PVC لتوفير التخزين تلقائيا استنادا إلى فئة تخزين. يمكن استخدام PVC إحدى فئات التخزين التي تم إنشاؤها مسبقا أو فئة تخزين معرفة من قبل المستخدم لإنشاء قرص Azure المدارة SKU المطلوبة وحجم. عند إنشاء تعريف جراب، يتم تحديد PVC لطلب التخزين المطلوب.
أنشئ نموذجاً للحجرة وكلوريد متعدد الفينيل ذي الصلة عن طريق تشغيل الأمر kubectl apply :
kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/azuredisk-csi-driver/master/deploy/example/pvc-azuredisk-csi.yaml
kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/azuredisk-csi-driver/master/deploy/example/nginx-pod-azuredisk.yaml
إخراج الأمر يشبه المثال التالي:
persistentvolumeclaim/pvc-azuredisk created
pod/nginx-azuredisk created
بعد أن يكون البود في حالة التشغيل، قم بتشغيل الأمر التالي لإنشاء ملف جديد يسمى test.txt
.
kubectl exec nginx-azuredisk -- touch /mnt/azuredisk/test.txt
للتحقق من صحة تثبيت القرص بشكل صحيح، قم بتشغيل الأمر التالي وتحقق من رؤية الملف test.txt
في الإخراج:
kubectl exec nginx-azuredisk -- ls /mnt/azuredisk
lost+found
outfile
test.txt
إنشاء فئة تخزين مخصصة
فئات التخزين الافتراضية مناسبة لمعظم السيناريوهات الشائعة. بالنسبة لبعض الحالات، قد ترغب في تخصيص فئة التخزين الخاصة بك مع المعلمات الخاصة بك. على سبيل المثال، قد ترغب في تغيير فئة volumeBindingMode
.
يمكنك استخدام فئة volumeBindingMode: Immediate
تضمن حدوثها فور إنشاء PVC. عندما تكون تجمعات العقد الخاصة بك مقيدة التخطيط، على سبيل المثال عند استخدام مناطق التوفر، سيتم ربط PVs أو توفيرها دون معرفة متطلبات جدولة الجراب.
لمعالجة هذا السيناريو، يمكنك استخدام volumeBindingMode: WaitForFirstConsumer
، مما يؤخر الربط وتوفير PV حتى يتم إنشاء جراب يستخدم PVC. بهذه الطريقة، يتوافق PV ويتم توفيره في منطقة الإتاحة (أو طوبولوجيا أخرى) المحددة بواسطة قيود جدولة pod. تستخدم فئات التخزين الافتراضية volumeBindingMode: WaitForFirstConsumer
الفئة.
قم بإنشاء ملف باسم sc-azuredisk-csi-waitforfirstconsumer.yaml
، ثم الصق البيان التالي. فئة التخزين هي نفسها فئة التخزين managed-csi
، ولكن بفئة volumeBindingMode
مختلفة.
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
name: azuredisk-csi-waitforfirstconsumer
provisioner: disk.csi.azure.com
parameters:
skuname: StandardSSD_LRS
allowVolumeExpansion: true
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer
أنشئ فئة التخزين عن طريق تشغيل الأمر kubectl apply وحدد ملف sc-azuredisk-csi-waitforfirstconsumer.yaml
الخاص بك:
kubectl apply -f sc-azuredisk-csi-waitforfirstconsumer.yaml
إخراج الأمر يشبه المثال التالي:
storageclass.storage.k8s.io/azuredisk-csi-waitforfirstconsumer created
لقطات مستوى الصوت
يدعم برنامج تشغيل Azure Disk CSI إنشاء لقطات من وحدات التخزين الثابتة. كجزء من هذه الإمكانية، يمكن لبرنامج التشغيل تنفيذ لقطات كاملة أو تزايدية اعتمادا على القيمة المحددة في incremental
المعلمة (افتراضيا، يكون ذلك صحيحا).
يوفر الجدول التالي تفاصيل عن جميع المعلمات.
الاسم | المعنى | القيمة المتاحة | إلزامي | القيمة الافتراضية |
---|---|---|---|---|
resourceGroup | مجموعة الموارد لتخزين اللقطات | مجموعة الموارد الحالية | لا | إذا لم يتم تحديدها، فسيتم تخزين اللقطة في نفس مجموعة الموارد مثل أقراص Azure المصدر |
incremental | خذ لقطة كاملة أو متزايدة | true , false |
لا | true |
العلامات | علاماتأقراص Azure | تنسيق العلامة: 'key1 = val1، key2 = val2' | لا | "" |
userAgent | عامل المستخدم في إحالة استخدام العميل | لا | عامل مستخدم تم إنشاؤه بتنسيق driverName/driverVersion compiler/version (OS-ARCH) |
|
subscriptionID | حدد معرّف اشتراك Azure حيث سيتم إنشاء أقراص Azure | مُعرف اشتراكك في Azure | لا | إذا لم يكن فارغاً، يجب تقديم resourceGroup ، ويجب تعيين incremental على أنه false |
إنشاء لقطة وحدة تخزين
إشعار
قبل المتابعة، تأكد من أن التطبيق لا يكتب البيانات إلى القرص المصدر.
للحصول على مثال من هذه الإمكانية إنشاء فئة لقطة وحدة تخزين مع أمر تطبيق kubectl:
kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/azuredisk-csi-driver/master/deploy/example/snapshot/storageclass-azuredisk-snapshot.yaml
إخراج الأمر يشبه المثال التالي:
volumesnapshotclass.snapshot.storage.k8s.io/csi-azuredisk-vsc created
الآن دعونا إنشاء لقطة حجم من PVC التي أنشأناها ديناميكيا في بداية هذا البرنامج التعليمي،pvc-azuredisk
.
kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/azuredisk-csi-driver/master/deploy/example/snapshot/azuredisk-volume-snapshot.yaml
إخراج الأمر يشبه المثال التالي:
volumesnapshot.snapshot.storage.k8s.io/azuredisk-volume-snapshot created
للتحقق من إنشاء اللقطة بشكل صحيح، قم بتشغيل الأمر التالي:
kubectl describe volumesnapshot azuredisk-volume-snapshot
إخراج الأمر يشبه المثال التالي:
Name: azuredisk-volume-snapshot
Namespace: default
Labels: <none>
Annotations: API Version: snapshot.storage.k8s.io/v1
Kind: VolumeSnapshot
Metadata:
Creation Timestamp: 2020-08-27T05:27:58Z
Finalizers:
snapshot.storage.kubernetes.io/volumesnapshot-as-source-protection
snapshot.storage.kubernetes.io/volumesnapshot-bound-protection
Generation: 1
Resource Version: 714582
Self Link: /apis/snapshot.storage.k8s.io/v1/namespaces/default/volumesnapshots/azuredisk-volume-snapshot
UID: dd953ab5-6c24-42d4-ad4a-f33180e0ef87
Spec:
Source:
Persistent Volume Claim Name: pvc-azuredisk
Volume Snapshot Class Name: csi-azuredisk-vsc
Status:
Bound Volume Snapshot Content Name: snapcontent-dd953ab5-6c24-42d4-ad4a-f33180e0ef87
Creation Time: 2020-08-31T05:27:59Z
Ready To Use: true
Restore Size: 10Gi
Events: <none>
إنشاء PVC جديد استنادا إلى لقطة وحدة تخزين
يمكنك إنشاء PVC جديد استنادا إلى لقطة وحدة تخزين. استخدام لقطة تم إنشاؤها في الخطوة السابقة، وإنشاء PVC جديدةوبودة جديدة لاستهلاكه.
kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/azuredisk-csi-driver/master/deploy/example/snapshot/pvc-azuredisk-snapshot-restored.yaml
kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/azuredisk-csi-driver/master/deploy/example/snapshot/nginx-pod-restored-snapshot.yaml
إخراج الأمر يشبه المثال التالي:
persistentvolumeclaim/pvc-azuredisk-snapshot-restored created
pod/nginx-restored created
أخيرًا، دعنا نتأكد من أنه نفس PVC الذي تم إنشاؤه من قبل عن طريق التحقق من المحتويات عن طريق تشغيل الأمر التالي:
kubectl exec nginx-restored -- ls /mnt/azuredisk
إخراج الأمر يشبه المثال التالي:
lost+found
outfile
test.txt
كما هو متوقع، لا يزال بإمكاننا رؤية ملفنا الذي تم إنشاؤه test.txt
مسبقا.
وحدات تخزين النسخ
يتم تعريف وحدة التخزين المستنسخة على أنها نسخة مكررة من وحدة تخزين Kubernetes موجودة. لمزيد من المعلومات حول أحجام الاستنساخ في Kubernetes، راجع الوثائق المفاهيمية لاستنساخ المجلد.
يدعم برنامج تشغيل CSI لأقراص Azure استنساخ وحدة التخزين. لإظهار إنشاء وحدة تخزين مستنسخة من تم إنشاؤه مسبقا و جراب azuredisk-pvc
جديد لاستهلاكه.
kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/azuredisk-csi-driver/master/deploy/example/cloning/pvc-azuredisk-cloning.yaml
kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/azuredisk-csi-driver/master/deploy/example/cloning/nginx-pod-restored-cloning.yaml
إخراج الأمر يشبه المثال التالي:
persistentvolumeclaim/pvc-azuredisk-cloning created
pod/nginx-restored-cloning created
يمكنك التحقق من محتوى المجلد المنسوخ عن طريق تشغيل الأمر التالي والتأكد من إنشاء الملف test.txt
:
kubectl exec nginx-restored-cloning -- ls /mnt/azuredisk
إخراج الأمر يشبه المثال التالي:
lost+found
outfile
test.txt
تغيير حجم وحدة تخزين ثابتة دون وقت تعطل
يمكنك طلب حجم أكبر لـ PVC. تحرير الكائن PVC، وتحديد حجم أكبر. يؤدي هذا التغيير إلى توسيع وحدة التخزين الأساسية التي تدعم PV.
إشعار
لا يتم إنشاء PV جديدة لتلبية المطالبة. بدلا من ذلك، يتم حجم وحدة تخزين موجودة.
في AKS، تدعم فئة التخزين managed-csi
المدمجة التوسيع بالفعل، لذا استخدم PVC الذي تم إنشاؤه مسبقًا مع فئة التخزين هذه . طلب PVC حجم 10-Gi المستمر. يمكنك التأكيد عن طريق تشغيل الأمر التالي:
kubectl exec -it nginx-azuredisk -- df -h /mnt/azuredisk
إخراج الأمر يشبه المثال التالي:
Filesystem Size Used Avail Use% Mounted on
/dev/sdc 9.8G 42M 9.8G 1% /mnt/azuredisk
قم بتوسيع PVC عن طريق زيادة الحقل spec.resources.requests.storage
بتشغيل الأمر التالي:
kubectl patch pvc pvc-azuredisk --type merge --patch '{"spec": {"resources": {"requests": {"storage": "15Gi"}}}}'
إشعار
تقليص وحدات التخزين الثابتة غير مدعوم حاليا. تؤدي محاولة تصحيح PVC موجود بحجم أصغر من الحجم الحالي إلى ظهور رسالة الخطأ التالية: The persistentVolumeClaim "pvc-azuredisk" is invalid: spec.resources.requests.storage: Forbidden: field can not be less than previous value.
إخراج الأمر يشبه المثال التالي:
persistentvolumeclaim/pvc-azuredisk patched
قم بتشغيل الأمر التالي لتأكيد زيادة حجم وحدة التخزين:
kubectl get pv
إخراج الأمر يشبه المثال التالي:
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
pvc-391ea1a6-0191-4022-b915-c8dc4216174a 15Gi RWO Delete Bound default/pvc-azuredisk managed-csi 2d2h
(...)
وبعد بضع دقائق، قم بتشغيل الأوامر التالية لتأكيد حجم PVC:
kubectl get pvc pvc-azuredisk
إخراج الأمر يشبه المثال التالي:
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
pvc-azuredisk Bound pvc-391ea1a6-0191-4022-b915-c8dc4216174a 15Gi RWO managed-csi 2d2h
قم بتشغيل الأمر التالي لتأكيد حجم القرص داخل الجراب:
kubectl exec -it nginx-azuredisk -- df -h /mnt/azuredisk
إخراج الأمر يشبه المثال التالي:
Filesystem Size Used Avail Use% Mounted on
/dev/sdc 15G 46M 15G 1% /mnt/azuredisk
الاندفاع عند الطلب
يسمح نموذج اندفاع القرص عند الطلب بدفعات قرصية كلما تجاوزت احتياجاتها سعتها الحالية. يولد هذا النموذج رسومًا إضافية في أي وقت يندفع فيه القرص. الاندفاع عند الطلب متاح فقط لمحركات أقراص الحالة الصلبة المتميزة التي يزيد حجمها عن 512 غيغابايت. لمزيد من المعلومات بشأن IOPS المزودة بمحركات أقراص الحالة الصلبة (SSD) المتميزة ومعدل النقل لكل قرص، راجع حجم SSD المتميز. وبدلاً من ذلك، فإن الاندفاع المستند إلى الائتمان هو المكان الذي ينفجر فيه القرص فقط إذا كانت لديه أرصدة متفجرة متراكمة في دلو الائتمان الخاص به. لا ينتج عن الاندفاع المستند إلى الائتمان رسوم إضافية عند اندفاع القرص. الاندفاع المعتمد على الرصيد متاح فقط لمحركات SSD (محرك الأقراص ذو الحالة الصلبة) المتميزة بسعة 512 غيغابايت وأصغر، ومحركات SSD (محرك الأقراص ذو الحالة الصلبة) القياسية بحجم 1024 غيغابايت وأصغر. لمزيد من المعلومات حول الاندفاع عند الطلب، راجع الاندفاع عند الطلب.
هام
تم تعطيل الاندفاع عند الطلب لفئة التخزين الافتراضية managed-csi-premium
وتستخدم الاندفاع المستند إلى الائتمان. أي SSD مميز تم إنشاؤه ديناميكياً عن طريق مطالبة مستمرة بالحجم استناداً إلى فئة التخزين الافتراضية managed-csi-premium
يتم أيضاً تعطيل الاندفاع عند الطلب.
لإنشاء وحدة تخزين ثابتة SSD مميزة مع تمكين الاندفاع عند الطلب، يمكنك إنشاء فئة تخزين جديدة مع ضبط معلمة enableBursting على true
كما هو موضح في نموذج YAML التالي. لمزيد من المعلومات حول تمكين الاندفاع عند الطلب، راجع الاندفاع عند الطلب. لمزيد من المعلومات حول إنشاء فئة التخزين الخاصة بك مع تمكين الاندفاع عند الطلب، راجع إنشاء فئة تخزين CSI Premium المدارة القابلة للاندفاع.
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: burstable-managed-csi-premium
provisioner: disk.csi.azure.com
parameters:
skuname: Premium_LRS
enableBursting: "true"
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true
حاويات Windows
يدعم برنامج تشغيل Azure Disk CSI عقد وحاويات Windows. إذا كنت تريد استخدام حاويات Windows، فاتبع التشغيل السريع لحاويات Windows لإضافة تجمع عقدة Windows.
بعد أن يكون لديك تجمع عقدة Windows، يمكنك الآن استخدام فئات التخزين المضمنة مثل managed-csi
. يمكنك توزيع مثال مجموعة الحالة المستندة إلى Windows والتي تحفظ الطوابع الزمنية في الملف data.txt
عن طريق تشغيل الأمر التالي kubectl apply :
kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/azuredisk-csi-driver/master/deploy/example/windows/statefulset.yaml
إخراج الأمر يشبه المثال التالي:
statefulset.apps/busybox-azuredisk created
للتحقق من صحة محتوى المجلد، قم بتشغيل الأمر التالي:
kubectl exec -it busybox-azuredisk-0 -- cat c:\\mnt\\azuredisk\\data.txt # on Linux/MacOS Bash
kubectl exec -it busybox-azuredisk-0 -- cat c:\mnt\azuredisk\data.txt # on Windows Powershell/CMD
إخراج الأمر يشبه المثال التالي:
2020-08-27 08:13:41Z
2020-08-27 08:13:42Z
2020-08-27 08:13:44Z
(...)
الخطوات التالية
- لمعرفة كيفية استخدام برنامج تشغيل CSI لـ Azure Files، راجع استخدام Azure Files مع برنامج تشغيل CSI.
- لمعرفة كيفية استخدام برنامج تشغيل CSI لتخزين Azure Blob، راجع استخدام تخزين Azure Blob مع برنامج تشغيل جهاز CSI.
- لمزيد من المعلومات حول أفضل ممارسات التخزين، راجع أفضل الممارسات للتخزين والنسخ الاحتياطي في خدمة Azure Kubernetes.
- لمزيد من المعلومات حول حلول التخزين المستندة إلى القرص، راجع الحلول المستندة إلى القرص في AKS.
Azure Kubernetes Service