जीआरपीसी क्लाइंट साइड लोड बैलेंसिंग

Question

मैं पाइथन के साथ जीआरपीसी का उपयोग क्लाइंट/सर्वर के रूप में कुबर्नेट्स पॉड्स के अंदर कर रहा हूं ... मैं उसी प्रकार के कई फोड लॉन्च करने में सक्षम होना चाहता हूं (जीआरपीसी सर्वर) और क्लाइंट को कनेक्ट करने दें उन्हें (यादृच्छिक रूप से)।

मैंने सर्वर के 10 फोड भेजे और उन्हें लक्षित करने के लिए 'सेवा' सेट अप किया। फिर, क्लाइंट में, मैंने सेवा के DNS नाम से कनेक्ट किया - जिसका अर्थ है कि कुबेरनेट को लोड-बैलेंसिंग करना चाहिए और मुझे यादृच्छिक सर्वर पॉड पर निर्देशित करना चाहिए। हकीकत में, ग्राहक जीआरपीसी फ़ंक्शंस (जो अच्छी तरह से काम करता है) को कॉल करता है लेकिन जब मैं लॉग देखता हूं तो मुझे लगता है कि सभी कॉल उसी सर्वर फोड पर जा रहे हैं।

मुझे लगता है कि क्लाइंट कुछ प्रकार की DNS कैशिंग कर रहा है जो सभी कॉल को उसी सर्वर पर भेजा जा रहा है। क्या यह मामला है? क्या इसे अक्षम करने के लिए वैसे भी है और एक ही स्टब क्लाइंट को "नया" कॉल करने के लिए सेट करें और प्रत्येक कॉल के साथ DNS द्वारा एक नया आईपी लाएं?

मुझे पता है कि अगर मैं हर बार DNS सर्वर से पूछता हूं तो ओवरहेड के बारे में मुझे पता है, लेकिन इस समय लोड को वितरित करना मेरे लिए अधिक महत्वपूर्ण है।

संपादित

शायद नहीं एक कैशिंग मुद्दा ... अभी जिस तरह से काम करता है gRPC हो सकता है। HTTP/2 और लगातार पुन: प्रयोज्य कनेक्शन। प्रत्येक कॉल के बाद "डिस्कनेक्ट" करने का कोई तरीका?

Answer 1

मुझे यह बताकर जवाब देने का मौका दें कि चीजों को कैसे काम करना चाहिए।

क्लाइंट-साइड:

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

एलबी नीति में इनपुट हल किए गए पते की एक सूची है। DNS का उपयोग करते समय, अगर foo.com [10.0.0.1, 10.0.0.2, 10.0.0.3, 10.0.0.4] पर हल करता है, तो नीति उन सभी के लिए कनेक्शन स्थापित करने का प्रयास करेगी। सफलतापूर्वक कनेक्ट करने वाला पहला व्यक्ति चयनित बन जाएगा जब तक कि यह डिस्कनेक्ट नहीं हो जाता है। इस प्रकार नाम "पिक-फर्स्ट"। एक लंबा नाम "पहले उठाएं और जितना संभव हो सके इसके साथ चिपके रहें" हो सकता है, लेकिन यह बहुत लंबे फ़ाइल नाम के लिए बनाया गया :)। यदि/जब कोई व्यक्ति डिस्कनेक्ट हो जाता है, तो पिक-फर्स्ट पॉलिसी अगले सफलतापूर्वक जुड़े हुए पते को वापस करने के लिए आगे बढ़ेगी (आंतरिक रूप से "कनेक्टेड सबचैनेल" के रूप में संदर्भित), यदि कोई हो। एक बार फिर, यह तब तक जुड़े हुए सबचैनल को तब तक चुनना जारी रखेगा जब तक यह कनेक्ट रहता है।अगर वे सभी असफल हो जाते हैं, तो कॉल विफल हो जाएगी।

समस्या यहाँ, आंतरिक रूप से लगाकर जा रहा है, कि DNS संकल्प है केवल चैनल निर्माण पर 1 शुरू हो रहा है) और 2) चुना जुड़े उपचैनल के वियोग पर।

अभी के रूप में, एक hacky समाधान हर अनुरोध के लिए एक नया चैनल बनाने के लिए होगा (बहुत अक्षम है, लेकिन यह चाल अपने सेटअप दिया करना चाहते हैं)।

प्रश्न 1 2017 में आने वाले परिवर्तन (https://github.com/grpc/grpc/issues/7818 देखें) ग्राहकों को एक अलग एलबी नीति, अर्थात् राउंड रॉबिन चुनने की अनुमति देगा। इसके अलावा, हम है कि ग्राहक config, जो पतों उन पर राउंड रोबिन कर रही है, प्रभावी रूप से प्राप्त करने के आप क्या इरादा करने से पहले शफ़ल हैं के लिए एक "randomize" बिट शुरू करने पर विचार कर सकते हैं।

Answer 2

यदि आपने एक वेनिला कुबर्नेट सेवा बनाई है, तो सेवा में अपना स्वयं का भार-संतुलित आभासी आईपी होना चाहिए (जांच करें कि kubectl get svc your-service आपकी सेवा के लिए CLUSTER-IP दिखाता है)। यदि ऐसा है, तो DNS कैशिंग कोई समस्या नहीं होनी चाहिए, क्योंकि वह एकल वर्चुअल आईपी वास्तविक बैकएंड के बीच यातायात को विभाजित करना चाहिए।

kubectl get endpoints your-service आज़माएं कि आपकी सेवा वास्तव में आपके सभी बैकएंडों के बारे में जानती है।

यदि आपके पास headless service है, तो एक DNS लुकअप 10 आईपी (आपके प्रत्येक पॉड के लिए एक) के साथ एक रिकॉर्ड लौटाएगा। यदि आपका ग्राहक हमेशा एक रिकॉर्ड में पहला आईपी चुन रहा है, तो वह व्यवहार भी समझाएगा जो आप देख रहे हैं।