İki siteli bir Kubernetes kümesinin üç etcd seçicisine ihtiyacı var mı?

Üç kontrol düzlemi VM'i kötü bir geceden sağ çıkmanın üç şansı gibi görünür. Değiller ve bu iki inanç arasındaki mesafe, düzenli bir üç düğümlü tasarımı bir bina elektrik kaybettiğinde yazma kabul etmeyi durduran bir kümeye dönüştürür. Siteler arasındaki VPN bağlantısı makineleri birbirine erişilebilir kılar ve sorunu çözmek yerine gizler. Oylar her etcd üyesi başına sayılır ve bu üyelerden ikisi hâlâ tek bir anahtar, tek bir UPS ve tek bir hat arkasında oturabilir.

Üç kontrol düzlemi düğümü, tek bir arıza alanı

kubectl get nodes çalıştırırsınız, üç kontrol düzlemi girdisi görürsünüz ve kümeyi yüksek erişilebilir olarak kaydedersiniz. Bu sayı planlanabilir kapasiteyi anlatır, hayatta kalmayı değil. Harici etcd olmadan tutulan kubeadm'de her kontrol düzlemi düğümü bir üyeyi de barındırır, yani üç düğüm gerçekten üç seçici verir. Bu seçicilerin bağımsız arızalanıp arızalanmadığı, düğüm listesinin yanıtlayamadığı ayrı bir sorudur.

Tek hipervizörde iki VM, tek güç kaynağında iki raf, tek ISP'den iki hat: her çift iki ana makine adı takan tek bir alandır. Yerleşimi yazın ve her seçicinin neyi paylaştığını işaretleyin — hipervizör, PDU, rafın üstündeki anahtar, depolama dizisi, NAT aygıtı, VPN yoğunlaştırıcı. Sonra kâğıt üzerinde paylaşılan her nesneyi kaldırın ve kalan oyları yeniden sayın. Tek bir başarısız ana makine yüzünden iki seçici kaybeden küme baştan beri tek seçicili bir kümedir; kimse ona bunu henüz sormamıştı.

İki site bölünmesinin dayanabildiği ve dayanamadığı şeyler

Üç seçici iki ve bir olarak iki siteye yerleştirildiğinde, diğer site kaybolduğunda büyük taraf çoğunluğu korur ve tek seçicili taraf asla korumaz. Bu asimetri aritmetiktir, ayar değil. Tam olarak iki bağımsız siteye yayılan çoğunluk tabanlı her etcd kümesi "herhangi bir siteyi kaybet ve işlemeye devam et" testinde başarısız olur, çünkü iki taraf aynı anda oyların yarısından fazlasını tutmak zorunda kalırdı.

Aşağıdaki tablo, hangi arızaları gerçekten satın aldığınızı görmenin en hızlı yoludur. Her satırı şöyle okuyun: bu gece bu satırın tamamı kaybolursa, hayatta kalanlar hâlâ bir yazmayı işleyebilir mi?

Tünel neden asla oy eklemez

VPN bir taşımadır, üye değil. Uzak bir seçiciyi erişilebilir kılabilir ve bir bölünmeyi yavaş bir zaman aşımı gibi görünen bir şeye çevirebilir ve çoğunluğa katkısı bundan ibarettir. Eklediği şey maliyettir, çünkü her işleme bağlantıyı geçmek zorundadır ve etcd raft günlüğüne dokunan yazmalarda bu gidiş dönüşü öder. Titreyen bir yol, çoğaltmayı yeniden denemelere ve seçimlere çevirir.

Bölünmeler insanların sihir beklediği yerdir, bu yüzden onlar hakkında kesin olun. Bağlantı düşerken eski lider tek seçicili tarafta oturuyorsa, o taraf işleyemez ve seçim zaman aşımı dolunca lider çekilir; iki seçicili taraf ise bir yedek seçer. etcd'nin arıza modları rehberi davranışı açıkça anlatır: çoğunluk tarafında süren hizmet, yalıtılmış tarafta ikinci bir yazılabilir küme yok.

Hangi kesintiyi satın aldığınıza karar verin

İki artı bir, Site A birincil olduğunda ve onu kaybetmenin biri harekete geçene kadar kontrol düzlemi yazmalarını kaybetmek anlamına geldiğini kabul ettiğinizde meşru bir tasarımdır. Bunu bir kusura çeviren şey, bu kararı örtük bırakmaktır. Runbook'a yazın: kontrol düzleminizin hangi siteden hayatta kaldığı ve diğer site 03:00'te kapandığında operatörün ne yaptığı.

Gereksinim bunun yerine "herhangi bir site başarısız olabilir" ise, yerleşim her sitede çoğunluğu tutmalıdır ve iki sitede üç seçici bunu yapamaz. Ya gerçekten bağımsız üçüncü bir alan eklersiniz — başka bir sağlayıcıdaki küçük bir bölge, oraya giden yol kararlıysa işe yarar — ya da ayrı etcd ile iki kümeye bölünür ve bu bölünmenin işletme maliyetini kabul edersiniz. Hiçbir tanık kısayolu bunu önlemez: etcd'de hafif bir hakem üyesi yoktur, bu yüzden üçüncü seçici kendi disk, bellek ve ağ gereksinimleri olan tam bir üyedir. Diyagrama "tanık" etiketli bir kutu çizmek tanık yaratmaz.

Çoğunluk hizmetle aynı şey değildir

etcd çoğunluğu API sunucusunu yazma kabul edebilir durumda tutar ve tuttuğu tek şey budur. Yük dengeleyicinin sağlık kontrolleri, ingress, tünel üzerinden CNI erişilebilirliği, birim bağlama bölgeleri ve uygulama çoğaltması her birinin kendi yanıtına ihtiyacı vardır. Bir küme temiz bir çoğunluğa sahip olabilir ve yine de kullanıcılara yararlı hiçbir şey sunmayabilir.

Sonra sahip olduğunuzu düşündüğünüz üyeliği doğrulayın, çünkü diyagramlar kayar:

kubectl -n kube-system get pods -l component=etcd -o wide
kubectl get endpoints kube-apiserver -n default
etcdctl member list -w table

Üye listesini yerleşim çizimiyle karşılaştırın. İki üye aynı ana makineye veya aynı rafa çözülüyorsa yanlış olan küme değil çizimdir ve yanlış topolojinin etrafında boyut değiştirmek aynı kesintinin yalnızca daha pahalı sürümünü satın alır.

Herhangi bir üç seçicili tasarımı onaylamadan önce dört soruyu yanıtlayın: kaç seçici birlikte elektrik kaybeder, hangi sitenin kaybı hâlâ çoğunluk bırakır, tünel düştüğünde lider nerede oturur ve hayatta kalan site hâlâ ne yapabilir. Bunlardan herhangi birinde "emin değilim" demek, kümenin henüz yüksek erişilebilir olmadığı anlamına gelir. Bunlar şansı yaver gitmiş üç makinedir.