کوبر Kubernetes

کوبر چیه؟

یک ابزار اپن‌سورس ارکستریشن (orchestration) هست که توسط گوگل توسعه پیدا کرده و کمک می‌کنه تعداد زیادی اپ کانتینرایز شده (containerized) رو در محیط‌های (environment) مختلف مدیریت کنیم.

مشکلی که حل می‌کنه اینه که وقتی از سمت منولوتیک به سمت میکروسرویس میری، به راهکاری نیاز داری که به روش درست و مناسبی بتونی صدها کانتینر رو مدیریت کنی، به این کار میکنم ارکستریشن.

کاری که برات میکنه اینه که:

• بهت high availability رو میده و کمک می‌کنه downtime نداشته باشی.
• بهت عملکرد بالا و scalibility رو میده. موقع نیاز، زیرساخت رو scale می‌کنه و هر زمان لازم نبود دوباره کاهشش می‌ده.
• بازیابی فاجعه‌ها: اگر هر مشکلی برای زیرساخت یا دیتاسنتر پیش بیاد، سازکاری برای بک‌آپ و بازیابی اطلاعات داره.

معماری کوبر:

حداقل یک Master Node که بهش Control Plane می‌گیم و چندین Worker Node که بهشون Nodes می‌گیم، تشکیل شده.

هر نود روش kubelet process ران شده، که کارش اینه که امکان ارتباط کلاستر با هم رو ایجاد کنه و یکسری تسک مثل اجرای برنامه رو انجام بده.

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

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

• بخش API Server: نقطه ورود به کلاستر کوبر، داشبورد و API و کامندلاین با این قسمت مرتبط میشه.
• بخش Controll Manager: کلیت اینی که در کلاستر وضعیت چیه رو نگه میداره. اینکه یک کانتینر مرده و نیازه بازیابی بشه و...
• بخش Scheduler: این بخش تصمیم می‌گیره که روی کدوم نود، پاد (کانتینر) جدید باید بالا بیاد بر اساس منابعی که اون کانتینر نیاز داره و منابعی که در اون نود موجوده.
• بخش etcd: استوریج key value، وضعیت هر لحظه کلاستر کوبر رو نگه میداره. همه دیتای تنظیمات رو داره. بخش بک‌آپ و بازیابی که صحبت کردیم هم براساس اسنپ‌شات‌هات این قسمت انجام میشه.

بخش VIrtual Network: کارش اینه که همه نودها رو تبدیل به یک ماشین unified بکنه و امکان صحبت کردن مستر نود و ورکر نودها رو فراهم کنه.

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

کامپوننت‌های اصلی کوبر:

بخش node: یک سرور فیزیکی یا مجازی

بخش pod: کوچک‌ترین کامپوننت کوبر هست. معمولا شامل یک کانتینر میشه. هر پاد یک ip آدرس داره و می‌تونن باهم صحبت کنن که این آدرس داخلیه و از طریق virtual network در اختیارشون قرار گرفته. پادها ephemeral هستن، این یعنی می‌تونن خیلی راحت بمیرن، و اگر این اتفاق بیوفته، یک جدیدش ایجاد و جایگزین میشه و ip آدرس جدید می‌گیره، اگر برای ارتباط برنامه با دیتابیس از ip استفاده کرده باشیم به مشکل می‌خوریم برای همین از کامپوننت دیگه‌ای به نام service استفاده می‌کنیم.

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

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

کامپوننت ConfigMap: فرض کنین که آدرس دیتابیس عوض شده، باید بری تو کدت عوض کنی، بعد build بگیری و بعد پوش کنی روی repo و بعد روی پاد pull بگیری! این برای همچین تغییر کوچیکی زیاده. در واقع کانفیگ‌مپ، تنظیمات بیرونی اپلیکیشن‌تونه که کانفیگ‌ها رو نگه میداره و پاد می‌تونه دیتا رو ازش بگیره. توجه داشته باشین که در کانفیگ‌مپ فقط دیتای غیرامنیتی رو بذارین.

کامپوننت Secret: کامل مشابه ConfigMap هست با این تفاوت که برای نگهداری دیتاهای امنیتی مثل پسوردها هست و به صورت encode base 64 نگهداری میشه. به طور پیشفرض رمزگذاری نشده و باید خودتون کانفیگ کنینش.

کامپوننت Volume: با رستارت پاد دیتابیس دیتاش میپره و این چیزی که ما می‌خوایم نیست. با استفاده از volume بخشی از حافظه فیزیکی روی هارد به پاد اختصاص داده میشه که می‌تونه روی لوکال ماشین و یا خارج از کلاستر کوبر باشه. کوبر کار مدیریت ماندگاری دیتا رو انجام نمیده، ما مسئول اینیم که مطمئن بشیم که رپلیکا و بکاپ و... برای اون دیتا داریم.

در کوبر همه چیز replica دارن، یعنی یک نسخه دیگه ازشون موجوده، اینطور وقتی اپ به هر دلیلی بیاد پایین، کاربر با downtime روبرو نمیشه. رپلیکا ها به یک سرویس متصل هستن، سرویس همینطور یک لودبالانسر هم هست، این یعنی درخواست رو دریافت می‌کنه و پادی میفرسته که کمتر سرش شلوغه. برای این که رپلیکا داشته باشیم باید یک blueprint برات پادها تعریف کنیم که توش مشخص کنیم که چه تعداد رپلیکا می‌خوایم داشته باشیم. به این بلو پرینت میگیم deployment.

کامپوننت deployment: در واقع abstraction ای از پاد هاست که رپلیکا کردن و تنظیمات دیگه‌ای مثل scale up یا scale down کردنشون رو انجام میده. در عمل ما غالبا با دپلویمنت کار می‌کنیم و نه پادها. اما ما دیتابیس رو با دپلویمنت نمی‌تونیم مدیریت کنیم چون state داره، یعنی اینکه نیاز به دسترسی به یک دیتا استوریج مشترک داره. و نیاز به یک مکانیزم داریم که مشخص کنه کدوم پاد داره می‌نویسه و کدوم پاد داره ازش می‌خونه تا از ناهماهنگی داده جلوگیری کنه. این مکانیزم همراه با قابلیت رپلیکا توسط Statefulset در اختیارمون قرار می‌گیره.

کامپوننت statefulset: این کامپوننت برای اپ‌های stateFUL ای مثل دیتابیس‌ها به کار میره. دپلوی statefulset ها آسون نیست، برای همین یک پرکتیس معمول اینه که دیتابیس رو خارج از کلاستر کوبر هاست می‌کنن.

کانفیگ کوبر

از طریق API Server که قبلا صحبت شد، ما کانفیگ‌ها رو در فرمت YAML و یا Json به کوبر میدیم.

سه بخش اصلی این فایل کانفیگ داره:

• متادیتا (metadata): که نام کامپوننت هست
• مشخصات (specification): همه مشخصاتی که می‌خوایم روی اون کامپوننت اعمال بشه.
• وضعیت (status): این بخش اتومات توسط کوبر ایجاد و اضافه میشه. کوبر همواره چک می‌کنه که وضعیت موجود چیه و وضعیت مورد نظر ما چیه، اگر یکی نباشن، کوبر میره و حلش می‌کنه. اطلاعات وضعیت موجود از etcd میاد.

راه اندازی لوکال

و minikube چیه؟

اگر ما بخوایم کل کلاستر پروداکشن رو روی ماشین لوکال‌مون ران کنیم، سیستم‌مون قاعدتا جواب نمیده. برای همین از minikube استفاده می‌کنیم. این‌طور یک نود داریم که روش هم Master processes و هم Worker Processes ران میشه و روش داکر کانتینر نصبه. خب برای راه‌اندازیش ما از kubectl استفاده می‌کنیم.

و kubectl چیه؟

ابراز کامندلاین (CLI) برای کلاستر کوبر هست. توجه داشته باشین که kubectl فقط برای کار با Minikube cluster نیست و با همین ابزار با همه نوع کلاستر کوبر میشه کار کرد.

از سایت minikube نصبش می‌کنیم. اتفاقی که می‌افته ما خود minikube رو با داکر ران می‌کنیم و داخل خودش باز با داکر ران میشه اپ (آپشن ران با virtual machine رو هم داریم). پس اگر داکر ندارین، اون رو هم نصب کنین.

ران کردن کوبر با درایور داکر:

minikube start --driver docker

چک وضعیت کلاستر:

minikube status

نمایش همه نود های داخل کلاستر:

kubectl get node

نمایش همه پادها:

kubectl get pod

دستور اعمال فایل‌های yaml پیکربندی:

kubectl apply -f [mongo-config.yaml]

گرفتن تمام کامپوننت‌های داخل کلاستر:

kubectl get all

گرفتن کانفیگ‌مپ و سکرت‌های کوبر:

kubectl get secret
kubectl get configmap

جزئیات یک کمپوننت:

kuectl describe pod [pod-name]

چک کردن لاگ‌های یک پاد:

kubectl logs [pod-name] -f

گرفتن minikube IP:

minikube ip

نمونه کانفیگ یک پروژه کوبر ساده:

https://gitlab.com/nanuchi/k8s-in-1-hour