پیکوسیستم خدمات فنی IT
دواپس و اتوماسیون

راه اندازی کلاستر کوبرنتیز و پشتیبانی Kubernetes

کوبرنتیز ابزار قدرتمندی است، اما کلاستری که بد ساخته شده خودش باعث قطعی می شود، و برای همین راه اندازی کلاستر کوبرنتیز را از طراحی نودها و شبکه شروع می کنیم. کلاستر را با چند نود کنترل (control plane) می سازیم و بکاپ، مانیتورینگ و به روزرسانی را از روز اول در طراحی می آوریم.

ابزارها و فناوری ها kubernetes
  • Kubernetes
  • kubeadm
  • RKE2
  • Rancher
  • Helm
  • Calico
  • Longhorn
  • Velero
  • cert-manager
  • ingress-nginx
6بخش کار
4خروجی
4مرحله

کلاستر کوبرنتیز چیست؟

راه اندازی کلاستر کوبرنتیز یعنی ساختن گروهی از سرورها که کانتینرها را با هم اجرا می کنند، طوری که اگر یک سرور از کار بیفتد، بارش به بقیه منتقل شود. وقتش معمولاً زمانی است که تعداد سرویس ها آن قدر زیاد شده که مدیریت دستی کانتینرها جواب نمی دهد، یا کلاستری که خودتان ساخته اید به جایی رسیده که کسی جرأت به روزرسانی اش را ندارد. پیکوسیستم نودهای control plane و worker را طراحی می کند و کلاستر را با kubeadm یا RKE2 روی سرورهای خود شما یا روی کوبرنتیز ابری نصب می کند. ذخیره سازی با Longhorn یا Ceph راه می افتد، بکاپ با snapshot از etcd و Velero گرفته می شود و هر تیم namespace و RBAC خودش را دارد. سرویس ها با Helm chart یکی یکی منتقل می شوند. تحویلی شامل kubeconfig برای هر نقش، chartها در گیت، runbook به روزرسانی و بازیابی etcd و نمودار معماری کلاستر است.

چه زمانی به کلاستر کوبرنتیز نیاز دارید؟

  • تعداد سرویس ها زیاد شده و مدیریت کانتینرها با دست دیگر جواب نمی دهد.
  • کلاستر را خودمان راه انداختیم ولی کسی جرأت به روزرسانی اش را ندارد.
  • گواهی های کلاستر منقضی شد و همه سرویس ها از کار افتادند.
  • می خواهیم با زیاد شدن ترافیک، تعداد podها خودکار بیشتر شود.

کلاستر کوبرنتیز شامل چه کارهایی است؟

01

طراحی کلاستر

تعیین تعداد نودهای control plane و worker، انتخاب شبکه pod با Calico یا Cilium و جای etcd، بر اساس بار و بودجه شما.

02

نصب و پیکربندی

نصب با kubeadm یا RKE2، تنظیم Ingress Controller، cert-manager برای گواهی ها و MetalLB برای سرورهایی که Load Balancer ابری ندارند.

03

ذخیره سازی و بکاپ

راه اندازی StorageClass با Longhorn یا Ceph، بکاپ منظم etcd و بکاپ منابع و volumeها با Velero.

04

دسترسی و امنیت

تعریف namespace و RBAC برای هر تیم، NetworkPolicy، سقف منابع (ResourceQuota) و Pod Security Standards.

05

انتقال سرویس ها

نوشتن manifest یا Helm chart برای سرویس های فعلی و انتقال مرحله ای آن ها از Docker Compose یا سرورهای معمولی.

06

نگهداری کلاستر

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

بعد از کلاستر کوبرنتیز چه چیزی تحویل می گیرید؟

  • کلاستر آماده با kubeconfig جداگانه برای هر نقش
  • Helm chart یا manifest سرویس ها در مخزن گیت
  • runbook به روزرسانی کلاستر، بازیابی etcd و افزودن نود
  • نمودار معماری کلاستر و شبکه

راهنمای کلاستر کوبرنتیز

kubeadm، RKE2 یا k3s؟ کدام برای کلاستر کوبرنتیز شما مناسب است؟

kubeadm همان کوبرنتیز استاندارد است و کنترل کامل می دهد، ولی تمدید گواهی ها و به روزرسانی نود به نود با خود شماست. گواهی هایی که kubeadm می سازد به طور پیش فرض یک سال اعتبار دارند و اگر در این مدت کلاستر به روز نشود یا kubeadm certs renew اجرا نشود، API Server دیگر اتصال ها را نمی پذیرد.

RKE2 تنظیمات امن تری به صورت پیش فرض دارد، etcd را داخل خودش اجرا می کند و به روزرسانی ساده تری دارد؛ برای کلاستر عملیاتی روی سرورهای خودتان معمولاً آن را پیشنهاد می کنیم. k3s سبک است و برای محیط تست، سرورهای کم منبع یا شعبه ها مناسب است. در کوبرنتیز ابری ارائه دهندگان داخلی، control plane با ارائه دهنده است و تصمیم اصلی شما به ذخیره سازی و شبکه برمی گردد.

مهاجرت به کوبرنتیز: برنامه شما چه آمادگی لازم دارد؟

pod ممکن است هر لحظه روی نود دیگری ساخته شود، پس برنامه نباید به فایل محلی یا IP ثابت وابسته باشد. باید سیگنال SIGTERM را بگیرد و درخواست های نیمه کاره را تمام کند، و مسیرهای جداگانه برای readinessProbe و livenessProbe داشته باشد.

برای هر سرویس هم باید requests و limits حافظه و CPU مشخص شود. بدون آن ها scheduler نمی داند pod را کجا بگذارد و یک سرویس پرمصرف می تواند نود را برای بقیه از کار بیندازد. چون دسترسی به registry.k8s.io و Docker Hub از ایران همیشه پایدار نیست، mirror ایمیج ها باید پیش از نصب در تنظیمات containerd تعریف شود.

تنظیم هایی که در کلاسترهای کوبرنتیز زیاد اشتباه انجام می شود

etcd به تأخیر نوشتن روی دیسک حساس است. اجرای آن روی دیسک کند یا ذخیره سازی مشترک شلوغ، باعث انتخاب های پی در پی leader و ناپایداری کل کلاستر می شود. نودهای control plane باید دیسک SSD و ترجیحاً اختصاصی داشته باشند.

Secretها در حالت پیش فرض فقط با base64 در etcd ذخیره می شوند، پس بدون EncryptionConfiguration هر کسی که به بکاپ etcd دسترسی داشته باشد رمزها را می بیند. نبودن PodDisruptionBudget باعث می شود هنگام drain کردن نود برای به روزرسانی، همه replicaهای یک سرویس با هم خاموش شوند. اتصال همه تیم ها با یک kubeconfig مدیر هم هیچ ردی از تغییر دهنده باقی نمی گذارد.

چه چیزهایی هزینه راه اندازی کلاستر کوبرنتیز را بالا می برد؟

عامل اصلی تعداد و اندازه نودهاست و انتخاب ذخیره سازی هم اثر زیادی دارد. Longhorn روی همان نودهای worker اجرا می شود و نگهداری ساده تری دارد. Ceph برای حجم بالا مناسب تر است ولی دیسک، شبکه و دانش نگهداری بیشتری می خواهد.

بعد از این ها نوبت تعداد سرویس هایی است که باید برایشان Helm chart یا manifest نوشته شود، و همین طور نیاز به چند کلاستر و Rancher، اتصال به احراز هویت سازمان، الزامات امنیتی مثل NetworkPolicy در همه namespaceها و وجود یا نبود رجیستری و پایپ لاین استقرار.

مراحل کلاستر کوبرنتیز

  1. 01

    بررسی نیاز

    بعد از شناختن سرویس ها، حجم بار، زیرساخت موجود و توان تیم شما برای نگهداری، معماری پیشنهادی را ارائه می دهیم.

  2. 02

    کلاستر آزمایشی

    یک کلاستر تست می سازیم و یکی دو سرویس را روی آن اجرا می کنیم تا طراحی پیش از محیط اصلی سنجیده شود.

  3. 03

    راه اندازی و انتقال

    کلاستر اصلی را می سازیم و سرویس ها را یکی یکی و با امکان برگشت منتقل می کنیم.

  4. 04

    تحویل و پشتیبانی

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

سؤالات متداول درباره کلاستر کوبرنتیز

کوبرنتیز را روی سرورهای خودمان راه می اندازید یا فقط کوبرنتیز ابری؟

روی هر دو کار می کنیم: سرور فیزیکی، ماشین های مجازی Proxmox یا VMware و سرویس کوبرنتیز ابری ارائه دهندگان داخلی. گزینه را بر اساس بودجه، حجم بار و توان تیم شما برای نگهداری پیشنهاد می دهیم.

کلاستر کوبرنتیز چیست و حداقل چند سرور لازم دارد؟

کلاستر کوبرنتیز گروهی از سرورهاست که کانتینرها را با هم اجرا می کنند و اگر یکی از کار بیفتد، بار را به بقیه می سپارند. برای محیط عملیاتی معمولاً سه نود control plane و دست کم دو نود worker پیشنهاد می کنیم تا از دست رفتن یک سرور کلاستر را از کار نیندازد، ولی محیط تست با یک یا دو سرور هم راه می افتد. عدد دقیق را بار سرویس های شما تعیین می کند.

Rancher را هم نصب می کنید؟

اگر تیم شما رابط گرافیکی برای مدیریت چند کلاستر می خواهد، Rancher را نصب و به احراز هویت سازمان وصل می کنیم. برای یک کلاستر کوچک گاهی kubectl و یک داشبورد ساده کافی است.

بعد از راه اندازی، نگهداری کلاستر با کیست؟

می توانیم تیم شما را آموزش دهیم و runbookها را تحویل دهیم، یا مدیریت کوبرنتیز را در قالب قرارداد پشتیبانی بر عهده بگیریم. دامنه کار و زمان پاسخ در قرارداد نوشته می شود.

جست وجوهای مرتبط

  • کلاستر کوبرنتیز
  • کوبرنتیز مدیریت شده
  • کوبرنتیز ابری
  • کلاستر کوبرنتیز چیست
  • داکر و کوبرنتیز
  • Rancher

مقاله های مرتبط

استعلام

کارتان را بگویید، مسیر و هزینه را می گوییم

چند خط درباره وضعیت فعلی و چیزی که می خواهید بنویسید. یک مهندس خودش با شما تماس می گیرد و درخواست به واحد فروش نمی رود.

  1. 01درخواست را می خوانیم و اگر ابهامی بود تماس می گیریم.
  2. 02در صورت نیاز، بررسی اولیه ریموت یا بازدید انجام می شود.
  3. 03پیشنهاد مکتوب با دامنه کار، زمان بندی و هزینه می فرستیم.

اطلاعات شما فقط برای پاسخ به همین درخواست استفاده می شود. حریم خصوصی