ملاحظات مربوط به کلاستر‌های بزرگ

یک کلاستر مجموعه‌ای از گره‌ها (ماشین‌های فیزیکی یا مجازی) است که عامل‌های کوبرنتیز را اجرا می‌کنند و توسط control plane مدیریت می‌شوند.

کوبرنتیز v1.33 از کلاستر‌هایی با حداکثر ۵,۰۰۰ گره(Node) پشتیبانی می‌کند. به طور خاص‌تر، کوبرنتیز به گونه‌ای طراحی شده است که پیکربندی‌هایی را که همه معیارهای زیر را برآورده می‌کنند، در خود جای دهد:

• حداکثر ۱۱۰ پاد در هر گره
• حداکثر ۵,۰۰۰ گره
• حداکثر ۱۵۰,۰۰۰ پاد در کل
• حداکثر ۳۰۰,۰۰۰ کانتینر در کل

شما می‌توانید با اضافه کردن یا حذف گره‌ها، کلاستر خود را مقیاس‌بندی کنید. روش انجام این کار به نحوه‌ی استقرار کلاستر شما بستگی دارد.

سهمیه منابع ارائه دهنده ابر

برای جلوگیری از مواجهه با مشکلات سهمیه ارائه دهنده ابر، هنگام ایجاد یک کلاستر با گره‌های زیاد، موارد زیر را در نظر بگیرید:

• درخواست افزایش سهمیه برای منابع ابری مانند:
  • نمونه‌های رایانه‌ای
  • پردازنده‌ها
  • حجم‌های ذخیره‌سازی
  • آدرس‌های IP در حال استفاده
  • مجموعه قوانین فیلتر بسته
  • تعداد متعادل‌کننده‌های بار
  • زیرشبکه‌های شبکه
  • جریان‌های گزارش
• محدود کردن اقدامات مقیاس‌بندی کلاستر برای ایجاد گره‌های جدید در دسته‌ها، با یک مکث بین دسته‌ها، زیرا برخی از ارائه دهندگان ابر، ایجاد نمونه‌های جدید را محدود می‌کنند.

اجزای Control plane

برای یک کلاستر بزرگ، به یک control plane با منابع محاسباتی و سایر منابع کافی نیاز دارید.

معمولاً شما یک یا دو نمونه control plane را در هر منطقه خرابی اجرا می‌کنید، ابتدا آن نمونه‌ها را به صورت عمودی مقیاس‌بندی می‌کنید و سپس پس از رسیدن به نقطه بازگشت نزولی به مقیاس (عمودی)، به صورت افقی مقیاس‌بندی می‌کنید.

شما باید حداقل یک نمونه را در هر منطقه خرابی اجرا کنید تا تحمل خطا فراهم شود. گره‌های Kubernetes به طور خودکار ترافیک را به سمت نقاط انتهایی control plane که در همان منطقه خرابی هستند هدایت نمی‌کنند. با این حال، ارائه دهنده ابر شما ممکن است مکانیسم‌های خاص خود را برای انجام این کار داشته باشد.

به عنوان مثال، با استفاده از یک متعادل کننده بار مدیریت شده، متعادل کننده بار را طوری پیکربندی می‌کنید که ترافیکی را که از kubelet و Pods در منطقه خرابی A سرچشمه می‌گیرد، ارسال کند و آن ترافیک را فقط به میزبان‌های control plane که در منطقه A نیز هستند، هدایت کند. اگر یک میزبان control plane یا منطقه خرابی نقطه انتهایی A آفلاین شود، به این معنی است که تمام ترافیک control plane برای گره‌های موجود در منطقه A اکنون بین مناطق ارسال می‌شود. اجرای چندین میزبان control plane در هر منطقه، احتمال وقوع چنین نتیجه‌ای را کاهش می‌دهد.

مخزن etcd

برای بهبود عملکرد کلاستر‌های بزرگ، می‌توانید اشیاء رویداد را در یک نمونه etcd اختصاصی جداگانه ذخیره کنید.

هنگام ایجاد یک کلاستر، می‌توانید (با استفاده از ابزارهای سفارشی):

• شروع و پیکربندی نمونه etcd اضافی
• پیکربندی API server برای استفاده از آن برای ذخیره رویدادها

برای جزئیات بیشتر در مورد پیکربندی و مدیریت etcd برای یک کلاستر بزرگ، به مدیریت کلاستر‌های etcd برای کوبرنتیز و راه‌اندازی یک کلاستر etcd با قابلیت دسترسی بالا با kubeadm مراجعه کنید.

منابع افزونه

کوبرنتیز محدودیت منابع به حداقل رساندن تأثیر نشت حافظه و سایر روش‌هایی که podها و containerها می‌توانند بر سایر اجزا تأثیر بگذارند، کمک می‌کند. این محدودیت‌های منابع، همانطور که برای بارهای کاری برنامه اعمال می‌شوند، برای منابع افزونه نیز اعمال می‌شوند.

به عنوان مثال، می‌توانید محدودیت‌های CPU و حافظه را برای یک جزء ثبت وقایع تنظیم کنید:

  ...
  containers:
  - name: fluentd-cloud-logging
    image: fluent/fluentd-kubernetes-daemonset:v1
    resources:
      limits:
        cpu: 100m
        memory: 200Mi

محدودیت‌های پیش‌فرض افزونه‌ها معمولاً بر اساس داده‌های جمع‌آوری‌شده از تجربه اجرای هر افزونه روی کلاستر‌های کوچک یا متوسط کوبرنتیز است. هنگام اجرا روی کلاستر‌های بزرگ، افزونه‌ها اغلب منابع بیشتری نسبت به محدودیت‌های پیش‌فرض خود مصرف می‌کنند. اگر یک کلاستر بزرگ بدون تنظیم این مقادیر مستقر شود، افزونه(ها) ممکن است به دلیل رسیدن به حد مجاز حافظه، به‌طور مداوم از کار بیفتند. از طرف دیگر، افزونه ممکن است اجرا شود اما به دلیل محدودیت‌های برش زمانی CPU، عملکرد ضعیفی داشته باشد.

برای جلوگیری از بروز مشکلات مربوط به منابع افزونه کلاستر، هنگام ایجاد کلاستر با گره‌های زیاد، موارد زیر را در نظر بگیرید:

• برخی افزونه‌ها به صورت عمودی مقیاس‌پذیر هستند - یک کپی از افزونه برای کلاستر وجود دارد یا به کل یک منطقه خرابی سرویس می‌دهد. برای این افزونه‌ها، درخواست‌ها و محدودیت‌ها را همزمان با مقیاس‌پذیری کلاستر خود افزایش دهید.

• بسیاری از افزونه‌ها به صورت افقی مقیاس‌پذیر هستند - شما با اجرای پادهای بیشتر ظرفیت را افزایش می‌دهید - اما با یک کلاستر بسیار بزرگ، ممکن است لازم باشد محدودیت‌های CPU یا حافظه را کمی افزایش دهید.

مقیاس پذیر خودکار عمودی می‌تواند در حالت recommender اجرا شود تا ارقام پیشنهادی برای درخواست‌ها و محدودیت‌ها را ارائه دهد.

• برخی افزونه‌ها به صورت یک رونوشت در هر گره اجرا می‌شوند که توسط DaemonSet کنترل می‌شوند: به عنوان مثال، یک تجمیع‌کننده لاگ در سطح گره. مشابه مورد افزونه‌های مقیاس‌پذیر افقی، ممکن است لازم باشد محدودیت‌های CPU یا حافظه را کمی افزایش دهید.

گام‌های بعدی

• VerticalPodAutoscaler یک منبع سفارشی است که می‌توانید در کلاستر خود مستقر کنید تا به شما در مدیریت درخواست‌های منابع و محدودیت‌های podها کمک کند. درباره مقیاس پذیر خودکار عمودی و نحوه استفاده از آن برای مقیاس‌بندی اجزای کلاستر، از جمله افزونه‌های حیاتی کلاستر، بیشتر بدانید.

• درباره مقیاس‌بندی خودکار گره بخوانید

• تغییر اندازه افزونه به شما کمک می‌کند تا با تغییر مقیاس کلاستر، اندازه افزونه‌ها را به طور خودکار تغییر دهید.