معرفی روز 2 Kubernetes

در طول سال‌ها، من چندین پست وبلاگ در مورد Kubernetes به اشتراک گذاشته‌ام (کانتینرها و Kubernetes چیست، استقرار و استفاده از ابر مدرن، مقدمه‌ای بر سیستم‌های عامل کانتینر و موارد دیگر).

Kubernetes به یک استاندارد واقعی برای اجرای بارهای کاری مبتنی بر کانتینر (هم برای فضای داخلی و هم برای ابر عمومی) تبدیل شد، اما اکثر سازمان‌ها تمایل دارند در آنچه به عنوان عملیات روز 2 Kubernetes نامیده می‌شود، شکست بخورند.

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

آماده، به صف، شروع!

در چرخه حیات نرم افزار، یا در زمینه این پست، چرخه حیات Kubernetes، چندین مرحله متمایز وجود دارد:

روز 0 – برنامه ریزی و طراحی

در این مرحله، ما بر طراحی راه حل خود (کاربرد و زیرساخت های زیربنایی)، درک نیازهای کسب و کار، بودجه، مهارت های مورد نیاز و موارد دیگر تمرکز می کنیم.

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

روز 1 – پیکربندی و استقرار

در این مرحله، ما بر روی استقرار برنامه خود با استفاده از ارکستراتور Kubernetes و تنظیم تنظیمات (تعداد کپی ها، پورت های عمومی، تنظیمات مقیاس خودکار و موارد دیگر) تمرکز می کنیم.

اکثر سازمان هایی که اولین گام های خود را برای استقرار برنامه های کاربردی در Kubernetes برمی دارند در این مرحله انباشته می شوند.

آنها ممکن است چندین محیط (مانند Dev، Test، UAT) و شاید حتی حجم کاری تولید داشته باشند، اما هنوز در روز اول هستند.

روز 2 – عملیات

سازمان های بالغ به این مرحله رسیده اند.

این در مورد نگهداری مداوم، قابلیت مشاهده و بهبود مستمر جنبه های امنیتی بارهای کاری تولید است.

در این پست وبلاگ، من به “روز 2 Kubernetes” شیرجه خواهم زد.

چالش های روز دوم Kubernetes

در زیر رایج ترین چالش های Kubernetes آورده شده است:

قابلیت مشاهده

مدیریت Kubernetes در مقیاس بزرگ به بینش در مورد خوشه (های) Kubernetes نیاز دارد.

نظارت بر خوشه Kubernetes با جمع‌آوری گزارش‌های عملکرد، خطاها یا تغییرات پیکربندی (مانند Nodes، Pods، کانتینرها و غیره) کافی نیست.

ما باید توانایی درک واقعی درونیات خوشه Kubernetes (از گزارش‌ها، معیارها، و غیره) را داشته باشیم، بتوانیم رفتار خوشه Kubernetes را تشخیص دهیم – نه فقط مشکلات عملکرد، بلکه مشکلات اشکال‌زدایی، تشخیص ناهنجاری‌ها، و (امیدوارم) بتوانیم مشکلات را قبل از اینکه بر مشتریان تأثیر بگذارد، پیش بینی کنیم.

برای نظارت بر خوشه‌های Kubernetes ترجیح می‌دهید از ابزارهای نظارت و قابلیت مشاهده بومی ابری استفاده کنید.

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

ابزارهای رایج برای مشاهده پذیری:

• Prometheus – یک جعبه ابزار نظارت و هشدار سیستم های منبع باز برای نظارت بر استقرارهای بزرگ بومی ابری.

• Grafana – یک ابزار جستجو، تجسم و هشدار منبع باز (استفاده از منابع، معیارهای داخلی و سفارشی، هشدارها، داشبوردها، همبستگی گزارش و غیره)

• OpenTelemetry – مجموعه ای از ابزارهای منبع باز برای جمع آوری و صادر کردن داده های تله متری (متریک ها، گزارش ها و ردیابی ها) برای تجزیه و تحلیل عملکرد و رفتار نرم افزار.

مراجع اضافی برای خدمات مدیریت شده:

امنیت و حکومت

از یک طرف، استقرار یک خوشه Kubernetes در حالت خصوصی آسان است، به این معنی که سرور API یا Pods در یک زیرشبکه داخلی هستند و مستقیماً در معرض مشتریان نیستند.

از سوی دیگر، بسیاری از چالش ها در حوزه امنیتی باید حل شوند:

• مدیریت اسرار – یک انبار مرکزی و امن برای تولید، ذخیره، بازیابی، چرخش و در نهایت ابطال اسرار (به جای اعتبارنامه های ثابت کدگذاری شده در داخل کد یا فایل های پیکربندی ما).
• مکانیسم‌های کنترل دسترسی – با استفاده از مکانیسم‌های RBAC (کنترل دسترسی مبتنی بر نقش) می‌توانید کنترل کنید که چه شخصی (اعم از حساب انسانی یا سرویس) به منابع درون خوشه Kubernetes دسترسی دارد و چه اقداماتی انجام می‌دهد.
• آسیب‌پذیری‌های نرم‌افزار – هر گونه آسیب‌پذیری مرتبط با کد – از زبان‌های برنامه‌نویسی (مانند جاوا، پی‌اچ‌پی، دات‌نت، نود جی‌اس و غیره)، استفاده از کتابخانه‌های منبع باز با آسیب‌پذیری‌های شناخته‌شده، تا آسیب‌پذیری‌های داخل Infrastructure-as-Code (مانند Terraform). ماژول ها)
• سخت شدن – امکان استقرار یک خوشه Kubernetes در مقیاس، با استفاده از پیکربندی ایمن، مانند معیارهای CIS.
• شبکه‌سازی – امکان تنظیم جداسازی بین خوشه‌های مختلف Kubernetes یا حتی بین تیم‌های توسعه مختلف با استفاده از یک خوشه، به غیر از چند اجاره‌نشینی که در آن از یک پلت فرم Kubernetes برای ارائه خدمات به مشتریان مختلف استفاده می‌شود.

مراجع اضافی:

تجربه توسعه دهندگان

سازمان‌های بالغ قبلاً متدولوژی‌های DevOps را برای ارسال کد از طریق خط لوله CI/CD پذیرفته‌اند.

کل فرآیند باید به صورت خودکار و بدون دسترسی مستقیم توسعه دهندگان به محیط های تولید انجام شود (برای این منظور شما مکانیزم های شیشه شکسته را برای تیم های SRE می سازید).

سوئیچ به برنامه های پیچیده در داخل کانتینرها، به توسعه دهندگان این امکان را می دهد که به صورت محلی یا در فضای ابری توسعه دهند و نسخه های جدید کد خود را به محیط های مختلف (مانند Dev، Test و Prod) منتقل کنند.

ادغام خط لوله CI/CD، همراه با کانتینرها، به سازمان ها اجازه می دهد تا به طور مداوم نسخه های نرم افزاری جدید را توسعه دهند، اما نیاز به گسترش دانش توسعه دهندگان با استفاده از آموزش دارد.

استفاده از GitOps و ابزارهایی مانند Argo CD امکان یک فرآیند تحویل مداوم را برای محیط های Kubernetes فراهم می کند.

برای اینکه توسعه دهندگان بهترین تجربه را داشته باشند، باید فرآیند CI/CD را در محیط توسعه ادغام کنید و به تیم توسعه اجازه دهید همان تجربه توسعه هر برنامه دیگر را داشته باشد، همانطور که قبلاً در برنامه های کاربردی قدیمی انجام می دادند. می تواند فرآیند نصب برنامه نویس را سرعت بخشد.

مراجع اضافی:

ذخیره سازی

هر خوشه Kubernetes نیاز به ذخیره سازی دائمی دارد – چه سازمان ها انتخاب کنند که با یک خوشه Kubernetes داخلی شروع کنند و به ابر عمومی مهاجرت کنند، یا یک خوشه Kubernetes را با استفاده از یک سرویس مدیریت شده در ابر ارائه دهند.

Kubernetes از چندین نوع ذخیره سازی دائمی پشتیبانی می کند – از ذخیره سازی اشیا (مانند ذخیره سازی Azure Blob یا Google Cloud Storage)، ذخیره سازی بلوک (مانند Amazon EBS، Azure Disk یا Google Persistent Disk) یا ذخیره سازی اشتراک گذاری فایل (مانند Amazon EFS، Azure Files یا Google Cloud Filestore).

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

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

در دسترس بودن بالا

در دسترس بودن بالا یک نیاز رایج برای هر حجم کاری تولید است.

این واقعیت که ما باید چندین خوشه Kubernetes را حفظ کنیم (به عنوان مثال یک خوشه در هر محیطی مانند Dev، Test و Prod) و گاهی اوقات در بالای چندین ارائه دهنده ابر، کارها را چالش برانگیز می کند.

ما باید از قبل طراحی کنیم که در آن خوشه(های) خود را فراهم کنیم، به محدودیت هایی مانند چندین منطقه در دسترس فکر کنیم، و گاهی اوقات به نحوه ارائه چندین خوشه Kubernetes در مناطق مختلف فکر کنیم، در حالی که الزامات HA، تنظیمات، مدیریت اسرار و موارد دیگر را حفظ کنیم. .

طراحی و نگهداری HA در خوشه های Kubernetes نیاز به درک عمیقی از داخلی Kubernetes، همراه با دانش در مورد صفحه مدیریت Kubernetes ارائه دهندگان ابر خاص دارد.

مراجع اضافی:

بهینه سازی هزینه

هزینه یک عامل مهم در مدیریت محیط های ابری است.

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

برای نظارت بر هزینه، باید ابزارهای مدیریت هزینه (یا خدمات اساسی ارائه شده توسط ارائه دهنده ابر) یا ابزارهای مدیریت هزینه اختصاصی شخص ثالث را مستقر کنیم.

برای هر خوشه Kubernetes، ما باید در مورد اندازه نمونه گره (مقدار CPU/Memory) تصمیم بگیریم، و به مرور زمان، باید استفاده از گره را بررسی کنیم و سعی کنیم نوع نمونه را اندازه درست کنیم.

برای خوشه‌های غیرتولیدی (مانند Dev یا Test)، باید از مستندات فروشنده ابری بفهمیم که چه گزینه‌هایی وجود دارد تا اندازه خوشه را در زمانی که استفاده نمی‌کنیم به حداقل برسانیم، و بتوانیم آن را پشتیبان‌گیری کنیم. وقتی لازم باشه.

هر ارائه‌دهنده ابری گزینه‌های قیمت‌گذاری خود را برای تهیه خوشه‌های Kubernetes دارد – برای مثال، ممکن است بخواهیم نمونه‌های رزرو شده یا برنامه‌های ذخیره‌سازی را برای خوشه‌های تولیدی که ۲۴ ساعته در حال اجرا هستند انتخاب کنیم، در حالی که برای محیط موقت Dev یا Test، ممکن است بخواهیم Spot را انتخاب کنیم. نمونه ها و صرفه جویی در هزینه

مراجع اضافی:

شکاف دانش

اجرای خوشه های Kubernetes به دانش زیادی نیاز دارد.

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

سرمایه گذاری در آموزش کارکنان، در تمام جنبه های Kubernetes بسیار مهم است.

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

مراجع اضافی:

ادغام شخص ثالث

Kubernetes بخشی از مشکلات مربوط به ارکستراسیون کانتینر را حل می کند.

به عنوان یک راه حل منبع باز، می تواند با سایر راه حل های مکمل منبع باز (از نظارت، امنیت و حاکمیت، مدیریت هزینه و موارد دیگر) ادغام شود.

هر سازمانی ممکن است بخواهد از مجموعه متفاوتی از ابزارها برای دستیابی به هر وظیفه مربوط به نگهداری مداوم خوشه Kubernetes یا برای استقرار برنامه استفاده کند.

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

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

خلاصه

در این پست وبلاگ، رایج ترین چالش های روز دوم Kubernetes را بررسی کرده ام.

من نمی توانم به اندازه کافی بر اهمیت آموزش کارکنان در استقرار و حفظ خوشه های Kubernetes تاکید کنم.

ارزیابی و جستجوی یک پلت فرم مدیریت متمرکز برای استقرار، نظارت (با استفاده از ابزارهای بومی ابری) و ایمن سازی کل ناوگان خوشه های Kubernetes در سازمان به شدت توصیه می شود.

توصیه مهم دیگر سرمایه گذاری در اتوماسیون است – از اجرای سیاست گرفته تا استقرار و ارتقاء برنامه، به عنوان بخشی از خط لوله CI/CD.

به شما توصیه می‌کنم به یادگیری و گسترش دانش خود در دنیای تغییر مداوم Kubernetes ادامه دهید.

درباره نویسنده

ایال استرین معمار امنیت ابر و اطلاعات، صاحب وبلاگ Security & Cloud 24/7 و نویسنده کتاب Cloud Security Handbook با بیش از 20 سال سابقه در صنعت فناوری اطلاعات است.

Eyal از سال 2020 یک جامعه ساز AWS است.

می توانید با او ارتباط برقرار کنید توییتر و لینکدین