दुई साइटको Kubernetes क्लस्टरलाई तीन etcd मतदाता आवश्यक छ?
दुई VPN साइटमा तीन कन्ट्रोल-प्लेन नोड ठूलो साइट बन्द हुँदा अझै क्वोरम गुमाउँछन्। वास्तविक etcd मतदाता गन्नुहोस् र तपाईंले सहने हानि छान्नुहोस्।
तीन कन्ट्रोल-प्लेन VM खराब रातबाट बाँच्ने तीन अवसरजस्ता देखिन्छन्। तर त्यस्तो होइन, र यी दुई विश्वासबीचको दूरीले नै एउटा सफा तीन-नोड डिजाइनलाई एक भवनले बिजुली गुमाउँदा लेखन स्वीकार गर्न छोड्ने क्लस्टरमा बदल्छ। साइटबीचको VPN लिङ्कले मेसिनहरूलाई एकअर्काका लागि पुग्नयोग्य बनाउँछ र समस्या समाधान गर्नुको सट्टा लुकाउँछ। मत प्रत्येक etcd सदस्यअनुसार गनिन्छ, र ती सदस्यमध्ये दुई अझै एउटै स्विच, एउटै UPS र एउटै अपलिङ्कपछाडि बस्न सक्छन्।
तीन कन्ट्रोल-प्लेन नोड, एउटा विफलता डोमेन
तपाईं kubectl get nodes चलाउनुहुन्छ, तीन कन्ट्रोल-प्लेन प्रविष्टि देख्नुहुन्छ र क्लस्टरलाई उच्च उपलब्धका रूपमा दर्ता गर्नुहुन्छ। त्यो संख्याले योजनायोग्य क्षमता वर्णन गर्छ, बाँच्ने क्षमता होइन। बाह्य etcd बिना राखिएको kubeadm मा, प्रत्येक कन्ट्रोल-प्लेन नोडले एउटा सदस्य पनि होस्ट गर्छ, त्यसैले तीन नोडले साँच्चै तीन मतदाता दिन्छन्। ती मतदाता स्वतन्त्र रूपमा विफल हुन्छन् कि भन्ने नोड सूचीले जवाफ दिन नसक्ने छुट्टै प्रश्न हो।
एउटै हाइपरभाइजरमा दुई VM, एउटै बिजुली आपूर्तिमा दुई र्याक, एउटै ISP बाट दुई अपलिङ्क: प्रत्येक जोडी दुई होस्टनाम लगाएको एउटै डोमेन हो। प्लेसमेन्ट लेख्नुहोस् र प्रत्येक मतदाताले के साझा गर्छ चिन्ह लगाउनुहोस् — हाइपरभाइजर, PDU, र्याकको माथिल्लो स्विच, स्टोरेज एरे, NAT उपकरण, VPN केन्द्रक। त्यसपछि कागजमा प्रत्येक साझा वस्तु हटाउनुहोस् र बाँकी मत फेरि गन्नुहोस्। एउटा असफल होस्टका कारण दुई मतदाता गुमाउने क्लस्टर सुरुदेखि नै एक-मतदाता क्लस्टर थियो; कसैले यो प्रश्न अझै सोधेको थिएन।
दुई साइटको विभाजन के सहन सक्छ र के सक्दैन
तीन मतदातालाई दुई साइटमा दुई र एकका रूपमा राख्दा, अर्को साइट गायब हुँदा ठूलो पक्षले क्वोरम राख्छ र एक-मतदाता पक्षले कहिल्यै राख्दैन। त्यो असमानता गणित हो, ट्युनिङ होइन। ठ्याक्कै दुई स्वतन्त्र साइटमा फैलिएको कुनै पनि बहुमत-आधारित etcd क्लस्टर "जुनसुकै साइट गुमाऊ र प्रतिबद्ध रहिरहो" परीक्षणमा असफल हुन्छ, किनकि दुवै पक्षले एकै समयमा आधाभन्दा बढी मत राख्नुपर्ने हुन्छ।
तलको तालिका तपाईंले वास्तवमा कुन विफलता किन्नुभयो हेर्ने सबैभन्दा छिटो तरिका हो। प्रत्येक पङ्क्ति यसरी पढ्नुहोस्: आज राति यो पूरै पङ्क्ति गायब भयो भने, बाँचेकाहरूले अझै लेखन प्रतिबद्ध गर्न सक्छन्?
| What disappears | Voters left | Writes still commit |
|---|---|---|
| Site B, holding voter 3 | 2 of 3 | Yes |
| Site A, holding voters 1 and 2 | 1 of 3 | No |
| One hypervisor carrying any two voters | 1 of 3 | No |
| The inter-site VPN only | 2 of 3 on one side | Only on the majority side |
सुरुङले कहिल्यै मत किन थप्दैन
VPN यातायात हो, सदस्य होइन। यसले टाढाको मतदातालाई पुग्नयोग्य बनाउन सक्छ र विभाजनलाई ढिलो टाइमआउटजस्तो देखिने कुरामा बदल्न सक्छ, र क्वोरममा यसको सम्पूर्ण योगदान त्यत्ति नै हो। यसले थप्ने कुरा लागत हो, किनकि प्रत्येक प्रतिबद्धताले लिङ्क पार गर्नुपर्छ र etcd raft लगलाई छुने लेखनमा त्यो आउ-जाउ तिर्छ। हल्लिने बाटोले प्रतिकृतिलाई पुनः प्रयास र निर्वाचनमा बदल्छ।
विभाजन त्यो ठाउँ हो जहाँ मानिसहरू जादू अपेक्षा गर्छन्, त्यसैले तिनीहरूबारे सटीक रहनुहोस्। यदि पुरानो नेता एक-मतदाता पक्षमा बसिरहेका बेला लिङ्क खस्छ भने, त्यो पक्ष प्रतिबद्ध गर्न सक्दैन र निर्वाचन समयसीमा सकिएपछि नेता पदबाट हट्छ, जबकि दुई-मतदाता पक्षले प्रतिस्थापक छान्छ। etcd को विफलता मोड गाइड व्यवहार सरल रूपमा वर्णन गर्छ: बहुमत पक्षमा जारी सेवा, अलग गरिएको पक्षमा कुनै दोस्रो लेख्नयोग्य क्लस्टर छैन।
तपाईं कुन अवरोध किन्नुहुन्छ निर्णय गर्नुहोस्
दुई जोड एक वैध डिजाइन हो जब साइट A प्राथमिक हुन्छ र तपाईं स्वीकार गर्नुहुन्छ कि त्यसलाई गुमाउनु भनेको कसैले कारबाही गर्नेसम्म कन्ट्रोल-प्लेन लेखन गुमाउनु हो। यसलाई दोषमा बदल्ने कुरा त्यो निर्णयलाई निहित राख्नु हो। यसलाई रनबुकमा लेख्नुहोस्: तपाईंको कन्ट्रोल प्लेन कुन साइटबाट बाँच्छ, र अर्को साइट 03:00 बजे बन्द हुँदा अपरेटरले के गर्छ।
यदि आवश्यकता त्यसको सट्टा "जुनसुकै साइट विफल हुन सक्छ" हो भने, प्लेसमेन्टले प्रत्येक साइटमा बहुमत राख्नुपर्छ, र दुई साइटमा तीन मतदाताले त्यो गर्न सक्दैनन्। तपाईं या त साँच्चै स्वतन्त्र तेस्रो डोमेन थप्नुहुन्छ — अर्को प्रदायकमा सानो क्षेत्र त्यहाँको मार्ग स्थिर भए काम गर्छ — या अलग etcd सहित दुई क्लस्टरमा विभाजित हुनुहुन्छ र त्यो विभाजनको सञ्चालन लागत स्वीकार गर्नुहुन्छ। कुनै पनि साक्षी छोटो बाटोले यो टार्दैन: etcd मा हल्का मध्यस्थ सदस्य छैन, त्यसैले तेस्रो मतदाता आफ्नै डिस्क, मेमोरी र नेटवर्क आवश्यकतासहितको पूर्ण सदस्य हो। रेखाचित्रमा "साक्षी" लेखिएको बाकस कोर्नाले साक्षी बन्दैन।
क्वोरम सेवा जस्तै होइन
etcd क्वोरमले API सर्भरलाई लेखन स्वीकार गर्न सक्षम राख्छ, र राख्ने त्यत्ति नै हो। लोड ब्यालेन्सरका स्वास्थ्य जाँच, ingress, सुरुङभरि CNI पुग्ने क्षमता, भोल्युम जडान क्षेत्र र अनुप्रयोग प्रतिकृतिलाई प्रत्येकले आफ्नै जवाफ चाहिन्छ। क्लस्टरले सफा बहुमत राख्न सक्छ र तैपनि प्रयोगकर्तालाई उपयोगी केही दिन सक्दैन।
त्यसपछि तपाईंसँग छ भन्ने लाग्ने सदस्यता पुष्टि गर्नुहोस्, किनकि रेखाचित्र सर्छन्:
kubectl -n kube-system get pods -l component=etcd -o wide
kubectl get endpoints kube-apiserver -n default
etcdctl member list -w table
सदस्य सूचीको प्लेसमेन्ट चित्रसँग तुलना गर्नुहोस्। यदि दुई सदस्य एउटै होस्ट वा एउटै र्याकमा हल हुन्छन् भने, गल्ती क्लस्टरमा होइन, चित्रमा छ, र गलत टोपोलोजीवरिपरि आकार बदल्नु त्यही अवरोधको महँगो संस्करण मात्र किन्नु हो।
कुनै पनि तीन-मतदाता डिजाइन स्वीकृत गर्नुअघि चार प्रश्नको जवाफ दिनुहोस्: कति मतदाताले एकैसाथ बिजुली गुमाउँछन्, कुन साइटको हानिले अझै बहुमत छोड्छ, सुरुङ खस्दा नेता कहाँ बस्छ, र बाँचेको साइटले अझै के गर्न सक्छ। तीमध्ये कुनैमा "निश्चित छैन" भन्नुको अर्थ क्लस्टर अझै उच्च उपलब्ध छैन। यी भाग्यमानी तीन मेसिन हुन्।