در STCLab ما پلتفرمهای پرترافیک SaaS را مدیریت میکنیم که نیازمند کنترل ترافیک در زمان واقعی و کاهش رباتها هستند. مدیریت میلیونها اتصال همزمان و شناسایی رباتهای مخرب بدون زیرساختی پایدار ممکن نیست؛ برای رسیدن به این هدف روی Istio حساب باز کردهایم ⚙️. اینجا تنها به چند قابلیت کلیدی که در محیط تولید ما بیشترین تأثیر را داشتند میپردازیم؛ چه در حال ارزیابی Istio برای پذیرش باشید و چه دنبال نمونههای کاربردی باشید، این نکات امیدوارم راهنمایی مفید باشند.
چرا Istio؟ Istio نقش کنترلکنندهای را ایفا میکند که پراکسیهای Envoy مستقر به صورت sidecar کنار کانتینرها را مدیریت میکند. هر پیکربندی Istio مثل VirtualService، DestinationRule یا AuthorizationPolicy به پیکربندی بومی Envoy ترجمه میشود. این طراحی دو مزیت اصلی دارد: انتزاعات Istio بسیاری از موارد استفاده را ساده میکند و وقتی نیاز به تنظیمات دقیقتر احساس شود، EnvoyFilter دسترسی مستقیم به امکانات Envoy فراهم میآورد. ما از هر دو رویکرد در سراسر زیرساختمان بهره میبریم.
حفظ IP واقعی مشتری با Proxy Protocol: برای پلتفرم کاهش ربات ما، نگهداری دقیق IP مشتری حیاتی است؛ بدون آن دقت تشخیص ربات بهشدت افت میکند. چالش این است که وقتی ترافیک از AWS NLB عبور میکند، IP اصلی مشتری از دست میرود. ما این مسئله را با استفاده از Proxy Protocol و اعمال آن از طریق EnvoyFilter حل کردهایم. برای بررسی فنی عمیقتر درباره حفظ IP منبع و پیکربندی توپولوژی شبکه، به پست وبلاگ رسمی Istio درباره پیکربندی توپولوژی شبکه دروازه مراجعه کنید. همچنین ما برای عملیاتهای امنیتی حساس، هدر X-Envoy-External-Address را به جای X-Forwarded-For اولویت میدهیم؛ بر خلاف XFF، این هدر توسط خود Envoy تنظیم میشود و توسط کلاینتهای خارجی قابل جعل نیست.
کنترل دسترسی مبتنی بر IP: APIهای داخلی مانند مستندات Swagger باید محافظت شوند. ما از AuthorizationPolicy برای محدود کردن دسترسی به IPهای اداری استفاده میکنیم. با استفاده از عمل DENY همراه با notRemoteIpBlocks میتوان یک لیست سفید ساده ساخت که تنها IPهای صراحتاً مجاز اجازه دسترسی دارند — راهحلی ساده و مؤثر.
مسیریابی مبتنی بر پارامتر پرسوجو: پلتفرم مدیریت ترافیک داخلی ما وضعیت صفها را در حافظه نگه میدارد، بنابراین درخواستهای هر مستاجر باید به همان نمونهی پشتیبان برسند تا ثبات حفظ شود. ما مسیریابی صریح را با استفاده از پارامترهای پرسوجو پیادهسازی کردهایم، زیرا با تیم برنامهنویسی ما هماهنگتر است: مشتریان میتوانند نمونه هدف خود را از طریق پارامتر چسبناک مشخص کنند. مزایا شامل مسیریابی قطعی (مشتریان دقیقاً میدانند کدام نمونه به درخواستها پاسخ میدهد)، جداسازی برای اشکالزدایی (مستاجران مشکلدار را به نمونههای مشخص هدایت کنید) و مهاجرت کنترلشده در طول تعمیر و نگهداری است. به عنوان جایگزین، برای سرویسهایی که نیاز به سازگاری سخت ندارند از consistent hashing استفاده میکنیم؛ در این حالت درخواستهایی با همان tenant_id به باطن یکسان هدایت میشوند. ما از مسیریابی صریح برای سرویس صف اصلی اتاق انتظار و از هش ثابت برای خدمات کمکی بهره میبریم.
جداسازی خودکار شکست با Outlier detection: یک پاد ناسالم میتواند کل خدمت را تحتالشعاع قرار دهد. ما از قابلیت Outlier detection استفاده میکنیم تا نمونههای ناموفق را بهصورت خودکار خارج کنیم. عملکرد مورد استفاده ما چنین است: پس از 5 پاسخ متوالی 5xx، نمونه را خارج کنید؛ نمونههای خارجشده حداقل 30 ثانیه بیرون میمانند و هرگز بیش از 50 درصد نمونهها را همزمان خارج نمیکنیم تا در دسترس بودن حفظ شود. در یک مشکل استقرار اخیر که یک پاد وارد حلقه خطا شده بود، تشخیص Outlier آن را ظرف 50 ثانیه از گردش خارج کرد و ترافیک بدون نیاز به دخالت دستی به پادهای سالم منتقل شد.
خاموششدن برازنده برای اتصالات طولانیمدت: دروازه ما اتصالاتی با بیش از 10 دقیقه دوام را مدیریت میکند و قطع ناگهانی آنها در هنگام استقرار باعث شکست تستها میشود. قاعده مهم این است که GracePeriodSeconds باید بیشتر از DrainDuration پایان باشد. دنباله خاموششدن ما به این شکل است: Pod سیگنال خاتمه را دریافت میکند، پذیرش اتصالات جدید متوقف میشود و در بررسیهای سلامت شکست میخورد، سپس اتصالات موجود تا پایان DrainDuration (مثلاً 600 ثانیه) ادامه مییابند. با فعالسازی EXIT_ON_ZERO_ACTIVE_CONNECTIONS، در صورتی که اتصالات سریع تخلیه شوند، پاد زودتر خارج میشود؛ در غیر این صورت Kubernetes پس از اتمام GracePeriodSeconds (مثلاً 660s) SIGKILL را ارسال میکند. نتایج عملی این پیکربندی: قطع اتصال صفر در حین استقرار و موفقیت در تستهای بار حین بهروزرسانیهای چرخشی.
نکات کلیدی عملیاتی در تولید: چند توصیه که هنگام مقیاسدهی با Istio بهخاطرتان باشد: با سادهترین تنظیمات شروع کنید — همه قابلیتها را از روز اول فعال نکنید و تنها وقتی مواردی مثل mTLS یا tracing را فعال کنید که توجیه تجاری هزینه فنی را داشته باشد. کاردینالیته متریکها را زیر نظر بگیرید: Envoy تلهمتری سنگینی تولید میکند که میتواند Prometheus را تحتفشار قرار دهد، بنابراین تنظیمات جمعآوری متریک را برای معیارهای ضروری محدود کنید. همچنین EnvoyFilter را با احتیاط مدیریت کنید؛ این ابزار قدرتمند است اما در زمان ارتقا میتواند شکننده باشد، پس مستندسازی دقیق و تست سازگاری ضروری است.
نتیجهگیری: Istio یک منحنی یادگیری دارد، اما برای پلتفرمهای پرترافیک ما کنترل و قابلیتهایی که فراهم میکند ارزش سرمایهگذاری دارد. امکاناتی مانند استفاده از Proxy Protocol برای حفظ IP مشتری، AuthorizationPolicy برای کنترل دسترسی، استراتژیهای مسیریابی انعطافپذیر، Outlier detection برای افزایش انعطافپذیری و هماهنگی خاموششدن برازنده به بخشهای حیاتی زیرساخت ما تبدیل شدهاند. اگر سرویسی را اجرا میکنید که مدیریت ترافیک، امنیت و قابلیت اطمینان برایش اهمیت دارد، Istio قطعاً ارزش بررسی دارد ✅.
