प्रॉम्प्ट और दायरा
एक प्लेटफॉर्म टीम एक शेयर्ड Kubernetes क्लस्टर चलाती है जबकि एप्लिकेशन टीमें gRPC सर्विसेज़ डिप्लॉय करती हैं। प्लेटफॉर्म को एक सिंगल एंट्री पॉइंट, TLS टर्मिनेशन, सर्विस/मेथड/हेडर द्वारा रूटिंग और कैनरी रिलीज़ की आवश्यकता होती है; प्रत्येक एप्लिकेशन टीम केवल अपने स्वयं के Route को एडिट कर सकती है और इन्फ्रास्ट्रक्चर या किसी अन्य namespace को नियंत्रित नहीं कर सकती है। रिसोर्सेज़, रिक्वेस्ट पाथ, ऑथराइजेशन बाउंड्री, ऑब्ज़र्वेबिलिटी और विफलता रोलबैक डिज़ाइन करें।
मान लें कि एक Gateway API कंट्रोलर इंस्टॉल है, बैकएंड्स HTTP/2 gRPC बोलते हैं, और क्लाइंट्स के पास स्पष्ट टाइमआउट और रीट्री नीतियां हैं। किसी एक वेंडर कार्यान्वयन के बजाय क्रॉस-टीम कंट्रोल-प्लेन सीमाओं पर ध्यान केंद्रित करें।
इंटरव्यूअर क्या मूल्यांकन करता है
- क्या आप GatewayClass, Gateway, GRPCRoute और Service की ज़िम्मेदारियों को अलग करते हैं।
- क्या आप जेनेरिक Ingress YAML प्रस्तुत करने के बजाय GRPCRoute मैचिंग ग्रैन्युलैरिटी को समझते हैं।
- क्या आप क्रॉस-namespace ReferenceGrant, RBAC, डिफ़ॉल्ट डिनाई और ऑडिट को संभालते हैं।
- क्या आप वेट्स, लंबे समय तक चलने वाले स्ट्रीम्स और रीट्री के खतरों की व्याख्या करते हैं।
- क्या आप स्टेटस सिग्नल्स, रोलबैक गेट्स और कंट्रोलर/डेटा-प्लेन विफलताओं को परिभाषित करते हैं।
उत्तर देने से पहले स्पष्ट करने वाले प्रश्न
- क्या Gateway केंद्रीय रूप से प्लेटफॉर्म के स्वामित्व में है या टीम के स्वामित्व में? यह Route अटैचमेंट और अप्रूवल को बदलता है।
- क्या रूटिंग सर्विस, मेथड, हेडर या होस्टनेम द्वारा है? मैचिंग प्राथमिकता विरोध प्रबंधन (conflict handling) को बदलती है।
- क्या कॉल्स यूनरी हैं या लंबे समय तक चलने वाली स्ट्रीमिंग? स्ट्रीमिंग को आमतौर पर प्रति-रिक्वेस्ट रीट्री या कट ओवर नहीं किया जाना चाहिए।
- क्या कैनरी चयन प्रतिशत, टेनेंट, हेडर या क्लाइंट वर्ज़न द्वारा है? वेट, स्टिकिनेस और रोलबैक सिग्नल्स को परिभाषित करें।
- क्या एक बैकएंड Service क्रॉस-namespace या क्रॉस-क्लस्टर हो सकती है? यह ReferenceGrant और हेल्थ-चेक संबंधी चिंताओं को जोड़ता है।
30-सेकंड उत्तर फ्रेमवर्क
मैं प्लेटफॉर्म-स्वामित्व वाले Gateway को एप्लिकेशन-स्वामित्व वाले GRPCRoutes से अलग करता हूँ, जिसमें बैकएंड-डिस्कवरी बाउंड्री के रूप में Services होती हैं। एक Route gRPC मेथड और मेटाडेटा मैचेस घोषित करता है; क्रॉस-namespace रेफरेंस के लिए स्पष्ट ऑथराइजेशन की आवश्यकता होती है। कंट्रोलर स्वीकृत (accepted) और रेफरेंस-रिज़ॉल्यूशन स्थिति को प्रदर्शित करता है, जबकि डेटा प्लेन वेट द्वारा रूट करता है और स्ट्रीम्स के लिए आंख मूंदकर रीट्री करने से बचता है। मैं एक टेनेंट या एक स्पष्ट हेडर के साथ कैनरी शुरू करता हूँ, रोलबैक गेट्स के रूप में मेथड एरर्स, टेल लेटेंसी और व्यावसायिक स्वास्थ्य का उपयोग करता हूँ, और जब कोई Route या बैकएंड अमान्य होता है तो स्थिर (stable) बैकएंड पर वापस लौट जाता हूँ।
चरण-दर-चरण गहन विश्लेषण
1. रिसोर्स जिम्मेदारियां और डेटा प्रवाह
प्लेटफॉर्म कंट्रोलर का चयन करते हुए एक GatewayClass बनाता है, फिर श्रोता (listeners), पते और TLS नीति निर्धारित करता है। एक एप्लिकेशन अपने namespace में एक GRPCRoute बनाता है, इसे parentRefs के साथ एक अनुमत Gateway से जोड़ता है, और अपनी Service को लक्षित करता है। कंट्रोलर स्वीकृत नियमों को डेटा-प्लेन कॉन्फ़िगरेशन में बदलता है, backendRefs का चयन करने से पहले होस्टनेम, gRPC सर्विस, मेथड और हेडर का मिलान करता है।
2. मैचिंग और विरोध प्रबंधन (Conflict Handling)
सटीक और फ़ॉलबैक मिलानों के बीच प्राथमिकता परिभाषित करें: एक पूर्ण सर्विस/मेथड मिलान केवल-सर्विस से बेहतर हो सकता है, जो हेडर फ़ॉलबैक से बेहतर हो सकता है। दो टीमों को एक ही पैरेंट और मिलान को अप्रत्यक्ष रूप से अधिलेखित (overwrite) करने की अनुमति न दें। Accepted और ResolvedRefs जैसी स्थितियों के माध्यम से विरोधों को सामने लाएं, और CI को उनकी जांच करने दें। अज्ञात मेथड के लिए, स्पष्ट UNIMPLEMENTED या एक स्थिर फ़ॉलबैक चुनें; कभी भी चुपचाप किसी भी मनमाने सर्विस पर रूट न करें।
3. मल्टी-टेनेंट ऑथराइजेशन
एक एप्लिकेशन केवल अपना Route और Service लिख सकता है। allowedRoutes उन namespaces को सीमित करता है जो Gateway से जुड़ सकते हैं; एक क्रॉस-namespace बैकएंड संदर्भ के लिए गंतव्य namespace स्वामी द्वारा स्वीकृत ReferenceGrant की आवश्यकता होती है। RBAC, एडमिशन नीतियां और Git समीक्षा एप्लिकेशन टीमों को प्लेटफॉर्म TLS, श्रोताओं, या किसी अन्य टीम के अनुदान को बदलने से रोकती हैं। ऑडिट करें कि पैरेंट, बैकएंड संदर्भ या वेट किसने बदला।
4. कैनरी, स्ट्रीम्स और रीट्री
यूनरी RPCs वेट के अनुसार स्थिर और कैनरी को नए अनुरोध भेज सकते हैं; एक स्ट्रीमिंग RPC कनेक्शन स्थापना के बाद अपना रूट बनाए रखता है। गैर-आइडम्पोटेंट कॉल्स को स्वचालित रूप से पुनः प्रयास (retry) न करें, और अस्पष्ट क्लाइंट टाइमआउट पर Gateway रीट्री को स्टैक न करें। कैनरी कुंजी के रूप में एक स्पष्ट हेडर या टेनेंट सूची का उपयोग करें ताकि डिबगिंग के दौरान एक टेनेंट बेतरतीब ढंग से विचलित (drift) न हो। छोटे कमिट्स में वेट्स बदलें और सक्रियण समय रिकॉर्ड करें।
5. हेल्थ, स्टेटस और विफलता रोलबैक
डेटा प्लेन को gRPC हेल्थ चेक्स, कनेक्शन पूल्स और एक स्पष्ट प्रति-रूट टाइमआउट की आवश्यकता होती है। यदि कंट्रोलर अनुपलब्ध है, तो अंतिम स्वीकृत कॉन्फ़िगरेशन की सेवा जारी रखें लेकिन असत्यापित परिवर्तनों को अस्वीकार करें। यदि कोई Gateway स्वीकृत नहीं है, कोई संदर्भ हल नहीं हो सकता है, या किसी बैकएंड में कोई एंडपॉइंट नहीं है, तो ऐसी स्थिति प्रदर्शित करें जो रिलीज़ को रोकती है। रोलबैक कैनरी वेट को शून्य पर सेट कर सकता है, पिछले Route को पुनर्स्थापित कर सकता है, या स्टैंडबाय Gateway पर स्विच कर सकता है; इसे आइडम्पोटेंट बनाएं।
6. ऑब्ज़र्वेबिलिटी और क्षमता सीमाएं
रूट, सर्विस, मेथड, स्टेटस, टेनेंट और वर्ज़न द्वारा अनुरोध, त्रुटियां, P50/P95/P99 लेटेंसी, सक्रिय स्ट्रीम्स, रीट्री और कनेक्शन समय रिकॉर्ड करें। मीट्रिक लेबल्स में कच्चा उच्च-कार्डिनैलिटी मेटाडेटा न डालें; लॉग में इसका नमूना लें और संशोधित (redact) करें। क्षमता परीक्षणों में यूनरी और स्ट्रीमिंग दोनों ट्रैफ़िक के लिए कनेक्शन, समवर्ती स्ट्रीम्स, TLS CPU, कंट्रोलर प्रसार विलंब और बैकएंड कनेक्शन सीमाएं शामिल होनी चाहिए।
उच्च-गुणवत्ता वाला नमूना उत्तर
मैं प्लेटफॉर्म टीम को GatewayClass, Gateway और लिसनर्स का स्वामित्व देता हूँ, जबकि एप्लिकेशन टीमें केवल namespace-स्कोप्ड GRPCRoutes और Services की मालिक होती हैं। एक GRPCRoute सर्विस/मेथड और नियंत्रित हेडर्स से मेल खाता है; एक क्रॉस-namespace बैकएंड को गंतव्य-स्वामित्व वाले ReferenceGrant की आवश्यकता होती है, और allowedRoutes प्लस RBAC अटैचमेंट को प्रतिबंधित करते हैं।
रिलीज़ के लिए, मैं स्थिर और कैनरी के बीच नए यूनरी अनुरोधों को वेट करता हूँ। स्ट्रीमिंग कनेक्शन स्थापना के समय केवल एक बार चयन करते हैं, इसलिए मैं उन्हें स्ट्रीम के बीच में कट ओवर नहीं करता। मैं गैर-आइडम्पोटेंट कॉल्स के लिए स्वचालित रीट्री से बचता हूँ और क्लाइंट तथा Gateway के बीच टाइमआउट और रीट्री बजट का समन्वय करता हूँ। कंट्रोलर Accepted, ResolvedRefs और बैकएंड हेल्थ को प्रदर्शित करता है; CI अमान्य संदर्भों या विरोधों को ब्लॉक करता है। कैनरी एक टेनेंट या स्पष्ट हेडर के साथ शुरू होता है और मेथड-स्तरीय त्रुटियों, टेल लेटेंसी, सक्रिय स्ट्रीम्स, या व्यावसायिक सफलता दर पर रोलबैक करता है, ऑडिट रिकॉर्ड के साथ पिछले वेट को पुनर्स्थापित करता है।
सामान्य गलतियाँ
GRPCRoute को साधारण Ingress मानना
सर्विस/मेथड और HTTP/2 सिमेंटिक्स को अनदेखा करने से मैचेस बहुत व्यापक हो जाते हैं। पहले प्राथमिकता और अज्ञात-मेथड व्यवहार को परिभाषित करें।
एप्लिकेशन्स को Gateway एडिट करने की अनुमति देना
साझा श्रोता और TLS टेनेंट्स द्वारा परिवर्तनशील हो जाते हैं। अलग-अलग गेट्स के रूप में allowedRoutes, RBAC, ReferenceGrant और एडमिशन नीति का उपयोग करें।
अंधाधुंध पुनः प्रयास करना या स्ट्रीम्स को कट ओवर करना
यह साइड इफेक्ट्स को दोहरा सकता है या लंबे कनेक्शनों को छोटा कर सकता है। आइडम्पोटेंसी और कनेक्शन जीवनकाल द्वारा यूनरी और स्ट्रीमिंग नीति को अलग करें।
केवल कंट्रोलर परिनियोजन (deployment) सफलता की जाँच करना
एक स्वस्थ कंट्रोलर स्वीकृत Route या प्रयोग करने योग्य बैकएंड को साबित नहीं करता है। Accepted, ResolvedRefs, हेल्थ और डेटा-प्लेन सिग्नल्स की जांच करें।
फॉलो-अप्स और प्रतिक्रियाएं
फॉलो-अप 1: दो Routes एक ही मेथड से मेल खाते हैं। क्या होता है?
किसी कार्यान्वयन के आकस्मिक क्रम पर निर्भर न रहें। namespace और पैरेंट-अटैचमेंट नीति के साथ स्वामित्व को सीमित करें, CI में विरोधों की जाँच करें, और अनसुलझी स्थिति को रिलीज़ विफलता के रूप में मानें।
फॉलो-अप 2: कैनरी सुरक्षित रूप से एक टेनेंट को कैसे लक्षित कर सकता है?
यादृच्छिक (random) वेट्स के बजाय एक स्पष्ट टेनेंट या हेडर मिलान का उपयोग करें, और वर्ज़न तथा टेनेंट त्रुटि दरों को रिकॉर्ड करें। रोलबैक सबसे पहले उस मिलान को हटाता है।
फॉलो-अप 3: क्या एक डेड Gateway कंट्रोलर ट्रैफ़िक को बाधित करता है?
यह इस बात पर निर्भर करता है कि डेटा प्लेन अंतिम स्वीकृत कॉन्फ़िगरेशन को बनाए रखता है या नहीं। परिवर्तनों को रोकते हुए इसकी सेवा जारी रखें, कॉन्फ़िगरेशन की आयु की निगरानी करें, और सुरक्षा विंडो समाप्त होने से पहले स्टैंडबाय पर विफल (failover) हो जाएं।
फॉलो-अप 4: क्रॉस-namespace backendRef के लिए ऑथराइजेशन की आवश्यकता क्यों है?
यह एक टीम को दूसरी टीम की Service पर ट्रैफ़िक भेजने की अनुमति देता है। गंतव्य-स्वामित्व वाला ReferenceGrant सहमति को स्पष्ट बनाता है, जबकि RBAC और ऑडिट छिपे हुए विशेषाधिकार वृद्धि (privilege escalation) को रोकते हैं।