Volume expansion: Recovery and monitoring in Kubernetes


کلید واژهٔ اصلی این مطلب volume expansion است که به بهبودهای observability در فرایند توسعهٔ حجم اشاره دارد.

نسخه v1.34 از Kubernetes حالا قابلیت بازیابی خودکار از خطاهای توسعه حجم (volume expansion) را در حالت GA ارائه می‌دهد. 😊 اشتباه تایپی موقع افزایش اندازه PersistentVolume یا PersistentVolumeClaim (مثلاً نوشتن 1000TB به‌جای 100TB) همیشه قابل حل بود، اما قبلاً نیاز به دخالت دستی و دسترسی cluster-admin داشت و فرایند پیچیده و وقت‌گیر می‌شد؛ این مشکل حالا به‌صورت خودکار قابل مدیریت است.

حالا اگر فوری متوجه اشتباه شدید، می‌توانید مقدار درخواست شده در PVC را کاهش دهید و تا زمانی که توسعه (expansion) به اندازهٔ اشتباه‌شده کامل نشده باشد، اندازهٔ موردنظر را اصلاح کنید. Kubernetes به‌صورت خودکار تلاش می‌کند وضعیت را اصلاح کند، هرQuota که به‌دلیل توسعهٔ ناموفق مصرف شده بود بازگردانده می‌شود و PersistentVolume متناظر باید به آخرین اندازه‌ای که مشخص کردید تغییر اندازه پیدا کند. 🔧

مثال عملی: فرض کنید PVC شما قبلاً 10TB بوده و می‌خواستید آن را به 100TB افزایش دهید، اما اشتباهاً 1000TB نوشتید. نمونهٔ YAML اشتباه:

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: myclaim
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1000TB # newly specified size - but incorrect!

در بسیاری از موارد توسعهٔ به 1000TB هیچ‌وقت موفق نخواهد شد — یا به‌خاطر محدودیت فیزیکی دِیسک یا به‌خاطر سهمیهٔ cloud provider. در Kubernetes v1.34 می‌توانید اشتباه را با درخواست اندازهٔ جدیدی که از مقدار اشتباه کمتر است اما همچنان از اندازهٔ واقعی اولیهٔ PV بزرگ‌تر باشد اصلاح کنید. مثال اصلاح‌شده:

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: myclaim
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 100TB # Corrected size; has to be greater than 10TB.
                     # You cannot shrink the volume below its actual size.

این کار نیازی به دخالت ادمین ندارد و Kubernetes به‌صورت خودکار هر منابعی که به‌طور موقت مصرف شده بود را آزاد می‌کند. 👍 یادتان باشد قید مهم این است که اندازهٔ جدید نباید کمتر از مقدار واقعی موجود در pvc.status.capacity باشد، چون Kubernetes از قبل از کوچک کردن PV پشتیبانی نمی‌کند.

برای پشتیبانی از این رفتار، تیم توسعه تقریباً معماری داخلی توسعهٔ حجم را بازطراحی کرده و چند فیلد API جدید در PVC اضافه شده که می‌توانید برای مشاهدهٔ پیشرفت از آن‌ها استفاده کنید — یعنی ابزارهای observability برای expansion بهتر شده‌اند.

برای مانیتور کردن پیشرفت توسعهٔ حجم می‌توانید مقدار pvc.status.allocatedResourceStatus[‘storage’] را بررسی کنید. برای یک Block volume معمولاً این مقدار بین حالت‌هایی مثل ControllerResizeInProgress، NodeResizePending و NodeResizeInProgress جابه‌جا می‌شود و وقتی توسعه کامل شد مقدارش خالی (nil) می‌شود. اگر توسعه به اندازهٔ درخواستی امکان‌پذیر نباشد، وضعیت‌هایی مثل ControllerResizeInfeasible یا NodeResizeInfeasible مشاهده خواهید کرد. همچنین می‌توانید به pvc.status.allocatedResources نگاه کنید تا ببینید Kubernetes روی چه اندازه‌ای کار می‌کند. 📈

در زمینهٔ خطاها و گزارش‌دهی هم بهبودهایی اعمال شده: Kubernetes حالا تلاش برای retry در توسعه‌هایی که شکست خورده‌اند را با نرخ کندتری انجام می‌دهد و درخواست‌های کمتر و بهینه‌تری به storage system و apiserver می‌فرستد. خطاهای رخ‌داده در جریان توسعه به‌صورت condition روی PVC ثبت می‌شوند (با کلیدهایی مثل ControllerResizeError یا NodeResizeError) و این شرایط پایدار خواهند ماند — برخلاف eventهایی که گذرا هستند. این کمک می‌کند تا خطاها بهتر دیده و دیباگ شوند.

این قابلیت، علاوه بر حل مشکل اصلی، اجازه داد تا چند باگ قدیمی در workflow تغییر اندازه حل شوند (مثلاً issue #115294). اگر با رفتاری نامعمول روبه‌رو شدید، لطفاً با مثال قابل بازتولید گزارش را در https://github.com/kubernetes/kubernetes/issues ثبت کنید تا تیم بتواند بررسی کند. 🐛

پیشنهاد عملی: در محیط‌های production همیشه بعد از اعمال تغییرات مربوط به PVC، وضعیت pvc.status.* و pvc.status.conditions را بررسی کنید تا از پیشرفت یا وجود خطا مطمئن شوید. اگر خواستید، می‌تونم چند command و kubectl one-liner برای مانیتورینگ و دیباگ این حالات براتون آماده کنم. 🚀