حذف محدودیت‌های نشست در Kubernetes با پیاده‌سازی Stateless MCP

اگر امروز سرورهای ابزارهای هوش مصنوعی خود را روی کوبرنتیز (Kubernetes) مستقر کرده‌اید، احتمالاً با ریسک‌های پایداری در نشست‌های کاربر (Sticky Sessions) دست‌وپنجه نرم می‌کنید. بازبینی مشخصات پروتکل زمینه مدل (Model Context Protocol یا MCP) در ۲۸ ژوئیه ۲۰۲۶، نیاز به اتصال اجباری کاربر به یک پاد (Pod) خاص را از بین برد تا هر نمونه از سرور بتواند هر درخواستی را در یک توالی پردازش کند.

همان‌طور که در پوشش پیشین ما درباره پشتیبانی SDK زبان PHP از این استاندارد بدون وضعیت (Stateless) اشاره کردیم، اکنون دستاوردهای عملی این تغییر برای مهندسان DevOps کاملاً روشن شده است. در ساختارهای قدیمی و حالت‌دار (Stateful)، کلاینت باید در طول یک جلسه به یک پاد خاص متصل می‌ماند. اگر آن پاد کرش می‌کرد یا بازراه‌اندازی می‌شد، کل جلسه کاربر همزمان با آن از بین می‌رفت.

تصور کنید یک عامل خرید آنلاین دارید — شبیه دستیاری که لیست خرید شما را در ذهن دارد و اگر ناگهان حافظه‌اش پاک شود، باید همه چیز را از اول بگویید. در مدل قدیمی، اگر پادی که درخواست «افزودن به سبد» را پردازش می‌کرد حین یک به‌روزرسانی غلتان (Rolling Update) خاموش می‌شد، درخواست «پرداخت» شما شکست می‌خورد چون پاد جدید هیچ خاطره‌ای از سبد خرید شما نداشت. این موضوع باعث تضاد دائمی بین نیاز به مقیاس‌پذیری افقی و الزام پایداری نشست‌ها شده بود. این رویکرد جدید در مدیریت وضعیت، پیش‌نیاز توسعه قابلیت‌های پیشرفته‌تری است که به کمک سرورهای MCP بدون نیاز به حساب کاربری، امکان پرداخت‌های مستقیم توسط عامل‌های هوش مصنوعی را فراهم می‌کند.

سازوکار حذف وضعیت (Statelessness)

به نقل از تحلیل فنی وب‌سایت webofmike.com که در ۳ اکتبر ۲۰۲۶ منتشر شد، مشخصات جدید، دست‌دادن (Handshake) دو مرحله‌ای قبلی را به یک فراخوانی واحد و مستقل تبدیل کرده است. پیش از این، کلاینت‌ها برای دریافت یک Mcp-Session-Id که در حافظه سرور ذخیره می‌شد، یک رقص پیچیده به نام initialize را اجرا می‌کردند. این فرآیند مستلزم تنظیم sessionAffinity: ClientIP در سرویس‌های کوبرنتیز یا استفاده از اتصال مبتنی بر کوکی در لایه‌های جلویی بود.

اتصال اجباری (Session Affinity) اگرچه تکنیک عجیبی نیست، اما هزینه عملیاتی سنگینی دارد. این سازوکار مستقیماً با مقیاس‌دهی خودکار پادها (HPA) تضاد دارد؛ زیرا رپلیکاهای جدید فقط نشست‌های جدید را می‌پذیرند و هرگز سهمی از نشست‌های موجود نمی‌گیرند. همچنین، هر بار بازراه‌اندازی غلتان یا کاهش مقیاس (Scale-down)، برای هر نشست کاربر که به پاد حذف‌شده متصل بود، به یک اتفاق ناگوار و قطع سرویس تبدیل می‌شد.

اکنون هر درخواست، نسخه پروتکل، هویت کلاینت و قابلیت‌هایش را در یک فیلد _meta حمل می‌کند. بر اساس مستندات رسمی این پروتکل: «هر درخواست اکنون به‌تنهایی سفر می‌کند و نسخه پروتکل، هویت کلاینت و قابلیت‌های آن را در _meta حمل می‌کند». این یعنی هر درخواست می‌تواند بدون نیاز به حافظه مشترک، روی هر نمونه سرور پشت یک Load Balancer ساده با روش Round-robin قرار بگیرد. این انعطاف‌پذیری در اتصال، دسترسی به مجموعه‌های گسترده‌تری از ابزارها را تسهیل می‌کند، مشابه آنچه در سرور رسمی MCP گیت‌هاب برای فراهم کردن دسترسی به ۸۰ ابزار مختلف مشاهده شد.

این چرخش، وضعیت را از رم (RAM) سرور به خودِ درخواست منتقل می‌کند. در این حالت، دست‌دادن initialize/initialized و هدر Mcp-Session-Id به‌طور کامل بازنشسته شده‌اند و دیگر اختیاری نیستند، بلکه حذف شده‌اند. اگر سروری نیاز دارد وضعیتی را بین فراخوانی‌ها حفظ کند، راهنمای پروتکل صریح است: «یک دستگیره (Handle) صریح از ابزار بسازید و از مدل بخواهید آن را به‌عنوان یک آرگومان بازگرداند».

اثبات مقیاس‌پذیری در کوبرنتیز

برای اثبات این ادعا، یک محیط آزمایشی با استفاده از agentgateway نسخه ۱.۵.۰ و یک استقرار کوبرنتیز با ۳ رپلیکا ساخته شد. در این تنظیمات، از یک سرویس ClusterIP ساده استفاده شد و sessionAffinity روی None (پیش‌فرض کوبرنتیز) قرار گرفت. مخزن دمو با نام stateless-mcp-scale این قابلیت را از طریق یک سرور MCP مینیمال به زبان پایتون (که فقط از کتابخانه‌های استاندارد یا stdlib استفاده می‌کند) ثابت می‌کند. این سرور متدهای initialize ،tools/list و tools/call را روی Streamable HTTP پیاده‌سازی می‌کند.

این سرور سه ابزار خاص را ارائه می‌دهد: cart_create ،cart_add_item و cart_checkout. وضعیت کاملاً در یک cartToken مبهم قرار دارد که توسط فراخواننده نگهداری می‌شود. برای ردیابی مسیر، هر پاسخ گزارش می‌دهد که توسط کدام پاد (servedBy.pod) و کدام IP (servedBy.podIP) پردازش شده است تا بتوان به‌وضوح دید که کدام رپلیکا پاسخ داده است.

نتایج دقیق آزمایش‌ها

• تأیید توزیع درخواست‌ها (Fan-out): در آزمونی با ۹ فراخوانی مستقل ابزار، درخواست‌ها بین رپلیکاهای مختلف توزیع شدند. در یک اجرا، دو رپلیکای مجزا (مانند stateless-mcp-demo-757875b499-z2zsg و stateless-mcp-demo-757875b499-w6mpr) به ۹ درخواست پاسخ دادند که ثابت می‌کند هیچ اتصال اجباری فعال نبوده است. در اجرای دیگری حین توسعه، در ۶ درخواست اول، هر ۳ رپلیکا مورد استفاده قرار گرفتند.
• تداوم نشست: یک جلسه خرید چهار مرحله‌ای با موفقیت و بدون هیچ حافظه مشترکی بین پادها تکمیل شد:
  • cart_create $
    ightarrow$ پاد ...-z2zsg (یک توکن ۱۰۸ کاراکتری بازگرداند)
  • cart_add_item $
    ightarrow$ پاد ...-w6mpr (افزودن کیبورد)
  • cart_add_item $
    ightarrow$ پاد ...-w6mpr (افزودن ماوس)
  • cart_checkout $
    ightarrow$ پاد ...-w6mpr (مبلغ ۶۵ دلار، تأیید شد)
• تاب‌آوری در برابر بازراه‌اندازی: بحرانی‌ترین تست، اجرای kubectl rollout restart deployment/stateless-mcp-demo در میانه جلسه بود. سبد خریدی که روی پاد ...-z2zsg (قبل از ری‌استارت) ایجاد شده بود، با موفقیت روی پاد ...-9vvrw (بعد از ری‌استارت) پرداخت شد؛ در حالی که پاد پرداخت در لحظه ایجاد سبد، اصلاً وجود نداشت. توالی به این شکل بود:
  • cart_create (قبل از ری‌استارت) $
    ightarrow$ پاد ...-z2zsg
  • cart_add_item حین رول‌اوت (۱ از ۵) $
    ightarrow$ پاد ...-n9s5r
  • cart_add_item حین رول‌اوت (۲ از ۵) $
    ightarrow$ پاد ...-z2zsg
  • cart_add_item حین رول‌اوت (۳ از ۵) $
    ightarrow$ پاد ...-9vvrw
  • cart_add_item حین رول‌اوت (۴ از ۵) $
    ightarrow$ پاد ...-9vvrw
  • cart_add_item حین رول‌اوت (۵ از ۵) $
    ightarrow$ پاد ...-rp9fm
  • cart_checkout (بعد از ری‌استارت) $
    ightarrow$ پاد ...-9vvrw (مبلغ ۵ دلار، تأیید شد)

الزامات فرمت انتقال داده

پیاده‌سازی این حالت بدون وضعیت، نیازمند هدرهای HTTP خاصی برای سازگاری با منطق مسیریابی agentgateway است. دمو نشان داد که بدنه استاندارد JSON-RPC کافی نیست؛ حتی در یادداشت‌های انتشار agentgateway پذیرفته شده که بیشتر این موارد هنوز در یک راهنمای اختصاصی پوشش داده نشده‌اند. با بررسی پیام‌های خطای سطح ۴۰۰، الزامات زیر شناسایی شدند:

• هدر پروتکل: MCP-Protocol-Version: 2026-07-28 باید یک هدر سطح بالای HTTP باشد. بدون آن، گیت‌وی خطای 400 mcp: invalid MCP protocol version header را برمی‌گرداند.
• هدرهای مسیریابی: Mcp-Method (مانند tools/call یا tools/list) و Mcp-Name (مانند cart_create) باید به‌عنوان هدرهای مجزای HTTP ارسال شوند. این‌ها هدرهای مسیریابی اختصاصی agentgateway هستند و از پاکت JSON-RPC جدا می‌باشند. عدم ارسال منجر به خطای 400 invalid MCP routing header: Mcp-Method می‌شود.
• پارامترهای Meta: پارامترهای JSON-RPC باید شامل یک کلید _meta باشند. این کلید باید دقیقاً به صورت reverse-DNS-qualified یعنی io.modelcontextprotocol/protocolVersion نوشته شود. استفاده از کلید ساده protocolVersion باعث خطای 400 invalid request parameters: _meta.protocolVersion is required می‌شود.

وقتی statefulMode: stateless در agentgateway فعال باشد، گیت‌وی هرگونه تلاش برای استفاده از دست‌دادن قدیمی initialize را با خطای {"jsonrpc":"2.0","id":1,"error":{"code":-32601,"message":"method not found: initialize"}} رد می‌کند تا استاندارد مدرن اجباری شود. در هیچ مرحله‌ای agentgateway مقدار Mcp-Session-Id را به کلاینت یا بک‌اند ارسال یا انتظار نمی‌کند.

پیکربندی و اعتبارسنجی

در نسخه ۱.۵.۰ ابزار agentgateway، تنظیم statefulMode: stateless کلید تغییر بین حالت نشست‌های پایدار (Stateful) و حالت «یک نشست برای هر درخواست» (Stateless) است. ساختار پیکربندی در دمو به این شکل است:

gateways:
  default:
    port: 3000
    mcp:
      gateways:
        - default
          statefulMode: stateless
          targets:
            - name: stateless-mcp-demo
              mcp:
                host: stateless-mcp-demo.stateless-mcp-scale.svc.cluster.local
                port: 8080
                path: /

این تنظیمات را می‌توان پیش از استقرار با استفاده از ایمیج agentgateway و دستور docker run --rm -v "$PWD/agentgateway:/config" cr.agentgateway.dev/agentgateway:v1.5.0 --validate-only -f /config/agentgateway.yaml اعتبارسنجی کرد. خروجی Configuration is valid! صحت تنظیمات را پیش از ورود به خوشه تأیید می‌کند.

خط زمانی پیاده‌سازی

برخلاف تصور برخی، پشتیبانی از این قابلیت بلافاصله پس از انتشار مشخصات رخ نداد. سایمون ویلیسون در هفته انتشار مشخصات، در یادداشتی با عنوان «Stateless MCP علاقه مرا دوباره جلب کرد» به تغییر فرمت انتقال داده اشاره کرد که در Hacker News مورد توجه قرار گرفت و ۳۸۶ امتیاز کسب کرد. پست او به‌وضوح توضیح داد که چگونه رقص دو مرحله‌ای قدیمی به یک درخواست واحد و مستقل تبدیل شده است.

نسخه ۱.۴.۰ ابزار agentgateway که پشتیبانی کامل از نسخه ۲۰۲۶-۰۷-۲۸ را اضافه کرد، در ۲۷ ژوئیه ۲۰۲۶ منتشر شد — یعنی یک روز پیش از نهایی شدن مشخصات. این نسخه بر اساس یک Release Candidate که از ۲۱ مه ۲۰۲۶ در دسترس بود ساخته شده بود و به توسعه‌دهندگان بیش از دو ماه فرصت داد تا خود را آماده کنند. یادداشت‌های انتشار نسخه ۱.۴.۰ به‌طور خاص به پشتیبانی از «سرورهای حالت‌دار و بدون وضعیت، از جمله بستن شکاف انطباق سرور-بدون وضعیت SEP-2575 و حذف دست‌دادن مصنوعی initialize برای درخواست‌های مدرن» اشاره می‌کند.

سپس در ۲۹ ژوئیه ۲۰۲۶، نسخه ۱.۴.۱ برای رفع باگ‌های سازگاری منتشر شد. این نسخه شامل اعتبارسنجی پاسخ‌های MCP بالادستی در برابر انواع مورد انتظار و متوقف کردن ثبت شناسه‌های نشست مصنوعی به‌عنوان مقادیر واقعی Mcp-Session-Id در لاگ‌ها بود.

تحلیل مهندسی

برای زیرساخت‌های هوش مصنوعی، این تغییر فرض بنیادی درباره مقیاس‌دهی سرورهای استفاده از ابزار را عوض می‌کند. ما از معماری‌های «چسبنده» (Sticky) که با مقیاس‌دهی خودکار پادها (HPA) در تضاد بودند، فاصله می‌گیریم. در دنیای حالت‌دار، رپلیکاهای جدید فقط نشست‌های جدید را می‌گرفتند و رپلیکاهای قدیمی تا زمان انقضای نشست‌ها، بیش از حد تحت فشار می‌ماندند.

با پذیرش فرمت بدون وضعیت، سرورهای MCP واقعاً جایگزین‌پذیر می‌شوند. این امر «اتفاقات ناگوار پایداری» را که معمولاً با کاهش مقیاس یا به‌روزرسانی خوشه همراه بود، حذف می‌کند. بار مدیریت وضعیت از لایه زیرساخت (کوبرنتیز) به لایه اپلیکیشن (منطق انتقال توکن) منتقل شده که مدیریت آن در مقیاس بالا بسیار ساده‌تر است.

این تغییر عملاً سرورهای ابزار هوش مصنوعی را مانند توابع بدون سرور (Serverless Functions) می‌کند و اجازه می‌دهد استقرارها بدون ریسک شکست در میانه جلسات پیچیده عامل‌محور، با زمان توقف صفر (Zero-downtime) انجام شوند. تمام کدها، مانیفست‌های کوبرنتیز، پیکربندی agentgateway و اسکریپت‌های تولید خروجی در github.com/themsquared/stateless-mcp-scale در دسترس است. اجرای دستورات make up && make demo هر سه آزمایش را روی یک خوشه kind بازتولید می‌کند.

گام بعدی برای مهندسان، تست این معماری در خوشه‌های چند-گره‌ای (Multi-node) با HPA فعال است تا تأیید شود که ویژگی‌های عدم-اتصال (No-affinity) هنگام جابجایی پادها بین ماشین‌های فیزیکی تحت بار زیاد، و نه فقط بین ReplicaSetها در یک گره واحد، به درستی عمل می‌کنند.

گام بعدی شما

• اگر از agentgateway استفاده می‌کنید، تنظیم statefulMode را به stateless تغییر دهید و اثر آن را روی توزیع بار بررسی کنید.
• معماری انتقال توکن (Token-passing) را در ابزارهای خود جایگزین حافظه داخلی سرور کنید.
• این معماری را در خوشه‌های چند-گره‌ای (Multi-node) با HPA فعال تست کنید تا مطمئن شوید جابجایی پادها بین ماشین‌های فیزیکی تأثیری بر پایداری ندارد.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره تراشه‌های Blackwell مراجعه کنید.