مقدمه ای بر Kubernetes

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

مقدمه ای بر Kubernetes

امروز قرار بود یه مقاله ای در مورد CRD ها در Kubernetes بنویسم. ولی فکر کردم شاید بهتر باشه ابتدا یه مقدمه ای در مورد Kubernetes و اجزای تشکیل دهنده اون داشته باشم تا درک بقیه مقالات مربوط به kubernetes راحت تر باشه و در هنگام مطالعه مقالات بعدی سوالات کمتری در ذهن شما ایجاد بشه.

سطح مقاله :‌ متوسط

مدت زمان مطالعه : 15 دقیقه

کوبرنتیز (Kubernetes) چیست؟

کوبرنتیز که به نام K8S نیز شناخته میشود،‌یک سیستم اوپن سورس برای خودکارسازی استقرار، مقیاس بندی و مدیریت نرم افزارهای Containerze شده است. Kubernetes بر اساس تجربه 15 سال اجرای Workloadهای Production در Google، همراه با بهترین ایده ها ساخته شده است. نام Kubernetes از یونان سرچشمه میگیرد که به معنی سکان دار یا خلبان است. K8s به عنوان مخفف از شمردن هشت حرف بین "K" و "s" حاصل می شود. این پروژه در سال ۲۰۱۴ توسط شرکت گوگل به صورت اوپن سورس ارائه گردید.

پاد (POD) چیست ؟

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

پاد در کوبرنتیز
پاد در کوبرنتیز

چرا ما به کوبرنتیز نیاز داریم و چه کارهایی برای ما انجام میدهد ؟

کانتینرها راه خوبی برای بسته بندی (bundle) و اجرای برنامه هستند. در محیط های Production نیاز به مدیریت کانتینرهایی که برنامه شما را اجرا میکنند دارید و همچنین باید مطمئن باشید که downtimeای وجود ندارد. برای مثال، در صورتی که یک کانتینر down شد یک کانتینر دیگر اجرا شود. حال اگر این عملیات توسط یک سیستم مدیریت شود کار شما آسانتر خواهد شد. اینجاست که Kubernetes به کمک ما میآید و یک framework برای اجرای انعطاف پذیر سیستم های توزیع شده در اختیار ما قرار میدهد که عملیات لازم را برای scaling و failover برای برنامه شما انجام میدهد و همچنین الگوهای استقرار و … را در اختیار شما قرار میدهد.

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

کلاستر کوبرنتیز
کلاستر کوبرنتیز

چیزهایی که Kubernetes در اختیار شما قرار میدهد :

  • ء- Service DIscovery و Load Balancing : کوبرنتیز می‌تواند یک کانتینر را با استفاده از نام DNS یا با استفاده از آدرس IP خود expose کند.در صورتی که ترافیک ورودی به کانتینر زیاد است، میتواند بار و ترافیک شبکه را بین کانتینرها توزیع کند تا یک استقرار پایدار بماند.
  • ء- Storage orchestration :‌ کوبرنتیز به شما این امکان را می دهد که به طور خودکار یک سیستم ذخیره سازی مورد نظر خود را mount کنید، مانند local storage، ارائه دهندگان ابر عمومی و موارد دیگر.
  • ء- Rollout و Rollback خودکار :‌شما می توانید state مورد نظرتان را برای کانتینرهای deploy شده توصیف کنید و state واقعی را با rate کنترل شده به state مورد نظرتان تغییر بدهید. برای مثال شما میتوانید به کوبرنیتز بگویید کانتینرهای جدیدی را برای شما بسازد و کانتینرهای فعلی را حذف کند و منابع آن را به کانتینرهای جدید اختصاص دهد.
  • ء- Automatic bin packing :‌ شما مجموعه ای از nodeها را در اختیار kubernetes قرار میدهید تا کانتینرها را بر روی آنها اجرا کند و مشخص میکنید که هر کانتینر چه مقدار CPU و RAM نیاز دارد. kubernetes به صورت خودکار کانتینر شما در node هایی اجرا میکند که منابع لازم را داشته باشد تا به بهترین شکل از منابع استفاده شود.
  • خوددرمانی (Self-healing) : کوبرنتیز کانتینرهای دارای مشکل را restart و replace میکند، کانتینرهایی را که وضعیت سلامت درستی ندارند را kill کرده و تا زمانی که آماده سرویس دهی به کلاینت نباشند به آنها ترافیکی هدایت نمیکند
  • مدیریت Secret ها و پیکربندی ها :‌ کوبرنتیز به شما امکان می دهد اطلاعات حساس مانند رمزهای عبور، توکن های OAuth و کلیدهای SSH را ذخیره و مدیریت کنید. شما می توانید secret ها و config های برنامه را بدون بازسازی image کانتینر خود مستقر و به روز کنید.

اجزای تشکیل دهنده Kubernetes

یک کلاستر کوبرنتیز از چند کامپوننت که بر روی ماشین های مختلف که بخشی از کلاستر هستند تشکیل شده است.

یک کلایتر کوبرنتیز شامل ۲ کامپوننت اصلی است :

  • نود Control Plane (نود مستر) که وظیفه مدیریت و هماهنگی کلاستر را برعهده دارد.
  • نود/نودهای Worker که کانتینرهای ما را اجرا میکنند.

هر یک از این کامپوننت ها میتوانند یک سرور فیزیکی، مجازی و یا سرور ابری باشند.

نود Control Plane

  • به عنوان نود master یا head شناخته میشود.
  • این node وظیفه ی مدیریت node های worker و هچنینpodهای داخل کلاستر را بر عهده دارد.
  • در محیط های production برای پایداری بیشتر، این node معمولا به صورت کلاستر اجرا میشود تا high availability و fault-tolerance را فراهم کند
  • نود control plane دستورات را از cli یا یک ui از طریق api دریافت میکند.
  • توصیه میشود که workload ها بر روی node های control plane اجرا نشوند.

نودهای Worker

  • سرورهای فیزیکی یا مجازی که شامل سرویس های لازم برای اجرای اپلیکیشن های کانتینرایز شده است.
  • یک کلاستر کوبرنتیز به حداقل یک نود worker نیاز دارد اما معمولا تعداد این nodeها زیاد است.
  • این nodeها میزبان podهای برنامه های شما هستند و podها برای اجرا روی این node ها برنامه ریزی و هماهنگ میشوند.
  • شما میتوانید با افزودن و حذف این nodeها، کلاستر را کوچکتر و یا بزرگتر کنید.

کامپوننت های Control Plane

کامپوننت های Control Plane وظیفه تصمیم گیری در مورد تمام کلاستر را دارند،‌همچنین event های کلاستر را تشخیص داده و پاسخ مناسب را ارائه میدهند. کوبرنتیز به چندین سرویس مدیریتی در حال اجرا بر روی Control Plane متکی است که این سرویس ها جنبه هایی مانند ارتباط بین کامپوننت های کلاستر،‌ برنامه ریزی workloadها، وضعیت کلاستر و… را مدیریت میکنند.



لیست کامپوننت های Control Plane

  • ETCD
  • Kube-apiserver
  • Kube-control-manager
  • kube-scheduler

کامپوننت ETCD

  • به عنوان یک DataStore برای کلاستر عمل میکند
  • یک دیتابیس key-value قدرتمند و با قابلیت High available است که وضعیت کلاستر را نگهداری میکند.
  • اطلاعاتی در مورد podها و nodeهای در حال اجرا در کلاستر و … را نگهداری میکند.
  • در صورتی که چند نود مستر وجود داشته باشیم،‌ دیتا را بین آنها sync میکند.
  • در صورتی که از etcd در کلاستر استفاده میکنید با استفاده از دستور etcd snapshot save از دادهای کلاستر خود نسخه پشتیبانی تهیه کنید.
  • ابزار etcdctl به زبان Go نوشته شده است و به ما این اجازه را میدهد تا داده های داخل کلاستر etcd را دستکاری کنیم. کارهایی که میتوانیم با آن انجام دهیم :
    • ذخیره، بروزرسانی و حذف یک key
    • بررسی سلامت کلاستر
    • اضافه و حذف نود etcd
    • ساخت snapshot از دیتابیس
    • همچنین دارای مکانیزم watch است که یک اینترفیس event-based را برای نظارت بر تغییرات key ها به صورت async ارائه میدهد. به محض این که مقدار یک key تغییر کند،‌ watcher آن مطلع میشود. این یک ویژگی حیاتی در Kubernetes است، زیرا کامپوننت API Server به شدت به آن متکی است تا از هرگونه تغییر در آن مطلع شود و کامپوننت مناسب آن تغییرات را فراخوانی

کامپوننت API Server (kube-apiserver)

  • ء-APIهای Kubernetes را ارائه میدهد
  • زمانی که در خط فرمان از kubectl استفاده میکنیم درواقع در حال ارتباط با kube-apiserver هستیم.
  • از kube-apiserver برای پردازش عملیات REST، اعتبار سنجی آنها و بروز رسانی آبجکت های مرتبط با آنها در etcd استفاده میشود.
  • تنها کامپوننتی است که به etcd متصل است. تمام کامپوننت های دیگر باید از kube-apiserver برای کار با کلاستر استفاده کنند.
  • این کامپوننت دارای مکانیزم watch در داخل خودش است (شبیه به etcd). ویژگی watch به کامپوننت هایی نظیر kube-scheduler و kube-control-manager اجازه تعامل با api-server را میدهد و در صورتی که تغییری در ectd رخ دهد، از تغییرات مطلع شده و task مرتبط با آن را انجام میدهند.
  • به نحوی طراحی شده است که بتوان به صورت افقی مقیاس بپذیرد.
  • فایل های manifest با فرمت های json/yaml برایش قابل درک است.

یک مثال : زمانی که ما یک پاد را ایجاد میکنیم چه اتفاقی رخ میدهد ؟

مراحل ایجاد یک پاد در کلاستر کوبرنتیز
مراحل ایجاد یک پاد در کلاستر کوبرنتیز
  1. ء- Kubectl دستور را به api-server ارسال میکند
  2. ء- Api-server درخواست را اعتبار سنجی کرده و آن را در etcd ذخیره میکند
  3. ء- Etcd به api-server اطلاع میدهد
  4. ء- Api-server کامپوننت scheduler را فراخوانی میکند
  5. ء- Scheduler تصمیم میگیرد که پاد در کدام نود اجرا شود و آن را به api-server برمیگرداند.
  6. ء- Api-server آن را در etcd ذخیره میکند
  7. ء- Etcd به api-server اطلاع میدهد
  8. ء- Api-server کامپوننت kubelet را در نود مورد نظر فراخوانی میکند.
  9. ء- Kubelet با استفاده از api با docker daemon صحبت میکند تا container را ایجاد نماید.
  10. ء- Kubelet وضعیت پاد را به api-server میدهد.
  11. ء- Api-server وضعیت جدید را etcd ذخیره میکند

کامپوننت kube-control-manager

  • ء- Kube-control-manager وضعیت کلاستر را از طریق ویژگی watch در api server مشاهده کرده و زمانی که به آن اطلاع رسانی میشود،‌ تغییرات لازم را برای حرکت از state موجود به state مورد نظر انجام میدهد.

مثال :‌ خرابی node، ریپلیکیشن کامپوننت ها، و حفظ تعداد پادها و غیره را مدیریت می کند.

  • ء- Kube-control-manager فقط یک سرویس (controller) نیست بلکه شامل بسیاری از سرویس های دیگر است که بر اساس flag آنها، تصمیم به فعال/غیرفعال سازی آنها میگیرد.
  • به منظور فعال سازی controller ها، از flagهای زیر در هنگام پیکربندی کلاستر استفاده کنید.
لیست کنترلر های قابل فعال سازی در کلاستر کوبرنتیز
لیست کنترلر های قابل فعال سازی در کلاستر کوبرنتیز
  • به منظور جلوگیری از پیچیدگی،‌تمام این سرویس ها (controller ها) در یک process عمل میکنند. به عنوان مثال کنترلر هایی که تا به امروز توسط کوبرنتیز ارائه شده است :
    • ء- Node controller : مسئول توجه و پاسخ دادن در هنگام down شدن یک node است.
    • ء- Replication controller: مسئول نگهداری تعداد صحیح podها به ازای هر آبجکت replication controller در سیستم است.
    • ء- Endpoints Controller: سرویس ها و pod ها را به هم متصل میکند. در واقع آدرس ip پادها که به صورت داینامیک به آنها اختصاص داده شده است را جمع آوری کرده و به عنوان یک service selector عمل میکند که service و pod را بر اساس labelها به هم متصل میکند.
    • ء- Service Account & Token Controllers: این کنترلر وظیفه ساخت account های پیش فرض و api access token ها را برای namespace های جدید دارد.
  • ء- Cloud Controller Manager
  • وقتی کلاستر در محیط ابری در حال اجرا است، cloud-controller-manager با فناوری‌های ابری زیربنایی در cluster شما integrate می‌شود.
  • ء- Cloud-controller-manager فقط کنترلرهایی را اجرا می کند که مختص ارائه دهنده ابر شما هستند.
  • ء- Cloud-controller به شما امکان می دهد کلاستر خود را به API ارائه دهنده ابر لینک کرده و کامپوننت هایی که با پلتفرم ابری در تعامل هستند را از کامپوننت هایی که فقط با کلاستر شما در تعامل هستند، جدا کند.

کنترلرهای زیر می توانند وابستگی هایی به ارائه دهنده خدمات ابر داشته باشند:

  • ء- Node controller
  • ء- Route Controller: برای راه اندازی route ها در زیر ساخت ابری
  • ء- Service controller : برای ایجاد ،‌بروز رسانی و حذف load balancer ارائه دهنده ابر.

کامپوننت kube-scheduler:

  • این کامپوننت وظیفه برنامه ریزی برای ساخت pod جدید را دارد و node ای را برای این کار در نظر میگیرد که از نظر منابع و فضا مناسب pod مورد نظر باشد.
  • درواقع به kube-apiserver و kube-controller-manager برای pod های جدید ایجاد شده گوش می دهد و سپس آن را برای یک node موجود در کلاستر برنامه ریزی می کند.
  • در صورتی که نود مناسبی برای پاد مورد نظر یافت نشود آن را در وضعیت pending قرار میدهد تا زمانی که نود مناسب آن پیدا شود.

مثال :‌ در صورتی که یک اپلیکیشن نیاز به 1 گیگ حافظه و ۲ هسته پردازنده داشته باشد، برنامه ریزی میشود تا در node ای اجرا شود که دارای حداقل نیازمندی ها باشد.

عواملی که برای تصمیم گیری های kube-scheduler در نظر گرفته می شوند عبارتند از:

  • منابع مورد نیاز موجود باشد
  • محدودیت های سخت افزاری و نرم افزاری
  • پیکربندی های Affinity و anti-affinity
  • محل داده ها
  • تداخل inter-workload
  • ء- Taint ها و dealine ها

کامپوننت های نودهای Worker

هر نود worker دارای کامپوننت های زیر است:

  • Kubelet
  • Kube-proxy
  • Container Runtime Interface (CRI)

کامپوننت kubelet :

  • یک Agent است که در تمام nodeهای کلاستر در حال اجرا است. (حتی نود control plane)
  • به عنوان مجرای بین api-server و node عمل می کند و گزارشات را به api-server میدهد.
  • سرویس kubelet به عنوان یک واسطه بین kube-apiserver و CRI (Container Runtime Interface) عمل می کند.
  • مشخصات pod را از kube-apiserver دریافت می کند و تضمین می کند که podها و containerهای آنها سالم هستند و در state مورد نظر کار می کنند.
  • پادها را راه اندازی و اجرا میکند.
  • ء- Kubelet ازcontainer runtime برای راه‌اندازی پاد استفاده می‌کند، چرخه عمر آن را مانیتور کرده و readiness و … را بررسی میکند.

کاموننت kube-proxy

  • ء- Kube-proxy با اجازه دادن به ارتباطات بین پادها، کانتینرها و node ها، ترافیک شبکه را مدیریت می کند.
  • این کامپوننت یک pod است در تمام نودهای کلاستر اجرا میشود ( حتی control plane)
  • این pod تغییرات kube-apiserver را زیر نظر میگیرد و شبکه را از طریق قوانین iptables که ترافیک را به endpoint صحیح ارسال می کند، به روز نگه می دارد.
  • اطمینان حاصل می کند که هر pod آدرس IP منحصر به فردی را دریافت می کند.
  • این امکان را فراهم می کند که همه کانتینرهای یک پاد یک IP واحد را به اشتراک بگذارند.
  • این کامپوننت load balancing را در تمام podهای یک service انجام میدهد.


ء- Container Runtime Interface

  • برای راه‌اندازی کانتینرها روی nodeها به نرم‌افزار Container Runtime نیاز داریم، می‌توانیم از Container Runtime مختلفی استفاده کنیم، اما به طور گسترده از docker استفاده می‌شود.
  • برای اجرای کانتینرها، هر worker node دارای یک container runtime engine است.
  • ء- kubelet با داکر صحبت می‌کند و کانتینرهای ما را در صورت تقاضا اجرا یا متوقف می‌کند.
  • ء- Kubernetes از چندین Container Runtime پشتیبانی می کند: Docker، containerd، cri-o، rktlet.


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

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