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

کوبرنتیز به سازمان‌ها با دیتابیس داخلی اجازه می دهد از زیرساخت‌ها و برنامه‌های کاربردی ابری بدون توجه به ارائه دهندگان ابر عمومی و میزبانی بهره‌مند شوند. بهترین معماری کوبرنتیز برای سازمان شما به نیازها و اهداف شما بستگی دارد. Kubernetes اغلب به عنوان یک فناوری کلود نیتیو توصیف می شود و مطمئناً مناسب آن است. با این حال، مفهوم Cloud-Native استفاده از زیرساخت داخلی در مواردی که منطقی است را حذف نمی کند. بسته به نیازهای سازمان شما در مورد انطباق، موقعیت مکانی، معماری فعلی و هزینه اجرای ورکلودهای شما، ممکن است مزایای قابل توجهی برای اجرای استقرار کوبرنتیز در محل وجود داشته باشد.

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

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

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

چرا سازمان‌ها تصمیم می‌گیرند کوبرنتیز را در دیتاسنتر خودشان اجرا کنند، در مقایسه نسبی با روش ساده ابر عمومی؟ معمولاً چند دلیل مهم وجود دارد که چرا یک شرکت ممکن است در استراتژی داخلی کوبرنتیز سرمایه گذاری کند:

1- امنیت و حفظ حریم خصوصی داده‌ها

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

2- خط مشی‌های سازمان

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

3- ابر آگنوستیک شدن برای جلوگیری از قفل شدن

بسیاری از شرکت‌ها ممکن است مایل نباشند به یک ارائه‌دهنده ابر متصل باشند و از این رو ممکن است بخواهند برنامه‌های خود را در چندین ابر، از جمله یک ابر خصوصی داخلی، مستقر کنند. این به طور بالقوه می تواند خطر تداوم کسب و کار را به دلیل مشکلات با یک ارائه دهنده ابر خاص کاهش دهد. همچنین به شما اهرمی در مورد مذاکره قیمت با ارائه دهندگان ابری خود می دهد.

4- هزینه

هزینه، احتمالاً مهمترین دلیل برای اجرای کوبرنتیز درون سازمانی است. اجرای همه برنامه های شما در فضای ابری عمومی می تواند در مقیاس، گران تمام شود. به طور خاص، اگر برنامه‌های کاربردی شما متکی به دریافت و پردازش مقادیر زیادی از داده هستند، مانند برنامه‌های AI/ML، یک ابر عمومی می‌تواند بسیار گران باشد. اگر دیتاسنتر سازمانی یا یک مرکز میزبانی مشترک دارید، اجرای Kubernetes در محل می‌تواند راهی موثر برای کاهش هزینه‌های عملیاتی شما باشد.

طبق گزارشی از a16z در سال 2021، «مشخص شده است که در حالی که ابر به وضوح در اوایل شروع کار یک شرکت به وعده خود عمل می کند، فشاری که بر حاشیه ها وارد می کند می تواند از مزایای آن بیشتر باشد، زیرا یک شرکت مقیاس می گیرد و رشد کند می شود. از آنجایی که این تغییر بعداً در مسیر یک شرکت اتفاق می‌افتد، تغییر آن دشوار است زیرا نتیجه سال‌ها توسعه متمرکز بر ویژگی‌های جدید است و نه بهینه‌سازی زیرساخت.

استراتژی موثر کوبرنتیز که در دیتاسنتر شما اجرا می‌شود، می‌تواند برای متحول کردن کسب‌وکار شما و مدرن‌سازی برنامه‌های کاربردی شما برای کلود نیتیو استفاده شود. در حالی که همزمان استفاده از زیرساخت را بهبود می‌بخشد و در هزینه‌ها نیز صرفه‌جویی می‌کند.

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

آیا تا به حال سعی کرده‌اید که با استفاده از زیرساخت‌های برمتال خود، کلاسترهای کوبرنتیز را مستقر کنید؟ با تمام مزایایی که پیش‌تر گفته شد، اجرای کوبرنتیز درون سازمانی دارای یک نقطه ضعف است، انجام توسط خودتان یا خودمدیریتی. کوبرنتیز به منحنی یادگیری شیب‌دار و پیچیدگی عملیاتیش شناخته شده است. هنگام استفاده از Kubernetes در AWS یا Azure، ارائه دهنده ابرعمومی شما اساساً پیچیدگی ها را ساده می کند. اجرای کوبرنتیز درون سازمانی به این معنی است که شما تنها هستید. در اینجا مناطق خاصی وجود دارد که این چالش می تواند بیشتر آشکار شود:

·   Etcd

کلاستر etcd همیشه در دسترس را مدیریت کنید. برای اطمینان از تداوم کسب و کار در صورتی که کلاستر از کار بیفتد و داده‌های etcd از بین برود، باید مکرراً نسخه پشتیبان تهیه کنید.

·   متعادل‌سازی بار

 تعادل بار ممکن است هم برای نودهای اصلی کلاستر و هم برای سرویس‌های برنامه‌ای که در کوبرنتیز اجرا می‌شوند مورد نیاز باشد. بسته به تنظیمات شبکه موجود، ممکن است بخواهید از متعادل کننده بار مانند F5 یا نرم افزار متعادل کننده مانند metallb استفاده کنید.

·   در دسترس بودن

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

·   مقیاس‌بندی خودکار

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

·   شبکه‌سازی

 شبکه‌سازی برای پیکربندی مرکز داده شما بسیار خاص است.

·   ذخیره سازی دائمی

 اکثر ورکلودهای تولیدی شما که در کوبرنتیز اجرا می شوند به ذخیره سازی دائمی نیاز دارند - ذخیره سازی بلوک یا فایل. خبر خوب این است که اکثر فروشندگان محبوب ذخیره سازی سازمانی دارای پلاگین CSI و ادغام با کوبرنتیز هستند. قبل از اینکه بتوانید راه حل ذخیره سازی موجود خود را با کوبرنتیز درون سازمانی ادغام کنید، باید با فروشنده فضای ذخیره سازی خود کار کنید تا افزونه مناسب را شناسایی کرده و اجزای مورد نیاز را نصب کنید.

·   آپگریدها

 زمانی که نسخه جدید کوبرنتیز منتشر می شود، تقریباً هر 3 ماه یکبار باید کلاسترهای خود را ارتقا دهید. اگر ناسازگاری های API با نسخه جدیدتر معرفی شده باشد، ممکن است ارتقاء نسخه مشکلاتی ایجاد کند. یک استراتژی ارتقای مرحله‌ای، که در آن ابتدا کلاسترهای توسعه/آزمایش شما قبل از ارتقاء کلاسترهای تولید شما ارتقا می‌یابند، توصیه می‌شود.

·   نظارت

 برای مانیتورینگ بر سلامت کلاسترهای کوبرنتیز در کوبرنتیز درون سازمانی باید روی ابزارهایی سرمایه‌گذاری کنید. اکثر ابزارهای مانیتورینگ و مدیریت گزارش دارای قابلیت های خاصی در مورد نظارت K8s هستند. اگر قبلاً از Datadog، Splunk یا ابزارهای مشابه استفاده کرده‌اید، می‌توانید پیاده‌سازی کوبرنتیز خود را در prem نظارت کنید. یا ممکن است سرمایه گذاری در استک منبع باز مانیتورینگ را در نظر بگیرید که به شما کمک می کند تا کلاسترهای کوبرنتیز مانند Prometheus و Grafana را نظارت کنید.

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

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

ادغام با محیط موجود

کوبرنتیز کاربران را قادر می سازد تا کلاسترها را در زیرساخت های مختلف درون سازمانی اجرا کنند. بنابراین می‌توانید محیط خود را برای ادغام با Kubernetes، با استفاده از ماشین‌های مجازی یا ایجاد کلاستر خود از ابتدا روی برمتال تغییر دهید. اما برای انجام این کار، باید درک عمیقی از ویژگی‌های استقرار Kubernetes در محیط موجود، از جمله سرورها، سیستم‌های ذخیره‌سازی و زیرساخت‌های شبکه خود ایجاد کنید تا یک محیط تولید K8s به خوبی پیکربندی شده باشد.

سه روش محبوب برای استقرار Kubernetes درون سازمانی عبارتند از:

1-    ماشین های مجازی در محیط VMware vSphere موجود شما

2-    سرورهای فیزیکی لینوکس که Ubuntu، CentOS یا RHEL Linux را اجرا می کنند

3-    ماشین‌های مجازی در انواع دیگر محیط‌های IaaS در محل، مانند OpenStack

اجرای Kubernetes بر روی سرورهای فیزیکی می تواند عملکرد سخت افزاری بومی را به شما ارائه دهد که ممکن است برای انواع خاصی از ورک‌لودها حیاتی باشد. با این حال، ممکن است توانایی شما در مقیاس‌بندی سریع زیرساخت خود را محدود کند. اگر به دست آوردن عملکرد برمتال برای شما مهم است و اگر نیاز به اجرای کلاسترهای کوبرنتیز در مقیاس دارید، سرمایه گذاری در یک پلت فرم اتوماسیون برمتال مانند Ironic، Metal3، یا یک استک برمتال مدیریت شده مانند برمتال مدیریت شده پشتیبان استک را در نظر بگیرید.

اجرای کوبرنتیز بر روی ماشین‌های مجازی در فضای ابری خصوصی خود در VMware یا KVM می‌تواند انعطاف‌پذیری ابر را به شما بدهد، زیرا می‌توانید به‌طور پویا کلاسترهای کوبرنتیز خود را بر اساس تقاضای حجم کار، افزایش یا کاهش دهید. کلاسترهای ایجاد شده در ماشین‌های مجازی نیز به راحتی تنظیم و از بین می‌روند و ایجاد محیط‌های آزمایشی زودگذر برای توسعه‌دهندگان را آسان می‌کند.

پرسنل تیم شما

بنیاد محاسبات بومی ابری (CNCF) گواهینامه‌هایی مانند Certified Kubernetes Administrator (CKA) و Certified Kubernetes Application Developer (CKAD) را معرفی کرده است. گواهینامه‌ها روش خوبی برای ارزیابی مهارت‌های کوبرنتیز هستند. یک راه عالی برای اطمینان از داشتن مهارت‌های مناسب برای پیاده سازی کوبرنتیز درون سازمانی، آموزش یا استخدام اعضای تیم با این گواهینامه‌ها است.

شما همچنین باید برای پروژه Kubernetes سازمانی DIY برنامه ریزی کنید تا پروژه‌های چند ماهه (و حتی چند ساله) را با آن برنامه ریزی کنید و در عین حال سعی کنید اجزای منبع باز را در مقیاس کنترل کنید و به طور موثر مدیریت کنید. اگر به درستی برای آن برنامه ریزی نشود، می‌تواند هزینه‌ها را جمع کند و زمان عرضه به بازار را به تاخیر بیاندازد.

پیکربندی نود

برای استقرار آزمایشی، کوبرنتیز می‌تواند روی یک سرور اجرا شود که می‌تواند هم به عنوان یک نود اصلی و هم به عنوان نود کارگر برای کلاستر عمل کند. اما برای اجرای یک برنامه کاربردی معنی دار در عمل، حداقل به سه سرور نیاز دارید: یکی برای همه اجزای اصلی، که شامل تمام اجزای صفحه کنترل مانند kube-apiserver، etcd، kube-scheduler و kube-controller-manager است و دو تا برای نودهای کارگر که در آن‌ها kubelet را اجرا می‌کنید.

در حالی که کامپوننت‌های اصلی می‌توانند بر روی هر ماشینی اجرا شوند، بهترین عمل مستلزم استفاده از مجموعه جداگانه‌ای از سرورها برای گره‌های اصلی و اجرا نکردن هیچ یک از کانتینرهای برنامه شما در این ماشین‌ها است.

یکی از ویژگی های کلیدی کوبرنتیز توانایی بازیابی از خرابی ها بدون از دست دادن اطلاعات است. این کار را با یک سیستم "سیاسی" از رهبران، انتخابات، و اصطلاحات - که به عنوان حد نصاب نامیده می شود - انجام می دهد که به سخت افزار "خوب" نیاز دارد تا این قابلیت را به درستی انجام دهد. برای اینکه هم در دسترس و هم قابل بازیابی باشد، توصیه می‌شود که سه نود را به عنوان نود اصلی با 4 گیگابایت رم و 16 گیگابایت SSD به این کار اختصاص دهید، که حداقل سه نود و حداکثر هفت نود برای گره‌های اصلی هستند.

SSD در اینجا توصیه می شود زیرا etcd روی دیسک می نویسد و کوچکترین تاخیر می تواند بر عملکرد تأثیر منفی بگذارد. در نهایت، همیشه اعضای کلاستر به تعداد فرد داشته باشید تا بتوان به اکثریت رسید.

برای محیط های تولیدی، برای اجرای اتوماسیون به یک نود متعادل کننده بار اختصاصی HAProxy و همچنین یک ماشین کلاینت نیاز دارید.

همچنین بهتر است که به طور قابل توجهی بیشتر از حداقل نیازهای کوبرنتیز قدرت داشته باشید. سرورهای مدرن کوبرنتیز معمولاً دارای دو CPU با هر کدام 32 هسته، 2 ترابایت رم تصحیح کننده خطا، و حداقل چهار SSD، هشت SSD SATA و چند کارت شبکه 10G هستند.

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

پیکربندی Etcd

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

برای استفاده در تولید، که در دسترس بودن و افزونگی فاکتورهای مهمی هستند، اجرای etcd به عنوان یک کلاستر حیاتی است. ایجاد یک کلاستر etcd ایمن - به ویژه در سازمان - شامل دانلود باینری های مناسب، نوشتن پیکربندی اولیه کلاستر در هر نود etcd، و تنظیم و آوردن etcd است. این علاوه بر پیکربندی مرجع و گواهی برای اتصالات ایمن است. برای اجرای آسان‌تر خوشه etcd به صورت on-prem، ابزار منبع باز etcdadm را بررسی کنید.

مخازن

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

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

به خاطر داشته باشید که هنگام اجرای کوبرنتیز در دیتاسنتر خود، باید همه ادغام های ذخیره سازی، متعادل کننده های بار و DNS را مدیریت کنید.

علاوه بر این، هر یک از این مؤلفه‌ها - از ذخیره‌سازی گرفته تا شبکه - به سیستم‌های نظارت و هشدار خاص خود نیاز دارند و شما باید فرآیندهای داخلی خود را برای نظارت، عیب‌یابی و رفع هر گونه مشکل رایجی که ممکن است در این سرویس‌های مرتبط ایجاد شود، تنظیم کنید تا از سلامت محیط شما اطمینان حاصل شود.

رجیستری کانتینر

یک رجیستری کانتینر شما را قادر می سازد تا تصاویر کانتینر را برای برنامه های خود به شیوه ای امن و بسیار در دسترس ذخیره کنید. حتی هنگام استقرار کلاسترهای کوبرنتیز در سازمان، می توانید از گزینه های رجیستری میزبانی شده مانند ECR، داکر هاب و غیره استفاده کنید. اگر رجیستری کانتینر شما باید در سازمان میزبانی شود، Harbor منبع باز گزینه خوبی است، اگرچه باید پیچیدگی آن را ارزیابی کنید.

UI

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

عیب یابی

بهترین روش‌ شامل بررسی همیشه گزارش‌ها در مواقعی که مشکلی پیش می‌آید با جستجو در فایل‌های syslog شماست.

خدمات اضافی

این مرحله می‌تواند بسیار سرگرم‌کننده باشد زیرا می‌توانید با تمام ابزارهای موجود در صنعت آزمایش کنید. یا یک مشکل بزرگ، بسته به زیرساخت‌ها و پیچیدگی فرآیندها.

Weaveworks و Flannel هر دو ابزارهای شبکه‌ای عالی هستند، در حالی که Istio و Linkerd گزینه‌های خدمات محبوب مش هستند. Grafana و Prometheus به نظارت کمک می‌کنند و تعدادی ابزار برای خودکارسازی CI/CD مانند Jenkins، Bamboo و JenkinsX وجود دارد.

امنیت یک نگرانی عمده است. هر مؤلفه منبع باز باید از نظر تهدیدها و آسیب پذیری ها اسکن شود. به‌علاوه، پیگیری به‌روزرسانی‌ها و اتصال نسخه و سپس مدیریت معرفی آن‌ها می‌تواند کار فشرده‌ای باشد، به‌ویژه اگر سرویس‌های اضافی زیادی در حال اجرا دارید.

توجه داشته باشید که کوبرنتیز به تنهایی هرگز برای برنامه های تولید در دنیای واقعی کافی نیست. یک زیرساخت کامل Kubernetes on-prem به DNS مناسب، تعادل بار، Ingress و کنترل دسترسی مبتنی بر نقش K8 (RBAC) در کنار تعداد زیادی مؤلفه اضافی نیاز دارد که فرآیند استقرار را برای IT بسیار دلهره آور می کند.

پس از استقرار Kubernetes، نظارت، ردیابی، ثبت و همه عملیات های مرتبط برای عیب یابی اضافه می شود - مانند زمانی که ظرفیت تمام می شود، اطمینان از HA، پشتیبان گیری و موارد دیگر.

نتیجه

از آنجایی که Kubernetes در ابتدا برای ابر ساخته شده بود، استقرار کلاسترهای داخلی چالش‌های زیادی را به همراه دارد. با این حال، کوبرنتیز به دیتاسنتر سازمانی کمک می‌کند از برنامه‌ها و زیرساخت‌های داخلی ابری، صرف نظر از میزبانی یا ارائه‌دهندگان ابر عمومی بهره‌مند شوند. آن‌ها می‌توانند روی Openstack، KVM، VMware vSphere یا حتی برمتال باشند و همچنان از مزایای ابری که از ادغام با Kubernetes به دست می‌آیند، بهره ببرند.

کوبرنتیز درون سازمانی با پشتیبان استک

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