VPN پاد در Kubernetes در برابر دروازه خروج: تونل از آن کیست؟
یک پاد فضای نام شبکه خود را دارد، بنابراین انتخاب واقعی این است که کدام لایه مالک تونل باشد: هویت برای هر بار کاری یا خروجی هدایت‌شده با CNI با یک منبع مشترک.
یک پاد به نام vpn-gateway مستقر می‌کنید، یک کلاینت آزمایشی را به آدرس آن اشاره می‌دهید و می‌بینید بسته‌ها ناپدید می‌شوند. هیچ چیز در مانیفست اشتباه نیست و kubelet هیچ اعتراضی ندارد. دلیل ساختاری است، نه پیکربندی: Kubernetes به هر پاد فضای نام شبکه خودش را می‌دهد، بنابراین یک نام، یک برچسب یا یک فضای نام API مشترک هیچ تغییری در مقصد بسته‌ها ایجاد نمی‌کند. بنابراین تصمیم درباره اینکه ترافیک VPN چگونه از خوشه خارج شود با پرسشی درباره مالکیت آغاز می‌شود، نه درباره ایمیج‌های کانتینر.
دو سازوکار بیشتر استقرارهای واقعی را پوشش می‌دهند و قابل جایگزینی نیستند. یکی تونل را درون فضای نام شبکه خود بار کاری قرار می‌دهد. دیگری از CNI می‌خواهد ترافیک انتخابی را از یک گره دروازه تعیین‌شده عبور دهد. آن‌ها به شکل‌های متفاوت شکست می‌خورند، متفاوت مقیاس می‌شوند و به تیم‌های متفاوتی پاسخ می‌دهند، و به همین دلیل پرسش کانتینر معمولاً بحث‌هایی ایجاد می‌کند که هرگز حل نمی‌شوند.
مرز پاد یک فضای نام است، نه میزبان پرش
یک فضای نام شبکه لینوکس مالک رابط‌ها، آدرس‌ها، مسیرها و قواعد فایروال خود است و هر پاد یکی دریافت می‌کند. کانتینرهای درون آن پاد به آن می‌پیوندند و دقیقاً به همین دلیل یک کانتینر کمکی می‌تواند مسیرهایی را بازنویسی کند که برنامه سپس از آن‌ها پیروی می‌کند. پاد همسایه پشته‌ای دارد که ظاهری یکسان اما کاملاً جدا دارد. هیچ جدول مشترکی برای ارث‌بری پاد دروازه وجود ندارد و هیچ انتقال ضمنی ترافیک از یک فضای نام به فضای نام دیگر نیست.
به همین دلیل الگوی پاد دروازه فقط زمانی کار می‌کند که چیزی در بالادست واقعاً بسته‌ها را به آن بفرستد: یک Service، یک مسیر ایستا روی گره یا سیاست هدایت در CNI. آدرس به‌تنهایی چیزی را جذب نمی‌کند.
تونل برای هر پاد چه می‌خرد و چه هزینه دارد
تونلی که در فضای نام بار کاری اجرا می‌شود به آن بار کاری هویت کلاینت خودش را می‌دهد، که بسیاری از سرویس‌های دسترسی از راه دور پیش از مجاز کردن یا محاسبه یک نشست آن را می‌خواهند. شعاع آسیب نیز محلی می‌ماند: تونل خراب یک Deployment را از کار می‌اندازد، نه مسیر مشترکی را که همه استفاده می‌کنند. نحوه اجرای آن به پیاده‌سازی بستگی دارد و اینجا جایی است که مردم اشتباه حدس می‌زنند.
پیکربندی‌ای که فقط به وضعیت هسته نیاز دارد می‌تواند در یک کانتینر init تمام شود و خارج شود. دیمون فضای کاربر که باید در تمام عمر پاد زنده بماند به شکل کانتینر init قابل راه‌اندازی مجدد نیاز دارد که به عنوان سایدکار بومی در Kubernetes 1.29 معرفی شد، و این تمایز از پیاده‌سازی تونل می‌آید نه از سلیقه. هزینه این مدل تکرار است: هر نسخه احراز هویت می‌کند، آدرس تونل خودش را می‌گیرد و یک جایگاه نشست از راه دور مصرف می‌کند، بنابراین یک رویداد مقیاس‌پذیری خودکار به یک رویداد ظرفیت در آن سوی اتصال تبدیل می‌شود. کپی کردن یک اعتبارنامه در همه نسخه‌ها آن هزینه را حذف نمی‌کند، مسیر حسابرسی را حذف می‌کند. قابلیت‌ها نیز همان بررسی را می‌طلبند، زیرا تونلی که NET_ADMIN را در فضای نام خود می‌خواهد دلیلی ندارد اختیار کل میزبان یک نمونه با privileged: true را به ارث ببرد.
وقتی CNI مالک خروج است
اگر CNI از آن پشتیبانی کند، دروازه خروج ترافیک را بر اساس بار کاری و محدوده مقصد انتخاب می‌کند و سپس آن را از گره‌های منتخب زیر یک آدرس مبدأ قابل پیش‌بینی می‌فرستد. نسخه Cilium مرجع رایج است و مستنداتش صریح می‌گوید این قابلیت به پیکربندی مشخص Cilium به‌علاوه گره‌های دروازه با رابط‌ها و آدرس‌های درست نیاز دارد. همچنین دوره‌ای اولیه پس از ایجاد پاد را ذکر می‌کند که در آن هدایت هنوز اعمال نمی‌شود، که یک ورودی طراحی است نه پانویس.
آن تأخیر را در برابر وعده خودتان بخوانید. اگر قاعده این است که هیچ ترافیکی نباید از مسیر دیگری خارج شود، پاد جدیدی که در طول آن شکاف ارسال کند آن را قبلاً نقض کرده است، بنابراین توالی راه‌اندازی پاسخ خودش را می‌خواهد: برنامه را تا اعمال سیاست نگه دارید، یا پنجره را بپذیرید و مستند کنید.
ادعا را باریک نگه دارید. دروازه خروج یک مسیر را انتخاب و ترجمه می‌کند. VPN را پایان نمی‌دهد و بدون اتصال پشتیبانی‌شده در پشت آن، خوشه را به کلاینت شبکه دور شما تبدیل نمی‌کند.
| Question | Per-Pod tunnel | CNI egress gateway |
|---|---|---|
| Who holds the client identity | Each workload | The gateway, shared |
| What scaling changes | Enrollment and sessions per replica | Throughput and capacity per node |
| What the remote side sees | Distinct addresses | One translated source |
| Failure scope | One Deployment | Every workload behind the gateway |
ترجمه بی‌صدا آنچه را طرف دور می‌بیند تغییر می‌دهد
وقتی دروازه مبدأ را بازنویسی می‌کند، آدرس‌های هر پاد از بین می‌روند، بنابراین یک فهرست مجاز مبتنی بر هویت به فهرستی مبتنی بر یک آدرس مشترک تبدیل می‌شود. این یک معاوضه است نه نقص: قواعد کمتر برای نگهداری، انتساب درشت‌تر وقتی چیزی بدرفتاری می‌کند.
احراز هویت در سطح برنامه و ثبت درخواست‌ها باید چیزی را حمل کنند که شبکه دیگر گزارش نمی‌کند. ظرفیت و جایگزینی دروازه را زیرساخت مشترک بدانید، زیرا راه‌اندازی مجدد یک گره اکنون هر بار کاری پشت آن را قطع می‌کند، و مسیر بازگشت را زود بررسی کنید: طرف دور باید بداند چگونه به آدرس ترجمه‌شده برسد، معمولاً از طریق یک مسیر یا NAT که یک انسان، نه یک مانیفست، باید مالک آن باشد. برنامه‌ریزی آدرس هم به اینجا تعلق دارد، زیرا محدوده‌های هم‌پوشان خوشه و دور هر دو مدل را می‌شکنند و پذیرش IPv6 بهانه یک طرح متناقض نیست.
بر اساس مالکیت تصمیم بگیرید، سپس شکستی را که وعده دادید آزمایش کنید
تونل برای هر پاد را وقتی انتخاب کنید که سرویس دور بارهای کاری فردی را احراز هویت می‌کند، وقتی فقط چند Deployment به اتصال نیاز دارند و وقتی شکست باید محلی بماند. دروازه را وقتی انتخاب کنید که یک تیم شبکه از قبل مالک مسیر است، وقتی بسیاری از بارهای کاری یک مقصد را شریک‌اند و وقتی آدرس مبدأ پایدار تمام هدف تمرین است.
در هر صورت، ویژگی‌ای را که فروخته‌اید بررسی کنید، نه حالت پایدار را. یک پاد بسازید، بگذارید فوراً ارسال کند و اگر وعده این بود که چیزی از تونل فرار نمی‌کند ثانیه‌های اول را تماشا کنید. به پنج نسخه مقیاس کنید و اگر وعده هویت برای هر بار کاری بود، نشست‌هایی را که طرف دور گزارش می‌کند بشمارید. این دو بررسی محدودیت‌های سازوکار را بسیار سریع‌تر از بازبینی مانیفست آشکار می‌کنند و به شما می‌گویند رخداد بعدی متعلق به کدام تیم است.