طراحی کلاستر
تعیین تعداد نودهای control plane و worker، انتخاب شبکه pod با Calico یا Cilium و جای etcd، بر اساس بار و بودجه شما.
دواپس و اتوماسیون
راه اندازی کلاستر کوبرنتیز و پشتیبانی 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ها خودکار بیشتر شود.
کلاستر کوبرنتیز شامل چه کارهایی است؟
نصب و پیکربندی
نصب با kubeadm یا RKE2، تنظیم Ingress Controller، cert-manager برای گواهی ها و MetalLB برای سرورهایی که Load Balancer ابری ندارند.
ذخیره سازی و بکاپ
راه اندازی StorageClass با Longhorn یا Ceph، بکاپ منظم etcd و بکاپ منابع و volumeها با Velero.
دسترسی و امنیت
تعریف namespace و RBAC برای هر تیم، NetworkPolicy، سقف منابع (ResourceQuota) و Pod Security Standards.
انتقال سرویس ها
نوشتن manifest یا Helm chart برای سرویس های فعلی و انتقال مرحله ای آن ها از Docker Compose یا سرورهای معمولی.
نگهداری کلاستر
به روزرسانی نسخه 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ها و وجود یا نبود رجیستری و پایپ لاین استقرار است.
مراحل کلاستر کوبرنتیز
-
01
بررسی نیاز
سرویس ها، حجم بار، زیرساخت موجود و توان تیم شما برای نگهداری را بررسی می کنیم و معماری پیشنهادی را ارائه می دهیم.
-
02
کلاستر آزمایشی
یک کلاستر تست می سازیم و یکی دو سرویس را روی آن اجرا می کنیم تا طراحی پیش از محیط اصلی سنجیده شود.
-
03
راه اندازی و انتقال
کلاستر اصلی را می سازیم و سرویس ها را یکی یکی و با امکان برگشت منتقل می کنیم.
-
04
تحویل و پشتیبانی
مستندات و دسترسی ها را تحویل می دهیم، تیم شما را آموزش می دهیم و در صورت نیاز نگهداری را در قالب قرارداد ادامه می دهیم.
سؤالات متداول درباره کلاستر کوبرنتیز
کوبرنتیز را روی سرورهای خودمان راه می اندازید یا فقط کوبرنتیز ابری؟
هر دو. روی سرور فیزیکی، ماشین های مجازی Proxmox یا VMware، یا سرویس کوبرنتیز ابری ارائه دهندگان داخلی کار می کنیم. گزینه را بر اساس بودجه، حجم بار و توان تیم شما برای نگهداری پیشنهاد می دهیم.
کلاستر کوبرنتیز چیست و حداقل چند سرور لازم دارد؟
کلاستر کوبرنتیز گروهی از سرورهاست که کانتینرها را با هم اجرا می کنند و اگر یکی از کار بیفتد، بار را به بقیه می سپارند. برای محیط عملیاتی معمولاً سه نود control plane و دست کم دو نود worker پیشنهاد می کنیم تا از دست رفتن یک سرور کلاستر را از کار نیندازد. برای محیط تست یک یا دو سرور کافی است. عدد دقیق به بار سرویس های شما بستگی دارد.
Rancher را هم نصب می کنید؟
اگر تیم شما رابط گرافیکی برای مدیریت چند کلاستر می خواهد، Rancher را نصب و به احراز هویت سازمان وصل می کنیم. برای یک کلاستر کوچک گاهی kubectl و یک داشبورد ساده کافی است.
بعد از راه اندازی، نگهداری کلاستر با کیست؟
می توانیم تیم شما را آموزش دهیم و runbookها را تحویل دهیم، یا مدیریت کوبرنتیز را در قالب قرارداد پشتیبانی بر عهده بگیریم. دامنه کار و زمان پاسخ در قرارداد نوشته می شود.
جست وجوهای مرتبط
- کلاستر کوبرنتیز
- کوبرنتیز مدیریت شده
- کوبرنتیز ابری
- کلاستر کوبرنتیز چیست
- داکر و کوبرنتیز
- Rancher
مقاله های مرتبط
-
دواپس آموزش نصب کوبرنتیز: راه اندازی کلاستر Kubernetes با kubeadm
راه اندازی کلاستر کوبرنتیز با kubeadm مسیر مشخصی دارد: آماده سازی نودها، نصب container runtime، ساخت نود کنترل، نصب CNI و اضافه کردن worker. این راهنما هر مرحله را با دستور واقعی و اشتباه های رایجش توضیح می دهد. -
دواپس چگونه داکر را نصب کنیم؟ نصب Docker روی Ubuntu و AlmaLinux
نصب داکر از مخزن رسمی چند دقیقه طول می کشد، ولی تنظیم درست کاربر، لاگ و پورت ها همان چیزی است که بعدا دردسر درست می کند. این راهنما نصب روی Ubuntu و AlmaLinux را با دستورهای واقعی نشان می دهد.
خدمات مرتبط
استعلام
کارتان را بگویید، مسیر و هزینه را می گوییم
چند خط درباره وضعیت فعلی و چیزی که می خواهید بنویسید. یک مهندس خودش تماس می گیرد، نه واحد فروش.
- 01درخواست را می خوانیم و اگر ابهامی بود تماس می گیریم.
- 02در صورت نیاز، بررسی اولیه ریموت یا بازدید انجام می شود.
- 03پیشنهاد مکتوب با دامنه کار، زمان بندی و هزینه می فرستیم.