VPA در Kubernetes چیست؟ راهنمای تنظیم خودکار منابع CPU و حافظه

برای هر کانتینر چقدر CPU و حافظه تعیین کنیم؟ این سؤال ساده، یکی از چالش‌های همیشگی مدیریت Kubernetes است. تعیین منابع بیش‌ازحد می‌تواند ظرفیت قابل استفادهٔ کلاستر را محدود کند؛ مقدار ناکافی نیز ممکن است عملکرد برنامه را تحت تأثیر قرار دهد.

مشکل زمانی پیچیده‌تر می‌شود که مصرف برنامه ثابت نباشد. منابع مناسب در زمان راه‌اندازی، ساعات عادی و دوره‌های پرترافیک الزاماً یکسان نیستند. بررسی دستی تمام سرویس‌ها نیز با رشد تعداد برنامه‌ها دشوارتر می‌شود.

Vertical Pod Autoscaler یا VPA برای کمک به این مسئله طراحی شده است: بررسی مصرف منابع و پیشنهاد یا اعمال مقادیر مناسب‌تر برای کانتینرها.

VPA چیست و چگونه کار می‌کند؟

VPA یکی از پروژه‌های اکوسیستم Kubernetes برای مقیاس‌پذیری عمودی است. تمرکز اصلی آن تنظیم requests منابع CPU و حافظه بر اساس مصرف مشاهده‌شده است. با توجه به سیاست انتخاب‌شده، می‌تواند فقط پیشنهاد تولید کند یا در اعمال آن نیز نقش داشته باشد.

VPA معمولاً به نصب و پیکربندی جداگانه نیاز دارد؛ بنابراین صرف داشتن کلاستر Kubernetes به معنای فعال‌بودن آن نیست. معرفی رسمی پروژه VPA

در عمل، سه جزء اصلی با یکدیگر همکاری می‌کنند:

• Recommender: مصرف فعلی و سابقهٔ مصرف را بررسی و منابع پیشنهادی را محاسبه می‌کند.
• Updater: دربارهٔ به‌روزرسانی منابع Podهای موجود، مطابق سیاست انتخاب‌شده تصمیم می‌گیرد.
• Admission Controller: هنگام ایجاد Podهای هدف، پیشنهاد منابع را روی آن‌ها اعمال می‌کند.

این تفکیک باعث می‌شود بتوان مرحلهٔ «مشاهده و پیشنهاد» را از «اعمال خودکار تغییر» جدا کرد. معماری رسمی VPA

VPA چه تفاوتی با HPA دارد؟

HPA تعداد نمونه‌های برنامه را تغییر می‌دهد؛ VPA منابع هر نمونه را تنظیم می‌کند.

برای مثال، یک API ممکن است با افزایش تعداد درخواست‌ها به Podهای بیشتری نیاز داشته باشد. در مقابل، ممکن است تعداد نمونه‌ها کافی باشد، اما منابع تعیین‌شده برای هر کانتینر با نیاز واقعی آن هماهنگ نباشد.

انتخاب میان این دو باید از شناخت گلوگاه شروع شود. اگر محدودیت اصلی پایگاه داده یا سرویس وابسته باشد، افزایش تعداد Pod یا منابع آن‌ها لزوماً مشکل را حل نمی‌کند.

همچنین VPA و HPA را نباید بدون طراحی روی یک معیار منبع مشترک فعال کرد. برای نمونه، تغییر CPU request توسط VPA می‌تواند محاسبات HPA مبتنی بر درصد مصرف CPU نسبت به request را تحت تأثیر قرار دهد. مستندات پروژه، استفاده از منابع جداگانه مانند VPA برای حافظه و HPA برای CPU، یا استفاده از معیارهای سفارشی و خارجی در HPA را مطرح می‌کنند. محدودیت‌های رسمی VPA

چرا بهتر است ابتدا فقط پیشنهادها را ببینیم؟

برای شروع، پیشنهاد ما استفاده از حالت Off است. در این حالت، VPA پیشنهاد تولید می‌کند اما آن را خودکار روی Podها اعمال نمی‌کند.

حالت‌های مهم دیگر عبارت‌اند از:

• Initial: پیشنهاد منابع هنگام ایجاد Pod اعمال می‌شود.
• Recreate: برای اعمال تغییر، ممکن است Pod تخلیه و توسط کنترلر دوباره ایجاد شود.
• InPlaceOrRecreate: ابتدا تغییر درجا را امتحان می‌کند و در صورت امکان‌پذیرنبودن، می‌تواند به بازایجاد Pod برگردد.

پشتیبانی از تغییر درجا به نسخهٔ VPA، قابلیت‌های کلاستر و نوع تغییر وابسته است. در نتیجه، نباید فعال‌سازی VPA را معادل تضمین «بدون restart» دانست. همچنین حالت قدیمی Auto در مستندات فعلی منسوخ شده است؛ بهتر است سیاست موردنظر را صریح انتخاب کنید. راهنمای حالت‌های به‌روزرسانی

نمونهٔ تنظیم VPA در حالت پیشنهاد

فرض کنید یک Deployment با نام payment-api در namespace برابر apps داریم. پس از نصب VPA، CRDهای آن و فراهم‌بودن منبع متریک، می‌توان نمونهٔ زیر را برای بررسی پیشنهادها تعریف کرد:

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: payment-api-vpa
  namespace: apps
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: payment-api
  updatePolicy:
    updateMode: "Off"
  resourcePolicy:
    containerPolicies:
      - containerName: "*"
        controlledResources:
          - cpu
          - memory
        controlledValues: RequestsOnly
        minAllowed:
          cpu: 100m
          memory: 128Mi
        maxAllowed:
          cpu: "2"
          memory: 2Gi

اعداد این مثال آموزشی هستند و باید با نیاز سرویس و ظرفیت زیرساخت جایگزین شوند.

گزینهٔ RequestsOnly دامنهٔ کنترل را به requests محدود می‌کند. همچنین minAllowed و maxAllowed مرز پیشنهادها را تعیین می‌کنند. این مرزها تضمین نمی‌کنند که ظرفیت لازم روی Nodeها موجود باشد. مرجع API پروژه VPA

برای ثبت تنظیم و مشاهدهٔ نتیجه:

kubectl apply -f payment-api-vpa.yaml
kubectl describe vpa payment-api-vpa -n apps

پیشنهادها پس از جمع‌آوری داده در وضعیت شیء VPA قابل مشاهده‌اند. وجود منبع متریک، مانند Metrics Server، از پیش‌نیازهای کارکرد آن است. مستندات Kubernetes

پیشنهاد VPA را چگونه ارزیابی کنیم؟

پیشنهاد تولیدشده را کنار رفتار واقعی برنامه بررسی کنید. بازه‌ای که فقط ساعات کم‌ترافیک را پوشش داده، مبنای مناسبی برای تصمیم دربارهٔ کل چرخهٔ کاری نیست.

پیش از اعمال تغییر، این پرسش‌ها را پاسخ دهید:

• آیا داده‌ها دورهٔ پرترافیک و عملیات زمان‌بندی‌شده را پوشش می‌دهند؟
• زمان پاسخ و نرخ خطای برنامه در بار هدف چگونه است؟
• آیا رخداد OOM یا CPU throttling دیده می‌شود؟
• تغییر منابع با محدودیت‌های namespace و ظرفیت Nodeها سازگار است؟
• اگر Pod جایگزین شود، برنامه چگونه به وضعیت آماده‌به‌کار می‌رسد؟

برای مثال، اگر پیشنهاد حافظه کمتر از مقدار فعلی است، بهتر است ابتدا آن را روی گروه محدودی از سرویس‌ها و تحت بار مشابه واقعی ارزیابی کنید. هدف، کاهش عدد منابع به هر قیمت نیست؛ باید کیفیت سرویس حفظ شود.

آیا VPA هزینهٔ زیرساخت را کاهش می‌دهد؟

VPA می‌تواند به شناسایی تخصیص نامناسب منابع کمک کند، اما کاهش request الزاماً به کاهش صورت‌حساب منجر نمی‌شود.

در ارزیابی اقتصادی باید بررسی کنیم آیا ظرفیت آزادشده واقعاً امکان کاهش تعداد Nodeها یا استفادهٔ بهتر از زیرساخت را فراهم کرده است. محدودیت‌های زمان‌بندی و نیازهای دسترس‌پذیری ممکن است همچنان نگهداری همان تعداد Node را ضروری کنند.

بنابراین، معیار موفقیت بهتر است ترکیبی از کیفیت سرویس، ظرفیت قابل استفاده و هزینهٔ واقعی باشد.

مسیر پیشنهادی برای استفاده در محیط عملیاتی

ابتدا یک سرویس با مالک مشخص و مانیتورینگ مناسب انتخاب کنید. VPA را در حالت پیشنهاد قرار دهید و داده‌های یک چرخهٔ کاری نماینده را بررسی کنید.

سپس پیشنهادها را با تیم توسعه ارزیابی کنید؛ به‌ویژه اگر برنامه تنظیمات حافظه یا پردازش را هنگام شروع تعیین می‌کند. پس از آزمایش محدود، دربارهٔ فعال‌کردن اعمال خودکار تصمیم بگیرید.

در این مرحله، تعداد replicaها، آمادگی Pod جایگزین، ظرفیت Nodeها و PodDisruptionBudget باید بررسی شوند. VPA هنگام eviction از PDB پیروی می‌کند، اما PDB به‌تنهایی تضمین‌کنندهٔ نبود اختلال نیست. مستندات Updater

مدیریت منابع بر اساس شواهد

VPA می‌تواند بررسی منابع Kubernetes را از حدس‌های اولیه به یک فرایند مبتنی بر مصرف واقعی نزدیک کند. استفادهٔ مؤثر از آن به انتخاب سیاست مناسب، مشاهدهٔ رفتار برنامه و کنترل تغییرات وابسته است.

برای شروع، پیشنهادها را ببینید، آن‌ها را آزمایش کنید و سپس دامنهٔ خودکارسازی را گسترش دهید.

برای بررسی تخصیص منابع، طراحی مانیتورینگ و بهینه‌سازی بهره‌برداری کلاستر Kubernetes، با خدمات دواپس ایران آشنا شوید.

منابع Kubernetes را بر اساس نیاز واقعی مدیریت کنیدبا خدمات دواپس ایران برای پایش و بهینه‌سازی بهره‌برداری کلاستر آشنا شوید.مشاهده خدمات دواپس ←