WIUNIX ACADEMY
PVC در Pending یا mount ناموفق؛ تشخیص مرحله‌های CSI در Kubernetes
مرحلهٔ گیرکردن PVC و CSI رو پیدا کن؛ از انتظار طبیعی برای مصرف‌کننده تا ساخت، attach و mount، بدون حذف حجم یا قطع خودسرانهٔ پردازشی که بهش داده می‌نویسه.
محیطت رو انتخاب کنآموزش متناسب با محیط تو
کجا اجرا می‌کنی؟
سیستم‌عامل و نسخهٔ سرورت رو انتخاب کن تا مراحل، دستورها و راه‌حل‌های همون محیط رو ببینی.
آموزش متناسب با مقادیر تو
تنظیمات این آموزش
مقادیر نمونه رو با مشخصات سرورت عوض کن تا متن و دستورها با هم تغییر کنن. رمز، کلید خصوصی و توکن اینجا وارد نکن. مقدارها فقط توی همین زبانه می‌مونن و به سرور یا لینک اشتراک‌گذاری فرستاده نمی‌شن. قبل از اجرا، DNS، گواهی‌ها و تنظیمات دسترسی شبکه رو روی سرورت بررسی کن.
اگر آی‌پی، دامنه یا پورت‌های نمونه با سرورت فرق دارن، بخش تنظیمات پایین رو باز کن. مقدارها رو عوض کن و «اعمال در آموزش» رو بزن؛ بعد دستورهای تازه رو کپی کن.
تنظیم مقادیر برای محیط من9 مقدار قابل‌تغییر
از اینجا شروع کن
آخر این آموزش چی خواهیم داشت؟
مرحلهٔ گیرکردن PVC و CSI رو پیدا کن؛ از انتظار طبیعی برای مصرف‌کننده تا ساخت، attach و mount، بدون حذف حجم یا قطع خودسرانهٔ پردازشی که بهش داده می‌نویسه.
سیستم‌عامل‌ها و نسخه‌های پوشش‌داده‌شده
این مسیر برای مشاهدهٔ کلاستر موجود از میزبان مدیریت لینوکس است؛ انتخاب OS نسخهٔ نودهای کلاستر رو تعیین نمی‌کنه. شاخه‌های upstream نگهداری‌شدهٔ ۱٫۳۵ تا ۱٫۳۷ و محدودیت skew کلاینت در ۲۰۲۶-۱۱-۰۵ مرور شده‌اند؛ نسخه و قابلیت عرضه‌کننده یا درایور جدا بررسی می‌شه. فرم نام ساده تا ۳۲ نویسه رو می‌پذیره؛ این محدودیت فرم است، نه محدودیت Kubernetes. اگر نام واقعی بلندتره یا نویسه‌ای بیرون از فرم داره، دستورهای همان شاخه رو در ویرایشگر مورد اعتماد با نام دقیق منابع خودت آماده کن؛ اسم رو کوتاه نکن و شیء رو تغییر نام نده. هیچ فرمان این راهنما هنگام نویسندگی روی کلاستر اجرا نشده و ماتریس اجرای همهٔ OSها ادعا نمی‌شه.
قبل از شروع
- کلاستر موجود، context و هویت مورد اعتماد و مجاز، kubectl سازگار و نام دقیق منابع و زمان رخداد.
- دسترسی خواندن منابع همان namespace؛ دیدن نود، PV یا منابع CSI و metrics ممکنه دسترسی جدا بخواد. نبود دسترسی باید با مالک همان بخش پیگیری بشه.
- روش موجود مدیریت تغییر و بازیابی برنامه و محل خصوصی برای شواهد؛ دادهٔ حساس و رمز و kubeconfig وارد فرم یا گزارش عمومی نمی‌شن.
بفهمیم کارِ ذخیره‌ساز در کدام مرحله مونده
claim با وضعیت Pending، پادی که هنوز نود نگرفته و ولومی که Bound شده ولی mount نمی‌شه، یک مشکل واحد نیستن. از یک پاد موجود و claim واقعی‌اش شروع می‌کنیم و انتخاب نود، اتصال درخواست به حجم، ساخت حجم، attach و mount رو دنبال می‌کنیم. این بررسی هیچ ولومی نمی‌سازه، حذف، جدا یا تعمیر نمی‌کنه.
PVC درخواست ذخیره‌سازیِ داخل یک namespace است؛ PV حجم ذخیره‌سازی رو در سطح کلاستر نمایندگی می‌کنه. StorageClass روش فراهم‌کردن حجم و معمولاً درایور CSI رو مشخص می‌کنه. CSI هم بخش کنترل ذخیره‌ساز رو از افزونهٔ هر نود جدا می‌کنه. سلامت و مجوز و سازگاری این بخش‌ها و backend، با سیستم‌عامل لپ‌تاپ مدیریت یکی نیست.
روی کلاستر موجود و نگهداری‌شدهٔ ۱٫۳۵ تا ۱٫۳۷ و درایور پشتیبانی‌شدهٔ خودش کار کن. عرضه‌کنندهٔ کلاستر ممکنه نسخهٔ مشخصی از درایور و sidecar بخواد یا بخشی از کنترل‌پلین رو در اختیارت نذاره؛ با مسئول ذخیره‌ساز روشنش کن. اینجا دوباره خطای برنامهٔ CrashLoop/OOM یا DNS/NetworkPolicy رو بررسی نمی‌کنیم و کلاستر تازه نمی‌سازیم.
نام واقعی اشیا رو وارد کن، بدون تغییر خود اشیا
فرم مقادیر نمونه رو باز کن و اول namespace، پاد و claim واقعی رو بذار. قبل از استفاده از شاخه‌های بعدی، کلاس، PV متصل‌شده و نود انتخاب‌شده رو پیدا کن و همان‌ها رو در فرم وارد کن. نام پاد و کانتینر درایور رو هم از مسئول ذخیره‌ساز بگیر؛ namespace یا label همگانی برای حدس‌زدن CSI نداریم.
مقدارها برای همین زبان و محیط در همین تب می‌مونن. قبل از کپی، اعمال یا بازنشانی کن؛ تغییر معلق و نامعتبر کپی رو متوقف می‌کنه. نام ساده تا ۳۲ نویسه محدودیت این فرم است، نه Kubernetes. اگر نام واقعی بلندتره یا مثلاً نقطه داره، دستورهای همان شاخه رو در ویرایشگر مورد اعتماد با نام دقیق منابع خودت آماده کن؛ اسم رو کوتاه نکن و شیء رو تغییر نام نده. رمز، اطلاعات دسترسی ذخیره‌ساز و kubeconfig وارد فرم نمی‌شن.
قدم بعدی
ابزار و کانال واقعی همین میزبان رو ببین
انتخاب سیستم‌عامل برای میزبان اجرای kubectl است، نه گواهی سازگاری سیستم‌عامل نودها. از همان حساب عادیِ مجاز و kubectl مورد تأیید تیم استفاده کن؛ اجرای kubectl با sudo می‌تونه kubeconfig و هویت متفاوتی انتخاب کنه. این ابزار روی میزبان مدیریت daemon نیست و برایش kubelet یا کلاستر تازه راه نمی‌اندازیم.
بسته‌های پایه و نسخهٔ خود کلاینت رو بخون. نبود ابزار یعنی قبل از ادامه، کلاینت سازگار رو در تغییر برنامه‌ریزی‌شده با روش رسمی تیم آماده کنی. آخرین نسخهٔ تصادفی، بستهٔ آرچ روی مانجارو یا مخزن خارجیِ تأییدنشده راه آماده‌سازی این رخداد نیست. راهنمای رسمی، دریافت نسخهٔ مشخص و بررسی checksum باینری رو هم توضیح می‌ده؛ این آموزش عمداً کلاینت موجود و مجاز رو پیش‌نیاز می‌گیره.
در شاخهٔ ۱۰/۹ از نسخهٔ فرعی پشتیبانی‌شده و به‌روز و مخزن مجاز RHEL یا مخزن رسمی راکی/آلما برای بستهٔ پایه استفاده کن. kubectl و افزونهٔ مجاز فعلی رو نگه دار. SELinux، firewalld و سیاست رمزنگاری میزبان حفظ می‌شن؛ پورت ورودی یا سرویس نود تازه لازم نیست.
میزبان مدیریت با حساب عادی مجاز
cat /etc/os-release
uname -m
rpm -q ca-certificates bash coreutils
command -v bash kubectl
kubectl version --client --output=yamlکلاینت موجود و سازگار و بسته‌های پایه مشخصن؛ نبود هرکدوم آماده‌سازی رو متوقف می‌کنه.
قدم بعدی
محدودیت SELinux و مسیر API رو جدا ببین
SELinux و firewalld و سیاست رمزنگاری فعلیِ میزبان مدیریت رو نگه دار. خطای افزونه یا kubeconfig یا اعتماد TLS رو با مسئول همان میزبان حل کن؛ سیاست رو permissive نکن، مسیرها رو بازگشتی relabel نکن و پورت عمومی تازه باز نکن. این بررسی فقط وضعیت موجود رو می‌خونه و دربارهٔ سیاست نودهای کلاستر رأی نمی‌ده.
میزبان مدیریت؛ فقط خواندن وضعیت
if command -v getenforce >/dev/null 2>&1; then getenforce; fi
if command -v firewall-cmd >/dev/null 2>&1; then firewall-cmd --state; fiوضعیت قابل‌مشاهده ثبت شده و خطای سیاست با مالک میزبان پیگیری می‌شه؛ حفاظتی خاموش نشده.
قدم بعدی
context رو مشخص کن و همان نشست رو نگه دار
نام context رو با مقصد مورد تأییدت تطبیق بده و همین شل Bash رو تا پایان نگه دار. تابع k در پنل‌های بعدی همان context رو صریح انتخاب می‌کنه و برای هر درخواست مهلت می‌ذاره. اگر شل تازه باز کردی، این مرحله رو دوباره انجام بده؛ context خالی نباید بی‌صدا به مقصد دیگری تبدیل بشه.
در تاریخ بررسی، شاخه‌های نگهداری‌شدهٔ upstream برابر ۱٫۳۷، ۱٫۳۶ و ۱٫۳۵ هستن. kubectl باید حداکثر یک نسخهٔ minor با همهٔ API serverهایی که ممکنه بهشون وصل بشه اختلاف داشته باشه؛ کلاستر HA هنگام ارتقا این بازه رو محدودتر می‌کنه. محدودیت عرضه‌کننده و نسخهٔ درایور هم جداست. خطا یا نرسیدن به نسخهٔ سرور، اجازهٔ ادامه بر اساس حدس نیست.
همان شل Bash مجاز روی میزبان مدیریت
context=$(kubectl config current-context) || exit 1
test -n "$context" || exit 1
printf 'Selected context: %s\n' "$context"
k() {
test -n "${context:-}" || { printf 'STOP: load the selected context in this shell first.\n' >&2; return 1; }
kubectl --context "$context" --request-timeout=20s "$@"
}
k version --output=yaml
context موردنظر و نسخه‌های واقعی تأیید شده‌اند و تابع k برای همین شل آماده است.
قدم بعدی
بدونیم کدام مشاهده برای این حساب مجازه
ممکنه مسئول namespace به پاد و PVC دسترسی داشته باشه ولی اجازهٔ دیدن PV، StorageClass، نود یا VolumeAttachment در سطح کلاستر رو نداشته باشه. قبل از رفتن سراغ این شاخه‌ها، مجوز رو بپرس. جواب هر خط فقط دسترسی همین هویت رو می‌گه، نه سلامت backend. جواب no یعنی از مسئول همان بخش کمک بگیر، نه اینکه cluster-admin بگیری.
پیام رخداد و لاگ درایور ممکنه شناسه‌های داخلی backend رو داشته باشه؛ در سابقهٔ خصوصیِ مجاز نگهش دار. برای این تشخیص محتوای Secret یا تنظیم خام احراز هویت رو دریافت نمی‌کنیم.
همان شل Bash مجاز روی میزبان مدیریت
k auth can-i get pods -n 'apps'
k auth can-i get persistentvolumeclaims -n 'apps'
k auth can-i list events -n 'apps'
k auth can-i get storageclasses.storage.k8s.io
k auth can-i get persistentvolumes
k auth can-i list volumeattachments.storage.k8s.ioدید لازمِ namespace موجوده و هر شاخهٔ کلاستری، خوانندهٔ مجاز یا مسئول مشخص داره.