Pod IP، ClusterIP یا متعادل‌کننده بار داخلی برای کاربران VPN
یک Pod IP تا زمانی که Pod جایگزین نشود، از طریق VPN قابل مسیریابی است. دسترسی مستقیم به Pod، ClusterIP و یک متعادل‌کننده داخلی را مقایسه کنید و ببینید هر کدام چه هزینه‌ای برای شما دارد.
با VPC CNI، یک Pod می‌تواند نشانی از VPC داشته باشد و کاربر VPN با مسیر درست می‌تواند مستقیماً به آن برسد. همین باعث می‌شود دسترسی مستقیم به Pod ساده‌ترین گزینه به نظر برسد، و واقعاً هم هست، تا زمانی که Pod جایگزین شود. نشانی که کاربر به یاد می‌سپارد باید متعلق به برنامه باشد، نه به یک نسخه تکراری. مقایسه این سه ورودی در نهایت به این برمی‌گردد که کدام شیء مالک نشانی است و چه چیزی باید هنگام جابه‌جایی بار کاری به کار خود ادامه دهد.
نخست بر اساس چرخه عمر انتخاب کنید، سپس بر اساس آنچه شبکه باید انجام دهد تا ورودی قابل دسترس شود.
سه ورودی، سه چرخه عمر
نشانی Pod IP متعلق به Pod است: همراه با آن تخصیص می‌یابد و هنگامی که پایان می‌یابد آزاد می‌شود. اما ClusterIP متعلق به یک Service است و مجازی است و تنها جایی معنا دارد که مسیریابی سرویس خوشه وجود داشته باشد. متعادل‌کننده بار داخلی متعلق به یک منبع ابری است که کنترل‌کننده خوشه آن را با بک‌اندها برنامه‌ریزی می‌کند. این مدل‌های مالکیت، خرابی‌ای را که دریافت می‌کنید پیش‌بینی می‌کنند: نشانی کهنه، نامی که در دسترس نیست، یا مجموعه‌ای از بک‌اندها که به‌روز نیست.
پیش از انتخاب، مقایسه را بنویسید. وقتی مالک و خرابی نام‌گذاری شوند، انتخاب معمولاً خودش را انجام می‌دهد.
| Entry | Owner | Failure when the workload moves |
|---|---|---|
| Pod IP | The Pod | Address changes and saved links break |
| ClusterIP | The Service | Virtual address with no meaning outside cluster routing |
| Internal balancer | Cloud resource plus controller | Backends update, but the DNS view is yours to maintain |
دسترسی مستقیم به Pod: مفید و موقت
دسترسی مستقیم واقعاً برای یک بررسی کنترل‌شده مفید است: یک مدیر، یک نشست کوتاه، یک درگاه مشخص. اما برای کاربران قرارداد بدی است، چون نشانی جزئیاتی از پیاده‌سازی است که با هر استقرار تغییر می‌کند. و ثبت یکی از آن‌ها در یک ویکی همان راهی است که یک سرویس سالم به شایعه تبدیل می‌شود.
این کار قواعد گسترده‌ای را هم دعوت می‌کند. اجازه دسترسی یک مدیر به یک Pod، اجازه برای هر نشانی در زیرشبکه گره نیست، و معمولاً دومی نوشته می‌شود.
ClusterIP: بر اساس طراحی محدود به خوشه
ClusterIP کار می‌کند چون dataplane خوشه مسیریابی را برای آن درون خوشه برنامه‌ریزی می‌کند. از یک لپ‌تاپ روی VPN، نشانی معنایی ندارد مگر اینکه چیزی آگاهانه آن را در معرض قرار دهد. نامی که به svc.cluster.local ختم می‌شود متعلق به DNS خوشه است، پس کپی کردن آن روی کارخواهی با resolver متفاوت نامی به وجود می‌آورد که وجود ندارد، نه خطای مسیریابی.
ClusterIP همچنان ورودی درست برای فراخوانندگان درون خوشه است، از جمله سایر بارهای کاری. فقط سازوکاری برای انتشار به کاربران بیرون از دامنه مسیریابی خوشه نیست.
متعادل‌کننده بار داخلی: مسیر منتشرشده
متعادل‌کننده بار داخلی به شما نشانی خصوصی پایدار و نامی می‌دهد که منطقه خودتان می‌تواند به آن اشاره کند، در حالی که کنترل‌کننده مجموعه بک‌اندها را به‌روز نگه می‌دارد، همان‌طور که راهنمای متعادل‌سازی بار EKS توضیح می‌دهد. این همان ورودی است که از یک جایگزینی معمول Pod جان سالم به در می‌برد بدون اینکه کسی سندی را ویرایش کند. هزینه‌اش یک منبع ابری، یک پیکربندی کنترل‌کننده و یک مسیر از VPN است و اینها همان بخش‌هایی هستند که مردم دست‌کم می‌گیرند.
از مدل کنترل‌کننده‌ای استفاده کنید که خوشه واقعاً اجرا می‌کند. حاشیه‌نویسی‌هایی که برای یک یکپارچه‌سازی نوشته شده‌اند برای دیگری اعمال نمی‌شوند.
نشانی مبدأ چه کسی است
گروه‌های امنیتی مبدأیی را می‌بینند که به مرز آن‌ها می‌رسد و بسته به مسیر VPN و متعادل‌سازی بار ممکن است کارخواه متصل یا نشانی ترجمه‌شده باشد. روی گره‌های مبتنی بر EC2، Podهای معمول VPC CNI به‌طور پیش‌فرض گروه‌های ENI گره را به ارث می‌برند، در حالی که پیکربندی‌های پشتیبانی‌شده می‌توانند گروه‌های مخصوص Pod را پیوست کنند. قواعد را برای مسیر مستند بنویسید، نه برای نشانی حدسی لپ‌تاپ.
شنونده و احراز هویت خود برنامه را به‌عنوان کنترل‌های جداگانه نگه دارید. قاعده شبکه‌ای که جریان را مجاز می‌کند تصمیم مجوزدهی نیست و نباید چنین تلقی شود.
چه چیزی به کاربران بدهید
به کاربران نام سرویس بدهید، نه نشانی. نام را در منطقه خصوصی منتشر کنید، آن را به ورودی داخلی اشاره دهید و سپس با جایگزین کردن یک Pod بک‌اند آزمایش کنید در حالی که کارخواه همان نام را باز نگه می‌دارد. این تمرین همان ویژگی‌ای را می‌سنجد که اهمیت دارد: رسیدن به همان برنامه پس از یک استقرار روتین.
دسترسی مستقیم به Pod را به‌عنوان یک استثنای عملیاتی مستند با دامنه خودش، دور از دستورالعمل‌های کاربران نگه دارید.