آیا خوشه Kubernetes در دو سایت به سه رأی‌دهنده etcd نیاز دارد؟
سه گره صفحه کنترل در دو سایت VPN هنوز هم وقتی سایت بزرگ‌تر خاموش می‌شود، حد نصاب را از دست می‌دهند. رأی‌دهندگان واقعی etcd را بشمارید و شکستی را انتخاب کنید که از آن جان سالم به در می‌برید.
سه ماشین مجازی صفحه کنترل مانند سه شانس برای زنده ماندن از یک شب بد به نظر می‌رسند. اما نیستند، و فاصله میان این دو باور همان چیزی است که طراحی مرتب سه گره را به خوشه‌ای تبدیل می‌کند که وقتی یک ساختمان برق را از دست می‌دهد، از پذیرش نوشتن بازمی‌ماند. پیوند VPN میان سایت‌ها ماشین‌ها را از یکدیگر در دسترس می‌کند و مشکل را به جای حل کردن پنهان می‌کند. رأی‌ها به ازای هر عضو etcd شمرده می‌شوند، و دو عضو از آن‌ها هنوز می‌توانند پشت یک سوئیچ، یک یو پی اس و یک خط ارتباطی بنشینند.
سه گره صفحه کنترل، یک دامنه خرابی
شما kubectl get nodes را اجرا می‌کنید، سه ورودی صفحه کنترل می‌بینید و خوشه را در دسته دسترس‌پذیری بالا ثبت می‌کنید. آن شمارش ظرفیت قابل زمان‌بندی را توصیف می‌کند، نه بقا را. در kubeadm که بدون etcd بیرونی نگه داشته می‌شود، هر گره صفحه کنترل نیز میزبان یک عضو است، پس سه گره واقعاً سه رأی‌دهنده به شما می‌دهد. اینکه آیا این رأی‌دهندگان به طور مستقل شکست می‌خورند، پرسشی جداست که فهرست گره‌ها نمی‌تواند پاسخ دهد.
دو ماشین مجازی روی یک هایپروایزر، دو رک روی یک منبع برق، دو خط ارتباطی از یک ISP: هر جفت یک دامنه واحد است که دو نام میزبان می‌پوشد. چیدمان را بنویسید و علامت بزنید هر رأی‌دهنده چه چیزی را مشترک دارد — هایپروایزر، واحد توزیع برق، سوئیچ بالای رک، آرایه ذخیره‌سازی، دستگاه 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 اصلی است و می‌پذیرید که از دست دادنش یعنی از دست دادن نوشتن‌های صفحه کنترل تا زمانی که کسی اقدام کند. آنچه آن را به نقص تبدیل می‌کند ضمنی گذاشتن آن تصمیم است. آن را در 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
فهرست اعضا را با نقشه چیدمان مقایسه کنید. اگر دو عضو به یک میزبان یا یک رک یکسان برسند، نقشه اشتباه است نه خوشه، و تغییر اندازه پیرامون توپولوژی اشتباه فقط نسخه گران‌تر همان قطعی را می‌خرد.
پیش از تأیید هر طراحی سه رأی‌دهنده، به چهار پرسش پاسخ دهید: چند رأی‌دهنده با هم برق را از دست می‌دهند، از دست رفتن کدام سایت هنوز اکثریت باقی می‌گذارد، رهبر وقتی تونل قطع می‌شود کجا می‌نشیند، و سایت بازمانده هنوز چه می‌تواند بکند. «مطمئن نیستم» در هر یک از آن‌ها یعنی خوشه هنوز در دسترس‌پذیری بالا نیست. این سه ماشین است که شانس آورده‌اند.