Apigee hybrid-এ MCP—agent request cluster ছাড়বে না

Google ১৪ অক্টোবর ২০২৬-এ Apigee hybrid 1.17.0-এ MCP সমর্থনের ঘোষণা দেয়। সংস্করণটি ১৪ সেপ্টেম্বর প্রকাশিত হয়েছিল। এতে MCP ডেটা প্লেন গ্রাহকের Kubernetes ক্লাস্টারে চলে; টুল কলের অনুরোধ ও উত্তর পরিচালনার সময় Google Cloud-এ যায় না। বিদ্যমান OpenAPI-ভিত্তিক এপিআইকে এজেন্টের ব্যবহারযোগ্য টুল হিসেবে প্রকাশ করার পথও এতে যুক্ত হয়েছে।

সুবিধাটি ডিফল্টভাবে চালু থাকে না। Google Cloud-এর MCP চালুর নির্দেশিকা অনুযায়ী, সমর্থিত সংস্করণের প্রতিটি সংশ্লিষ্ট ক্লাস্টারে সেটি সক্রিয় করতে হয়। একই এনভায়রনমেন্ট গ্রুপের কোনো ক্লাস্টারে MCP চালু এবং অন্যটিতে বন্ধ থাকলে, বন্ধ ক্লাস্টারে যাওয়া অনুরোধ সাধারণত 503 Service Unavailable ত্রুটিতে ব্যর্থ হয়। স্থানীয় অনুরোধপথের পাশাপাশি Google Cloud থেকে কনফিগারেশন আনার সংযোগ এবং ক্লাস্টারের ভেতরে নতুন পরিষেবাটির প্রবেশাধিকারও রোলআউটের অংশ।

টুল কল ক্লাস্টারের ভেতর কোন পথে যায়

প্রথমে OpenAPI 3.0.x বিবরণ থেকে MCP Discovery Proxy তৈরি করা হয়। বিবরণে থাকা অপারেশনগুলো MCP টুল হিসেবে প্রকাশিত হয়; এজেন্ট JSON-RPC-এর tools/list দিয়ে উপলব্ধ টুল জানতে এবং tools/call দিয়ে অনুমোদিত অপারেশন চালাতে পারে। Apigee প্রোটোকল ও এপিআই কলের রূপান্তর সামলায়, ফলে প্রতিটি টুলের জন্য আলাদা MCP সার্ভারের সফটওয়্যার পরিচালনা করতে হয় না।

অনুরোধটি প্রতিষ্ঠানের Apigee প্রবেশপথ দিয়ে Message Processor-এ আসে। সেখানে প্রক্সির নীতি প্রয়োগের পর Message Processor একই Kubernetes ক্লাস্টারের MCP পরিষেবায় টুল কল পাঠায়; পরিষেবাটি সংশ্লিষ্ট এপিআই অপারেশনের সঙ্গে কাজ করে। অনুরোধ চলাকালে এই MCP অনুরোধ ও তার উত্তর Google Cloud-এর কন্ট্রোল প্লেন ঘুরে আসে না। এজেন্টের প্রতিষ্ঠানের প্রবেশপথ পর্যন্ত পৌঁছানোর নেটওয়ার্ক এবং লক্ষ্য এপিআইয়ের অবস্থান নির্ভর করে প্রতিষ্ঠানের নিজস্ব স্থাপনার ওপর।

প্রক্সিতে পরিচয় যাচাইয়ের জন্য OAuth, OpenID Connect বা এপিআই কী যাচাইয়ের মতো Apigee নীতি ব্যবহার করা যায়। API product দিয়ে কোন ক্লায়েন্ট কোন টুল দেখতে ও ডাকতে পারবে, সেটিও নির্ধারণ করা যায়; tools/list-এর ফল সেই অনুমতি অনুযায়ী সীমিত হয়। এই নিয়ন্ত্রণ Message Processor-এর মধ্য দিয়ে আসা অনুরোধের ক্ষেত্রে কাজ করে। ক্লাস্টারের ভেতর থেকে কেউ সরাসরি MCP পরিষেবায় পৌঁছালে সেই পথের নিরাপত্তা আলাদাভাবে নিশ্চিত করতে হয়।

Google Cloud থেকে কী আসে, আর পুরোনো কনফিগারেশন কতক্ষণ থাকে

টুলের কনফিগারেশন তৈরি হয় Google Cloud-এ থাকা Apigee কন্ট্রোল প্লেনে। MCP পডের সাইডকার নিজে বাইরে সংযোগ করে নির্দিষ্ট বিরতিতে কনফিগারেশনের উল্লেখ ও বান্ডেল নিয়ে আসে; কন্ট্রোল প্লেন ক্লাস্টারের ভেতরে সংযোগ শুরু করে না। সাইডকার বিদ্যমান apigee-watcher পরিচয় ব্যবহার করে, তবে প্রতিষ্ঠানের controlPlaneAccess-এ সেই পরিচয়ের অনুমতি একবার যোগ করতে হয়। একাধিক ক্লাস্টার একই প্রতিষ্ঠান পরিবেশন করলেও এই অনুমতি প্রতিটি ক্লাস্টারের জন্য নতুন করে দেওয়ার প্রয়োজন নেই।

কনফিগারেশনের বান্ডেল Apigee-পরিচালিত Cloud Storage-এ থাকে। তাই সাইডকারের বহির্গামী সংযোগে কন্ট্রোল প্লেনের ঠিকানার পাশাপাশি storage.googleapis.com-এ পৌঁছানোর ব্যবস্থাও দরকার। ডেটা রেসিডেন্সি সক্রিয় থাকলে কন্ট্রোল প্লেনের আঞ্চলিক ঠিকানা ব্যবহৃত হয় এবং বান্ডেল প্রতিষ্ঠানের নির্ধারিত অঞ্চলের বাকেটে থাকে। শুধু কন্ট্রোল প্লেনের সংযোগ খোলা থাকলে সাইডকার নতুন কনফিগারেশনের উল্লেখ পেলেও বান্ডেল নামাতে ব্যর্থ হতে পারে।

কনফিগারেশন আনা বন্ধ হলে MCP ডেটা প্লেন শেষ সফল বান্ডেলটি দিয়েই কাজ চালিয়ে যায়। 1.17.0 সংস্করণে সেই পুরোনো বান্ডেল ব্যবহারের স্বয়ংক্রিয় সময়সীমা নেই: পড প্রস্তুত দেখাতে পারে, অথচ সদ্য প্রকাশিত টুল বা বদলানো অনুমতি সেখানে পৌঁছায়নি। সাইডকারের ত্রুটি লগে consecutive_failures বাড়তে থাকা তাই পডের প্রস্তুত অবস্থার চেয়ে আলাদা সংকেত। সংযোগ ফিরে না এলে শুধু পড পুনরায় চালু করেও বান্ডেল আনার সমস্যাটি মেটে না।

ক্যানারি রোলআউটে সব ক্লাস্টারের অবস্থা কেন জরুরি

চালুর ন্যূনতম সুইচ overrides.yaml ফাইলে enableMcpServer: true। স্থানীয় Helm চার্টও সমর্থিত সংস্করণের হতে হবে; পুরোনো চার্ট দিয়ে আপগ্রেড সফল দেখালেও MCP রিসোর্স তৈরি নাও হতে পারে। ক্রমটি হলো আগে apigee-operator, পরে apigee-org চার্ট আপগ্রেড করা। প্রথম চার্ট নতুন রিসোর্সের কাঠামো বসায়, দ্বিতীয়টি তা ব্যবহার করে; উল্টো ক্রমে কমান্ড সফল হলেও MCP পড তৈরি না হওয়ার ঝুঁকি আছে।

সুইচ চালু বা বন্ধ করলে Message Processor-এর পড বিন্যাস বদলায় এবং পর্যায়ক্রমিক ক্যানারি রিলিজ শুরু হয়। নতুন পড প্রস্তুত হওয়া পর্যন্ত পুরোনো পড ট্রাফিক পরিবেশন করে। এই পরিবর্তন নির্ধারিত রক্ষণাবেক্ষণের সময়ে করা এবং রিলিজ শেষ হওয়া পর্যন্ত অপেক্ষা করা দরকার; স্বাভাবিক টুল কলের প্রতিবার এমন রিলিজ হয় না। MCP পড, পরিষেবা ও Message Processor-এর অভ্যন্তরীণ রুট প্রস্তুত হলেও Discovery Proxy প্রকাশের আগে পূর্ণ টুল কল সফল হওয়ার কথা নয়।

একই এনভায়রনমেন্ট গ্রুপের ঠিকানায় আসা অনুরোধ সেই গ্রুপ পরিবেশনকারী যেকোনো ক্লাস্টারে যেতে পারে। তাই একটি ক্লাস্টারে MCP চালু করে অন্যটি আগের অবস্থায় রাখলে এজেন্টের কাছে ব্যর্থতা অনিয়মিত মনে হতে পারে: কোন ক্লাস্টারে অনুরোধ পৌঁছাল, তার ওপর ফল নির্ভর করবে। রোলআউটের তালিকায় সংস্করণ ও চার্টের ক্রম, watcher-এর অনুমতি, কনফিগারেশন আনার বহির্গামী পথ, ক্যানারি রিলিজের সমাপ্তি এবং গ্রুপের সব ক্লাস্টারে একই সক্রিয় অবস্থা—প্রতিটি শর্তের নিজস্ব স্থান আছে।

ফিরিয়ে নেওয়ার সময় enableMcpServer: false করে apigee-org চার্ট আপগ্রেড করতে হয়; তখনও Message Processor-এর আরেকটি রিলিজ হয়। ক্লাস্টারে MCP বন্ধ হলেও আগে প্রকাশিত Discovery Proxy কন্ট্রোল প্লেনে থেকে যায়। ফলে রোলব্যাকের পর সেই প্রক্সিগুলো সরানো হবে, নাকি পরবর্তী সক্রিয়করণের জন্য রাখা হবে, সেটিও রোলআউটের সিদ্ধান্তের অংশ।

ভেতরের MCP পরিষেবায় নতুন আক্রমণপৃষ্ঠ

MCP ডেটা প্লেন নিজে কলকারীর পরিচয় যাচাই করে না; সে ধরে নেয় Message Processor-এর Apigee প্রক্সি আগেই যাচাই করেছে। ফলে ক্লাস্টারের অন্য কোনো কাজের চাপ সরাসরি MCP Service-এ পৌঁছাতে পারলে প্রক্সির পরিচয় যাচাই এড়িয়ে টুল ডাকতে পারে। Krypton Forge Labs-এর নিরাপত্তা বিশ্লেষণ এই অভ্যন্তরীণ আস্থার সীমাটি তুলে ধরেছে; লেখক নিজস্ব Apigee hybrid ক্লাস্টারে নিয়মটি পরীক্ষা করার দাবি করেননি।

এ কারণে এজেন্টের পরিচয় যাচাইয়ের নীতি Discovery Proxy-তে প্রয়োগের পাশাপাশি MCP পডে প্রবেশ সীমিত করতে হয়। Kubernetes NetworkPolicy বা সমতুল্য ক্লাস্টার নীতিতে কেবল Message Processor পডকে টুল কলের সংযোগ দেওয়া এবং অন্য কাজের চাপকে আটকানোই নির্ধারিত ব্যবস্থা। পরিষেবার TLS সংযোগ সার্ভারের পরিচয় যাচাই করলেও সেটি কলকারীর পরিচয় যাচাইয়ের বিকল্প নয়। প্রস্তুতি যাচাইয়ের অভ্যন্তরীণ পথও অন্য কাজের চাপের জন্য খোলা থাকার কথা নয়।

পোর্টের ক্ষেত্রে বাস্তব নেটওয়ার্ক নীতির আচরণ গুরুত্বপূর্ণ: MCP Service টুল কল গ্রহণ করে TCP 443-এ, যা পডের 8443 পোর্টে যায়। NetworkPolicy পডের ট্রাফিকে প্রয়োগ হয় বলে ব্যবহৃত নীতি ইঞ্জিনে কোন পোর্ট মিলবে, তা স্থাপনার বাস্তব নিয়মের সঙ্গে মিলিয়ে নিতে হবে। ক্লাস্টারের ভেতরে অননুমোদিত পড সরাসরি MCP পরিষেবায় পৌঁছাতে পারলে অনুরোধ Google Cloud-এ না গেলেও এজেন্ট টুলের ওপর প্রক্সিতে নির্ধারিত নিয়ন্ত্রণ কার্যকর থাকবে না।

আরও পড়ুন:

• Pull request-এ secret থাকলে merge বন্ধ—push protection-এর পরেও নতুন জাল
• AI agent registry বানালেই শাসন হয় না—owner ও expiry না দিলে catalog-ও ঝুঁকি
• OpenSearch MCP Apps-এ agent-এর দাবির পাশে দেখা যাবে আসল trace