کیا دو سائٹس والے 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
ارکان کی فہرست کا پلیسمنٹ خاکے سے موازنہ کریں۔ اگر دو ارکان ایک ہی ہوسٹ یا ایک ہی ریک پر حل ہوں، تو غلط خاکہ ہے، کلسٹر نہیں، اور غلط ٹوپولوجی کے گرد سائز بدلنا اسی رکاوٹ کا صرف مہنگا نسخہ خریدتا ہے۔
کسی بھی تین ووٹر ڈیزائن کی منظوری سے پہلے چار سوالوں کے جواب دیں: کتنے ووٹرز ایک ساتھ بجلی کھوتے ہیں، کس سائٹ کے جانے پر اب بھی اکثریت بچتی ہے، سرنگ گرنے پر رہنما کہاں بیٹھتا ہے، اور بچی ہوئی سائٹ اب بھی کیا کر سکتی ہے۔ ان میں سے کسی پر بھی "یقین نہیں" کا مطلب ہے کہ کلسٹر ابھی اعلیٰ دستیاب نہیں۔ یہ تین مشینیں ہیں جن کی قسمت اچھی رہی۔