یک سایدکار VPN به قاعده شروع و قاعده خرابی نیاز دارد
شروع تونل پیش از برنامه یک رقابت را حل می‌کند. جداگانه تصمیم بگیرید که برنامه پیش از آمادگی، در هنگام خرابی تونل و پس از راه‌اندازی دوباره چه چیزی می‌تواند بفرستد.
یک pod کانتینر تونل را پیش از برنامه شروع می‌کند و درخواست‌های نخست موفق می‌شوند، و این دقیقاً همان حالتی است که مشکل را پنهان می‌کند. ترتیب یک رقابت را درست می‌کند و هیچ چیزی درباره ترافیکی نمی‌گوید که برنامه چهار ساعت بعد، پس از خرابی تونل، آغاز می‌کند. این‌ها دو تصمیم جداگانه‌اند. معمولاً فقط یکی از آن‌ها طراحی می‌شود.
ترتیب فقط درخواست نخست را مهار می‌کند
Kubernetes چرخه عمر سایدکار را که از کانتینرهای init قابل راه‌اندازی دوباره ساخته شده پشتیبانی می‌کند. در آن مدل، یک probe شروع می‌تواند گام مقداردهی بعدی را نگه دارد تا تونل آمادگی را گزارش کند. این بهبودی واقعی است و ارزش دارد که آگاهانه از آن استفاده شود، نه با افزودن sleep به اسکریپت نقطه ورود. دروازه فقط به اندازه شرطی که می‌آزماید خوب است.
بیرون از آن مدل، معناشناسی ترتیب به همان runtime یا سامانه وابستگی که استفاده می‌کنید تعلق دارد و لازم نیست مطابقت داشته باشند. یک استقرار کپی‌شده از پلتفرم دیگر ممکن است چنین به نظر برسد که منتظر تونل است، زیرا برنامه به‌طور تصادفی کند شروع می‌شود. این همان تضمین نیست و زیر بار شکست می‌خورد.
بگویید دروازه چه چیزی را مشاهده می‌کند: فرآیندی وجود دارد، رابطی وجود دارد، دست‌دهی کامل شده است. هر یک از این‌ها ادعایی ضعیف‌تر از «مسیر داده به مقصدهایی که این pod نیاز دارد کار می‌کند» است.
مسیر داده را اعمال کنید، نه اینکه آن را فرض بگیرید
probe یک بررسی در یک لحظه است و فایروال ویژگی‌ای است که میان لحظه‌ها برقرار می‌ماند. اگر الزام این است که ترافیک برنامه هرگز بیرون تونل نرود، باید در فضای نام شبکه مشترک به‌صورت قاعده پذیرش یا حذف بیان شود. ترتیب شروع کانتینرها نمی‌تواند این الزام را حمل کند. فقط یک قاعده می‌تواند.
کانتینرها در یک pod آن فضای نام را شریک‌اند، پس نقطه اعمال خود فضای نام است. هر چه بنویسید باید اتصال بیرونی خود تونل را در دسترس بگذارد، زیرا مسدود کردن آن برای محافظت از برنامه مسیری را که برنامه نیاز دارد قطع می‌کند.
سیاست خرابی را صریحاً تعیین کنید: آیا ترافیک برنامه باید وقتی تونل ناسالم است کاملاً متوقف شود، یا ادامه یابد و به‌عنوان محافظت‌نشده علامت بخورد؟ هر دو قابل دفاع است و هیچ‌کدام آن چیزی نیست که با شروع کانتینرها در ترتیبی خاص به دست می‌آید.
ترافیکی را که ذکر نکردید بیازمایید
در هنگام یک خرابی کنترل‌شده تونل درخواست تازه‌ای بگیرید و ببینید آیا بیرون می‌رود. سپس بررسی را برای مسیرهایی تکرار کنید که آزمون نشانی خروج هرگز به آن‌ها نمی‌رسد: تحلیل DNS درون خوشه، مقصدهای IPv6، و سرویس‌هایی که از طریق نشانی‌های داخلی خوشه و نه اینترنت عمومی در دسترس‌اند. این‌ها همان مسیرهایی هستند که پس از مرگ تونل بی‌صدا ادامه می‌یابند.
صفحه نشانی خروج اثبات می‌کند که یک درخواست در آن لحظه به جایی که انتظار داشتید رفته است. نمی‌تواند سایر مسیرها را فهرست کند، و شکاف میان آنچه آزمودید و آنچه pod می‌تواند به آن برسد همان جایی است که خرابی‌های جالب زندگی می‌کنند.
آزمون را پس از راه‌اندازی دوباره سایدکار تکرار کنید، نه فقط پس از یک شروع پاک. کانتینر تونلی که دوباره راه‌اندازی شده می‌تواند فضای نام را با مسیرها و سیاست در حالتی میانی رها کند.
سابقه استقرار را بنویسید
سه واقعیت به یادداشت‌های استقرار تعلق دارند: آزمون آمادگی و آنچه مشاهده می‌کند، اقدام بازیابی وقتی آن آزمون شکست می‌خورد، و قاعده اعمالی که خروج را اداره می‌کند. مستندات کانتینرهای سایدکار مکانیک چرخه عمر را پوشش می‌دهد و آن تصمیم سیاستی را به شما واگذار می‌کند. این تقسیم درست است، و همین دلیل است که سیاست معمولاً غایب است.
بررسی سلامت که با محافظت اشتباه گرفته شود، گران‌ترین نوع نشانگر سبز است، زیرا مردم را از پرسیدن باز می‌دارد. نامگذاری دقیق آن در مستندات یک جمله هزینه دارد و از آن جلوگیری می‌کند.
در پایان، مسیر بازیابی را یک بار با برنامه در حال اجرا بیازمایید. طراحی‌ای که برای بازگرداندن خروج نیاز به بازسازی pod دارد یک تصمیم است، و باید تصمیمی باشد که شما گرفتید، نه یکی که کشف کردید.