طراحی کلاستر
تعیین تعداد نودهای control plane و worker، انتخاب شبکه pod با Calico یا Cilium و جای etcd، بر اساس بار و بودجه شما.
شروع و ارزیابی
ارزیابی رایگان 5مشکل فوری
خدمات فوری 4پشتیبانی مستمر
قرارداد پشتیبانی 5پروژه ها
سرور و هاستینگ 6 شبکه و مجازی سازی 9 دواپس و اتوماسیون 5 امنیت و بازیابی 5 تجهیزات و لایسنس 2 اینترنت اشیا و هوشمندسازی 3بدون هزینه بفهمید وضعیت سرور، امنیت، بکاپ و سرعت سیستم هایتان چطور است.
سرور یا شبکه قطع است، سایت هک شده یا اطلاعات از دست رفته؟ همین حالا تماس بگیرید.
پشتیبانی و نگهداری ماهانه شبکه و سرور با زمان پاسخ مشخص در قرارداد.
نصب، کانفیگ، مدیریت و انتقال سرورهای لینوکس، ویندوز، کنترل پنل ها و ایمیل سرور.
طراحی و اجرای شبکه، میکروتیک، ویپ، اتصال شعب، مجازی سازی و ابر خصوصی.
شبکه و ارتباطات
مجازی سازی و ابر
کانتینر، کوبرنتیز، استقرار خودکار، زیرساخت به عنوان کد و مانیتورینگ پیشرفته.
امن سازی سرور، فایروال، بکاپ و DR، بازیابی از باج افزار و بررسی حملات.
مشاوره، تأمین و نصب سرور و تجهیزات شبکه، و لایسنس اورجینال نرم افزارهای سازمانی.
خانه، محیط کار و تجهیزات متصل؛ از انتخاب سناریو تا کنترل و پایش.
شروع و ارزیابی
مشکل فوری
پشتیبانی مستمر
پروژه ها
کوبرنتیز ابزار قدرتمندی است، اما کلاستری که بد ساخته شده خودش باعث قطعی می شود، و برای همین راه اندازی کلاستر کوبرنتیز را از طراحی نودها و شبکه شروع می کنیم. کلاستر را با چند نود کنترل (control plane) می سازیم و بکاپ، مانیتورینگ و به روزرسانی را از روز اول در طراحی می آوریم.
راه اندازی کلاستر کوبرنتیز یعنی ساختن گروهی از سرورها که کانتینرها را با هم اجرا می کنند، طوری که اگر یک سرور از کار بیفتد، بارش به بقیه منتقل شود. وقتش معمولاً زمانی است که تعداد سرویس ها آن قدر زیاد شده که مدیریت دستی کانتینرها جواب نمی دهد، یا کلاستری که خودتان ساخته اید به جایی رسیده که کسی جرأت به روزرسانی اش را ندارد. پیکوسیستم نودهای control plane و worker را طراحی می کند و کلاستر را با kubeadm یا RKE2 روی سرورهای خود شما یا روی کوبرنتیز ابری نصب می کند. ذخیره سازی با Longhorn یا Ceph راه می افتد، بکاپ با snapshot از etcd و Velero گرفته می شود و هر تیم namespace و RBAC خودش را دارد. سرویس ها با Helm chart یکی یکی منتقل می شوند. تحویلی شامل kubeconfig برای هر نقش، chartها در گیت، runbook به روزرسانی و بازیابی etcd و نمودار معماری کلاستر است.
تعیین تعداد نودهای control plane و worker، انتخاب شبکه pod با Calico یا Cilium و جای etcd، بر اساس بار و بودجه شما.
نصب با 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، تمدید گواهی ها، بررسی سلامت نودها و رفع مشکل، با دامنه کار و زمان پاسخی که در قرارداد می آید.
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ها و وجود یا نبود رجیستری و پایپ لاین استقرار.
بعد از شناختن سرویس ها، حجم بار، زیرساخت موجود و توان تیم شما برای نگهداری، معماری پیشنهادی را ارائه می دهیم.
یک کلاستر تست می سازیم و یکی دو سرویس را روی آن اجرا می کنیم تا طراحی پیش از محیط اصلی سنجیده شود.
کلاستر اصلی را می سازیم و سرویس ها را یکی یکی و با امکان برگشت منتقل می کنیم.
تیم شما مستندات و دسترسی ها را می گیرد و آموزش می بیند. اگر بخواهید، نگهداری در قالب قرارداد با ما ادامه پیدا می کند.
روی هر دو کار می کنیم: سرور فیزیکی، ماشین های مجازی Proxmox یا VMware و سرویس کوبرنتیز ابری ارائه دهندگان داخلی. گزینه را بر اساس بودجه، حجم بار و توان تیم شما برای نگهداری پیشنهاد می دهیم.
کلاستر کوبرنتیز گروهی از سرورهاست که کانتینرها را با هم اجرا می کنند و اگر یکی از کار بیفتد، بار را به بقیه می سپارند. برای محیط عملیاتی معمولاً سه نود control plane و دست کم دو نود worker پیشنهاد می کنیم تا از دست رفتن یک سرور کلاستر را از کار نیندازد، ولی محیط تست با یک یا دو سرور هم راه می افتد. عدد دقیق را بار سرویس های شما تعیین می کند.
اگر تیم شما رابط گرافیکی برای مدیریت چند کلاستر می خواهد، Rancher را نصب و به احراز هویت سازمان وصل می کنیم. برای یک کلاستر کوچک گاهی kubectl و یک داشبورد ساده کافی است.
می توانیم تیم شما را آموزش دهیم و runbookها را تحویل دهیم، یا مدیریت کوبرنتیز را در قالب قرارداد پشتیبانی بر عهده بگیریم. دامنه کار و زمان پاسخ در قرارداد نوشته می شود.
جست وجوهای مرتبط
دواپس
دواپس
دواپس
دواپس
دواپس استعلام
چند خط درباره وضعیت فعلی و چیزی که می خواهید بنویسید. یک مهندس خودش با شما تماس می گیرد و درخواست به واحد فروش نمی رود.