مدل پیاده‌سازی شبکه در کوبرنتیز باعث می‌شود اجزای مختلف کلاستر مثل پادها و نودها با هم ارتباط برقرار کنند و ترافیک خارجی به سمت اپلیکیشن‌های روی کوبرنتیز هدایت شوند. این شبکه به شکلی طراحی شده است که ترافیک بدون دردسر بین نودهای کلاستر جابه‌جا شود و به مقصد خود برسد.
فهمیدن نحوه کار شبکه در کوبرنتیز به شما کمک می‌کند هنگام طراحی سناریوهای پیچیده دید بهتری به کلاستر خود داشته باشید و بتوانید مشکلات احتمالی را سریع‌تر عیب‌یابی و برطرف کنید. در این مطلب قصد داریم با معماری شبکه کوبرنتیز آشنا شویم و انواع ارتباطات در آن را بررسی کنیم.
پیش‌نیازهای خواندن این مقاله عبارت‌اند از:
- دانستن مفاهیم شبکه و 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 است. برای داشتن آیپی پابلیک می‌توان لود بالانسری در جلوی کلاستر قرار داد که آیپی پابلیک دارد و پکت‌ها را به نودپورت مناسب در نودهای کوبرنتیز می‌رساند. پس از آن پکت‌ها به نود می‌رسند و از آنجا تحویل پاد داده می‌شوند.
جمع‌بندی
در این مقاله با مفاهیم کلی شبکه در کوبرنتیز آشنا شدیم و دیدیم که چه قواعدی بر ایجاد این شبکه حکم‌فرماست. سپس بررسی کردیم که چگونه انواع ترافیک در کلاستر کوبرنتیز جابه‌جا می‌شوند و چه ابزارهایی در این میان کار می‌کنند.
