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

در این مقاله فرض می‌شود شما با مفاهیم کوبرنتیز و آبجکت‌های آن آشنایی خوبی دارید.

معرفی برخی از تغییرات و ویژگی های مهم

در ادامه به برخی از تغییرات و ویژگی‌های جدید نسخه جدید کوبرنتیز اشاره می‌کنیم:

پشتیبانی از memory swap

استفاده از swap در لینوکس توسط کوبرنتیز دست‌خوش تغییرات بزرگی شده که پایداری بیشتری در مدیریت منابع نود ارائه کند. این ویژگی در مرحله‌ بتا قرار دارد و به طور پیش‌فرض در این نسخه از کوبرنتیز فعال است. با معرفی این ویژگی می‌توان به پادهای روی نود اجازه داد که از swap استفاده کنند و kubelet روی نودهایی که swap آن‌ها فعال است اجرا می‌شود.

تنظیمات دسترسی ساختاریافته

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

استفاده از CEL برای admission control

در کوبرنتیز برای اعمال محدودیت‌ها و بررسی policyها از زبانی به نام CEL یا Common Expression Language استفاده می‌شود. این زبان سینتکسی شبیه C و Java دارد. در نسخه‌ی 1.30 برای admission control می‌توان از CEL استفاده کرد و این ویژگی در حالت پایدار قرار دارد. منظور از admission control این است که بعد از احراز هویت و تعیین دسترسی‌ها و قبل از ذخیره شدن درخواست‌هایی که به API Server می‌آیند، می‌توان آن‌ها را بررسی و تایید کرد (validation) و/یا تغییرشان داد (mutation). حال با اضافه شدن CEL به کوبرنتیز این کار راحت‌تر از قبل انجام می‌شود.

مقیاس‌پذیری خودکار پاد بر اساس منابع کانتینر

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

پشتیبانی از نیم‌اسپیس user

این ویژگی تنها در لینوکس مورد استفاده است و در حالت بتا قرار دارد. به کمک آن می‌توان پادها را بهتر ایزوله کرد و از نظر امنیتی جلوی بسیاری از آسیب‌پذیری‌های خطرناک را گرفت.

تخصیص منابع پویا

این ویژگی که ترجمه‌شده‌ Dynamic Resource Allocation یا به اختصار DRA است،‌ در نسخه‌ی 1.26 به‌عنوان ویژگی آلفا معرفی شد. به کمک آن می‌توان منابعی که کوبرنتیز آن‌ها را نمی‌شناسد را در پاد آورد و توسط ابزارهای third-party فرایند تخصیص و آزادسازی منابع را انجام داد. توسط آن می‌توان هر نوع منابعی را برای پاد درخواست کرد. در نسخه‌ 1.30 بهبودهای بزرگی در این ویژگی اعمال شده که بتوان به شکل ساختارمند ارتباط بین درایورهای third-party و اجزای اصلی کوبرنتیز را فراهم کرد

جمع‌بندی

در این مقاله با برخی ویژگی‌های مهم که در کوبرنتیز 1.30 وجود دارند آشنا شدیم. در هر نسخه تغییرات زیادی اعمال می‌شود. با مراجعه به این لینک در گیت‌هاب می‌توانید تمام تغییرات این نسخه از نسخه‌ قبل را ببینید.

The post آشنایی با تغییرات کوبرنتیز نسخه ۱.۳۰ appeared first on بلاگ هم‌روش.

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

پیش‌نیازهای خواندن این مقاله عبارت‌اند از:

• دانستن مفاهیم شبکه و  TCP/IP و نحوه‌ پیاده‌سازی آن‌ها در لینوکس
• آشنایی با کانتینرها و نیم‌اسپیس‌ها در لینوکس
• آشنایی با کوبرنتیز، مفاهیم و آبجت‌های آن

معرفی شبکه‌ی کوبرنتیز

کوبرنتیز یک محیط توزیع‌شده است که روی ماشین‌های مجازی متعددی ایجاد می‌شود. این ماشین‌های مجازی روی تعدادی سرور فیزیکی قرار دارند که با استفاده از شبکه‌ فیزیکی با هم در ارتباط‌اند. برای این که ترافیک بین پادها و ترافیک خارج کلاستر به داخل مستقل از زیرساخت فیزیکی باشد، کوبرنتیز بین نودها شبکه‌ای مجازی می‌سازد. این شبکه دارای ساختاری flat است که همه‌ پادها بدون NAT به یکدیگر دسترسی دارند.

برای پیاده‌سازی چنین شبکه‌ای ابزارهای متن‌باز متعددی وجود دارند ولی همه‌ آن‌ها این موارد را رعایت می‌کنند:

• هر پاد آی‌پی یکتا و خاص خود را دارد.
• هر پاد اینترفیس و استک شبکه‌ خود را دارد. تمام ترافیک پاد از این اینترفیس می‌گذرد.
• هر پاد بدون NAT باید بتواند با پادهای دیگر در سراسر کلاستر ارتباط بگیرد.
• بین نودهای کلاستر باید مکانیزمی باشد که ارتباط پادهای آن‌ها را بدون مشکل فراهم کند.

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

پلاگین شبکه وظیفه‌ ایجاد و تنظیم نیم‌اسپیس شبکه‌ پادها را برعهده دارند. از پلاگین‌های شبکه‌ متن‌باز معروف می‌توان به Cillium و Calico اشاره کرد. ایجاد ارتباط پاد با دنیای بیرون و دنیای بیرون با پاد هم با این پلاگین‌ است. 

انواع ترافیک شبکه در کوبرنتیز

در ادامه انواع ارتباط شبکه در کوبرنتیز را خواهیم دید. ابتدا ارتباط پادها با هم بررسی می‌شود و سپس روش‌های پیچیده‌تر دسترسی به پاد را خواهیم دید.

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

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

در شکل بالا در پاد ۱ از eth0 از نیم‌اسپیس شبکه‌ پاد خارج شده و از veth0 وارد نیم‌اسپیس root نود می‌شود. eth0 و veth0 یک جفت اترنت مجازی یا virtual ethernet pair هستند. این جفت‌ها قابلیت این را دارند که ترافیک را از هر طرف بگیرند از طرف دیگر بیرون می‌دهند و به این شکل نیم‌اسپیس شبکه‌ پاد به نیم‌اسپیس شبکه‌ root وصل می‌شود. بعد از ورود پکت‌ها به نیم‌اسپیس root به کمک یک bridge لینوکسی به veth1 و از آن‌جا به داخل پاد ۲ که مقصد پکت‌ها بود هدایت می‌شوند. veth1 و eth0 در پاد ۲ هم جفت اترنت مجازی هستند. ممکن است پلاگین‌های مختلف در نیم‌اسپیس root کارهای متفاوتی انجام دهند ولی چیزی جز routing معمولی لینوکسی نیستند.

 ارتباط پاد با پاد در نودهای مختلف

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

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

ارتباط سرویس با پاد

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

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

مزیت سرویس این است که آیپی آن مانند آیپی پاد متغیر نیست. علاوه بر این نام سرویس در کوبرنتیز را می‌توان با DNS سرور کلاستر کوبرنتیز به آیپی سرویس resolve کرد. یعنی حتی آیپی سرویس را هم نیاز نداریم و با نام آن به پاد‌ مربوطه می‌رسیم. سرویس به کمک label پادها می‌تواند هم‌زمان چندین پاد را پشتیبانی و ترافیک را بین آن‌ها توزیع کند. 

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

ارتباط خارج کلاستر با پاد

آیپی پاد و سرویس ClusterIP فقط داخل کلاستر در دسترس هستند. برای دریافت پکت‌ها از خارج کلاستر از نوع دیگر سرویس که NodePort است استفاده می‌کنیم. از نام آن مشخص است که روی نودهای کلاستر یک پورت را برای پاد در نظر می‌گیرد. اگر پکت‌ها به آن پورت روی هر کدام از نودهای کلاستر برسند به پادهای مربوط به سرویس فرستاده می‌شوند. فرایند تبدیل از نودپورت به آیپی پاد هم مانند بخش قبل توسط ابزاری مثل iptables انجام می‌شود.  

بازه‌ای که برای اختصاص نودپورت در نظر گرفته شده به شکل پیش‌فرض از 30000 تا 32767 است. برای داشتن آیپی پابلیک می‌توان لود بالانسری در جلوی کلاستر قرار داد که آیپی پابلیک دارد و پکت‌ها را به نودپورت مناسب در نودهای کوبرنتیز می‌رساند. پس از آن پکت‌ها به نود می‌رسند و از آنجا تحویل پاد داده می‌شوند.

جمع‌بندی

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

The post شبکه (networking) در کوبرنتیز appeared first on بلاگ هم‌روش.

نمودار مصرف CPU

در این نمودار مصرف CPU را بر حسب زمان می‌بینید. خطی هم در آن نمایش داده شده که حداکثر میزان CPUی است که اپ یا همان کانتینر می‌تواند استفاده کند.

برای توضیح متریک مصرف CPU باید به جایی که این متریک از آن خوانده می‌شود نگاه کنیم؛ یعنی کرنل لینوکس. کرنل به ازای هر کانتینر (یا به طور کلی هر پردازه) عددی را برای مصرف CPU می‌دهد که cpuacct.usage است. این عدد بیان می‌کند پردازه‌های کانتینر در مجموع چند نانوثانیه از زمان CPU استفاده کرده‌اند. چون این عدد مجموع است، باید برای این که در بازه‌های مختلف مصرف CPU به دست آید نرخ تغییرات آن محاسبه شود. مثلا در زمان t کرنل عدد ۱۰۰۰۰۰ را برای cpuacct.usage یک کانتینر می‌دهد. در زمان t+1 هم عدد ۳۰۰۰۰۰ را می‌دهد. ما متوجه می‌شویم در یک ثانیه دویست هزار نانوثانیه یا ۲۰۰ میکروثانیه (اختلاف دو عدد در زمان t و t+1) از زمان CPU در پردازه‌های این کانتینر استفاده شده است.

 این متریک توسط ابزاری از کرنل خوانده می‌شود و به واحد ثانیه تبدیل می‌شود. سپس ابزار مانیتورینگ* آن‌ را دریافت و ذخیره می‌کند. این کار در بازه‌های زمانی خاصی به طور متناوب انجام می‌شود. مثلا هر ۱۰ ثانیه یک بار. در نتیجه ما هر ده ثانیه یک بار مجموع زمان استفاده شده در CPU را برای هر کانتینر داریم. آن چه در نمودار دیده می‌شود نرخ تغییرات این عدد در یک دقیقه است. یعنی نشان می‌دهد در هر دقیقه چقدر از زمان CPU مصرف شده است. برای مثال اگر در زمان یک ثانیه به اندازه ۲ ثانیه از CPUهای سیستم استفاده کند یعنی ۲ کور  CPU مصرف کرده است.

در این نمودار یک خط افقی هم دیده می‌شود که حداکثر میزان CPUی است که این کانتینر می‌تواند استفاده کند؛ این همان عددی است که موقع تعیین منابع برای CPU انتخاب می‌کنید.

نمودار CPU Throttling

متریک دیگری که برای CPU داریم در نمودار CPU throttling آمده است:

برای توضیح این نمودار باید با مفهوم دیگری در کرنل لینوکس آشنا شویم. در کرنل بازه‌هایی زمانی برای تخصیص CPU به پردازه‌های سیستم تعریف شده است. طول این بازه‌ها قابل تنظیم است و معمولا ۱۰۰ میلی ثانیه است. فرض کنید یک سیستم با ۴ عدد CPU داریم. در این سیستم در هر بازه‌ی ۱۰۰ میلی ثانیه‌ای زمانی به اندازه‌ی ۴۰۰ میلی ثانیه پردازه‌ها می‌توانند از CPU استفاده کنند چون ۴ عدد CPU داریم و هر کدام ۱۰۰ میلی ثانیه دارند.  

حال فرض کنید ما برای یک پردازه‌ یا همان کانتینر پایتونی محدودیتی تعیین می‌کنیم که فقط می‌تواند ۰.۳ تمام CPUهای این سیستم را مصرف کند. کرنل این ۰.۳ را در آن بازه‌های ۱۰۰ میلی ثانیه‌ای محاسبه می‌کند. یعنی از ابتدای بازه تا انتهای آن این پردازه‌ی پایتونی مجموعا می‌تواند

0.3*100ms=30ms

از تمام CPUهای سیستم استفاده کند. ممکن است در همان ۳۰ میلی ثانیه‌ی اول تمام بودجه مصرف شود و تا ابتدای بازه‌ی دیگر کرنل به این پردازه اجازه‌ی اجرا شدن نخواهد داد. 

کرنل برای throttling دو عدد مهم را در اختیار ما می‌گذارد. اولین عدد تعداد کل بازه‌های ۱۰۰ میلی ثانیه‌ای است که در آن کانتینر اجرا شده است. دومین عدد تعداد کل بازه‌هایی است که در آن‌ها throttling رخ داده است. پس اگر کانتینری ۱ ثانیه اجرا شود تعداد کل بازه‌ها و عدد اول ۱۰ می‌شود. اگر در ۲ تا از بازه‌ها این کانتینر throttle

شده باشد عدد دوم ۲ می‌شود. در نتیجه ۲۰ درصد بازه‌ها throttling داشتند. چیزی که در نمودار دوم نمایش داده می‌شود همین نسبت است. البته با توجه به این که عدد کرنل مجموع تعداد بازه‌ها را می‌دهد، نسبت افزایش این دو عدد در نمودار می‌آید. این اعداد هم توسط همان ابزاری که در قسمت قبل گفتیم خوانده می‌شوند. سپس ابزار مانیتورینگ در بازه‌های ۱۰ ثانیه‌ای آن‌ها را جمع‌آوری می‌کند.

مقایسه‌ دو نمودار

گاهی در بررسی این نمودارها سوالی پیش می‌آید که «چرا مصرف CPU به مقدار حداکثر تعیین شده نرسیده است ولی CPU throttling به وجود آمده است؟». با توجه به توضیحات داده شده این موضوع مشخص‌ می‌شود. اولاً داده‌های نمودار مصرف هر ۱۰ ثانیه یک بار خوانده می‌شوند؛ در نتیجه اگر در این میان افزایش ناگهانی باشد دیده نمی‌شود و ابتدا و انتهای بازه را فقط می‌بینیم. دوماً نقاط روی نمودار میانگین یک دقیقه‌ای از داده‌ها هستند. اگر در بعضی باز‌ه‌های ۱۰۰ میلی ثانیه‌ای مصرف CPU کانتینر زیاد شده و throttle شود و بعد از آن در بازه‌هایی کم شود، در نمودار مصرف خود را به‌خوبی نشان نمی‌دهد. ولی عدد نمودار throttling افزایش می‌یابد چون در کرنل پردازه‌های کانتینر throttle شده‌اند. وقتی مصرف CPU افزایش ندارد ولی CPU throttling افزایش قابل توجهی پیدا می‌کند به این معنی است که سرویس مورد نظر به شکل bursty از CPU استفاده می‌کند. حضور این دو نمودار زیر هم کمک می‌کند که متوجه این گونه رفتارهای برنامه‌ی درون کانتینر هم بشویم و در صورت نیاز منابع آن را افزایش دهیم.

The post نمودارهای مصرف CPU در دارکوب appeared first on بلاگ هم‌روش.