WIUNIX ACADEMY
PVC در Pending یا mount ناموفق؛ تشخیص مرحله‌های CSI در Kubernetes
صفحهٔ 3 از 3؛ قبل از ادامه، مراحل قبلی و چیزهایی رو که لازم داری مرور کن.
آموزش متناسب با محیط تو
کجا اجرا می‌کنی؟
سیستم‌عامل و نسخهٔ سرورت رو انتخاب کن تا مراحل، دستورها و راه‌حل‌های همون محیط رو ببینی.
آموزش متناسب با مقادیر تو
تنظیمات این آموزش
مقادیر نمونه رو با مشخصات سرورت عوض کن تا متن و دستورها با هم تغییر کنن. رمز، کلید خصوصی و توکن اینجا وارد نکن. مقدارها فقط توی همین زبانه می‌مونن و به سرور یا لینک اشتراک‌گذاری فرستاده نمی‌شن. قبل از اجرا، DNS، گواهی‌ها و تنظیمات دسترسی شبکه رو روی سرورت بررسی کن.
اگر آی‌پی، دامنه یا پورت‌های نمونه با سرورت فرق دارن، بخش تنظیمات پایین رو باز کن. مقدارها رو عوض کن و «اعمال در آموزش» رو بزن؛ بعد دستورهای تازه رو کپی کن.
تنظیم مقادیر برای محیط من9 مقدار قابل‌تغییر
قدم بعدی
attach رو از mount روی نود جدا کنیم
این فهرست اختیاری به مجوز دیدن VolumeAttachmentهای کل کلاستر نیاز داره. درخواست در صفحه‌های API خوانده می‌شه و فقط نتیجهٔ مربوط به PV انتخاب‌شده چاپ می‌شه؛ مجوزش محدود به namespace نیست. attacher و نود رو با محل پاد تطبیق بده و attached و خطای attach/detach رو بخون. اگر درایور به مرحلهٔ attach جداگانه نیاز نداره، نبود این شیء می‌تونه طبیعی باشه.
مقدار attached=true هنوز NodeStage/NodePublish، مجوز mount یا دسترسی برنامه رو ثابت نمی‌کنه. نام رخدادهای FailedAttachVolume، Multi-Attach و FailedMount به مرحله‌های متفاوت اشاره دارن؛ پیام کامل و زمان رو بخون. برای backend تک‌نویسنده، قبل از هر جابه‌جایی مطمئن شو writer قبلی واقعاً از مسیر مسئولش متوقف یا fenced شده. حذف attachment یا detach اجباری ممکنه دو writer بسازه و داده رو خراب کنه.
همان شل Bash مجاز روی میزبان مدیریت
k get volumeattachments.storage.k8s.io --chunk-size=100 -o jsonpath='{range .items[?(@.spec.source.persistentVolumeName=="example-volume")]}{.metadata.name}{"\t"}{.spec.attacher}{"\t"}{.spec.nodeName}{"\tattached="}{.status.attached}{"\n"}{.status.attachError.message}{"\n"}{.status.detachError.message}{"\n"}{end}'
k events -n 'apps' --for 'pod/example-app'attachment لازم به همین PV و نود وصل شده و از خطای mount یا برنامه تفکیک شده.
قدم بعدی
اختیاری: فقط لاگ بخش CSI شناسایی‌شده رو بخون
از مسئول ذخیره‌ساز بپرس کدام پاد کنترل‌کننده یا نود و کدام کانتینر به همین درایور و زمان شکست مربوطه. نام کشف‌شده رو وارد کن، اول نام کانتینر و image رو ببین و بعد فقط قسمت کوتاه اخیر لاگ رو بخواه. خطای ساخت حجم با provisioner پیگیری می‌شه، attach با attacher و NodeStage/Publish با افزونهٔ نود و kubelet.
خطای اختصاصی backend ممکنه آدرس یا شناسهٔ داخلی بده؛ این خروجی رو خصوصی نگه دار. مجوز ناکافی یا جزء مدیریت‌شده‌ای که نمی‌بینی باید به مسئولش برسه، نه اینکه پاد debug با دسترسی بالا بسازی، Secret بگیری یا همهٔ اجزای CSI رو ری‌استارت کنی. قبل از نتیجه‌گیری دربارهٔ قابلیت غایب، جدول سازگاری نسخهٔ همین درایور و sidecarها رو ببین.
همان شل Bash مجاز روی میزبان مدیریت
k get pod 'example-csi-controller' -n 'kube-system' -o jsonpath='{.metadata.uid}{"\n"}{.spec.nodeName}{"\n"}{range .spec.containers[*]}{.name}{"\t"}{.image}{"\n"}{end}'
k logs 'example-csi-controller' -n 'kube-system' -c 'csi-provisioner' --since=10m --tail=80 --timestampsجزء دقیق و بازهٔ محدود شکست مشخصه؛ بخش مدیریت‌شدهٔ دیده‌نشده به مسئول خودش سپرده می‌شه.
برای همان مرحلهٔ خراب، مسئول و راه ادامه رو انتخاب کن
اگر نود واجدشرایط برای مصرف‌کننده نداریم، مشکل مصوب جای‌گیری یا ظرفیت workload رو از منبع معمول پلتفرم حل کن. در شکست ساخت پویا، مسئول ذخیره‌ساز پارامتر کلاس، احراز هویت از راه محافظت‌شده، سهمیه و ظرفیت backend و سازگاری کنترل‌کننده رو می‌بینه. برای PV موجود، UID و محل دقیق رو تطبیق بده؛ نام‌ها رو برای شبیه‌شدن وضعیت عوض نکن.
در شکست attach یا mount، هویت حجم و وضعیت writer قبلی رو حفظ کن تا اپراتور روش بازیابی پشتیبانی‌شدهٔ درایور رو دنبال کنه. حذف PVC/PV، پاک‌کردن finalizer یا claimRef، detach اجباری، format دستگاه یا ویرایش mount نود راه‌حل عمومی نیست. reclaim policy از نوع Delete می‌تونه بعد از حذف شیء، ذخیره‌ساز زیرش رو هم حذف کنه؛ Retain هم بکاپ نیست.
تغییر workload یا کلاس و جایگزینی حجم، کار جداگانهٔ بررسی‌شده با بکاپ داده، کنترل writer و محدودیت بازیابی/جابه‌جایی است. تغییر تنظیم ناموفق رو فقط وقتی از مسیر GitOps یا استقرار مالک برگردون که رابطهٔ اولیهٔ داده و جای‌گیری هنوز معتبر باشه. برگشت mount، مهاجرت داده یا تغییر schema رو معکوس نمی‌کنه.
وقتی وضعیت کامل دیده نمی‌شه
برای همان ابهام از کادر متناسب استفاده کن. هیچ شاخه منبع یا مجوز رو تغییر نمی‌ده. UID اولیه و زمان شکست رو نگه دار تا شیء تازه رو به‌جای بازیابی حجم قبلی تحویل ندی.
مجوز یا API ذخیره‌ساز در دسترس نیست
دسترسی همین هویت و فهرست API رو ببین. Forbidden فقط یعنی این مشاهده مجاز نشده؛ از اون نمی‌شه دربارهٔ وجود یا نبود درایور نتیجه گرفت. بررسی لازم رو از مسئول ذخیره‌ساز بخواه و نقش رو صرفاً برای موفق‌شدن پنل گسترده نکن.
k auth can-i get persistentvolumes
k auth can-i get storageclasses.storage.k8s.io
k api-resources --api-group=storage.k8s.ioclaim در Pending مونده و نود انتخاب نشده
مصرف‌کنندهٔ واقعی و شرط زمان‌بندی رو دوباره ببین. WaitForFirstConsumer بدون پاد یا جای‌گیری واجدشرایط ممکنه درست کار کنه؛ این شاهد حذف claim نیست.
k get pod 'example-app' -n 'apps' -o jsonpath='{.spec.nodeName}{"\n"}{.spec.nodeSelector}{"\n"}{.spec.affinity}{"\n"}{.spec.tolerations}{"\n"}{range .spec.containers[*]}{.name}{"\t"}{.resources}{"\n"}{end}'
k events -n 'apps' --for 'pod/example-app'Bound شده ولی پاد هنوز بالا نمیاد
هویت claim/PV و رخداد پاد رو دوباره تأیید کن. Bound قبل از attach و mount است. مرحله و نود دقیق رو به مسئول درایور بده؛ writer دیگری وصل نکن.
k get pvc 'data-example' -n 'apps' -o jsonpath='{.metadata.uid}{"\n"}{.status.phase}{"\n"}{.spec}{"\n"}{.metadata.annotations.volume\.kubernetes\.io/selected-node}{"\n"}'
k events -n 'apps' --for 'persistentvolumeclaim/data-example'
k events -n 'apps' --for 'pod/example-app'رخدادها دیگر نگه داشته نشده‌اند
UID و شرط‌های فعلی رو بخون و نبود مدرک را ثبت کن. با مسئول از رخداد مرکزی یا لاگ کنترل‌کنندهٔ موجود کمک بگیر. برای تولید خطای تازهٔ این آموزش، اشیا رو حذف و دوباره ایجاد نکن.
k get pod 'example-app' -n 'apps' -o jsonpath='{.metadata.uid}{"\n"}{.metadata.creationTimestamp}{"\n"}{.status.conditions}{"\n"}'
k get pvc 'data-example' -n 'apps' -o jsonpath='{.metadata.uid}{"\n"}{.metadata.creationTimestamp}{"\n"}{.status.phase}{"\n"}'قدم بعدی
یک رابطهٔ ذخیره‌سازیِ درست و کار برنامه رو با هم تأیید کن
بعد از اصلاح جداگانهٔ مصوب، رابطهٔ پاد و claim و PV و رخدادها رو دوباره بخون. اگر کنترل‌کننده پاد رو جایگزین کرده، UID تازه و نود واقعی رو ثبت کن و نمونه‌های فرم رو آگاهانه تغییر بده. فرض نود قبلی رو به نمونهٔ جدید منتقل نکن.
بازیابی وقتی پذیرفته است که اتصال درخواست به حجم، attach لازم و mount نود کامل شده باشه، workload نگه‌داشته‌شده یا جایگزین به سلامت مورد انتظار برسه و مسئول برنامه دادهٔ موجود و سازگاریش رو تأیید کنه. Bound یا یک فایل آزمایشی خالی، آزمون بازیابی دادهٔ واقعی نیست. پنل‌های فقط‌خواندنی برگشت تنظیم یا جمع‌کردن کلاستر تازه نمی‌خوان.
همان شل Bash مجاز روی میزبان مدیریت
k get pod 'example-app' -n 'apps' -o jsonpath='{.metadata.uid}{"\n"}{.metadata.ownerReferences}{"\n"}{.status.phase}{"\t"}{.spec.nodeName}{"\n"}{range .spec.volumes[*]}{.name}{"\t"}{.persistentVolumeClaim.claimName}{"\n"}{end}{range .status.conditions[*]}{.type}{"="}{.status}{"\t"}{.reason}{"\t"}{.message}{"\n"}{end}'
k events -n 'apps' --for 'pod/example-app'
k get pvc 'data-example' -n 'apps' -o jsonpath='{.metadata.uid}{"\n"}{.status.phase}{"\n"}{.spec}{"\n"}{.metadata.annotations.volume\.kubernetes\.io/selected-node}{"\n"}'
k events -n 'apps' --for 'persistentvolumeclaim/data-example'workload موردنظر از همان رابطهٔ صحیحِ داده استفاده می‌کنه و تغییر هویت واقعی و محدودیت دید ثبت شده.
منابع این آموزش
منابع رسمی
بالای صفحه می‌بینی که هر محیط چطور بررسی شده. بررسی مستندات به معنی اجرای عملی همهٔ نسخه‌ها نیست.
- Kubernetes maintained releases
- kubectl/API-server version skew
- Official Linux kubectl setup and verified binary workflow
- Kubeconfig context and trusted access
- Kubernetes authentication plugins
- Kubernetes authorization checks
- Ubuntu lifecycle
- Debian release lifecycle
- RHEL supported lifecycle
- Rocky Linux release branches
- AlmaLinux releases
- Manjaro complete upgrades
- PersistentVolume lifecycle, binding, access modes and reclaim policy
- StorageClass binding mode and topology
- CSI architecture, sidecars and driver-specific compatibility
- CSIDriver attachRequired and mount policy
- CSINode registration and topology keys
- VolumeAttachment API status
- Dynamic provisioning
- Debugging Pods
- Kubernetes events
ادامهٔ مسیر