రెండు సైట్ల 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 రవాణా, సభ్యుడు కాదు. ఇది దూరపు ఓటర్ను చేరుకోగలిగేలా చేయగలదు మరియు విభజనను నెమ్మదిగా కాల మితి లాగా కనిపించే దానిగా మార్చగలదు, కోరమ్కు దాని పూర్తి సహకారం అంతే. ఇది జోడించేది ఖర్చు, ఎందుకంటే ప్రతి కమిట్ లింక్ను దాటాలి మరియు raft లాగ్ను తాకే రచనలలో etcd ఆ రాకపోకను చెల్లిస్తుంది. ఊగిసలాడే మార్గం ప్రతిరూపాన్ని పునర్ ప్రయత్నాలు మరియు ఎన్నికలుగా మారుస్తుంది.
విభజనలు ప్రజలు మాయాజాలం ఆశించే స్థలం, కాబట్టి వాటి గురించి ఖచ్చితంగా ఉండండి. పాత నాయకుడు ఒక-ఓటర్ వైపున కూర్చున్నప్పుడు లింక్ పడిపోతే, ఆ వైపు కమిట్ చేయలేదు మరియు ఎన్నిక కాల మితి ముగిసినప్పుడు నాయకుడు పదవి విరమిస్తాడు, రెండు-ఓటర్ వైపు ప్రత్యామ్నాయుడిని ఎన్నుకుంటుంది. etcd యొక్క వైఫల్య మోడ్ మార్గదర్శిని ప్రవర్తనను స్పష్టంగా వివరిస్తుంది: మెజారిటీ వైపున కొనసాగే సేవ, వేరుచేసిన వైపున రెండో రాయగలిగే క్లస్టర్ లేదు.
మీరు ఏ అంతరాయాన్ని కొంటున్నారో నిర్ణయించుకోండి
సైట్ A ప్రాథమికం అయినప్పుడు మరియు దానిని కోల్పోవడం అంటే ఎవరైనా చర్య తీసుకునే వరకు నియంత్రణ-తల రచనలను కోల్పోవడం అని మీరు అంగీకరించినప్పుడు రెండు ప్లస్ ఒకటి చట్టబద్ధమైన డిజైన్. దానిని లోపంగా మార్చేది ఆ నిర్ణయాన్ని అవ్యక్తంగా వదిలేయడం. దానిని runbookలో రాయండి: మీ నియంత్రణ తలం ఏ సైట్ నుండి తట్టుకుంటుంది, మరియు రెండో సైట్ 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
సభ్యుల జాబితాను ప్లేస్మెంట్ చిత్రంతో పోల్చండి. రెండు సభ్యులు ఒకే హోస్ట్కు లేదా ఒకే ర్యాక్కు పరిష్కరించబడితే, తప్పు క్లస్టర్లో కాదు, చిత్రంలో ఉంది, తప్పు టోపాలజీ చుట్టూ పరిమాణం మార్చడం అదే అంతరాయం యొక్క ఖరీదైన సంస్కరణను మాత్రమే కొంటుంది.
ఏ మూడు-ఓటర్ డిజైన్ను ఆమోదించే ముందు నాలుగు ప్రశ్నలకు సమాధానం ఇవ్వండి: ఎంతమంది ఓటర్లు కలిసి విద్యుత్ కోల్పోతారు, ఏ సైట్ నష్టం ఇంకా మెజారిటీని మిగులుస్తుంది, సొరంగం పడిపోయినప్పుడు నాయకుడు ఎక్కడ కూర్చుంటాడు, తట్టుకున్న సైట్ ఇంకా ఏమి చేయగలదు. వాటిలో దేనికైనా "ఖచ్చితంగా తెలియదు" అంటే క్లస్టర్ ఇంకా అధిక అందుబాటులో లేదు. అవి అదృష్టం ఉన్న మూడు యంత్రాలు.