معماری مانیتورینگ در کوبرنتیز (Kubernetes)

در‌این مقاله به معماری Monitoring در Kubernetes خواهیم پرداخت. پیش نیاز مطالعه‌این مقاله آشنایی با کوبرنتیز  است که در آکادمی ‌ابری XaaS مطالب مختلفی در‌این خصوص منتشر شده است.

بررسی Monitoring از دیدگاه لایه‌ای

مدل سنتی (دولایه)

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

مدل docker base (مدل سه لایه)

در‌این مدل‌ هاست و یا سروری وجود دارد که که روی آن container engine همانند docker راه‌اندازی شده است و app‌های مختلف مایکروسرویسی به صورت dockerize پیاده سازی شده اند. علاوه بر موارد اعلامی‌ در مدل سنتی، نیازمند راه حلی برای مانیتور کردن خود container engine همانند docker هستیم.
می‌توانیم ‌این نوع مانیتورینگ را سه لایه در نظر بگیریم. ماینیتورینگ سرور، مانیتورینگapp ‌ها و ماینیتورینگ docker ‌ این سه لایه را تشکیل می‌دهند. این مدل یک مزیتی نسبت به مدل قبل دارد و آن سادگی مانیتورینگ app‌های مختلف run شده روی سرور است.
با توجه به container base بودنapplication ‌های run شده روی سرور با مانیتور کردن container مربوط به هر app می‌توانیم از وضعیت مربوط به app ‌های خود به صورت مجزا آگاه شویم، اما در مدل سنتی مانیتور کردن app ‌های مختلف در سرور چالش برانگیز و پیاده سازی مانیتورینگ app‌ها به صورت مجزا دارای پیچیدگی است.

مدل orchestration (چهار لایه)

در‌این مدل چهار لایه برای مانیتورینگ وجود دارد که علاوه بر لایه‌های معرفی شده در مدل docker base لایه‌ای مدیریتی برای مدیریتcontainer ‌ها به وجود آمده است که ابزار‌هایی همچون کوبرنتیز‌این وظیفه را بر عهده دارند که لایه چهارم‌این مدل، مربوط به مانیتورینگ خود کوبرنتیز و اجزای آن است. مانیتورینگ اجزایی هم چون api server و etcd و…

مفهومی‌ به نام Metric

منظور ازmetric درMonitoring، اطلاعات و لاگ‌های مربوط به تارگت (چیزی که می‌خواهیم مانیتور کنیم) است، اطلاعاتی همچون میزان ترافیک Network سرور و میزان CPU usage و… که از جهات مختلف می‌توان آن را تقسیم بندی و تحلیل و تفسیر کرد که در ادامه مقاله به برخی از آنها می‌پردازیم.

A core metrics pipeline

A core metrics pipeline اطلاعات و دیتا‌های مورد نیاز کوبرنتیز برای برخی از کارهای خود است. Core metrics ‌ها شامل داده‌هایی است که اجزای کوبرنتیز با آن کار می‌کنند و با کمک آنها به انجام وظایف خود می‌پردازند. Core metrics‌ها در بحث‌های replica و auto scaling مربوط به podهای مختلف در کوبرنتیز کاربرد زیادی دارند.
حالا با یک مثال کاربری ‌این موضوع را شفاف کنیم. در نظرم می‌گیریم pod ‌های مختلفی از کانتینر nginx داریم که replica آن به عدد 20 افزایش یافته است، حال کوبرنتیز برای‌اینکه به ‌این تشخیص برسد pod ‌های مختلف خود را در چه node ‌هایی از کلاستر‌ایجاد کند نیاز به اطلاعات و داده‌هایی درخصوص وضعتیت node‌ها دارد، scheduler با توجه به اطلاعاتی که از Core metrics‌ها به دست آورده است مشخص می‌کند که pod ‌های روی کدام node از کلاستر kubernetes ‌ایجاد شوند، در حقیقت‌ این اطلاعات مربوط به نود‌ها که در تصمیم گیری scheduler مهم و موثر می‌باشند، مربوط به بحث  core metric‌ها است.

A monitoring pipeline

در‌این نوع مانیتورینگ می‌توان اطلاعاتی همچون میزان مصرف منابع در هر namespace یا میزان مصرف resource ‌ها برای هر pod را مشخص کرد. Monitoring pipeline  توسط ابزار‌های بیرونی (ابزار‌هایی هم چون Prometheus) کمک می‌کنند که با جمع آوری و مرتب کردن دیتا‌ها بتوانیم مانینورینگی در خصوص مصرف منابع در pod و یا namespace ‌ها و…. داشتیم باشیم. با توجه به کارکرد آن برخلافcore metrics ‌ها، ‌این نیاز وجود دارد که کوبرنتیز به کمک ابزار‌های جانبی داده‌ها و لاگ‌های مربوط به مانیتورینگ را به بیرون expose کند.

انواع metric‌ها در کوبرنتیز

System metrics

شامل اطلاعات کلی همچون cpu و memory و… است. در حقیقت system metric ‌ها اطلاعات کلی همچون رم و پردازنده و دیسک‌ها را به بیرون expose و با کمک ابزار‌های بیرونی استخراج و نمایش می‌دهد.

Service metrics

هر سرویسی می‌تواندmetric ‌های خاص خود را داشته باشد. به عنوان مثال توسعه دهنده در نرم افزار خود، موارد خاصی را که مربوط به نرم افزار است در برنامه مشخص و expose کرده است که با service metric‌ها می‌توان موارد خاص‌ این چنینی را نیز مانیتور کرد. حالا نرم افزاری مانند whatsapp را در نظر بگیریم، با توجه به ماهیت‌ این نرم افزار مثلا می‌توان موارد خاص مربوط به‌این نرم افزار را مانیتور کرد، مثلا در هر لحظه چه تعداد یوزری در حال مکالمه تلفنی با نرم افزار هستند و…. با Service metrics‌ها می‌توان تعداد‌ تماس‌های whatsapp را استخراج کرد.

Exporters

قبلا ابزار‌های ماینتورینگی وجود داشتند که با کمک‌این ابزار‌ها، سرور‌ها مانیتور می‌شدند، به عنوان مثال با نصب agent zabbix سرور‌های مختلف را zabbix base مانیتور می‌کردند و یا به کمک snmp ‌ها اطلاعاتی در خصوص سرور‌ها استخراج و در نمودار‌ها نمایش می‌دادند ابزار‌هایی هم چون cacti و PRTG و… اما با توجه به پیشرفت تکنولوژی و به وجود آمدن container ‌ها عملا بحث agent zabbix و snmp‌ها در مانیتورینگcontainer ‌ها تاثیر چندانی نداشته است. به همین دلیل مفاهیمی‌ به نامExporters ‌ها به وجود آمدند.
Exporters ‌ها به‌این صورت عمل می‌کنند که برای هر تارگتی (هر آنچه مربوط به container ‌ها و orchestration‌ها) exporter جداگانه‌ای جهت مانیتورینگ نوشته می‌شود. Exporter ‌ها یا یک نرم افزار جداگانه جهت مانیتورینگ هستند یا خودآنها بخشی از application توسعه داده شده هستند.
وظیفه مهم exporter ‌ها Expose کردن اطلاعات و دیتای و یا metric ‌های مربوط به مانیتورینگ است. به بیان ساده، exporter‌ها اطلاعات مورد نظر تارگت‌ها را (چیزی که قصد مانیتور کردن آن را داریم) استخراج و تحویل ابزار بیرونی جهت نمایش دادن اطلاعات مانیتورینگ می‌دهند.

انواع Exporters

Metrics-server

Metrics-server مربوط به مانیتورینگ core metric ‌ها است که به بیرون expose نمی‌شود و جهت مانیتورینگ خود kubernetes است. اطلاعات یا Metric‌های مربوطه به‌ این مانیتورینگ مورد استفاده خود کوبرنتیز است وMetric ‌های آن به ابزار‌های جانبی بیرونی expose نمی‌شود.

Cadvisor

Cadvisor اطلاعات مربوط به docker را ارائه می‌کند. برای مانیتورینگ مربوط به هر آنچه که مربوط به docker است مورد استفاده قرار گرفته می‌شود.

Kube-state-metrics

Kube-state-metrics برای مانیتورینگ object ‌های مختلف Kubernetes مورد استفاده قرار گرفته می‌شود، مانیتورینگ مواردی همچون pod و namespace و deployments و… که metric‌ها را به بیرون expose می‌کنند.

Node-exporter

Node-exporter برای مانیتورینگ سرور‌ها مورد استفاده می‌باشند که metric ‌های مربوط به‌ هاست را به ابزار‌های بیرونی جانبی expose می‌کند. به عنوان مثال کلاستری از کوبرنتیز با سه نود master و سه نود worker وجود دارد. می‌ توان با استفاده ازnode exporter ‌ها نود‌های مد نظر خود را مانیتور و اطلاعاتی کلی همچون میزان مصرف پردازنده و رم و دیسک و…. را در مورد آنها دریابیم.

نتیجه گیری

برای مانیتورینگ Application مختلف که در کلاستر کوبرنتیز Deploy شده اند نمی‌توان از روش‌های سنتی و قدیمی‌ بهره‌مند شد، برای‌این نوع مانیتورینگ می‌بایست از Exporter‌های مختلف استفاده کرد و با کمک ابزار‌های جانبی مانند Prometheus داده‌ها را به داشبوردهای گرافیکی مانند گرافانا جهت مانیتورینگ تحویل داد.