مفاهیم پیش‌نیاز

کوبِرنِتیز: ارکستراسیون کانتینرها

کوبرنتیز یک پلتفرم ارکستراسیون پکیج‌های کانتینری (Container Orchestration Engine) است که به‌ویژه برای مدیریت پکیج‌هایی که در قالب کانتینرهای داکر (Docker containers) ساخته شده‌اند، به‌کار می‌رود. کوبرنتیز کمک می‌کند تا این پکیج‌ها به صورت خودکار در محیط‌های مختلف اجرا، مقیاس‌دهی و بازیابی شوند.

کلاستر (Cluster)

یک کلاستر کوبرنتیز (Kubernetes Cluster) از کنترل پلین (Control Plane) و مجموعه‌ای از ماشین‌های اجرایی (worker machines) به اختصار نود (Nodes) تشکیل شده است که اپلیکیشن‌های کانتینری‌شده (containerized applications) را اجرا می‌کنند (اپلیکیشن‌هایی مانند ایمیج‌های داکری). نودهای اجرایی (Worker Nodes) میزبان پادها (Pods) هستند که اجزای اصلی ورک‌لود (Workload) یک اپلیکیشن را تشکیل می‌دهند.
هر کلاستر برای اجرای پادها به حداقل یک نود نیاز دارد.

نود (Node)

کوبرنتیز برای اجرای ورک‌لود (Workload)، کانتینرها را درون پادها قرار می‌دهد و آن‌ها را روی نودها (Nodes) اجرا می‌کند. نود می‌تواند یک ماشین مجازی یا فیزیکی باشد، بسته به نوع کلاستر. هر نود توسط کنترل پلین (Control Plane) مدیریت می‌شود و شامل سرویس‌هایی است که برای اجرای پادها لازم هستند.

ورک‌لود (Workload)

در کوبرنتیز، ورک‌لود به برنامه‌ای گفته می‌شود که در حال اجرا روی کلاستر است. این برنامه می‌تواند یک جزء مستقل یا مجموعه‌ای از اجزا باشد که با هم کار می‌کنند. در کوبرنتیز، ورک‌لود همیشه در قالب مجموعه‌ای از پادها (Pods) اجرا می‌شود. هر پاد، مجموعه‌ای از کانتینرها (Containers) را شامل می‌شود که در حال اجرا روی کلاستر هستند. مثال: یک اپلیکیشن وب یا سامانه پردازش داده (شامل یک یا چند پاد) می‌تواند به‌عنوان یک ورک‌لود تعریف شود. به‌صورت دقیق‌تر، اجرای ورک‌لودها توسط نودها (Nodes) انجام می‌شود.

پاد (Pod)

پاد (Pod) کوچک‌ترین واحد قابل استقرار و مدیریت در کوبرنتیز است. یک پاد، گروهی از یک یا چند کانتینر (Container) است که منابع ذخیره‌سازی و شبکه‌ای مشترکی دارند و مشخصاتی برای نحوه اجرای آن‌ها تعریف شده است. همه‌ی اجزای داخل یک پاد در یک محیط مشترک اجرا می‌شوند (هم‌مکان و هم‌زمان) و یک بستر منطقی (logical host) برای اجرای اپلیکیشن فراهم می‌کنند. این کانتینرهای داخل پاد می‌توانند به‌سادگی با هم ارتباط برقرار کنند و منابع را به اشتراک بگذارند. در محیط‌های غیر‌ابری، این ساختار اپلیکیشن‌هایی است که روی یک ماشین فیزیکی یا مجازی مشترک اجرا می‌شوند مشابه اپلیکیشن‌های ابری که روی یک بستر منطقی (logical host) اجرا می‌شوند.

ارتباط پادها (Pod Communication)

پادها می‌توانند از طریق سرویس‌ها (Services) با یکدیگر ارتباط برقرار کنند. این سرویس‌ها آدرس‌های پایدار و مسیرهای ارتباطی داخلی/خارجی برای پادها فراهم می‌کنند.
همچنین مفاهیم پیشرفته‌ای مثل Network Policies (سیاست‌های شبکه‌ای) هم برای کنترل امنیت و دسترسی وجود دارند.

از طریق پیکربندی ارتباط این بخش‌ها را تنظیم می‌کنید.


آبجکت‌ها در کوبرنتیز (Objects in Kubernetes)

آبجکت‌های کوبرنتیز (Kubernetes Objects) موجودیت‌هایی پایدار (persistent) در کلاستر هستند که برای نمایش وضعیت سیستم استفاده می‌شوند. این آبجکت‌ها تعیین می‌کنند:

  • چه اپلیکیشن‌های کانتینری‌شده‌ای در حال اجرا هستند و روی کدام نودها (Nodes)
  • چه منابعی در اختیار این اپلیکیشن‌ها قرار دارد
  • سیاست‌هایی درباره رفتار اپلیکیشن‌ها مانند قوانین راه‌اندازی مجدد (restart policies)، به‌روزرسانی‌ها (upgrades) و تحمل خطا (fault-tolerance)

هر آبجکت در واقع یک رکورد از نیت شما (record of intent) است. زمانی‌که آبجکتی را ایجاد می‌کنید، سیستم کوبرنتیز به‌طور مداوم تلاش می‌کند آن را حفظ کند. یعنی شما به کوبرنتیز می‌گویید: «من می‌خواهم این وضعیت (desired state) برای کلاستر من برقرار باشد.»

برای ایجاد، ویرایش یا حذف آبجکت‌ها، باید از رابط API کوبیت (Kubit API) که به پنل شما متصل است استفاده کنید؛ زمانی که در حال ویرایش فایل مانیفست (Object Manifest) هستید این نکته را مد نظر داشته‌باشید.

فضای‌نام (Namespace)

Namespace در کوبرنتیز یک مفهوم انتزاعی برای ایزوله‌سازی و دسته‌بندی منابع درون یک کلاستر است.
با استفاده از فضای‌نام‌ها کلاسترهای مجازی گوناگونی که به‌وسیله کوبرنتیز پشتیبانی می‌شود را ایجاد کرده و می‌توان منابع تخصیص شده بین پروژه‌ها، کاربران، محیط‌های مختلف (مثل dev، staging، prod) و رمزها را از هم جدا کرد.

  • نام منابع باید در داخل هر namespace یکتا باشد، اما می‌توانند در namespaceهای مختلف تکرار شوند.
  • فضای‌نام فقط برای منابع namespaced مثل Deployment و Service کاربرد دارد، و نه برای منابع سراسری (cluster-wide) مانند Node یا StorageClass.

از طریق تب فضای‌نام، فضاهای‌نام خود را مدیریت کنید.

زیرساخت به‌عنوان کد (Infrastructure as Code)

رویکرد ذخیره فایل های کانفیگ به صورت کد (configurations files stored as code) باعث می‌شود پیکربندی کلاستر و اپلیکیشن‌ها، مانند کد منبع نرم‌افزار، در قالب فایل ذخیره شود و از طریق Git قابل نسخه‌بندی، بررسی و بازیابی باشد. بدین صورت تمام تنظیمات شما به‌جای پنل‌های دستی یا دستورات متغیر، در قالب کد قابل تکرار، قابل بررسی و قابل ردیابی ذخیره می‌شوند. فضای نام و والت و فایل‌های کانفیگ و مانیفست همه به این صورت پیاده‌سازی شده‌اند تا راحتی استفاده را در پروژه‌ها فراهم کنند.

فایل مانیفست (Object Manifest)

فایل‌های مانیفست کوبرنتیز معمولاً در قالب YAML نوشته می‌شوند و برای تعریف منابع مختلف مورد استفاده قرار می‌گیرند؛ مانند:

  • Deployment
  • Service
  • ConfigMap

هر فایل مانیفست معمولاً شامل دو بخش داخلی (nested) است:

  • spec: بخشی که هنگام ایجاد شیء (Object) باید تعریف شود و وضعیت مطلوب (desired state) منبع را مشخص می‌کند.
  • status: وضعیت فعلی منبع را توصیف می‌کند که به‌صورت خودکار توسط کوبرنتیز به‌روزرسانی می‌شود.

این فایل در قسمت پیکربندی قابل ویرایش است. شما فایل پیکربندی یکپارچه خود را در آن قسمت بارگذاری می‌کنید کنترل پلین (Control Plane) کوبرنتیز سرویس کوبچی به‌طور مداوم status واقعی را بررسی کرده و تلاش می‌کند آن را با spec دلخواه شما همسان نگه دارد.

فایل پیکربندی (ConfigMap)

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


هلم (Helm)

هلم یک ابزار مدیریت بسته‌های کوبرنتیز است که کار نصب، به‌روزرسانی و حذف اپلیکیشن‌ها را آسان می‌کند. کاربرد آن به صورت یک "مدیر نرم‌افزار لینوکس یا npm در بسته‌های js" برای کوبرنتیز است و می‌تواند دستورات مختلفی را اجرا کند.

چارت (Helm Chart)

در هِلم (Helm)، چارت‌ها بسته‌هایی هستند که شامل قالب‌های YAML، فایل‌های کانفیگ و اطلاعات مورد نیاز برای اجرای یک اپلیکیشن خاص در کوبرنتیز هستند. چارت‌های کتابخانه‌ای (Library Charts) نوع خاصی از چارت هلم است که برای ارائه‌ی منطق و قالب‌های مشترک طراحی شده، اما خودش هیچ منبعی (Resource) مستقر (deploy) نمی‌کند. هر چارت مثل یک نسخه قابل نصب از اپلیکیشن‌هاست که می‌توان با هلم مستقرش (deploy) کرد. چارت‌ها می‌توانند منطق خود را به‌صورت قابل بازاستفاده (Reusable) طراحی کنند تا از تکرار جلوگیری و توسعه‌پذیری افزایش یابد. برای مستقر کردن و منبع‌دهی به چارت از فایل کانفیگ و فرم استفاده می‌شود. از بخش پیکربندی و تب ویرایشگر هلم چارت‌ها که به صورت فایل yaml رندر شده‌اند (قابلیت ویرایش ندارند از طریق بخش‌هایی مانند والت و مانیفست تغییراتی که اعمال می‌کنید روی این چارت اثر دارند) را مشاهده کنید.


نصب پک

منابع سفارشی (Custom Resources)

در کوبرنتیز، منابع سفارشی (Custom Resources) به‌عنوان افزونه‌هایی برای API عمل می‌کنند که امکان تعریف انواع جدیدی از آبجکت‌ها را فراهم می‌سازند و معمولاً در نصب پیش‌فرض وجود ندارند. فایل‌های تعریف کننده این منابع (معمولا در قالب YAML) را CRD یا Custom Resource Definition گویند. این منابع به توسعه‌دهندگان و اپراتورها اجازه می‌دهند تا قابلیت‌های خاصی را به کلاستر اضافه کنند، مستقلاً و بدون نیاز به تغییر در هسته‌ی کوبرنتیز. بسیاری از قابلیت‌های جدید و مدرن کوبرنتیز، مانند اپراتورها (Operators)، بر پایه‌ی همین منابع سفارشی ساخته شده‌اند. پس از نصب، این منابع دقیقاً مانند منابع داخلی (مثل Pod) قابل استفاده با ابزارهایی داخلی کوبرنتیز هستند.

اپراتورها در کوبرنتیز (Operators)

Operator افزونه‌ای نرم‌افزاری در کوبرنتیز است که با استفاده از منابع سفارشی (Custom Resources)، مسئولیت مدیریت اپلیکیشن‌ها و اجزای آن‌ها را بر عهده می‌گیرد.

اپراتورها بر پایه‌ی اصول کوبرنتیز، به‌ویژه حلقه کنترل (Control Loop) طراحی شده‌اند؛ یعنی وضعیت واقعی سیستم را با وضعیت مطلوب (Desired State) مقایسه می‌کنند و در صورت تفاوت، آن را اصلاح می‌کنند.

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

پک

پک در سامانه‌ی کوبچی (Kubchi) نوع اختصاصی از منابع سفارشی تعریف شده (Custom Resources Definition یا CRD)‌ است و برای مدیریت نسخه‌ی نصب‌شده‌ی یک چارت (Helm Release) در کوبچی (مستقل از هسته‌ی کوبرنتیز) می‌باشد.

این نسخه نصب‌شده شامل تمامی منابعی است که از طریق آن چارت روی کلاستر کوبرنتیز (Kubernetes Cluster) مستقر (deploy) شده‌اند، به همراه وضعیت اجرایی، تنظیمات، و تاریخچه تغییرات می‌باشد.

به عبارتی پک برای مستقر (deploy) کردن یک بسته روی کلاستر است و در واقع همان اپلیکیشن نصب‌شده‌ای است که از یک چارت هلم ساخته شده و اکنون توسط کوبرنتیز اجرا می‌شود.

ویژگی‌های اصلی پک‌ها در کوبیت:

  • هر پک شامل یک چارت هلم و فایل‌های پیکربندی مرتبط است
  • تغییرات در فایل‌های YAML به‌صورت آنی روی پک قابل اعمال است
  • کوبچی وضعیت اجرای پک را مانیتور کرده و قابلیت‌هایی مانند به‌روزرسانی، بازگشت (rollback) و حذف امن را ارائه می‌دهد
  • تمامی نسخه‌ها و تغییرات پک در سیستم گیت یا مخزن داخلی ذخیره می‌شوند (GitOps)

اپراتور پک (Pack Operator)

در سامانه کوبچی، پک اپراتور (PO) ابزاری توسعه داده‌شده توسط تیم کوبیت است به جهت مدیریت منابع سفارشی از جمله:

  • Pack
  • SecretReflector
  • و منابع اختصاصی دیگر

مهم‌ترین وظیفه‌ی این اپراتور، مدیریت چرخه عمر نصب چارت‌های Helm سفارشی یا پک (Pack) در کلاستر است؛ شامل:

  • نصب، به‌روزرسانی و حذف پک‌ها

  • همگام‌سازی وضعیت پک‌ها با کلاستر

  • اعمال تغییرات ایجاد شده روی پیکربندی (مثلاً از طریق YAML یا فرم) روی پک‌ها

  • مدیریت چرخه حیات پک‌ها (راه‌اندازی مجدد، تازه‌سازی و ...)

    و ...


اینگرس (Ingress)

Ingress در کوبرنتیز به شما این امکان را می‌دهد که ترافیک HTTP/HTTPS را از بیرون کلاستر به سمت سرویس‌های داخلی (Services) هدایت کنید. این مسیرها و قواعد مسیردهی توسط آبجکتی به نام Ingress تعریف می‌شوند. به بیان ساده: Ingress پلی میان دنیای بیرون (اینترنت) و سرویس‌های داخلی کلاستر شماست.

ویژگی‌های اصلی Ingress

یک Ingress می‌تواند برای شما امکانات زیر را فراهم کند:

  • آدرس‌های قابل دسترس عمومی (externally-reachable URLs) برای سرویس‌ها
  • متعادل‌سازی بار (Load Balancing) برای درخواست‌ها
  • مدیریت گواهی‌های TLS/SSL و پایان‌ دادن به ارتباط امن (SSL Termination)
  • میزبانی مجازی مبتنی بر نام دامنه (Name-Based Virtual Hosting)

اینگرس کنترلر (Ingress Controller)

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

بسته به پیکربندی شما، Ingress Controller می‌تواند:

  • از یک Load Balancer خارجی استفاده کند
  • با Router یا Reverse Proxy مثل NGINX، Traefik یا HAProxy ارتباط داشته باشد
  • گواهی‌های TLS را مدیریت کند (مانند اتصال به Let’s Encrypt)

سرویس کوبچی مدیریت ingress controller را به عهده دارد و می‌توانید از بخش مدیریت دامنه‌ها، دامنه را به آن متصل کنید و از قابلیت ingress بهره‌مند شده و به آن دسترسی داشته باشید.


رویداد (Event)

در یک رویداد (Event)، اطلاعات مربوط به تغییر وضعیت یا عملکرد یک آبجکت (مثل Pod، Node، Deployment و ...) را ثبت می‌کند؛ مانند:

  • زمان‌بندی موفق یا ناموفق یک پاد
  • ناپایدار شدن نود
  • شکست در mount شدن volume
  • یا راه‌اندازی مجدد کانتینر به دلیل کرش

رویدادهای کوبرنتیز می‌توانند در یکی از دسته‌های زیر قرار گیرند:

نوع (Type)توضیح
Normalپیام‌های اطلاعاتی که نشان‌دهنده‌ی عملیات‌های موفق هستند
Warningهشدارها، مثل تأخیر در زمان‌بندی یا تلاش برای mount ناموفق
Errorمعمولاً وجود ندارد؛ به‌جای آن Warning استفاده می‌شود و خطا در لاگ‌ها دیده می‌شود

سامانه مانتورینگ/آلرتینگ بر پایه پرومتئوس (Prometheus)

پرومتئوس (Prometheus) یک ابزار متن‌باز برای مانیتورینگ سیستم‌ها و ارسال هشدار (Alerting) است که در اکوسیستم کلود بومی (Cloud Native) بسیار پرکاربرد است. کلاسترهای کوبرنتیز مدیریت شده کوبچی از این ابزار برای پایش و مانیتورینگ سرویس استفاده می‌کنند.

این ابزار از یک مدل مبتنی بر Pull برای جمع‌آوری متریک‌ها (Metrics) استفاده می‌کند؛ به این معنا که به‌جای دریافت داده‌ها از طریق Push، خود پرومتئوس در بازه‌های زمانی مشخص اقدام به دریافت (scrape) داده‌ها از سرویس‌ها می‌کند.

نحوه عملکرد:

  1. اپلیکیشن‌ها یا سرویس‌ها باید متریک‌های خود را از طریق یک پایان‌نقطه‌ی HTTP یا HTTPS (مانند /metrics) در قالبی استاندارد (Prometheus exposition format) در دسترس قرار دهند.
  2. پرومتئوس طبق پیکربندی خود (مثلاً در فایل prometheus.yml یا از طریق CRDها در Kubernetes) به‌صورت دوره‌ای (scrape interval) متریک‌ها را از endpointهای HTTP(S) جمع‌آوری می‌کند. در محیط کوبرنتیز، Prometheus Operator از CRDهایی مانند ServiceMonitor برای کشف خودکار سرویس‌ها و از یک CRD دیگر به نام PrometheusRule برای تعریف هشدارها استفاده می‌کند.

خروجی /metrics یک اپلیکیشن ساده:

# HELP http_requests_total تعداد کل درخواست‌های HTTP
# TYPE http_requests_total counter
http_requests_total{method="GET", endpoint="/"} 1287
http_requests_total{method="POST", endpoint="/login"} 214

# HELP cpu_usage درصد مصرف CPU
# TYPE cpu_usage gauge
cpu_usage 67.3

# HELP memory_usage مصرف حافظه بر حسب مگابایت
# TYPE memory_usage gauge
memory_usage 512

# HELP go_gc_duration_seconds مدت زمان اجرای GC در Go
# TYPE go_gc_duration_seconds summary
go_gc_duration_seconds{quantile="0.5"} 0.000031
go_gc_duration_seconds{quantile="0.9"} 0.00005
go_gc_duration_seconds{quantile="0.99"} 0.00009
go_gc_duration_seconds_sum 0.0035
go_gc_duration_seconds_count 102

# HELP process_resident_memory_bytes Resident memory size in bytes.
# TYPE process_resident_memory_bytes gauge
process_resident_memory_bytes 15892480

می‌توان اطلاعات خروجی این ابزار را با استفاده از ابزارهای دیگری مثل grafana به نمایش درآورد.


متغیرهای محیطی (Environment Variables)

Environment Variables مقادیر نام‌گذاری‌شده‌ای هستند که خارج از برنامه ذخیره می‌شوند و معمولاً توسط سیستم‌عامل تنظیم می‌شوند. این متغیرها توسط برنامه‌ها و فرآیندها قابل دسترسی و استفاده هستند.

در کوبرنتیز، زمانی‌که یک پاد (Pod) ایجاد می‌کنید، می‌توانید برای کانتینرهای (Containers) داخل پاد، متغیرهای محیطی تعریف کنید. برای انجام این کار، باید در فایل پیکربندی YAML از فیلدهای env یا envFrom استفاده کنید.

تفاوت env و envFrom

هر یک از این دو فیلد نقش متفاوتی دارند:

env

به شما امکان می‌دهد برای هر متغیر محیطی، به‌صورت مستقیم مقدار مشخصی تعیین کنید.

مثال:

env:
  - name: PORT
    value: '8080'

envFrom

به شما اجازه می‌دهد متغیرهای محیطی را از یک ConfigMap یا Secret تعریف‌شده در کلاستر بارگذاری کنید.
تمام کلید-مقدارهای داخل ConfigMap یا Secret به عنوان متغیرهای محیطی در کانتینر تنظیم می‌شوند.

ویژگی‌ها:

  • می‌توانید یک پیشوند (prefix) مشترک برای همه متغیرها مشخص کنید.
  • روشی مناسب برای مدیریت تنظیمات محیطی به‌صورت متمرکز و قابل نسخه‌بندی است.

مثال:

envFrom:
  - configMapRef:
      name: my-config

واحدهای حافظه در کوبرنتیز (Memory Resource Units)

در کوبرنتیز، مقدار حافظه برای کانتینرها برحسب بایت (Bytes) تعریف می‌شود و می‌توان آن را با عدد یا پسوند مشخص کرد.

انواع پسوندها:

  • اعشاری (پایه ۱۰):
    k, M, G, T, P, E
    مثال: 400M یعنی ۴۰۰ مگابایت
  • باینری (پایه ۲):
    Ki, Mi, Gi, Ti, Pi, Ei
    مثال: 400Mi یعنی ۴۰۰ مِبی‌بایت (تقریباً ۴۲۰ مگابایت)

نکته مهم: