Kubernetes چیست و چه کاربردی دارد؟

امروزه پایداری، سرعت و مقیاسپذیری زیرساختها، به اصلیترین دغدغه توسعهدهندگان و مدیران سیستم تبدیل شده است. با گسترش معماریهای مبتنی بر میکروسرویس و رواج کانتینرها، شیوههای سنتی مدیریت سرور دیگر پاسخگوی نیازهای رو به رشد دیتاسنترها و اپلیکیشنهای بزرگ نیستند. در این میان، پلتفرمهای ارکستریشن به عنوان منجی زیرساختهای مدرن وارد میدان شدهاند تا فرآیندهای پیچیده استقرار و پایداری شبکه را به طور کامل خودکار کنند. در میان تمامی ابزارهای موجود، یک نام بیش از همه میدرخشد؛ سیستمی هوشمند که مدیریت هزاران کانتینر را در ابعاد وسیع ممکن ساخته است. در این مقاله به بررسی دقیق این موضوع میپردازیم که کوبرنتیز چیست، چه جایگاهی در دنیای فناوری دارد و چگونه ساختار مدیریت سرورها را متحول میکند.
سیر تکامل زیرساختهای نرمافزاری و پیدایش کانتینرها
برای درک عمیق این که کوبرنتیز دقیقا چیست و چرا تا این حد در دنیای فناوری امروز اهمیت پیدا کرده است، ابتدا باید نگاهی به مسیر تکامل زیرساختهای استقرار نرمافزار بیندازیم. در دهههای گذشته، تیمهای توسعه و عملیات نرمافزار با چالشهای عظیمی برای اجرای برنامههای خود روی سرورها مواجه بودند.
در دوران استقرار سنتی، برنامهها مستقیما روی سختافزار فیزیکی سرورها اجرا میشدند. این روش یک مشکل بزرگ داشت؛ هیچ راهی برای تعیین حد و مرز مصرف منابع برای هر برنامه وجود نداشت. اگر یک برنامه دچار نشت حافظه میشد یا ترافیک ناگهانی دریافت میکرد، تمام منابع سرور را میبلعید و باعث قطعی سایر برنامههای روی همان سرور میشد. راهکار این بود که برای هر برنامه یک سرور فیزیکی مجزا تهیه شود که از نظر هزینه و نگهداری به هیچ وجه منطقی نبود.
پس از آن، دوران مجازیسازی فرا رسید. ماشینهای مجازی به مدیران سیستم اجازه دادند تا یک سرور فیزیکی قدرتمند را به چندین سرور مجازی ایزوله تقسیم کنند. هر ماشین مجازی سیستمعامل کامل و مستقل خود را داشت. این روش ایزولهسازی منابع را بهبود بخشید اما به دلیل اجرای چندین سیستمعامل روی یک سختافزار، بخش بزرگی از منابع صرف پردازشهای خود سیستمعامل میشد و سربار بالایی داشت.
در نهایت، عصر استقرار کانتینری فرا رسید. کانتینرها شبیه به ماشینهای مجازی هستند، با این تفاوت که سیستمعامل را بین خود به اشتراک میگذارند. این ویژگی باعث میشود کانتینرها بسیار سبک، سریع و قابل حمل باشند. شما میتوانید یک برنامه را با تمام پیشنیازهایش در یک کانتینر بستهبندی کنید و مطمین باشید که این برنامه روی لپتاپ توسعهدهنده، سرور تست و سرور محیط عملیاتی دقیقا یک رفتار یکسان خواهد داشت. اما با رواج کانتینرها، چالش جدیدی متولد شد: مدیریت هزاران کانتینر در یک سیستم توزیعشده چگونه امکانپذیر است؟
کوبرنتیز (Kubernetes) چیست؟
کوبرنتیز که معمولا به صورت مخفف با عنوان «K8s» نیز شناخته میشود، یک پلتفرم متنباز برای ارکستریشن و مدیریت خودکار استقرار، مقیاسپذیری و عملیات کانتینرها است. نام کوبرنتیز ریشه یونانی دارد و به معنای «سکاندار» یا «خلبان» است. عدد هشت در مخفف آن نیز نشاندهنده هشت حرفی است که بین حرف اول و آخر کلمه انگلیسی آن قرار دارد.
این سیستم در ابتدا توسط مهندسان شرکت گوگل طراحی شد. گوگل سالها برای مدیریت زیرساختهای عظیم خود از سیستمهای داخلی به نامهای Borg و Omega استفاده میکرد. تجربیات حاصل از اجرای میلیاردها کانتینر در هفته در گوگل، منجر به تولد کوبرنتیز شد. گوگل در سال ۲۰۱۴ این پروژه را به صورت متنباز منتشر کرد و امروزه این پلتفرم توسط بنیاد رایانش ابری بومی نگهداری و توسعه داده میشود.
کوبرنتیز به شما یک چارچوب قدرتمند برای اجرای سیستمهای توزیعشده به صورت انعطافپذیر ارائه میدهد. این پلتفرم وظیفه مقیاسپذیری برنامهها، مدیریت خرابیها (Failover)، الگوهای استقرار و مدیریت شبکه کانتینرها را بر عهده میگیرد. با استفاده از این ابزار، دیگر نیازی نیست مدیران سیستم نگران خاموش شدن ناگهانی یک کانتینر یا کمبود منابع باشند، زیرا سیستم بر اساس قوانین تعریف شده، وضعیت مطلوب را حفظ میکند.
چرا به ابزارهای ارکستریشن کانتینر نیاز داریم؟
در یک محیط عملیاتی واقعی (Production)، شما باید کانتینرهایی را که برنامههای شما را اجرا میکنند مدیریت کنید و مطمین شوید که هیچگونه قطعی و تاخیر در سرویسدهی رخ نمیدهد. مثلا اگر یک کانتینر به دلیل خطای نرمافزاری یا سختافزاری متوقف شود، باید بلافاصله یک کانتینر جایگزین اجرا شود تا کاربران نهایی متوجه اختلال نشوند.
انجام این کارها به صورت دستی برای سیستمی که شامل دهها یا صدها کانتینر (میکروسرویس) است، عملا غیرممکن است. اینجاست که ابزارهای ارکستریشن وارد عمل میشوند. کوبرنتیز به عنوان قدرتمندترین ابزار در این حوزه، به سیستم شما هوشمندی میبخشد. شما به کوبرنتیز اعلام میکنید که چه وضعیتی برای سیستم شما «مطلوب» است (مثلا همیشه باید سه نسخه از برنامه من در حال اجرا باشد) و کوبرنتیز به صورت مداوم سیستم را مانیتور کرده و اگر وضعیت فعلی با وضعیت مطلوب مغایرت داشت، خودکار اقدامات لازم را برای رسیدن به وضعیت مطلوب انجام میدهد.
معماری کلاستر کوبرنتیز و اجزای سازنده آن
زمانی که کوبرنتیز را مستقر میکنید، در واقع یک کلاستر دریافت میکنید. یک کلاستر کوبرنتیز از مجموعهای از ماشینها (فیزیکی یا مجازی) تشکیل شده است که به آنها نود (Node) میگویند. این نودها برنامههای کانتینری شما را اجرا میکنند. هر کلاستر دارای حداقل یک نود کاری و یک نود کنترلی است.
اجزای نود کنترلی (Control Plane)
نود کنترلی مغز متفکر کلاستر است. این بخش وظیفه تصمیمگیریهای کلان کلاستر (مانند زمانبندی) و تشخیص و پاسخ به رویدادهای کلاستر (مانند راهاندازی یک کانتینر جدید زمانی که کانتینر قبلی از بین رفته است) را بر عهده دارد. اجزای اصلی نود کنترلی شامل موارد زیر است:
- kube-apiserver: این کامپوننت هسته اصلی و دروازه ورودی نود کنترلی است. تمامی ارتباطات داخلی کلاستر و همچنین ارتباطات خارجی (مانند دستوراتی که شما از طریق خط فرمان ارسال میکنید) باید از طریق این API انجام شود. این بخش وظیفه احراز هویت و بررسی اعتبار درخواستها را نیز بر عهده دارد.
- etcd: یک پایگاه داده کلید-مقدار توزیعشده، بسیار پایدار و سازگار است که کوبرنتیز از آن به عنوان منبع اصلی ذخیره تمام دادهها و وضعیت کلاستر استفاده میکند. اگر این پایگاه داده دچار مشکل شود، کلاستر حافظه خود را از دست میدهد.
- kube-scheduler: این بخش به صورت مداوم کلاستر را مانیتور میکند تا پادهای جدیدی که ایجاد شدهاند اما هنوز به هیچ نودی اختصاص نیافتهاند را پیدا کند. زمانبند بر اساس منابع مورد نیاز پاد، محدودیتهای سختافزاری، و سیاستهای تعریف شده، بهترین نود را برای اجرای آن پاد انتخاب میکند.
- kube-controller-manager: این بخش شامل مجموعهای از کنترلرها است که فرآیندهای پسزمینه را اجرا میکنند. هر کنترلر یک حلقه کنترلی است که وضعیت فعلی کلاستر را از طریق API Server دریافت کرده و تلاش میکند آن را به وضعیت مطلوب نزدیک کند.
اجزای نود کاری (Worker Node)
نودهای کاری ماشینهایی هستند که بار کاری اصلی (کدهای برنامه شما) را اجرا میکنند. این نودها توسط نود کنترلی مدیریت میشوند. هر نود کاری شامل اجزای زیر است:
- kubelet: یک عامل یا ایجنت است که روی هر نود در کلاستر اجرا میشود. وظیفه اصلی آن اطمینان از این موضوع است که کانتینرها به درستی در یک پاد در حال اجرا هستند. این عامل مشخصات پادها را دریافت کرده و وضعیت سلامت کانتینرها را به نود کنترلی گزارش میدهد.
- kube-proxy: یک پروکسی شبکه است که روی هر نود اجرا میشود و قواعد شبکه کوبرنتیز را روی نود پیادهسازی میکند. این کامپوننت اجازه میدهد تا ارتباطات شبکهای به پادهای شما از داخل یا خارج کلاستر به درستی مسیریابی شوند.
- Container Runtime: نرمافزاری است که وظیفه اجرای کانتینرها را بر عهده دارد. کوبرنتیز از رانتایمهای مختلفی مانند containerd و CRI-O پشتیبانی میکند و ارتباط خود با آنها را از طریق رابط استانداردی به نام CRI برقرار میسازد.
مفاهیم و موجودیتهای اصلی در کوبرنتیز
برای کار با کوبرنتیز باید با الفبای آن آشنا باشید. در این سیستم همه چیز بر اساس مفاهیم انتزاعی یا موجودیتها (Objects) تعریف میشود.
پاد (Pod)؛ کوچکترین واحد اجرایی
در کوبرنتیز شما کانتینرها را به صورت مستقیم اجرا نمیکنید، بلکه آنها را درون یک موجودیت به نام پاد قرار میدهید. پاد کوچکترین و پایهایترین واحد قابل استقرار در کوبرنتیز است. یک پاد میتواند شامل یک یا چند کانتینر باشد که منابع ذخیرهسازی و شبکه را با هم به اشتراک میگذارند. معمولا در الگوهای استاندارد، هر پاد میزبان یک کانتینر است، مگر اینکه دو کانتینر وابستگی بسیار شدیدی به یکدیگر داشته باشند. پادها موجودیتهایی فانی هستند؛ اگر یک نود خراب شود، پادهای روی آن نیز از بین میروند و کوبرنتیز پادهای جدیدی را روی نودهای سالم ایجاد میکند.
دپلویمنت (Deployment) و رپلیکا ست (ReplicaSet)
همانطور که گفته شد، پادها فانی هستند و نباید به صورت دستی ایجاد شوند. دپلویمنت موجودیتی است که مدیریت چرخه حیات پادها را بر عهده میگیرد. شما در یک دپلویمنت مشخص میکنید که مثلا به سه کپی از یک پاد نیاز دارید. دپلویمنت در پسزمینه از موجودیت دیگری به نام رپلیکا ست استفاده میکند تا همیشه تضمین کند دقیقا سه کپی در حال اجرا هستند. همچنین دپلویمنتها فرآیند بروزرسانی برنامهها را بدون قطعی سرویس مدیریت میکنند.
سرویس (Service) و مفاهیم شبکه
چون پادها مدام از بین میروند و ساخته میشوند، آدرس آیپی آنها مدام تغییر میکند. در این شرایط، کانتینرهای دیگر چگونه باید با یکدیگر ارتباط برقرار کنند؟ سرویس در کوبرنتیز یک آدرس ثابت و یک سیاست برای دسترسی به مجموعهای از پادها تعریف میکند. به این ترتیب، حتی اگر پادها تغییر کنند، آدرس سرویس ثابت میماند و درخواستها را به صورت متوازن بین پادهای در حال اجرا پخش میکند.
نیماسپیس (Namespace) برای ایزولهسازی
زمانی که کلاستر شما بزرگ میشود و تیمهای مختلفی روی آن کار میکنند، نیاز به تفکیک منابع دارید. نیماسپیسها مانند کلاسترهای مجازی درون یک کلاستر فیزیکی هستند. با استفاده از آنها میتوانید محیطهای تست و عملیات را از هم جدا کنید یا منابع پردازشی خاصی را به یک تیم مشخص اختصاص دهید تا از تداخل پروژهها با یکدیگر جلوگیری شود.
کانیفگ مپ (ConfigMap) و سیکرت (Secret)
در برنامهنویسی مدرن، کد برنامه باید از تنظیمات پیکربندی جدا باشد. کانیفگ مپها به شما اجازه میدهند متغیرهای محیطی، فایلهای پیکربندی یا آرگومانهای خط فرمان را به صورت مجزا از کانتینر ذخیره کنید و در زمان اجرا به آن تزریق کنید. سیکرتها نیز عملکردی مشابه دارند اما برای ذخیرهسازی اطلاعات حساس مانند رمزهای عبور، کلیدهای SSH و توکنها با مکانیزمهای رمزنگاری استفاده میشوند.
مهمترین ویژگیها و مزایای استفاده از کوبرنتیز
استفاده از این معماری پیچیده تنها زمانی توجیه دارد که مزایای آن ارزش این پیچیدگی را داشته باشد. کوبرنتیز قابلیتهایی را ارائه میدهد که مدیریت زیرساخت را متحول میکند.
مقیاسپذیری خودکار و بینقص
کوبرنتیز به شما اجازه میدهد منابع را هم به صورت افقی و هم به صورت عمودی مقیاسدهی کنید. اگر ترافیک سایت شما در ساعات خاصی افزایش یابد، ویژگی مقیاسپذیری خودکار افقی پادها (HPA) تعداد کپیهای در حال اجرای برنامه شما را افزایش میدهد و پس از کاهش ترافیک، آنها را دوباره به حالت عادی برمیگرداند. این فرآیند باعث بهینهسازی شدید هزینههای زیرساخت ابری میشود.
خودترمیمی و پایداری بالا (Self-healing)
یکی از جذابترین ویژگیهای کوبرنتیز خاصیت خودترمیمی آن است. اگر یک کانتینر کرش کند یا پاسخی به بررسیهای سلامت ندهد، کوبرنتیز آن را میکشد و مجددا راهاندازی میکند. اگر یک نود به طور کامل از کار بیفتد، کوبرنتیز تمام پادهای آن نود را روی نودهای سالم دیگر بازآفرینی میکند. این رفتار باعث میشود تاثیر خرابیهای سختافزاری بر سرویسدهی نهایی به حداقل برسد.
مدیریت استقرار و بازگشت به نسخه قبل (Rollout and Rollback)
زمانی که میخواهید نسخه جدیدی از برنامه خود را منتشر کنید، کوبرنتیز این کار را به صورت تدریجی انجام میدهد. به این معنی که ابتدا یک پاد با نسخه جدید ایجاد میکند، در صورت سلامت آن، ترافیک را به سمت آن هدایت کرده و یک پاد قدیمی را پاک میکند. این الگو تضمین میکند که هیچگونه قطعی در زمان بروزرسانی رخ ندهد. اگر در نسخه جدید باگی وجود داشته باشد، سیستم با یک دستور ساده میتواند وضعیت را به نسخه قبلی بازگرداند.
هماهنگسازی فضای ذخیرهسازی (Storage Orchestration)
کوبرنتیز به شما اجازه میدهد سیستمهای ذخیرهسازی مختلفی را اعم از فضاهای محلی، فضاهای ابری عمومی یا سیستمهای ذخیرهسازی شبکه به صورت خودکار متصل کنید. این بدان معناست که دادههای برنامههای شما حتی در صورت حذف شدن پادها، امن و در دسترس باقی میمانند.
استفاده از این قابلیت کوبرنتیز در سرور اختصاصی مناسب کسب و کار، باعث افزایش امنیت داده شده و یک لایه ایزولاسیون جدیدی را به محیط کاری شما اضافه میکند، چرا که در این سیستم، داده کاملا مستقل از برنامهها ذخیره و مدیریت میشوند.
چه زمانی نباید از کوبرنتیز استفاده کنیم؟
با وجود تمام قدرت و جذابیت، کوبرنتیز یک ابزار همهکاره برای تمام مشکلات نیست و استفاده از آن در پروژههای اشتباه میتواند به یک کابوس مهندسی تبدیل شود.
- معماریهای مونولیتیک ساده: اگر برنامه شما یک سیستم یکپارچه و قدیمی (Monolith) است که نیازی به مقیاسپذیری توزیعشده ندارد، اجرای آن روی کوبرنتیز تنها باعث افزایش پیچیدگی بدون هیچ دستاورد خاصی میشود. یک سرور مجازی معمولی یا هاست لینوکس برای چنین پروژههایی بسیار منطقیتر است.
- تیمهای فاقد تخصص دواپس: یادگیری و مدیریت کلاستر کوبرنتیز نیازمند دانش عمیق در زمینه سیستمعامل، شبکه و مفاهیم بومی ابری است. اگر تیم شما تخصص کافی برای عیبیابی و نگهداری این پلتفرم را ندارد، راهاندازی آن ریسک بالایی در پی خواهد داشت.
- پروژههای با ترافیک پایین و ثابت: اگر سایت شما ترافیک مشخص و محدودی دارد و نیازی به مقیاسپذیری لحظهای در آن احساس نمیشود، ابزارهای سادهتر مانند داکر کامپوز برای مدیریت کانتینرها پاسخگوی نیاز شما خواهند بود.
بررسی یک پیکربندی ساده در کوبرنتیز
برای اینکه درک بهتری از نحوه کار با این پلتفرم داشته باشیم، نگاهی به سینتکس فایلهای پیکربندی آن میاندازیم. در کوبرنتیز شما وضعیت مطلوب را در قالب فایلهای YAML مینویسید و این فایلها را به API Server ارسال میکنید.
قطعه کد زیر نمونهای از تعریف یک Deployment است که از سرور میخواهد همیشه سه نسخه از کانتینر یک برنامه وب را در حال اجرا نگه دارد:
apiVersion: apps/v1 kind: Deployment metadata: name: my-web-app labels: app: web spec: replicas: 3 selector: matchLabels: app: web template: metadata: labels: app: web spec: containers: - name: nginx-container image: nginx:latest ports: - containerPort: 80
در این پیکربندی ساده، ما نوع موجودیت را Deployment تعریف کردهایم. در بخش replicas مشخص شده است که ۳ عدد پاد باید وجود داشته باشد. در بخش template نیز تعریف کردهایم که هر کدام از این پادها باید شامل یک کانتینر با ایمیج nginx:latest باشند و روی پورت ۸۰ سرویسدهی کنند. با ارسال این فایل به کلاستر، کوبرنتیز تمام کارهای مربوط به دانلود ایمیج، پیدا کردن نود مناسب، اجرای کانتینرها و مانیتورینگ سلامت آنها را بر عهده میگیرد.
نتیجهگیری؛ آینده مدیریت زیرساخت با کوبرنتیز
کوبرنتیز استانداردهای مدیریت زیرساخت در دنیای نرمافزار را از پایه تغییر داده است. این پلتفرم با ارائه راهکارهایی قدرتمند برای اتوماسیون، پایداری و مقیاسپذیری، به شرکتهای کوچک و بزرگ اجازه داده است تا نرمافزارهای خود را در محیطهای ابری بهینهتر و مطمئنتر اجرا کنند. اگرچه منحنی یادگیری این سیستم بسیار پرشیب و نیازمند زمان است، اما تسلط بر آن کلید ورود به معماریهای مدرن مبتنی بر میکروسرویس و سیستمهای بومی ابری محسوب میشود. در نهایت، تصمیمیگیری برای مهاجرت به این پلتفرم باید بر اساس نیاز واقعی کسبوکار به مقیاسپذیری لحظهای و توانایی تیم فنی در مدیریت پیچیدگیهای معماری توزیعشده صورت گیرد.
سوالات متداول
کوبرنتیز یک پلتفرم ارکستریشن و مدیریت کانتینرها است، در حالی که داکر ابزاری برای ساخت، بستهبندی و اجرای خود کانتینرها به شمار میرود. به زبان ساده، داکر کانتینرها را میسازد و کوبرنتیز مدیریت و هماهنگسازی هزاران کانتینر را در ابعاد بزرگ بر عهده میگیرد.
پاد کوچکترین واحد قابل استقرار و مدیریت در کوبرنتیز است که میتواند شامل یک یا چند کانتینر باشد. کانتینرهای درون یک پاد، منابع ذخیرهسازی، آدرس آیپپی و تنظیمات شبکه را با یکدیگر به اشتراک میگذارند.
کوبرنتیز به صورت مداوم وضعیت کلاستر را مانیتور میکند. اگر کانتینری دچار خطا شده و متوقف شود، سیستم فورا آن را راهاندازی مجدد میکند. همچنین اگر یک نود به طور کامل از کار بیفتد، پادهای روی آن نود در کمتر از چند دقیقه روی نودهای سالم دیگر بازآفرینی میشوند تا تاخیر یا قطعی در سرویسدهی رخ ندهد.
نود کنترلی مغز متفکر کلاستر است که وظیفه تصمیمگیری، زمانبندی و مدیریت وضعیت کلی کلاستر را بر عهده دارد. در مقابل، نودهای کاری ماشینهایی هستند که کدهای برنامه شما و بار کاری اصلی را در قالب کانتینرها اجرا میکنند.
این کار از طریق موجودیتی به نام سرویس (Service) انجام میشود. سرویس یک آدرس آیپی ثابت برای مجموعهای از پادها تعریف میکند و با استفاده از کامپوننت kube-proxy، ترافیک ورودی کاربران را به صورت متوازن بین پادهای فعال و سالم پخش میکند.
برای پروژههای کوچک، برنامههای تکنسخهای (Monolith) با ترافیک ثابت و محدود، یا تیمهایی که متخصص دواپس برای مدیریت و عیبیابی کلاستر ندارند، استفاده از کوبرنتیز توجیه فنی ندارد و تنها باعث افزایش شدید پیچیدگی و هزینهها میشود.
یک پایگاه داده کلید-مقدار توزیعشده و بسیار امن است که درون نود کنترلی قرار دارد. تمام دادههای مربوط به پیکربندی، وضعیت کلاستر و تنظیمات حیاتی کوبرنتیز در etcd ذخیره میشود و به عنوان منبع اصلی حقیقت برای کلاستر عمل میکند.
کوبرنتیز برای جداسازی کدهای برنامه از تنظیمات، از دو موجودیت کانیفگ مپ (ConfigMap) و سیکرت (Secret) استفاده میکند. اطلاعات معمولی در کانیفگ مپ و اطلاعات حساس مانند رمزهای عبور و توکنها به صورت رمزنگاری شده در سیکرتها ذخیره و در زمان اجرا به کانتینر تزریق میشوند.
HPA مکانیزمی است که به صورت خودکار میزان مصرف منابع (مانند پردازنده و رم) پادها را مانیتور میکند. در صورتی که میزان مصرف از حد مجاز بالاتر برود، کوبرنتیز تعداد کپیهای در حال اجرای آن برنامه را افزایش میدهد تا فشار ترافیک تقسیم شود و پس از فروکش کردن ترافیک، تعداد آنها را کم میکند.
هنگام انتشار نسخه جدید یک برنامه، دپلویمنت به صورت گامبهگام پادهای جدید را ایجاد کرده و پس از اطمینان از سلامت آنها، پادهای قدیمی را به مرور حذف میکند. این الگوی استقرار باعث میشود کاربران در طول فرآیند بروزرسانی با هیچگونه قطعی مواجه نشوند.






























شما میتوانید دیدگاه خود را در مورد این مطلب با ما با اشتراک بگذارید.