https://virgool.io/feed/@satrobit fa 2026-06-17 03:09:53 https://files.virgool.io/upload/users/14702/avatar/avatar.png?height=120&width=120 https://virgool.io/@satrobit https://virgool.io/@satrobit/%D8%A2%D8%B4%D9%86%D8%A7%DB%8C%DB%8C-%D8%A8%D8%A7-kata-containers-rp5sy4is7jwo پروژه‌ی Kata Containers از سال ۲۰۱۷ کار خودش رو شروع کرده و هم‌اکنون توسط بنیاد OpenStack پشتیبانی میشه. Kata Containers درواقع کار Clear Containers رو داره ادامه میده که پروژه‌ای از شرکت Intel بود که حالا توسعه‌اش متوقف شده. ایده‌ی Kata Containers آشتی دو دنیای ماشین‌های مجازی و کانتینرها هست که در ادامه بیشتر باهاش آشنا میشیم.شرح مشکلات موجودمشکلات کانتینرهاامنیت، امنیت و امنیت! همانطور که می‌دانید کانتینرهای در لینوکس همگی به‌صورت مشترک از کرنل، شبکه، I/O و مموری میزبان استفاده می‌کنند. ترکیب کرنل مشترک و آسیب‌پذیری‌های احتمالی در لینوکس میتونه منجر به فرار یک کاربر از محدودیت‌های موجود بشه و عملا به هاست دسترسی پیدا کنه.در بسیاری از موارد که تنها یک کاربر در یک هاست موجود است شاید این مشکل زیاد حس نشه اما در محیط‌های multi-tenant مثل public cloud ها که کاربران زیادی از یک هاست مشترک استفاده می‌کنند این مسئله یکی از دغدغه‌های اصلی است.کانتینرهای لینوکسی از چیزی به نام cgroups برای تخصیص و مدیریت منابع و namespace ها استفاده می‌کنند. برای ایجاد محدودیت و ایزوله کردن محیط کانتینر موارد زیادی اعمال میشن که شامل استفاده از SELinux و AppArmor، دراپ کردن syscall ها با استفاده از seccomp و ... میشه. این روزها بحث sandbox کردن خیلی داغ شده که برای مثال gvisor رو ببینید.کانتینرهای سنتیمشکلات ماشین‌های مجازیتوی زمینه‌ی مورد بحث ما میشه گفت اصلی‌ترین مشکل ماشین‌های مجازی سنگین‌وزن بودن آن‌ها و overhead بیش‌تر نسبت به کانتینرها هست.راه حل Kata Containersراه حل Kata Containers برای این قضیه ترکیب کانتینرها و ماشین‌های مجازی هست! درواقع ما با ماشین‌های مجازی‌ای طرف هستیم که قیافه‌ی کانتینر به خودشون گرفتن، باشگاه رفتن وزن کم کردن و حالا سرعت و چابکی کانتینرها رو دارند.کانتینرها در Kata Containersدر Kata Containers هر کانتینر روی یک ماشین مجازی سبک‌وزن اجرا میشه و اینطوری دسترسی به کرنل هاست نداره و توسط مجازی‌سازی سخت‌افزاری از بقیه‌ی کانتینرها ایزوله شده. ( در Kubernetes هر Pod روی یک ماشین مجازی مجزا اجرا میشه )این معماری به Public Cloud ها این امکان رو میده که بدون نگرانی (نسبتا!) چندین کاربر رو روی یک کلاستر یا روی یک هاست میزبانی کنند. شرح ارتباطات در Kata Containersهمونطور که در تصویر بالا می‌بینید Kata Containers یک OCI-compatible runtime داره که به شما اجازه میده به راحتی از ابزارهای موجود مربوط به Docker و کلا OCI برای مدیریت Kata Containers استفاده کنید.در مورد Kubernetes هم Kata Containers به شما امکان استفاده از طریق CRI میده ولی برای کوتاه نگه داشتن این پست وارد این بخش نمیشیم.من توی این پست سعی کردم مطالبی که به نظرم برای آشنایی خوب بودن رو از چند منبع جمع‌آوری کنم که البته اگر می‌خواستید جزئیات بیشتری در رابطه با Kata Containers بخونید میتونید از چندتا لینک زیر شروع کنید.لینک‌هاA Minimalistic Guide to Kata Containers10 Things You Need to Know about the Kata Containers ProjectWhy Kata Containers doesn’t replace KubernetesKata Containers Documentations امیر کشاورز امیر کشاورز Thu, 06 Jun 2019 19:11:53 +0430 https://virgool.io/@satrobit/%D9%85%D9%82%DB%8C%D8%A7%D8%B3%D9%BE%D8%B0%DB%8C%D8%B1%DB%8C-nginx-%D8%A8%D9%87-%D9%87%D9%85%D8%B1%D8%A7%D9%87-cache-itevye8kgir5 انجین‌ایکس چی هست؟!انجین‌ایکس یک Web Server/Load Balancer/Reverse Proxy هست که از مدل event-driven به‌جای thread برای درخواست‌های ورودی استفاده می‌کنه.سرعت رشد خوب NGINX این اجازه رو بهش داده که برای خیلی‌ها در واقع تبدیل بشه به یک وب‌سرور استاندارد.مقیاس‌پذیری NGINX در شروع کار ممکنه سخت به نظر برسه چون خود NGINX مکانیزمی کلاستر کردن نداره. توی مقیاس‌پذیری معمولا اولین چیزی که به ذهنمون می‌رسه مقیاس‌پذیری عمودی هست اما در این مدل ما محدودیت‌های زیادی از جمله سخت‌افزار داریم. درکل مقیاس‌پذیری عمودی در بسیاری موارد راه حل بی‌سلیقه‌ای هست.بزرگترین مشکل ما در مقیاس‌پذیری NGINX پیدا کردن cache هست! فرض کنید ما ده‌ها سرور لبه داریم و هر درخواست به‌صورت رندوم به یکی از این سرورها ارسال می‌شود. سرورهای NGINX که در بی خبری از یکدیگر به سر می‌برند سعی می‌کنند آن درخواست را کش کنند که باعث کاهش کارکرد کش می‌شود (مشکل فضای ذخیره‌سازی cache پیش‌کش).یک راه حل که ممکن است به ذهن خطور کند به اشتراک‌گذاری فضای ذخیره‌سازی cache بین تمامی سرورها می‌باشد. اما به‌دلیل این که hash های درخواست‌ها در مموری ذخیره می‌شوند، سرورهای NGINX از فایل‌هایی که توسط دیگر سرورها ذخیره شده‌اند خبری ندارند و ... (درکل NGINX رابطه خوبی با فضاهای مشترک مخصوصا برای cache ندارد. مشکلاتی اعم از latency نیز وجود دارد).امکان استفاده از Consistent Hashing برای فرستادن یک درخواست به یک سرور ثابت نیز در این مرحله برای ما وجود ندارد چون سرورهای NGINX در این ستاپ همگی سرور لبه هستند.چه کنیم؟از سوی دیگر ما می‌توانیم این مشکل را با یک مدل کلاستر دو مرحله‌ای حل کنیم. این مدل یکی از مدل‌های پیشنهادی خود NGINX هست. برای فهمیدن این مدل تصویر زیر رو ببینید:مدل ترکیبی لودبالانسر و کشدر این مدل ما روی هر سرور دو NGINX داریم؛ یکی به عنوان لودبالانسر و دیگری به عنوان کش سرور. هنگامی که یک درخواست HTTP به یکی از لودبالانسرها برسه (فرقی نداره کدوم) NGINX از روی یک key تعریف شده ( معمولا متشکل از URI و ... ) و با استفاده از Consistent Hashing و ایجاد هش یک کش سرور همیشه ثابت رو انتخاب می‌کنه. در دفعات بعد نیز اگر درخواست مشابهی در هر یک لودبالانسرها دریافت شد، درخواست به همان کش سرور ارسال می‌شود. حالا که کش سرور این درخواست را دریافت نموده مموری خود را چک کرده و اگر فایل کش وجود داشت آن را از روی فضای خود برگشت می‌دهد و اگر وجود نداشت درخواست را به سرور origin یا همان backend پراکسی می‌کند. برای دوستان عزیزی که کد و کانفیگ فایل رو بهتر از متن توضیحات متوجه می‌شن، من یک کانفیگ مثال متشکل از ۳ سرور آماده کرده‌ام.کانفیگ مثال https://gist.github.com/satrobit/526c91635f2ae603c98eabebbc0be880 کانفیگ بالا رو می‌تونید متناسب با نیازتون تغییر بدید و روی تمامی سرورها اجرا کنید.برای خوندن جزئیات بیشتر در این رابطه می‌تونید به Shared Caches with NGINX Plus Cache Clusters, Part 1 و Shared Caches with NGINX Plus Cache Clusters, Part 2 مراجعه کنید. امیر کشاورز امیر کشاورز Mon, 03 Jun 2019 20:51:02 +0430