सिस्टम डिज़ाइन इंटरव्यू: मल्टी-टेनेंट इनग्रेस के लिए Kubernetes Gateway API ListenerSets का उपयोग करें

प्रश्न और परिदृश्य

एक शेयर्ड Kubernetes Gateway डिज़ाइन करें। प्लेटफ़ॉर्म टीम Gateway और लोड-बैलेंसिंग इंफ्रास्ट्रक्चर की मालिक है; एप्लिकेशन टीमें अपने नेमस्पेस में होस्टनेम, पोर्ट, HTTPRoutes और सर्टिफिकेट्स की मालिक हैं। मान लें कि 20 टीमें हैं जिनमें से प्रत्येक के 50 लिसनर्स हैं, यानी लगभग 1,000 डोमेन, जबकि एक सिंगल Gateway की बेसलाइन लिसनर सीमा 64 है।

बताएं कि एक बड़े Gateway से लिसनर्स को ListenerSets में कैसे विभाजित किया जाए, क्रॉस-नेमस्पेस अटैचमेंट को कैसे ऑथराइज किया जाए, विरोधों (conflicts) के दौरान ट्रैफ़िक को स्थिर कैसे रखा जाए, और स्थिति को कैसे प्रदर्शित किया जाए ताकि टीमें Accepted, Programmed, या Conflicted कॉन्फ़िगरेशन में अंतर कर सकें।

इंटरव्यूअर क्या जांच रहा है

रिसोर्स सीमाएं और डेलिगेशन

एक मजबूत उत्तर शेयर्ड इंफ्रास्ट्रक्चर, टेनेंट कॉन्फ़िगरेशन और रूट अटैचमेंट को अलग करता है, और फिर यह बताता है कि एप्लिकेशन टीमों को सीधे प्लेटफ़ॉर्म Gateway को एडिट क्यों नहीं करना चाहिए।

विरोध और सुरक्षित डिफ़ॉल्ट (Conflicts and secure defaults)

ListenerSets का डिफ़ॉल्ट डिनायल (denial), स्वीकृत नेमस्पेस स्रोत, डिटर्मिनिस्टिक होस्टनेम प्राथमिकता और सर्टिफिकेट-रेफरेंस सीमाओं का उल्लेख करें।

कंट्रोलर कंसिस्टेंसी

वॉचेस (watches), मर्जिंग, वैलिडेशन, स्टेटस कंडीशंस और रीट्राइज़ (retries) को कवर करें। केवल एक YAML ऑब्जेक्ट का अर्थ यह नहीं है कि डेटा प्लेन प्रोग्राम हो गया है।

स्केल और माइग्रेशन

एक Gateway, प्रति टेनेंट एक Gateway, और Ingress एनोटेशन की तुलना करें। बताएं कि ListenerSet की जटिलता डेलिगेशन और इंटरऑपरेबिलिटी के लिए कब उचित है।

उत्तर देने से पहले स्पष्ट करने वाले प्रश्न

क्या सभी 1,000 डोमेन एक ही लोड-बैलेंसर एड्रेस साझा करते हैं, या प्रत्येक टीम को एक अलग एंट्री पॉइंट की आवश्यकता है?
क्या एप्लिकेशन टीमें अपने TLS Secrets का प्रबंधन कर सकती हैं, या प्लेटफ़ॉर्म सर्टिफिकेट को स्वीकृत करता है?
क्या क्रॉस-नेमस्पेस अटैचमेंट को सभी नेमस्पेस, एक लेबल चयनकर्ता (label selector), या केवल समान नेमस्पेस की अनुमति देनी चाहिए?
क्या विरोध की स्थिति में पुराने कॉन्फ़िगरेशन को ट्रैफ़िक सर्व करना जारी रखना चाहिए, या नया कॉन्फ़िगरेशन उसकी जगह ले सकता है?
कंट्रोलर को परिवर्तनों को कितनी तेज़ी से दर्शाना चाहिए, और क्या क्रॉस-क्लस्टर रेप्लिकेशन आवश्यक है?
क्या HTTPRoute, TLSRoute, और अन्य रूट प्रकार समान ऑथराइजेशन सीमा साझा करते हैं?

30-सेकंड उत्तर फ्रेमवर्क

"मैं प्लेटफ़ॉर्म टीम को Gateway बनाने दूंगा और डिफ़ॉल्ट रूप से ListenerSets को अस्वीकार (deny) करूँगा, फिर अनुमत नेमस्पेस का चयन करने के लिए allowedListeners का उपयोग करूँगा। प्रत्येक एप्लिकेशन टीम अपने नेमस्पेस में एक ListenerSet और रूट्स सबमिट करती है। कंट्रोलर ParentRef, होस्टनेम, पोर्ट, प्रोटोकॉल, सर्टिफिकेट रेफरेंस और AllowedRoutes को मान्य करता है, फिर पहले पैरेंट Gateway, दूसरे सबसे पुराने निर्माण समय और तीसरे नेमस्पेस/नाम क्रम का उपयोग करके लिसनर्स को मर्ज करता है। विरोध को Accepted=False और Conflicted=True के रूप में चिह्नित किया जाता है और यह किसी सक्रिय लिसनर को बदल नहीं सकता है। डेटा प्लेन केवल मान्य एग्रीगेट से प्रोग्राम किया जाता है, जबकि स्टेटस कंडीशंस और मेट्रिक्स अस्वीकृति, विरोध, अनप्रोग्राम्ड और प्रोग्राम्ड स्थितियों में अंतर करते हैं।"

चरण-दर-चरण विस्तृत उत्तर

चरण 1: स्केल का अनुमान लगाएं और रिसोर्स चुनें

बीस टीमें गुणा 50 लिसनर्स लगभग 1,000 एंट्री पॉइंट होते हैं। सभी 1,000 घोषणाओं को एक Gateway में रखने से सिंगल-ऑब्जेक्ट राइट कंटेंशन, व्यापक अनुमतियाँ और बार-बार कंट्रोलर रीकम्प्यूटेशन की स्थिति बनती है। ListenerSets टीम के स्वामित्व वाले कॉन्फ़िगरेशन को स्वतंत्र रिसोर्स में विभाजित करते हैं; Gateway प्लेटफ़ॉर्म एड्रेस, क्लास और अटैचमेंट पॉलिसी रखता है।

चरण 2: ऑथराइजेशन हैंडशेक स्थापित करें

allowedListeners सुरक्षा द्वार है। None डिफ़ॉल्ट रूप से किसी भी ListenerSet को स्वीकार नहीं करता है; प्लेटफ़ॉर्म Same, एक लेबल Selector, या All चुन सकता है। एक ListenerSet Gateway का नाम निर्दिष्ट करने के लिए parentRef का उपयोग करता है। कंट्रोलर इसे केवल तभी शामिल करता है जब दोनों पक्ष संबंध को ऑथराइज करते हैं, रेफरेंस मान्य होता है, और नेमस्पेस चयन इसकी अनुमति देता है।

yaml

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: shared-gateway
spec:
  allowedListeners:
    namespaces:
      from: Selector
      selector:
        matchLabels:
          gateway-access: shared
---
apiVersion: gateway.networking.k8s.io/v1
kind: ListenerSet
metadata:
  name: team-a-listeners
  namespace: team-a
spec:
  parentRef:
    name: shared-gateway
    namespace: platform
  listeners:
  - name: app-a
    hostname: app-a.example.com
    protocol: HTTPS
    port: 443

चरण 3: मर्ज और विरोध नियम परिभाषित करें

Gateway लिसनर्स को ऑथराइज्ड ListenerSet लिसनर्स के साथ मिलाएं, फिर पोर्ट, प्रोटोकॉल और लागू होस्टनेम से पहचान निर्धारित करें। विरोधों को डिटर्मिनिस्टिक रूप से हल करें: पैरेंट Gateway जीतता है; फिर पुराना ListenerSet जीतता है; शेष टाई के लिए नेमस्पेस/नाम क्रम का उपयोग किया जाता है। सक्रिय ट्रैफ़िक को चुपचाप बदलने के बजाय हारने वाले रिसोर्स को Conflicted के रूप में चिह्नित करें।

चरण 4: रूट्स और सर्टिफिकेट्स को अलग करें

ListenerSet allowedRoutes सीमित करता है कि कौन से नेमस्पेस रूट्स को बाइंड कर सकते हैं। एक रूट ListenerSet सेक्शन को लक्षित करने के लिए parentRefs का उपयोग करता है। प्लेटफ़ॉर्म पॉलिसी TLS Secret रेफरेंस को सीमित करती है, जो एप्लिकेशन रिलीज़ अनुमति से सर्टिफिकेट अनुमोदन को अलग करती है। एक टीम अपने स्वयं के ListenerSet और Secret को एडिट कर सकती है लेकिन किसी अन्य टेनेंट के रिसोर्स को पढ़ने के लिए ParentRef का उपयोग नहीं कर सकती है।

चरण 5: कंट्रोलर को कन्वर्ज कराएं

Gateway, ListenerSet, Route, नेमस्पेस लेबल्स और Secrets को वॉच करें और Gateway द्वारा समूहीकृत एक वांछित मॉडल बनाएं। इवेंट्स को डुप्लीकेट-मुक्त (deduplicate) और डिबाउंस (debounce) करें, एग्रीगेट को मान्य करें, फिर लोड बैलेंसर को प्रोग्राम करें। Accepted, Programmed, ResolvedRefs, और Conflicted स्थितियाँ वापस करें। रीट्राइज़ इडेम्पोटेंट (idempotent) हैं; अंतिम वांछित स्थिति तब तक बनी रहती है जब तक नया कॉन्फ़िगरेशन सफलतापूर्वक प्रोग्राम नहीं हो जाता।

चरण 6: विकल्पों और विफलता पथों की तुलना करें

प्रति टेनेंट एक Gateway अनुमति सीमाओं को सरल बनाता है लेकिन पते, लोड बैलेंसर और सर्टिफिकेट लागत को बढ़ाता है। एनोटेशन के साथ एक सिंगल Gateway सस्ता है लेकिन इसमें साझा स्कीमा, विरोध सिमेंटिक्स और क्रॉस-इम्प्लीमेंटेशन इंटरऑपरेबिलिटी की कमी होती है। जब ListenerSet कंट्रोल प्लेन अनुपलब्ध हो, तो अंतिम Programmed स्नैपशॉट बनाए रखें और अज्ञात नए लिसनर्स को अस्वीकार करें। यदि पैरेंट Gateway गायब हो जाता है या ParentRef अमान्य हो जाता है, तो चाइल्ड रिसोर्स को अनएक्सेप्टेड चिह्नित करें और रिकवरी के बाद रीकंसाइल करें।

उच्च गुणवत्ता वाला नमूना उत्तर

"मैं Gateway को प्लेटफ़ॉर्म-स्वामित्व वाली शेयर्ड सीमा और ListenerSets को टेनेंट-स्वामित्व वाली घोषणाओं के रूप में मानूंगा। प्लेटफ़ॉर्म डिफ़ॉल्ट रूप से अस्वीकृति के साथ GatewayClass, पते और allowedListeners को कॉन्फ़िगर करता है; केवल gateway-access=shared लेबल वाले नेमस्पेस ही जुड़ सकते हैं। प्रत्येक टीम अपना स्वयं का ListenerSet, HTTPRoute और सर्टिफिकेट रेफरेंस सबमिट करती है।

प्रत्येक इवेंट पर, कंट्रोलर मर्ज करने से पहले ParentRef, नेमस्पेस ऑथराइजेशन, पोर्ट/प्रोटोकॉल/होस्टनेम, AllowedRoutes और Secret रेफरेंस को मान्य करता है। पैरेंट Gateway विरोधों में जीतता है, जिसके बाद ListenerSet निर्माण समय और नेमस्पेस/नाम क्रम आता है। हारने वालों को Accepted=False और Conflicted=True प्राप्त होता है और वे लाइव ट्रैफ़िक पर कब्जा नहीं कर सकते। केवल एक मान्य एग्रीगेट ही लोड बैलेंसर को प्रोग्राम करता है, और Programmed का अर्थ है कि डेटा प्लेन ने इसे लागू कर दिया है।

20 टीमों गुणा 50 लिसनर्स (लगभग 1,000 प्रविष्टियों) के लिए, रिसोर्स स्प्लिटिंग सिंगल-ऑब्जेक्ट राइट कंटेंशन और केंद्रीकृत अनुमतियों से बचाती है। कंट्रोलर डाउनटाइम के दौरान, डेटा प्लेन अंतिम स्थिर स्नैपशॉट को सर्व करता है और परस्पर विरोधी जोड़ को अस्वीकार करता है। यदि किसी टेनेंट को एक अलग पते, अनुपालन सीमा या विफलता डोमेन की आवश्यकता होती है, तो मैं अलग Gateways का उपयोग करूंगा और इंफ्रास्ट्रक्चर लागत को स्वीकार करूंगा।"

सामान्य गलतियाँ

प्रत्येक टीम को Gateway एडिट करने देना → कॉन्फ़िगरेशन एक दूसरे को ओवरराइट करते हैं और अनुमतियां व्यापक हो जाती हैं → प्लेटफ़ॉर्म Gateway का मालिक है, टेनेंट्स ListenerSets के मालिक हैं।
डिफ़ॉल्ट रूप से प्रत्येक नेमस्पेस को अनुमति देना → कोई भी टेनेंट शेयर्ड इनग्रेस का अनुरोध कर सकता है → डिफ़ॉल्ट रूप से None करें, फिर Same या Selector के साथ सीमित करें।
अंतिम राइट को जीतने देना (last write win) → एक नया लिसनर होस्टनेम को हाईजैक कर सकता है → डिटर्मिनिस्टिक प्राथमिकता का उपयोग करें और हारने वालों को कॉन्फ़्लिक्टेड चिह्नित करें।
केवल होस्टनेम की तुलना करना → विभिन्न प्रोटोकॉल अभी भी टकरा सकते हैं → पोर्ट, प्रोटोकॉल और लागू होस्टनेम का एक साथ उपयोग करें।
Secret नामों को सीधे डेटा प्लेन में पास करना → क्रॉस-नेमस्पेस विशेषाधिकार या सर्टिफिकेट लीकेज → पहले रेफरेंस और ऑथराइजेशन को मान्य करें।
प्रत्येक इवेंट के लिए तुरंत रीप्रोग्राम करना → क्षणिक अमान्य स्थितियाँ चर्न (churn) का कारण बनती हैं → डिबाउंस करें, इडेम्पोटेंट तरीके से मर्ज करें, सफलता के बाद स्विच करें, और एक स्नैपशॉट बनाए रखें।
स्थिति में केवल Ready प्रदर्शित करना → टेनेंट अस्वीकृति, विरोध या प्रोग्रामिंग लैग में अंतर नहीं कर सकते → Accepted, Programmed, ResolvedRefs, और Conflicted स्थितियों का उपयोग करें।
ListenerSet को असीमित स्केलिंग के रूप में मानना → कंट्रोलर्स और लोड बैलेंसर्स की अभी भी सीमाएं हैं → Gateway द्वारा शार्ड करें, टेनेंट कोटा निर्धारित करें, और कन्वर्जेंस की निगरानी करें।

फॉलो-अप प्रश्न और उत्तर

फॉलो-अप 1: दो टीमें एक ही होस्टनेम और पोर्ट सबमिट करती हैं। कौन जीतता है?

पैरेंट Gateway जीतता है। ListenerSets के बीच, पुराना निर्माण समय जीतता है; शेष टाई नेमस्पेस/नाम क्रम का उपयोग करता है। हारने वाला Conflicted के साथ दिखाई देता है और रीट्राई टाइमिंग के माध्यम से परिणाम नहीं बदल सकता है।

फॉलो-अप 2: प्लेटफ़ॉर्म एक टेनेंट को अस्थायी रूप से कैसे फ्रीज कर सकता है?

इसके नेमस्पेस लेबल को हटाकर या allowedListeners चयनकर्ता को सीमित करके। कंट्रोलर अंतिम स्नैपशॉट को बनाए रखते हुए ListenerSet को अनएक्सेप्टेड चिह्नित करता है। ऑडिट के लिए फ्रीज को रिकॉर्ड करें, और पुराने ऑब्जेक्ट पर आँख बंद करके भरोसा करने के बजाय रिकवरी पर पुन: सत्यापित करें।

फॉलो-अप 3: एक ListenerSet में 64 लिसनर्स हैं। क्या यह और बढ़ सकता है?

कार्यान्वयन सीमा अभी भी लागू होती है; कुल क्षमता अनंत नहीं है। कोटे के साथ ListenerSets और Gateways में टेनेंट को विभाजित करें। यदि पते या सर्टिफिकेट का अलगाव साझा करने से अधिक महत्वपूर्ण है, तो एकाधिक Gateways का उपयोग करें।

फॉलो-अप 4: बिना किसी आउटेज के TLS Secret को कैसे रोटेट करें?

Secret वर्ज़न को वॉच करें, इसकी चेन, होस्टनेम और समाप्ति को मान्य करें, और डेटा प्लेन द्वारा नए सर्टिफिकेट की पुष्टि करने के बाद ही Programmed को अपडेट करें। ग्रेस विंडो के लिए पुराने सर्टिफिकेट को बनाए रखें; विफलता पर अंतिम ज्ञात-अच्छे वर्ज़न को सर्व करना जारी रखें और अलर्ट भेजें।

फॉलो-अप 5: क्या कंट्रोलर के पुनरारंभ (restart) होने के दौरान एक नया Route लाइव ट्रैफ़िक की जगह ले सकता है?

नहीं। डेटा प्लेन द्वारा अंतिम सफल स्नैपशॉट सर्व करने के दौरान वांछित स्थिति को बनाए रखें या पुनर्निर्माण करें। पुनरारंभ के बाद, रेफरेंस और विरोधों की पुनर्गणना करें, फिर एक ऑब्ज़र्वेबल कॉन्फ़िगरेशन वर्ज़न पर एक बार स्विच करें।

स्रोत 1: Gateway API ListenerSet यूज़र गाइड

गाइड ListenerSet के डेलिगेटेड मल्टी-टेनेंट उपयोग, 64-लिसनर सीमा, allowedListeners, parentRef, और विरोध प्राथमिकता को परिभाषित करता है। वे तथ्य रिसोर्स मॉडल, ऑथराइजेशन हैंडशेक, विरोध प्रबंधन और स्टेटस डिज़ाइन को आधार प्रदान करते हैं।

स्रोत 2: GEP-1713

GEP-1713 रिसोर्स कंटेंशन, क्रॉस-नेमस्पेस प्रबंधन और बड़े-डोमेन उपयोग के मामलों का वर्णन करता है, और पैरेंट Gateway, निर्माण-समय, और लेक्सिकल मर्ज नियमों को निर्दिष्ट करता है। क्षमता का अनुमान और विकल्प उन बाधाओं का उपयोग करते हैं।

स्रोत 3: Kubernetes Gateway API v1.5 रिलीज़ नोट्स

रिलीज़ नोट्स ListenerSet के Standard में जाने और मल्टी-टेनेंसी, डेलिगेटेड लिसनर्स और 64 से अधिक लिसनर्स पर इसके फोकस को रिकॉर्ड करते हैं। यह उत्तर उस सार्वजनिक परिवर्तन को माइग्रेशन और गवर्नेंस निर्णयों में बदलता है।

स्रोत 4: पब्लिक सिस्टम-डिज़ाइन इंटरव्यू गाइड

पब्लिक गाइड आवश्यकताओं को स्पष्ट करने, पैमाने और विफलता पर चर्चा करने और ट्रेड-ऑफ़ को समझाने पर जोर देती है। स्पष्टीकरण, अनुमान, विरोध फॉलो-अप और विकल्प उन अवलोकन योग्य साक्षात्कार संकेतों को प्रशिक्षित करते हैं।