Bu sayfadaki topoloji genel bir referans mimaridir, belirli bir müşteri kurulumu değildir. Sizin mimariniz iş yükünüze, mevzuat gereksinimlerinize ve mevcut ortamınıza göre birlikte belirlenir.
Topoloji
Kesikli çizgiler control plane ile worker node'lar arasındaki yönetim trafiğini gösterir; uygulama trafiği load balancer üzerinden akar.
Neden üç control plane
Control plane, cluster'ın karar veren katmanı. Hangi pod'un hangi node'da çalışacağını o belirliyor, durumu izliyor ve sapma gördüğünde düzeltiyor. Tek control plane'li bir cluster, çalışan uygulamalar açısından bir süre ayakta kalır ama artık kendini onaramaz: yeni dağıtım yapılamaz, düşen pod yerine yenisi açılmaz.
Sayının üç olmasının sebebi etcd'nin çoğunluk esasına göre çalışması. Üç düğümlü bir kümede biri düştüğünde kalan ikisi çoğunluğu oluşturuyor ve küme karar vermeye devam ediyor. İki düğümlü bir kurulumda biri düştüğünde çoğunluk kalmıyor, yani iki düğüm tek düğümden daha dayanıklı olmuyor. Bu yüzden üretimde alt sınır pratikte üç.
Önündeki load balancer, üç control plane'i tek bir adres arkasında topluyor. Biri devre dışı kaldığında istekler diğerlerine yönleniyor ve bu geçiş uygulamalar açısından görünmez oluyor.
etcd neden ayrı ele alınıyor
etcd, cluster'ın tüm durumunu tutan dağıtık veri deposu. Hangi deployment'ın olduğu, hangi ayarın nerede durduğu, hangi gizli bilginin tanımlandığı orada. Cluster'ın hafızası odur ve kaybedilirse cluster yeniden kurulamaz.
En sık yaptığımız uyarı şu: uygulama verisinin yedeği ile cluster durumunun yedeği aynı iş değil. İkisini aynı işlemin parçası saymak yaygın bir hata; uygulama verisi geri gelse bile cluster durumu gelmezse kurtarma yarım kalıyor. Bu yüzden etcd yedeğini ayrı alıyor ve ayrı doğruluyoruz. Nedenini ve nasıl yaptığımızı etcd yedekleme ve kurtarma yazısında ölçümlerle anlattık.
Node havuzları neden ayrılıyor
Diyagramdaki iki havuz bilinçli. Genel havuz uygulama iş yüklerini taşıyor ve yük arttıkça yatay ölçekleniyor. Ayrılmış havuz ise veri tabanı gibi gecikmeye duyarlı bileşenler için ayrılıyor; buradaki kaynaklar diğer iş yükleriyle paylaşılmıyor.
Ayrımın sebebi komşu etkisi. Ölçeklenen bir uygulama aniden bellek ve işlemci tüketmeye başladığında, aynı node'daki veri tabanının yanıt süresi bundan etkileniyor. Kaynak limitleri bu etkiyi sınırlıyor ama tamamen ortadan kaldırmıyor; ayrı havuz kaldırıyor.
Ölçeklemenin nasıl kurulduğunu auto-scaling ve self-healing sayfasında, cluster yönetiminin kapsamını Kubernetes cluster yönetimi sayfasında bulabilirsiniz.
Bu topolojinin sınırları
Yüksek erişilebilirlik, her arızaya karşı bağışıklık anlamına gelmiyor. Bu topoloji donanım arızasına ve tek düğüm kaybına karşı koruyor. Korumadığı üç şey var ve bunları baştan söylemek gerekiyor.
Uygulama hatası. Hatalı bir dağıtım üç control plane'in olduğu bir cluster'da da üretimi durdurur. Kubernetes yanlış çalışan bir uygulamayı düzeltmez, yalnızca çalışmayan bir pod'u yeniden başlatır. Sürekli çöküp yeniden başlayan bir pod, sağlıklı görünen bir cluster'da saatlerce dönebilir.
Mantıksal veri kaybı. Silinen bir kayıt ya da bozulan bir tablo, yedeklilik sayesinde tüm kopyalara yayılır. Bu topoloji veri bütünlüğünü korumaz; onun için yedekleme ve felaket kurtarma topolojisi gerekiyor.
Ortamın tamamının kaybı. Cluster tek bir konumdaysa, o konumu etkileyen bir olayda yedeklilik işe yaramıyor. İkinci bir konum gerektiğinde konu artık yüksek erişilebilirlik değil, felaket kurtarma oluyor.
Bir de gerekmediği durum var: tek bir uygulama ve tek bir veri tabanı çalıştırıyorsanız bu topoloji çözdüğü sorundan fazla işletim yükü getiriyor. Ne zaman gerekli olduğunu Kubernetes nedir sayfasında açtık.
Yükseltme sırası
Bu topolojinin en büyük kazancı, sürüm yükseltmesinin kesintisiz yapılabilmesi. Sıra şöyle işliyor: önce control plane düğümleri teker teker yükseltiliyor, her adımda kümenin sağlığı doğrulanıyor. Ardından worker node'lar sırayla boşaltılıp yükseltiliyor; boşaltılan node'un iş yükleri diğerlerinde çalışmaya devam ediyor.
Bu sıranın tersine dönmesi ya da adımların paralel yürütülmesi, kesinti riskinin en yüksek olduğu senaryo. Adım adım nasıl yürüttüğümüzü ve nerede neyin ters gidebileceğini sürüm yükseltme yazımızda anlattık. Kavramların kısa tanımları Kubernetes nedir sayfasında.
Diğer topolojiler için referans mimariler sayfasına dönebilirsiniz.
Bu topolojinin kurulması bir günlük iş, işletilmesi sürekli bir iş. Sertifika yenileme, kaynak limitlerinin gözden geçirilmesi, etcd yedeğinin doğrulanması ve sürüm takvimi bir süre bırakıldığında cluster sessizce çürüyor ve bu genelde ilk arızada fark ediliyor. Yönetimi bize bırakmak isterseniz kapsam Kubernetes cluster yönetimi sayfasında, container düzeyinde tam yönetilen seçenek Container as a Service sayfasında.