منظور از مشاهده‌پذیری و امنیت کوبرنتیز یا Kubernetes چیست – قسمت دوم (پایانی)

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

اخیراً در جامعه‌ی Kubernetes، مشاهده‌پذیری موضوع بحث بوده است و افراد زیادی به آن علاقه‌مند شده‌اند، ما بحث خود را با درک تفاوت بین مانیتورینگ و مشاهده‌پذیری شروع می‌کنیم. سپس می‌بینیم که چرا مشاهده‌پذیری برای امنیت در یک برنامه کاربردی توزیعی مثل کوبرنتیز حیاتی می باشد و ابزار آن را مرور کرده و به پیاده‌سازی‌ها برای مشاهده‌پذیری ارجاع خواهیم داد. با اینکه مشاهده‌پذیری موضوع گسترده‌ای می باشد و به چندین حوزه مربوط می‌شود، تمرکز ما در این بخش روی Kubernetes خواهد بود. با تعریف مانیتورینگ و مشاهده‌پذیری و تفاوت بین این دو شروع می‌کنیم.

مانیتورینگ در Kubernetes چیست

مانیتورینگ مجموعه‌ای از اقدامات در یک سیستم است که برای هشداردهی در مورد انحرافات از گستره‌ی عادی استفاده می‌گردد. موارد زیر مثال‌هایی هستند از انواع داده‌ای که می‌توان در کوبرنتیز آن‌ها را مانیتور کرد:

• Logهای Pod
• Logهای جریان شبکه
• Logهای جریان برنامه کاربردی
• Logهای ممیزی

مثال‌هایی از معیارهایی که می‌توان آن‌ها را مانیتور کرد:

• اتصالات در هر ثانیه
• Packetها در هر ثانیه، بایت در ثانیه
• درخواست برنامه کاربردی API در ثانیه
• استفاده از CPU و حافظه

این Logها و معیارهای سنجش می‌توانند به کاربر کمک کنند که خرابی‌های موجود را شناسایی کند و اطلاعات بیشتری را در مورد علائم بدست آوردند تا بتواند مسئله را حل کند.

برای مانیتور کردن کلاستر کوبرنتیز، بسته به SLAهایی که باید برای کلاستر به آن پایبند باشیم، از تکنیک‌هایی مثل نظرسنجی و بررسی Uptime استفاده می‌شود. در ادامه مثال‌هایی از معیارهایی که باید برای SLAها مانیتور شود، مطرح می‌گردد:

• نظرسنجی Endpointهای برنامه کاربردی/API
• کدهای پاسخ برنامه کاربردی، برای مثال کدهای خطای HTTP یا دیتابیس
• زمان پاسخ برنامه کاربردی به عنوان مثال طول HTTP، مدت‌زمان تراکنش دیتابیس
• دسترس‌پذیری Node برای موارد کاربرد Scale-Out
• منابع حافظه/CPU/دیسک/IO روی یک Node

بخش مهم دیگری از مانیتورینگ، هشداردهی می باشد، باید در راهکار مانیتورینگ خود، یک سیستم هشداردهی داشته باشیم که برای هر معیار سنجشی که  آستانه‌ی به‌خصوصی را نقض می‌کند هشدارهایی را ایجاد کند. ابزاری مثل Grafana ،Prometheus ،OpenMetrics ،OpenTelemetry و Fluentd به‌عنوان ابزار مانیتورینگ مورد استفاده قرار می‌گیرند تا Logها و معیارهای سنجش را جمع‌آوری کنند و گزارشات، داشبوردها و هشدارهایی را برای کلاسترهای Kubernetes ایجاد نمایند. کوبرنتیز برای Forward کردن و مدیریت هشدارها، با ابزاری مثلOpsgenie ،PagerDuty ، Slack و JIRA یکپارچه‌سازی شده است. مانیتور کردن کلاستر کوبرنتیز مشکلات زیر را در پی دارد:

بیشتر بخوانید: پلتفرم Grafana چیست و چگونه کار میکند

مقدار داده‌های Log

در یک سیستم مثل کوبرنتیز ، یک Node دارای چندین Pod است که روی Host اجرا می‌شوند و هر Pod با Logهای خود، هویت شبکه خود و منابع خود همراه است. این یعنی Logهایی از عملیات برنامه کاربردی، Logهای جریان شبکه، Logهای ممیزی Kubernetes و Logهای جریان برنامه کاربردی برای هر Pod وجود دارد. در یک محیط غیر Kubernetes، معمولاً یک برنامه کاربردی روی یک Node اجرا می‌شود، پس فقط یک مجموعه از Logها خواهد بود، نه یک مجموعه از Logها به ازای هر Pod که روی Node اجرا می‌گردد. این امر مقدار داده‌های Log که باید جمع‌آوری و بررسی شوند را چند برابر می‌کند. علاوه بر Logهای Pre-pod، لازم است که Logهای کلاستر نیز از Kubernetes جمع‌آوری گردد. معمولاً این موارد تحت عنوان Logهای ممیزی نیز شناخته می‌شوند که قابلیت دیدی را به فعالیت کلاستر کوبرنتیز ارائه می‌دهند. تعداد Logها در سیستم باعث می‌شوند که مانیتورینگ بسیار پرهزینه باشد و منابع زیادی را مصرف کند. عملیات کلاستر جمع‌آوری Log نباید پرهزینه‌تر از کلاستری باشد که برنامه‌های کاربردی در آن اجرا می‌گردد.

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

در یک کلاستر کوبرنتیز ، برنامه‌های کاربردی روی شبکه کلاستر کوبرنتیز توزیع می‌شوند. یک برنامه کاربردی که به بیش از یک Pod نیاز داشته باشد به عنوان مثال مجموعه پیاده‌سازی یا یک سرویس، برای هر Pod چندین Log خواهد داشت که باید بررسی شوند و همچنین باید حوزه‌ی این Podها تعیین شود مثلاً Scale Out، رسیدگی به خطا و غیره. ما چندین Pod داریم که پیش از ایجاد یک هشدار برای برنامه کاربردی، باید به‌عنوان یک گروه مدنظر قرار گیرند. حتماً باید توجه داشت که هدف ما مانیتور کردن برنامه کاربردی و ایجاد هشدارهایی برای برنامه کاربردی است و ایجاد هشدار به‌طور مستقل برای Podهایی که بخشی از یک برنامه کاربردی هستند، وضعیت برنامه کاربردی را به‌درستی نشان نمی‌دهد. همچنین موضوع برنامه‌های کاربردی میکروسرویس‌ مطرح است که در این حالت، یک برنامه کاربردی واحد به‌عنوان مجموعه‌ای از سرویس‌ها تحت عنوان میکروسرویس‌ها شناخته می‌شود و هر میکروسرویس مسئول بخشی از عملکرد برنامه کاربردی می باشد. در این صورت باید هر میکروسرویس را به‌عنوان یک نهاد مانیتور کنیم باید توجه شود که میکروسرویس مجموعه‌ای از یک یا چند Pod است و سپس بفهمیم که کدام میکروسرویس‌ها روی تراکنش هر برنامه کاربردی تأثیر می‌گذارند. فقط در این صورت است که می‌توانیم هشداری را برای برنامه کاربردی گزارش دهیم.

بیشتر بخوانید: معرفی و نحوه عملکرد Kubernetes در vSphere به همراه بررسی مزایای این تکنولوژی

طبیعت اخباری Kubernetes چیست

همان‌طور که قبلاً اشاره شد، کوبرنتیز اخباری است و به کاربران این توانایی را می‌دهد که مشخص کنند  می‌خواهند Podها دقیقاً چطور در کلاستر ایجاد و اجرا شوند. Kubernetes چیست؟ Kubernetes به کاربران این امکان را می‌دهد که محدودیت‌های منابع را برای حافظه، CPU، Storage و غیره مشخص کنند و همچنین منابعی سفارشی را بسازند و محدودیت‌هایی را برای این منابع مشخص نمایند. مسئول برنامه‌ریزی یک Node را پیدا می‌کند که دارای منابع لازم بوده و یک Pod را روی آن Node برنامه‌ریزی می‌نماید.  کوبرنتیز همچنین میزان استفاده را برای Podها مانیتور می‌کند و Podهایی را که منابع بیشتر از آنچه به آن‌ها اختصاص داده می‌شود مصرف می‌کنند، حذف می‌نماید. به علاوه، کوبرنتیز معیارهای سنجش دقیقی را فراهم می‌کند که می‌توان از آن‌ها برای مانیتور کردن Podها و وضعیت کلاستر استفاده کرد. مثلاً می‌توان از ابزاری مثل Prometheus استفاده کرد که می‌تواند Podها و وضعیت کلاستر را مانیتور کرده و از معیارها استفاده نماید و می‌توان به‌طور خودکار Podها یا منابع کلاستر دیگر را با مکانیزمی به نام Horizontal Pod Autoscaler توسعه داد. این بدین معنا است که کوبرنتیز به‌عنوان بخشی از عملیات خود مانیتورینگ انجام می‌دهد و تغییراتی را به کلاستر اعمال می‌کند تا عملیات را طبق مشخصات پیکربندی اجرایی نماید. در این سناریو، یک هشدار از مانیتورینگ یک معیار واحد می‌تواند نتیجه‌ی این باشد که کوبرنتیز تغییراتی را اعمال می‌کند تا خود را با بار درون کلاستر تطبیق دهد و یا ممکن است مشکلی واقعی وجود داشته باشد. کاربر باید بتواند تمایز بین این دو سناریو را متوجه شود و به‌طور دقیقی برنامه کاربردی خود را مانیتور نماید.

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

مشاهده‌پذیری

مشاهده‌پذیری Kubernetes چیست؟ مشاهده‌پذیری عبارت است از توانایی درک وضعیت داخلی یک سیستم با صرفاً دیدن خروجی‌های خارجی سیستم. مشاهده‌پذیری بر پایه مانیتورینگ تعریف می‌شود و به کاربران توانایی کسب بینش به وضعیت داخلی برنامه کاربردی را می‌دهد. مثلاً در یک کلاستر کوبرنتیز ، ری‌استارت Pod به‌صورت غیرمنتظره ممکن است تأثیر ناچیزی روی خدمات داشته باشد، زیرا شاید Instanceهای دیگر Pod برای رسیدگی به بار در زمان ری‌استارت کافی باشند. یک سیستم مانیتورینگ هشداری را ایجاد می‌کند که می‌گوید یک ری‌استارت Pod غیرمنتظره رخ داده است و یک سیستم مشاهده‌پذیری یک رخداد با اولویت متوسط ایجاد می‌کند که می‌گوید یک ری‌استارت Pod غیرمنتظره رخ داده است اما تأثیری روی سیستم نگذاشته است، البته درصورتی‌که در زمان ری‌استارت شدن Pod رخداد دیگری مثل خطای برنامه کاربردی وجود نداشته باشد. مثال دیگر زمانی است که یک رخداد در لایه برنامه کاربردی ایجاد شده باشد مثلاً در زمانی که درخواست HTTP بزرگ‌تر از حالت عادی باشد. در این سناریو، سیستم مشاهده‌پذیری ساختاری را برای دلایل تنزل در زمان پاسخ برنامه کاربردی فراهم می‌کندبه عنوان مثال مشکلات در لایه شبکه، ارسال مجدد، ری‌استارت Pod برنامه کاربردی به دلیل مشکلاتی در منابع یا برنامه‌های کاربردی دیگر، مشکلی در زیرساخت کوبرنتیز مثل میزان تأخیر DNS یا بار سرور API.

نحوه‌ی کار مشاهده‌پذیری برای کوبرنتیز

طبیعت اخباری کوبرنتیز در پیاده‌سازی یک سیستم مشاهده‌پذیری بسیار مفید می باشد،  پیشنهاد می‌شود که سیستمی ساخته شود که برای Kubernetes، Native محسوب شده و بتواند عملیات را در یک کلاستر درک نماید. مثلاً سیستمی که کوبرنتیز را درک کند، یک Pod را مانیتور می‌کند، مثلاً ری‌استارت، از حافظه، فعالیت شبکه و غیره. اما همچنین درک کند که آیا Pod یک Instance مستقل است یا بخشی از یک پیاده‌سازی، مجموعه Replica یا سرویس. همچنین خواهد دانست که Pod چقدر برای سرویس یا پیاده‌سازی حیاتی است، مثلاً سرویس چطور برای مقیاس‌پذیری و دسترس‌پذیری بالا پیکربندی‌شده است. پس وقتی رخدادی مربوط به Pod را گزارش می‌کند، تمام این ساختار را فراهم می‌کند و باعث می‌شود که به‌راحتی بتوانیم تصمیمی در مورد نحوه‌ی پاسخ به رخداد بدهیم.

چیز دیگری که باید به خاطر داشت این است که در کوبرنتیز می‌توان برنامه‌های کاربردی را به‌عنوان Podهایی پیاده‌سازی کرد که بخشی از ساختارهایی در سطح بالا مثل یک پیاده‌سازی یا سرویس هستند. برای درک پیچیدگی پیاده‌سازی مشاهده‌پذیری برای این ساختارها، از مثالی برای توضیح‌شان استفاده می‌کنیم. وقتی‌که یک سرویس پیکربندی می‌شود، کوبرنتیز تمام Podهای مربوط به آن سرویس را مدیریت‌ کرده و اطمینان حاصل می‌کند که ترافیک به Podهای قابل‌دسترسی که بخشی از سرویس هستند ارائه گردد. در ادامه نگاهی می‌اندازیم به مثالی از تعریف سرویس از اسناد Kubernetes:

apiVersion: v1 kind: Service metadata:

name: my-service

spec:

selector:

app: MyApp

ports:

– protocol: TCP

port: 80

targetPort: 9376

در این مثال، تمام Podهایی که دارای برچسب MyApp هستند و روی پورت TCP به شماره‌ی 9376 گوش می‌دهند، تبدیل می‌شوند به بخشی از سرویس و تمام ترافیکی که مقصدش سرویس است به سمت این Podها هدایت می‌گردد. پس در این سناریو، راهکار مشاهده‌پذیری نیز باید کار کند تا بینش‌هایی را در سطح سرویس فراهم نماید. مانیتور کردن یک Pod در این صورت کافی نیست. نیاز است که مشاهده‌پذیری معیارهای سنجش را روی تمام Podها در یک سرویس تجمیع کند و با استفاده از اطلاعات جمع‌آوری‌شده تجزیه‌وتحلیل‌ها و هشدارهای بیشتری را فراهم نماید.

حالا به مثالی از پیاده‌سازی‌ها در کوبرنتیز می‌پردازیم. پیاده‌سازی به کاربر این توانایی را می‌دهند که Podها و مجموعه Replicaها، Replicaهایی از یک Pod که معمولاً برای توسعه و دسترس‌پذیری بالا مورداستفاده قرار می‌گیرد را مدیریت نماید. در ادامه مثالی از پیکربندی برای یک پیاده‌سازی در کوبرنتیز می‌بینیم:

apiVersion: apps/v1 kind: Deployment metadata:

name: nginx-deployment

labels:

app: nginx

spec:

replicas: 3

selector:

matchLabels:

app: nginx

template:

metadata:

labels:

app: nginx

spec:

containers:

– name: nginx

image: nginx:1.14.2

ports:

– containerPort: 80

این پیکربندی یک پیاده‌سازی را برای nginx با سه Replica Pod با فراداده و مشخصات پیکربندی‌شده، می‌سازد. Kubernetes دارای یک کنترلر پیاده‌سازی است تا اطمینان حاصل کند که تمام Podها و Replicaها که بخشی از پیاده‌سازی هستند، قابل‌دسترسی می‌باشند.

چندین مزیت دیگر نیز وجود دارد، مثل ارائه بروزرسانی‌ها، توسعه خودکار و غیره که می‌توان با استفاده از منابع پیاده‌سازی در Kubernetes به آن‌ها دست پیدا کرد. در چنین سناریویی برای مشاهده‌پذیری، ابزاری که مورداستفاده قرار می‌گیرد باید به فعالیت تمام Podها (Replicaها) در یک پیاده‌سازی به‌عنوان یک تجمیع نگاه کند، مثلاً کل ترافیک از Podها و به Podها در یک پیاده‌سازی، ری‌استارت‌های  و تأثیر آن‌ها روی یک پیاده‌سازی و غیره. مانیتورینگ و هشداردهی برای هر Pod برای درک اینکه پیاده‌سازی چطور کار می‌کند، کافی نخواهد بود.