‏مدیریت منابع در سطح Pod در کوبرنتیز v1.36

کوبرنتیز v1.36 یه قابلیت آلفای جالب معرفی کرده به اسم Pod-Level Resource Managers که نحوه مدیریت منابع رو در kubelet زیر و رو می‌کنه. تا قبل از این، Topology Manager، CPU Manager و Memory Manager فقط می‌تونستن منابع رو در سطح کانتینر تخصیص بدن. حالا این مدیرها می‌تونن روی مشخصات منابع کل Pod (یعنی .spec.resources) هم کار کنن.

مشکل اصلی که این ویژگی حلش می‌کنه اینه که در ورک‌لودهای سنگین و حساس به تأخیر، معمولاً یه Pod چند کانتینر داره؛ یه کانتینر اصلی برای اپلیکیشن اصلی، چند تا سیدکار برای لاگ‌گیری، مانیتورینگ یا service mesh. قبلاً برای اینکه به Guaranteed QoS برسی و از NUMA alignment استفاده کنی، مجبور بودی به همه کانتینرها حتی سیدکارهای سبک هم منابع اختصاصی integer-based بدی. این خیلی اسراف‌کارانه بود.

با فعال کردن feature gate های PodLevelResourceManagers و PodLevelResources، kubelet می‌تونه یه مدل هیبریدی بسازه؛ منابع اختصاصی و NUMA-aligned برای کانتینرهای اصلی، و یه pool مشترک در سطح Pod برای سیدکارها. این pool مشترک از بودجه کلی Pod تأمین می‌شه.

یه سناریوی کاربردی اینه که یه Pod دیتابیس داری با یه کانتینر اصلی و چند سیدکار برای متریک و بکاپ. وقتی Topology Manager روی pod scope تنظیم بشه، kubelet یه بار بر اساس کل بودجه Pod تصمیم NUMA می‌گیره. کانتینر دیتابیس CPU و مموری اختصاصی‌اش رو از اون NUMA node می‌گیره و سیدکارها از منابع باقیمانده توی pool مشترک Pod استفاده می‌کنن:

spec:
  resources:
    requests:
      cpu: "8"
      memory: "16Gi"
    limits:
      cpu: "8"
      memory: "16Gi"
  containers:
  - name: database
    resources:
      requests:
        cpu: "6"
        memory: "12Gi"
      limits:
        cpu: "6"
        memory: "12Gi"

سناریوی دیگه برای ورک‌لودهای ML هست. فرض کن یه Pod داری با یه کانتینر GPU-accelerated برای آموزش مدل و یه سیدکار service mesh. با تنظیم container scope در Topology Manager، kubelet هر کانتینر رو جداگانه ارزیابی می‌کنه. کانتینر ML منابع اختصاصی NUMA-aligned می‌گیره ولی سیدکار از pool عمومی node استفاده می‌کنه:

spec:
  resources:
    requests:
      cpu: "4"
      memory: "8Gi"
    limits:
      cpu: "4"
      memory: "8Gi"
  containers:
  - name: ml-training
    resources:
      requests:
        cpu: "3"
        memory: "6Gi"
      limits:
        cpu: "3"
        memory: "6Gi"

از نظر ایزولیشن هم سیستم هوشمندانه عمل می‌کنه. کانتینرهایی که CPU اختصاصی گرفتن، CFS quota enforcement در سطح کانتینر روشون غیرفعاله و throttle نمی‌شن. اما کانتینرهایی که توی pool مشترک Pod هستن، CFS quota در سطح Pod روشون اعمال می‌شه تا از بودجه باقیمانده تجاوز نکنن.

برای مانیتورینگ هم چند متریک جدید kubelet اضافه شده: resource_manager_allocations_total برای ردیابی تخصیص‌های اختصاصی، resource_manager_allocation_errors_total برای خطاها، و resource_manager_container_assignments که نشون می‌ده هر کانتینر با چه نوع تخصیصی (node_exclusive، pod_exclusive یا pod_shared) داره اجرا می‌شه.

برای فعال کردن این ویژگی نیاز به Kubernetes v1.36 یا جدیدتر داری. باید feature gate های مربوطه رو فعال کنی، CPU Manager رو روی static policy بذاری، Memory Manager رو روی Static policy، و Topology Manager رو با یه policy غیر از none (مثل best-effort یا single-numa-node) و scope مناسب تنظیم کنی.

نکات کلیدی:

• Kubernetes v1.36 مدیریت منابع NUMA-aligned رو از سطح کانتینر به سطح Pod گسترش داده
• سیدکارهای سبک می‌تونن از یه pool مشترک Pod تغذیه بشن و دیگه نیازی به منابع اختصاصی ندارن
• دو scope قابل تنظیمه: pod (یه تصمیم NUMA برای کل Pod) و container (تصمیم NUMA جداگانه برای هر کانتینر)
• ایزولیشن CPU از طریق CFS quota در سطح Pod یا کانتینر اعمال می‌شه
• سه متریک جدید kubelet برای مانیتورینگ و دیباگ اضافه شده
• این قابلیت هنوز آلفاست و برای استفاده در پروداکشن باید با احتیاط بررسی بشه