یک sidecar VPN در Pod کوبرنتیز شبیه یک VPN در سطح میزبان با رفتار بهتر است و شباهت در مرز فضای نام تمام می‌شود. کانتینرهای یک Pod فضای نام شبکه، از جمله فضای آدرس و پورت را به اشتراک می‌گذارند، بنابراین sidecar‌ای که مسیرها و سیاست نصب می‌کند واقعاً تغییر می‌دهد که بسته‌های برنامه کجا می‌روند. برای Podهای دیگر روی گره هیچ چیز را تغییر نمی‌دهد و به پشتهٔ خود گره دست نمی‌زند مگر اینکه آن را این‌گونه پیکربندی کنید. درست گرفتن این مرز هم تعیین می‌کند چه چیزی می‌توانید مستقر کنید و هم چه چیزی را باید آزمایش کنید. بخش‌های زیر آن را از فضای نام به سمت بیرون دنبال می‌کنند.

فضای نام مشترک، پیامدهای مشترک

دو کانتینر در یک Pod از طریق loopback صحبت می‌کنند و همان رابط‌ها را می‌بینند، و به همین دلیل الگوی sidecar اصلاً کار می‌کند: برنامه لازم نیست بداند تونلی وجود دارد، زیرا مسیری که به آن می‌رسد در فضای نامی که استفاده می‌کند نصب شده است. همین ویژگی یعنی خطاهای sidecar همان خطاهای برنامه هستند. مسیری که بیش از حد بگیرد، یا تغییر DNS که به یک resolver داخل تونل اشاره کند، فوراً بر هر فرایند در آن Pod اعمال می‌شود. در فضای نام مشترک مسیرگذاری به ازای هر کانتینر وجود ندارد، پس sidecar را نمی‌توان به یک فرایند محدود کرد.

این همان سازوکاری است که هنگام بازبینی باید در ذهن داشت: شعاع اثر همان Pod است، نه گره و نه خوشه.

sidecar به کجا نمی‌رسد

Podهای دیگر فضای نام و مسیرگذاری خودشان را نگه می‌دارند، بنابراین باری که به همان خروجی نیاز دارد به همان sidecar یا در عوض طرحی در سطح گره نیاز دارد. ترافیک گره هم بیرون از فضای نام Pod است و Podهای با شبکهٔ میزبان آگاهانه کاملاً از این جداسازی کنار می‌کشند. اگر sidecar را با شبکهٔ میزبان اجرا کنید تا به چیزی راحت برسید، دامنه را از یک Pod به کل گره گسترده‌اید و باید این را بلند بگویید.

ترافیک سرویس‌های خوشه غافلگیری رایج دیگر است. یک مسیر پیش‌فرض عریض درون Pod می‌تواند درخواست‌هایی را که برای سرور API یا سرویس ClusterIP در نظر گرفته شده‌اند بگیرد و بعد آن‌ها طوری شکست بخورند که به نظر برسد تونل خراب است.

طرح مسیر: بازه‌های Pod، سرویس، گره و VPN

چهار بازه را بنویسید و پیش از استقرار هر چیزی همپوشانی آن‌ها را بررسی کنید: CIDR پاد، CIDR سرویس، آدرس‌های گره و مقصدهای پشت VPN. همپوشانی میان بازه‌های خصوصی VPN و فضای خود خوشه نادر نیست و مسیر پیش‌فرض راه‌حل اشتباهی برای آن است. طرح مسیر باید در همان مخزن مانیفست باشد، چون خوشهٔ بعدی ممکن است بازه‌های Pod و سرویس کاملاً متفاوتی بدهد.

DNS بخشی از طرح است نه دغدغه‌ای جدا. sidecar‌ای که پیکربندی resolver را بازنویسی می‌کند می‌تواند کشف سرویس درون خوشه را بشکند، در حالی که جست‌وجوهای بیرونی بی‌نقص کار می‌کنند.

راه‌اندازی و شکست حالت‌های صریح‌اند

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

این شکاف در خوشهٔ سالم کوتاه و در خوشهٔ خراب دائمی است، و دقیقاً همان ویژگی‌ای است که مهاجم یا نشت تصادفی داده ترجیح می‌دهد.

ترتیب را با یک آزمون شکست جفت کنید. sidecar را بکشید و تأیید کنید که برنامه خروجی مورد نظرش را از دست می‌دهد نه اینکه بی‌صدا به عقب برگردد.

توانایی‌ها، سیاست‌ها و آزمایش از کانتینر برنامه

دادن توانایی‌های لازم برای ساخت رابط‌ها و تغییر مسیرها یک تصمیم امتیازی است و امتیازی که برای یک Pod جداافتاده مناسب است به‌طور خودکار روی پشتهٔ گره مناسب نیست. از سازوکارهای سیاست شبکه و امنیتی پشتیبانی‌شدهٔ خوشه استفاده کنید و فرض نکنید هر پیاده‌سازی CNI یا سیاست با یک رابط VPN یکسان رفتار می‌کند؛ تفاوت‌ها دقیقاً در همان موارد شکستی ظاهر می‌شوند که برایتان مهم‌اند.

از کانتینر واقعی برنامه آزمایش کنید، با درخواست‌های تازه به یک مقصد خصوصی، یک سرویس خوشه و اینترنت عمومی. آزمایش از sidecar ثابت می‌کند تونل کار می‌کند، نه اینکه برنامه به آنچه لازم دارد می‌رسد.

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

مقالات مرتبط