आप ज़ोन के बीच Kubernetes Topology Aware Routing को कैसे डिज़ाइन करेंगे?

प्रश्न और संदर्भ

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

साक्षात्कारकर्ता क्या मूल्यांकन करता है

क्या आप EndpointSlice हिंट्स, kube-proxy उपयोग, और Service ट्रैफ़िक नीति को अलग-अलग समझते हैं।
क्या आप यह मान लेने के बजाय कि समान-ज़ोन हमेशा बेहतर होता है, एंडपॉइंट संख्या और संतुलित स्रोत ट्रैफ़िक जैसी पूर्वापेक्षाओं की पहचान करते हैं।
क्या आप ग्लोबल फ़ॉलबैक, विफलता से सुरक्षा के उपाय, और हॉट-स्पॉट मॉनिटरिंग डिज़ाइन करते हैं।
क्या आप क्रॉस-ज़ोन लागत, लेटेंसी, एंडपॉइंट लोड, और रोलआउट जोखिम का मात्रात्मक आकलन करते हैं।

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

ट्रैफ़िक और लक्ष्य

क्या स्रोत ट्रैफ़िक सभी ज़ोन में समान रूप से वितरित है? क्या लक्ष्य कम p95 लेटेंसी, कम क्रॉस-ज़ोन लागत, या डेटा रेजिडेंसी है? क्या त्रुटि (error) लौटाने की तुलना में क्रॉस-ज़ोन एक्सेस बेहतर है?

एंडपॉइंट्स और स्केलिंग

प्रत्येक ज़ोन में कितने रेडी Pods मौजूद हैं? क्या स्केलिंग, रोलिंग रिलीज़, या PodDisruptionBudget सुरक्षित एंडपॉइंट संख्या को अस्थायी रूप से कम कर सकता है? क्या Service को नोड-लोकल ट्रैफ़िक की भी आवश्यकता है?

विफलता और ऑब्ज़र्वेबिलिटी

क्या विफलता डोमेन कोई ज़ोन, नोड, या नेटवर्क है? आप ओवरलोड ज़ोन, अनुपलब्ध हिंट्स, या kube-proxy फ़ॉलबैक का पता कैसे लगाएंगे? क्या इस सुविधा को प्रति Service सक्षम किया जा सकता है?

30-सेकंड का उत्तर

मैं पहले सत्यापित करूँगा कि स्रोत ट्रैफ़िक और एंडपॉइंट वितरण रूटिंग पूर्वापेक्षाओं को पूरा करते हैं, फिर EndpointSlice हिंट्स या Service की समर्थित traffic-distribution सेटिंग के माध्यम से ज़ोन प्राथमिकता सक्षम करूँगा। क्षमता या सुरक्षा स्थितियां विफल होने पर कंट्रोल प्लेन और kube-proxy को क्लस्टर-व्यापी एंडपॉइंट्स पर वापस जाना (fallback करना) चाहिए। क्रॉस-ज़ोन बाइट्स, p95 लेटेंसी, प्रति-ज़ोन अनुरोध, और एंडपॉइंट लोड की निगरानी करें; बदलाव का कैनरी रोलआउट करें और यदि कोई हॉट स्पॉट या विफलता दिखाई देती है तो प्राथमिकता को अक्षम करें।

गहन समाधान

1. कंट्रोल और डेटा प्लेन को अलग करें

EndpointSlice कंट्रोलर हिंट्स उत्पन्न करने के लिए एंडपॉइंट टोपोलॉजी का उपयोग करता है, और kube-proxy या कोई अन्य नोड डेटा-प्लेन घटक उनका उपयोग करता है। Topology Aware Routing स्रोत ज़ोन में एंडपॉइंट्स को प्राथमिकता देता है; यह सख्त समान-ज़ोन रूटिंग की गारंटी नहीं देता है। कंट्रोल-प्लेन गणना, EndpointSlice प्रसार (propagation), और नोड व्यवहार का अलग-अलग निरीक्षण करें।

2. पूर्वापेक्षाओं की जाँच करें

Kubernetes दस्तावेज़ प्रति ज़ोन कम से कम तीन एंडपॉइंट्स की अनुशंसा करता है; तीन-ज़ोन क्लस्टर में इसका आमतौर पर अर्थ कम से कम नौ एंडपॉइंट्स होता है। बहुत कम एंडपॉइंट्स होने पर, कंट्रोलर कोई हिंट जारी नहीं कर सकता है। एक ही ज़ोन में केंद्रित स्रोत वितरण उस ज़ोन को ओवरलोड भी कर सकता है, इसलिए ट्रैफ़िक इतिहास और क्षमता डेटा के साथ इस धारणा को मान्य करें।

3. कॉन्फ़िगरेशन चुनें

लक्ष्य Kubernetes संस्करण के लिए टोपोलॉजी मोड या समर्थित trafficDistribution क्षमता का उपयोग करें। उदाहरण के लिए:

yaml

apiVersion: v1
kind: Service
metadata:
  name: checkout
  annotations:
    service.kubernetes.io/topology-mode: "Auto"
spec:
  selector:
    app: checkout
  ports:
    - port: 443
      targetPort: 8443

API संस्करण, फ़ीचर गेट्स, और kube-proxy व्यवहार की जाँच किए बिना लीगेसी topology-aware-hints एनोटेशन, वर्तमान टोपोलॉजी मोड, और संस्करण-विशिष्ट फ़ील्ड्स को मिश्रित न करें।

4. सुरक्षित फ़ॉलबैक डिज़ाइन करें

जब एंडपॉइंट्स अपर्याप्त हों, हिंट्स अमान्य हों, या आवंटन असुरक्षित हो, तो कंट्रोल प्लेन या kube-proxy को क्लस्टर-व्यापी एंडपॉइंट्स का उपयोग करना चाहिए। फ़ॉलबैक को ऑब्ज़र्वेबल बनाएं; अन्यथा क्रॉस-ज़ोन ट्रैफ़िक को गलती से एक सफल अनुकूलन मान लिया जा सकता है। पूरे ज़ोन के आउटेज, विलंबित EndpointSlice प्रसार, गलत नोड लेबल्स, और मिश्रित kube-proxy संस्करणों का परीक्षण करें।

5. हॉट स्पॉट्स को रोकें

समान-ज़ोन प्राथमिकता एंडपॉइंट सेट को सीमित करती है। प्रति-ज़ोन अनुरोध, कनेक्शन, CPU, कतार की गहराई, और त्रुटियों को ट्रैक करें। यदि किसी ज़ोन को अनुपातहीन रूप से बड़ा स्रोत हिस्सा मिलता है या उसमें बहुत कम एंडपॉइंट्स हैं, तो प्राथमिकता कम करें या अस्थायी रूप से ग्लोबल रूटिंग का उपयोग करें। स्केलिंग और रोलिंग रिलीज़ को प्रत्येक ज़ोन में रेडी एंडपॉइंट्स और PDB हेडरूम को बनाए रखना चाहिए।

6. लागत और लेटेंसी का मूल्यांकन करें

क्रॉस-ज़ोन बाइट्स, अनुरोध p50/p95/p99, कनेक्शन का पुन: उपयोग, एंडपॉइंट लोड, और विफलता दर को एक साथ रिकॉर्ड करें। सक्षमीकरण से पहले और बाद में समान ट्रैफ़िक विंडो की तुलना करें; अन्यथा कैश-हिट या क्लाइंट-पुनर्प्रयास परिवर्तनों को गलत तरीके से टोपोलॉजी रूटिंग के लिए जिम्मेदार ठहराया जा सकता है। लागत में कमी के कारण त्रुटि दर या टेल लेटेंसी खराब नहीं होनी चाहिए।

7. धीरे-धीरे रोल आउट और रोल बैक करें

इस सुविधा को किसी गैर-महत्वपूर्ण Service या एक ज़ोन वाले कैनरी पर सक्षम करें, EndpointSlice हिंट्स, kube-proxy चॉइस, और फ़ॉलबैक इवेंट्स को सत्यापित करें, फिर समान सेवाओं में इसका विस्तार करें। रोलबैक प्राथमिकता को हटाता है और ग्लोबल एंडपॉइंट्स को सत्यापित करता है; कॉन्फ़िगरेशन संस्करण, मेट्रिक विंडो, और विफलता-ड्रिल साक्ष्य बनाए रखें।

एक मजबूत उत्तर का उदाहरण

मैं टोपोलॉजी प्राथमिकता को एक प्रतिवर्ती (reversible) प्रदर्शन अनुकूलन मानता हूँ। पहले एंडपॉइंट संख्या और स्रोत वितरण को मान्य करें, फिर EndpointSlice कंट्रोलर को नोड डेटा प्लेन के लिए हिंट्स बनाने दें। अपर्याप्त एंडपॉइंट्स, ज़ोन असंतुलन, या असंगत घटक ग्लोबल फ़ॉलबैक को ट्रिगर करते हैं। क्रॉस-ज़ोन बाइट्स, प्रति-ज़ोन लोड, लेटेंसी, त्रुटियों, और फ़ॉलबैक संख्या की निगरानी करें; विस्तार से पहले कैनरी करें। कोई भी ओवरलोड या विफल ज़ोन प्राथमिकता को अक्षम करके उपलब्धता को पुनर्प्राप्त कर सकता है।

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

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

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

एंडपॉइंट्स की कमी होने पर फ़ॉलबैक क्यों करें?

टोपोलॉजी प्राथमिकता उम्मीदवार सेट को सीमित करती है; बहुत कम एंडपॉइंट्स ओवरलोड और विफलता के जोखिम को बढ़ाते हैं। ग्लोबल एंडपॉइंट्स सबसे पहले उपलब्धता बनाए रखते हैं।

क्या तीन एंडपॉइंट्स एक सख्त नियम है?

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

क्या होगा यदि सभी अनुरोध एक ही ज़ोन से उत्पन्न होते हैं?

समान-ज़ोन प्राथमिकता वहां लोड को केंद्रित कर सकती है। प्राथमिकता कम करें, उस ज़ोन में एंडपॉइंट्स जोड़ें, या विश्व स्तर पर फ़ॉलबैक करें, फिर लोड और लेटेंसी मेट्रिक्स के साथ पुष्टि करें।

आप कैसे साबित करेंगे कि kube-proxy ने हिंट्स का उपभोग किया?

EndpointSlice हिंट्स, नोड कंपोनेंट संस्करणों, और वास्तविक अनुरोध वितरण का निरीक्षण करें। केवल कंट्रोल-प्लेन ऑब्जेक्ट्स की जाँच करने के बजाय एंड-टू-एंड साक्ष्य के लिए क्रॉस-ज़ोन बाइट्स और प्रति-ज़ोन एंडपॉइंट हिट दर का उपयोग करें।

क्या रोलबैक के लिए Service को पुनर्गठित करने की आवश्यकता होती है?

आमतौर पर टोपोलॉजी प्राथमिकता को हटाएं या समायोजित करें और सत्यापित करें कि EndpointSlice और नोड डेटा-प्लेन व्यवहार ग्लोबल चयन पर वापस आ जाए। एक रोलबैक ड्रिल और मेट्रिक साक्ष्य बनाए रखें।