दोन साइटच्या 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
सदस्य यादीची प्लेसमेंट चित्राशी तुलना करा। जर दोन सदस्य एकाच होस्टवर किंवा एकाच रॅकवर सोडवले गेले, तर चूक क्लस्टरमध्ये नाही, चित्रात आहे, आणि चुकीच्या टोपोलॉजीभोवती आकार बदलणे त्याच खंडाची फक्त महाग आवृत्ती विकत घेते।
कोणतीही तीन-मतदार रचना मंजूर करण्यापूर्वी चार प्रश्नांची उत्तरे द्या: किती मतदार एकत्र वीज गमावतात, कोणत्या साइटच्या गमावणीने अजूनही बहुमत राहते, बोगदा पडल्यावर नेता कुठे बसतो, आणि वाचलेली साइट अजून काय करू शकते। त्यांपैकी कोणत्याही एकावर "निश्चित नाही" म्हणजे क्लस्टर अजून उच्च उपलब्ध नाही। ही नशीबवान तीन यंत्रे आहेत।