Kubernetes kümesi oluştururken şu sorular ortaya çıkabilir: Kaç tane çalışan düğümü yapılandırılacak ve hangi türde? Şirket içi bir küme için hangisi daha iyi: birkaç güçlü sunucu satın almak mı yoksa veri merkezinizde bir düzine eski makine mi kullanmak? Bulutta sekiz adet tek çekirdekli örnek mi yoksa iki adet dört çekirdekli örnek mi almak daha iyidir?
Bu soruların cevapları makalede yer alıyor. komutun çevirisinde .
Küme kapasitesi
Genel olarak bir Kubernetes kümesi büyük bir "süper düğüm" olarak düşünülebilir. Toplam hesaplama gücü, kendisini oluşturan tüm düğümlerin güçlerinin toplamıdır.
İstediğiniz küme kapasitesi hedefine ulaşmanın birkaç yolu vardır. Örneğin bir dizi uygulama çok fazla kaynak gerektirdiğinden toplam 8 işlemci çekirdeği ve 32 GB RAM kapasitesine sahip bir kümeye ihtiyacımız var. Ardından, 16 GB belleğe sahip iki düğüm veya 8 GB belleğe sahip dört düğüm, iki dört çekirdekli işlemci veya dört çift çekirdekli işlemci kurabilirsiniz.
Küme oluşturmanın yalnızca iki olası yolu şunlardır:
Her iki seçenek de aynı kapasiteye sahip bir küme oluşturur, ancak alt konfigürasyonda dört küçük düğüm bulunur ve üst konfigürasyonda iki büyük düğüm bulunur.
Hangi seçenek daha iyi?
Bu soruyu cevaplamak için her iki seçeneğin de avantajlarına bakalım. Bunları bir tabloda özetledik.
Birkaç büyük düğüm
Birçok küçük düğüm
Daha kolay küme yönetimi (şirket içi ise)
Sorunsuz otomatik ölçeklendirme
Daha ucuz (eğer şirket içindeyse)
Fiyat biraz farklı (bulutta)
Kaynak yoğun uygulamaları çalıştırabilir
Tam çoğaltma
Kaynaklar daha verimli kullanılır (sistem arka plan programlarına daha az yük bindirilir)
Daha yüksek küme hatası toleransı
Lütfen yalnızca çalışan düğümlerden bahsettiğimizi unutmayın. Ana düğümlerin sayısını ve boyutunu seçmek tamamen farklı bir konudur.
Öyleyse tablodaki her noktayı daha ayrıntılı olarak tartışalım.
İlk seçenek: birkaç büyük düğüm
En uç seçenek, tüm küme kapasitesi için bir çalışan düğümüdür. Yukarıdaki örnekte bu, 16 CPU çekirdeği ve 16 GB RAM'e sahip tek bir çalışan düğüm olacaktır.
Avantajları:
Artı No. 1. Daha kolay yönetim
Birkaç makineyi yönetmek bütün bir filoyu yönetmekten daha kolaydır. Güncellemeleri ve düzeltmeleri kullanıma sunmak daha hızlıdır ve senkronizasyon daha kolaydır. Mutlak sayılarda arıza sayısı da daha azdır.
Yukarıdakilerin hepsinin donanımınız ve sunucularınız için geçerli olduğunu ve bulut örnekleri için geçerli olmadığını lütfen unutmayın.
Bulutta ise durum farklıdır. Burada yönetim bulut servis sağlayıcısı tarafından gerçekleştirilir. Dolayısıyla buluttaki on düğümü yönetmek, bir düğümü yönetmekten çok da farklı değil.
Buluttaki bölmeler arasında trafik yönlendirme ve yük dağıtımı : İnternetten gelen trafik, trafiği düğümlerden birinin bağlantı noktasına ileten ana yük dengeleyiciye gönderilir (NodePort hizmeti, bağlantı noktasını her küme düğümünde 30000-32767 aralığına ayarlar). Kube-proxy tarafından belirlenen kurallar, trafiği düğümden bölmeye yönlendirir. İki düğümdeki on bölmenin nasıl göründüğü şöyle:
Profesyonel #2: Düğüm başına daha az maliyet
Güçlü bir araba daha pahalıdır ancak fiyat artışı mutlaka doğrusal değildir. Başka bir deyişle, 10 GB belleğe sahip on çekirdekli bir sunucu, aynı miktarda belleğe sahip on adet tek çekirdekli sunucudan genellikle daha ucuzdur.
Ancak bu kuralın genellikle bulut hizmetlerinde çalışmadığını unutmayın. Tüm büyük bulut sağlayıcılarının mevcut fiyatlandırma planlarında fiyatlar kapasiteyle birlikte doğrusal olarak artıyor.
Bu nedenle bulutta genellikle daha güçlü sunuculara tasarruf edemezsiniz.
Profesyonel #3: Yoğun kaynak kullanan uygulamaları çalıştırabilirsiniz
Bazı uygulamalar bir kümede güçlü sunucular gerektirir. Örneğin, bir makine öğrenimi sistemi 8 GB bellek gerektiriyorsa, bunu 1 GB'lık düğümlerde çalıştıramazsınız; yalnızca en az bir büyük çalışan düğümle çalıştırabilirsiniz.
Eksileri
1 Numaralı Dezavantaj. Düğüm başına çok sayıda bölme
Aynı görev daha az sayıda düğümde gerçekleştirilirse, doğal olarak her birinin daha fazla bölmesi olacaktır.
Bu bir problem olabilirdi.
Bunun nedeni, her modülün konteyner çalışma zamanına (örneğin Docker) ve ayrıca kubelet ve cAdvisor'a bir miktar yük getirmesidir.
Örneğin bir kubelet, bir düğümdeki tüm konteynerleri hayatta kalma açısından düzenli olarak inceler; ne kadar çok konteyner varsa kubelet'in yapması gereken iş de o kadar fazladır.
CAdvisor, bir düğümdeki tüm kapsayıcılar için kaynak kullanım istatistiklerini toplar ve kubelet bu bilgileri düzenli olarak sorgulayarak bir API aracılığıyla sağlar. Yine, daha fazla kapsayıcı hem cAdvisor hem de kubelet için daha fazla iş anlamına gelir.
Modül sayısının artması sistemi yavaşlatabilir ve hatta güvenilirliğini zayıflatabilir.
Kubernetes deposunda bazı Bir düğümdeki tüm kapsayıcıların düzenli kubelet kontrolleri çok uzun sürdüğü için düğümler Hazır/Hazır Değil durumları arasında geçiş yapar.
Bu nedenle Kubernetes . Düğümün performansına bağlı olarak düğüm başına daha fazla bölme çalıştırabilirsiniz ancak sorun olup olmayacağını veya her şeyin yolunda gidip gitmeyeceğini tahmin etmek zordur. Çalışmayı önceden test etmeye değer.
2 Numaralı Dezavantaj. Çoğaltma sınırlaması
Çok az sayıda düğüm, uygulama çoğaltmasının etkili kapsamını sınırlar. Örneğin, beş kopyası olan ancak yalnızca iki düğümü olan yüksek kullanılabilirliğe sahip bir uygulamanız varsa, uygulamanın etkin çoğaltma derecesi ikiye düşer.
Beş kopya yalnızca iki düğüme dağıtılabilir ve bunlardan biri başarısız olursa aynı anda birden fazla kopya kaldırılır.
Beş veya daha fazla düğümünüz varsa, her kopya ayrı bir düğümde çalışır ve bir düğümün arızalanması en fazla bir kopyanın kaldırılmasına neden olur.
Bu nedenle, yüksek kullanılabilirlik gereksinimleri, kümede belirli bir minimum sayıda düğüm gerektirebilir.
Dezavantaj No. 3. Başarısızlığın daha kötü sonuçları
Az sayıda düğüm olduğunda her hatanın daha ciddi sonuçları olur. Örneğin, yalnızca iki düğümünüz varsa ve bunlardan biri arızalanırsa modüllerinizin yarısı anında kaybolur.
Elbette Kubernetes, iş yükünü başarısız olan düğümden diğerlerine taşıyacaktır. Ancak bunlardan azı varsa, yeterli boş kapasite olmayabilir. Sonuç olarak, başarısız olan düğümü açana kadar bazı uygulamalarınız kullanılamayacaktır.
Dolayısıyla ne kadar çok düğüm olursa donanım arızalarının etkisi o kadar az olur.
Dezavantaj #4: Daha fazla otomatik ölçeklendirme adımı
Kubernetes, bulut altyapısı için mevcut ihtiyaçlarınıza göre otomatik olarak düğüm eklemenize veya kaldırmanıza olanak tanıyan bir küme otomatik ölçeklendirme sistemine sahiptir. Daha büyük düğümlerle otomatik ölçeklendirme daha ani ve hantal hale gelir. Örneğin, iki düğümde ek bir düğüm eklemek küme kapasitesini anında %50 artıracaktır. İhtiyacınız olmasa bile bu kaynaklar için ödeme yapmanız gerekecek.
Dolayısıyla, otomatik küme ölçeklendirmeyi kullanmayı planlıyorsanız düğümler ne kadar küçük olursa, o kadar esnek ve uygun maliyetli ölçeklendirme elde edersiniz.
Şimdi çok sayıda küçük düğümün avantaj ve dezavantajlarına bakalım.
İkinci seçenek: birçok küçük düğüm
Bu yaklaşımın avantajları esas olarak birkaç büyük düğüm içeren karşıt seçeneğin dezavantajlarından kaynaklanmaktadır.
Avantajları:
Pro #1: Başarısızlığın daha az etkisi
Ne kadar çok düğüm olursa, her düğümde o kadar az bölme olur. Örneğin, on düğüm başına yüz modülünüz varsa, her düğümün ortalama on modülü olacaktır.
Bu şekilde, düğümlerden biri arızalanırsa iş yükünün yalnızca %10'unu kaybedersiniz. Muhtemelen yalnızca az sayıda kopya etkilenecek ve genel uygulama çalışır durumda kalacaktır.
Ek olarak, geri kalan düğümler büyük olasılıkla arızalı düğümün iş yükünü karşılamaya yetecek kadar boş kaynağa sahip olacak, böylece Kubernetes bölmeleri serbestçe yeniden planlayabilir ve uygulamalarınız nispeten hızlı bir şekilde işlevsel duruma geri dönecektir.
Profesyonel #2: İyi kopyalama
Yeterli düğüm varsa Kubernetes planlayıcısı tüm replikalara farklı düğümler atayabilir. Bu şekilde, bir düğümün arızalanması durumunda yalnızca bir kopya etkilenecek ve uygulama kullanılabilir durumda kalacaktır.
Eksileri
1 Numaralı Dezavantaj. Kontrol edilmesi zor
Çok sayıda düğümün yönetilmesi daha zordur. Örneğin, her Kubernetes düğümünün diğerleriyle iletişim kurması gerekir, yani bağlantı sayısı ikinci dereceden artar ve tüm bu bağlantıların izlenmesi gerekir.
Kubernetes Controller Manager'daki düğüm denetleyicisi, durumu kontrol etmek için düzenli olarak kümedeki tüm düğümlerin üzerinden geçer; ne kadar çok düğüm olursa, denetleyici üzerindeki yük de o kadar fazla olur.
Etcd veritabanındaki yük de artıyor - her kubelet ve kube-proxy çağrısı vbd'nin nesne güncellemelerini yayınlaması gereken etcd için (API aracılığıyla).
Genel olarak her bir çalışan düğüm, ana düğümlerin sistem bileşenlerine ek yük getirir.
Kubernetes resmi olarak kümeleri destekliyor . Ancak pratikte zaten 500 düğüm var .
Çok sayıda çalışan düğümü yönetmek için daha güçlü ana düğümleri seçmelisiniz. Örneğin kube-up Çalışan düğümlerin sayısına bağlı olarak ana düğüm için doğru VM boyutu. Yani, ne kadar çok çalışan düğüm olursa, ana düğümlerin de o kadar verimli olması gerekir.
Bu spesifik sorunları çözmek için aşağıdaki gibi özel gelişmeler vardır: . Bu sistem, kısıtlamaları atlamanıza ve çok sayıda çalışan düğümden oluşan kümeler oluşturmanıza olanak tanır.
Dezavantaj #2: Daha fazla genel gider.
Kubernetes, her çalışan düğümde bir dizi sistem arka plan programını çalıştırır; bunlara konteyner çalışma zamanı (Docker gibi), kube-proxy ve cAdvisor dahil kubelet dahildir. Birlikte belirli miktarda sabit miktarda kaynak tüketirler.
Çok sayıda küçük düğümünüz varsa, bu ek yükün her düğümdeki oranı daha büyük olur. Örneğin, tek bir düğümdeki tüm sistem arka plan programlarının birlikte 0,1 CPU çekirdeği ve 0,1 GB bellek kullandığını hayal edin. 10 GB belleğe sahip on çekirdekli bir düğümünüz varsa, arka plan programları küme kapasitesinin %1'ini tüketir. Öte yandan, 1 GB belleğe sahip on adet tek çekirdekli düğümde, arka plan programları küme kapasitesinin %10'unu alacaktır.
Böylece ne kadar az düğüm olursa altyapı o kadar verimli kullanılır.
3 Numaralı Dezavantaj. Kaynakların verimsiz kullanımı
Küçük düğümlerde, kalan kaynak parçaları herhangi bir iş yükünün atanamayacağı kadar küçük olduğundan kullanılmadan kalabilirler.
Örneğin, her bir bölme 0,75 GB bellek gerektirir. Her biri 1 GB belleğe sahip on düğümünüz varsa, her düğümde 0,25 GB kullanılmayan bellek bırakarak on bölme çalıştırabilirsiniz.
Bu, tüm kümenin belleğinin %25'inin boşa gittiği anlamına gelir.
10 GB belleğe sahip büyük bir düğümde, bu modüllerden 13'ünü çalıştırabilirsiniz - ve kullanılmayan yalnızca 0,25 GB'lık bir parça olacaktır.
Bu durumda belleğin yalnızca %2,5'i boşa gider.
Böylece kaynaklar daha büyük düğümlerde daha optimum şekilde kullanılır.
Birkaç büyük düğüm mü yoksa çok sayıda küçük düğüm mü?
Peki hangisi daha iyi: bir kümedeki birkaç büyük düğüm mü yoksa çok sayıda küçük düğüm mü? Her zaman olduğu gibi net bir cevap yok. Çoğu uygulama türüne bağlıdır.
Örneğin, bir uygulama 10 GB bellek gerektiriyorsa, daha büyük düğümler bariz bir seçimdir. Ve eğer bir uygulama yüksek kullanılabilirlik için on kat çoğaltma gerektiriyorsa, kopyaları yalnızca iki düğüme yerleştirme riskine pek değmez; kümede en az on düğüm olmalıdır.
Ara durumlarda her seçeneğin avantaj ve dezavantajlarına göre bir seçim yapın. Belki bazı argümanlar sizin durumunuzla diğerlerinden daha alakalı olabilir.
Ve tüm düğümleri aynı boyutta yapmak hiç de gerekli değildir. Hiçbir şey, önce aynı boyuttaki düğümleri denemenizi, ardından onlara farklı boyuttaki düğümleri eklemenizi ve bunları bir kümede birleştirmenizi engellemez. Kubernetes kümesindeki çalışan düğümler tamamen heterojen olabilir. Böylece her iki yaklaşımın avantajlarını birleştirmeyi deneyebilirsiniz.
Tek bir tarif yoktur ve her durumun kendine has nüansları vardır ve gerçeği yalnızca üretim gösterecektir.
Bulut platform ekibi tarafından hazırlanan çeviri .
Kubernetes hakkında daha fazla bilgi: .
Kaynak: habr.com