Not. tercüme: Bu materyal bir eğitim projesinden alınmıştır Kubernetes tabanlı altyapı tasarlarken popüler bir sorunun cevabıdır. Her seçeneğin artıları ve eksilerinin oldukça ayrıntılı açıklamalarının projeniz için en iyi seçimi yapmanıza yardımcı olacağını umuyoruz.
TL; DR: Aynı iş yükü kümesi, birkaç büyük kümede (her kümede çok sayıda iş yükü olacaktır) veya çok sayıda küçük kümede (her kümede az sayıda yük olacak şekilde) çalıştırılabilir.
Aşağıda her yaklaşımın artılarını ve eksilerini değerlendiren bir tablo bulunmaktadır:
Kubernetes'i uygulamaları çalıştırmak için bir platform olarak kullanırken, genellikle küme kurmanın karmaşıklıkları hakkında birkaç temel soru ortaya çıkar:
- Kaç tane küme kullanmalıyım?
- Bunları ne kadar büyük yapmalıyım?
- Her küme neleri içermelidir?
Bu yazıda her yaklaşımın artılarını ve eksilerini analiz ederek tüm bu soruları cevaplamaya çalışacağım.
Bir soru bildirimi
Bir yazılım geliştiricisi olarak muhtemelen birçok uygulamayı aynı anda geliştirip çalıştırıyorsunuz.
Ayrıca bu uygulamaların pek çok örneğinin farklı ortamlarda çalışması muhtemeldir; örneğin bunlar dev, test и dürtme.
Sonuç, tam bir uygulama ve ortam matrisidir:
Uygulamalar ve Ortamlar
Yukarıdaki örnek 3 uygulamayı ve 3 ortamı temsil eder ve sonuçta toplam 9 olası seçenek ortaya çıkar.
Her uygulama örneği, diğerlerinden bağımsız olarak çalışılabilen, bağımsız bir dağıtım birimidir.
Lütfen dikkat: uygulama örneği birçok kişiden oluşabilir BileşenleriÖn uç, arka uç, veritabanı vb. gibi. Bir mikro hizmet uygulaması söz konusu olduğunda örnek, tüm mikro hizmetleri içerecektir.
Sonuç olarak Kubernetes kullanıcılarının birkaç sorusu var:
- Tüm uygulama örnekleri tek bir kümeye mi yerleştirilmelidir?
- Her uygulama örneği için ayrı bir kümeye sahip olmaya değer mi?
- Veya belki de yukarıdaki yaklaşımların bir kombinasyonu kullanılmalıdır?
Kubernetes, kullanıcının yeteneklerini sınırlamayan esnek bir sistem olduğundan, bu seçeneklerin tümü oldukça uygundur.
İşte olası yollardan bazıları:
- büyük bir ortak küme;
- çok sayıda küçük, yüksek düzeyde uzmanlaşmış kümeler;
- uygulama başına bir küme;
- ortam başına bir küme.
Aşağıda gösterildiği gibi, ilk iki yaklaşım seçenekler ölçeğinin zıt uçlarındadır:
Birkaç büyük kümeden (solda) birçok küçük kümeye (sağda)
Genel olarak, bir kümenin düğüm ve bölme toplamı daha fazlaysa diğerinden "daha büyük" olduğu kabul edilir. Örneğin, 10 düğüm ve 100 bölmeden oluşan bir küme, 1 düğüm ve 10 bölmeden oluşan bir kümeden daha büyüktür.
Peki, haydi başlayalım!
1. Büyük bir ortak küme
İlk seçenek, tüm iş yüklerini tek bir kümeye yerleştirmektir:
Büyük bir küme
Bu yaklaşımda küme evrensel olarak kullanılmaktadır. altyapı platformu — ihtiyacınız olan her şeyi mevcut bir Kubernetes kümesinde dağıtmanız yeterlidir.
Kubernetes, her uygulama örneğinin kendi ad alanına sahip olabilmesi için kümenin parçalarının mantıksal olarak birbirinden ayrılmasına olanak tanır.
Bu yaklaşımın artılarına ve eksilerine bakalım.
+ Kaynakların verimli kullanımı
Tek bir kümeyle Kubernetes kümesini çalıştırmak ve yönetmek için gereken tüm kaynakların yalnızca bir kopyasına ihtiyacınız olur.
Örneğin bu durum ana düğümler için geçerlidir. Genellikle her Kubernetes kümesinde 3 ana düğüm bulunur, dolayısıyla tek bir küme için sayıları bu şekilde kalacaktır (karşılaştırma için 10 kümenin 30 ana düğüme ihtiyacı olacaktır).
Yukarıdaki incelik aynı zamanda yük dengeleyiciler, Giriş denetleyicileri, kimlik doğrulama, günlük kaydı ve izleme sistemleri gibi kümenin tamamında çalışan diğer hizmetler için de geçerlidir.
Tek bir kümede, tüm bu hizmetler tüm iş yükleri için aynı anda kullanılabilir (birden fazla kümede olduğu gibi bunların kopyalarını oluşturmaya gerek yoktur).
+ Ucuz
Yukarıdakilerin bir sonucu olarak, daha az küme genellikle daha ucuzdur çünkü genel giderler yoktur.
Bu özellikle, nasıl barındırıldıklarına (şirket içi veya bulutta) bakılmaksızın önemli miktarda paraya mal olabilen ana düğümler için geçerlidir.
Yönetilen Kubernetes hizmetlerinden bazıları: veya , kontrol katmanını ücretsiz sağlayın. Bu durumda maliyet sorunu daha az ciddidir.
Ayrıca her Kubernetes kümesinin çalışması için sabit bir ücret talep eden yönetilen hizmetler de vardır (örneğin, ).
+ Verimli yönetim
Bir kümeyi yönetmek, birkaç kümeyi yönetmekten daha kolaydır.
Yönetim aşağıdaki görevleri içerebilir:
- Kubernetes sürüm güncellemesi;
- bir CI/CD hattının kurulması;
- CNI eklentisinin kurulması;
- bir kullanıcı kimlik doğrulama sisteminin kurulması;
- bir erişim denetleyicisinin kurulumu;
Ve bircok digerleri…
Tek küme durumunda tüm bunları yalnızca bir kez yapmanız gerekecektir.
Birçok küme için operasyonların birçok kez tekrarlanması gerekecek ve bu da süreçte tutarlılık ve tutarlılık sağlamak için muhtemelen süreçlerin ve araçların bir miktar otomasyonunu gerektirecektir.
Ve şimdi eksileri hakkında birkaç söz.
− Tek arıza noktası
Reddetme durumunda tek küme hemen çalışmayı durduracak tüm iş yükleri!
İşlerin ters gitmesinin birçok yolu vardır:
- Kubernetes'in güncellenmesi beklenmeyen yan etkilere yol açar;
- Küme çapındaki bir bileşen (örneğin, bir CNI eklentisi) beklendiği gibi çalışmamaya başlar;
- küme bileşenlerinden biri doğru yapılandırılmamış;
- Temel altyapıdaki başarısızlık.
Böyle bir olay, paylaşılan bir kümede barındırılan tüm iş yüklerinde ciddi hasara neden olabilir.
− Sert izolasyon yok
Paylaşılan bir kümede çalışmak, uygulamaların küme düğümlerindeki donanımı, ağ özelliklerini ve işletim sistemini paylaştığı anlamına gelir.
Bir bakıma, aynı düğümde çalışan iki farklı uygulamaya sahip iki kapsayıcı, aynı işletim sistemi çekirdeğini çalıştıran aynı makinede çalışan iki işlem gibidir.
Linux kapsayıcıları bir tür izolasyon sağlar, ancak bu, örneğin sanal makinelerin sağladığı kadar güçlü değildir. Temelde, bir kaptaki bir işlem, ana bilgisayar işletim sisteminde çalışan işlemin aynısıdır.
Bu bir güvenlik sorunu olabilir: Bu düzenleme teorik olarak ilgisiz uygulamaların birbirleriyle (kasıtlı veya kazara) iletişim kurmasına olanak tanır.
Ayrıca bir Kubernetes kümesindeki tüm iş yükleri, aşağıdakiler gibi küme çapındaki bazı hizmetleri paylaşır: - bu, uygulamaların kümedeki diğer uygulamaların Hizmetlerini bulmasına olanak tanır.
Yukarıdaki hususların tümü, uygulamanın güvenlik gereksinimlerine bağlı olarak farklı anlamlara sahip olabilir.
Kubernetes, aşağıdaki gibi güvenlik sorunlarını önlemek için çeşitli araçlar sağlar: и . Ancak bunları doğru şekilde kurmak biraz tecrübe gerektirir, ayrıca tüm güvenlik açıklarını kesinlikle kapatamazlar.
Kubernetes'in orijinal olarak tasarlandığını her zaman hatırlamak önemlidir. paylaşım, değil izolasyon ve güvenlik.
− Kesin çoklu kiracılığın olmaması
Bir Kubernetes kümesindeki paylaşılan kaynakların bolluğu göz önüne alındığında, farklı uygulamaların birbirinin ayağına basmasının birçok yolu vardır.
Örneğin, bir uygulama paylaşılan bir kaynağı (CPU veya bellek gibi) tekeline alabilir ve aynı düğümde çalışan diğer uygulamaların bu kaynağa erişimini engelleyebilir.
Kubernetes bu davranışı kontrol etmek için çeşitli mekanizmalar sağlar: (ayrıca “makaleye bakın)" - yakl. çeviri.), и . Bununla birlikte, güvenlik durumunda olduğu gibi, konfigürasyonları oldukça önemsizdir ve öngörülemeyen tüm yan etkileri kesinlikle önleyemezler.
− Çok sayıda kullanıcı
Tek bir küme olması durumunda, onu birçok kişiye erişime açmanız gerekir. Ve sayıları ne kadar fazla olursa, bir şeyi "kırma" riski de o kadar yüksek olur.
Küme içinde kimin ne yapabileceğini kontrol edebilirsiniz. (bkz. makale “" - yakl. çeviri.). Ancak kullanıcıların kendi sorumluluk alanları dahilindeki bir şeyi “kırmasına” engel olmayacaktır.
− Kümeler süresiz olarak büyüyemez
Tüm iş yükleri için kullanılan küme muhtemelen oldukça büyük olacaktır (düğüm ve bölme sayısı açısından).
Ancak burada başka bir sorun ortaya çıkıyor: Kubernetes'teki kümeler süresiz olarak büyüyemez.
Küme boyutunda teorik bir sınır vardır. Kubernetes'te bu yaklaşık olarak .
Ancak gerçek hayatta sorunlar çok daha erken başlayabilir - örneğin .
Gerçek şu ki, büyük kümeler Kubernetes kontrol katmanına büyük bir yük getiriyor. Başka bir deyişle, kümeyi verimli bir şekilde çalışır durumda tutmak dikkatli ayarlama gerektirir.
Bu konu, orijinal blogdaki "'.
Ancak tam tersi yaklaşımı ele alalım: birçok küçük küme.
2. Birçok küçük, uzmanlaşmış küme
Bu yaklaşımla dağıttığınız her öğe için ayrı bir küme kullanırsınız:
Birçok küçük küme
Bu makalenin amaçları doğrultusunda, konuşlandırılabilir öğe bir uygulamanın örneğini, örneğin ayrı bir uygulamanın geliştirme sürümünü ifade eder.
Bu strateji, Kubernetes'i uzmanlaşmış bir araç olarak kullanıyor Çalışma süresi bireysel uygulama örnekleri için.
Bu yaklaşımın artılarına ve eksilerine bakalım.
+ Sınırlı "patlama yarıçapı"
Bir küme başarısız olduğunda olumsuz sonuçlar yalnızca o kümede dağıtılan iş yükleriyle sınırlıdır. Diğer tüm iş yüklerine dokunulmaz.
+ Yalıtım
Bireysel kümelerde barındırılan iş yükleri işlemci, bellek, işletim sistemi, ağ veya diğer hizmetler gibi kaynakları paylaşmaz.
Sonuç, ilgisiz uygulamalar arasında sıkı bir izolasyondur ve bu da güvenlik açısından faydalı olabilir.
+ Az sayıda kullanıcı
Her kümenin yalnızca sınırlı sayıda iş yükü içerdiği göz önüne alındığında, kümeye erişimi olan kullanıcı sayısı azalır.
Kümeye ne kadar az kişi erişebilirse, bir şeyin "kırılma" riski de o kadar düşük olur.
Eksilerine bakalım.
− Kaynakların verimsiz kullanımı
Daha önce de belirtildiği gibi, her Kubernetes kümesi belirli bir yönetim kaynakları kümesi gerektirir: ana düğümler, kontrol katmanı bileşenleri, izleme ve günlük kaydı çözümleri.
Çok sayıda küçük kümelenme olması durumunda, kaynakların daha büyük bir kısmının yönetime tahsis edilmesi gerekmektedir.
− Pahalı
Kaynakların verimsiz kullanımı otomatik olarak yüksek maliyetlere yol açar.
Örneğin, aynı bilgi işlem gücüne sahip üç yerine 30 ana düğümün sürdürülmesi mutlaka maliyetleri etkileyecektir.
− Yönetimdeki zorluklar
Birden fazla Kubernetes kümesini yönetmek, tek bir kümeyi yönetmekten çok daha zordur.
Örneğin, her küme için kimlik doğrulama ve yetkilendirmeyi yapılandırmanız gerekecektir. Kubernetes sürümünün de birkaç kez güncellenmesi gerekecek.
Tüm bu görevleri daha verimli hale getirmek için muhtemelen otomasyonu kullanmanız gerekecektir.
Şimdi daha az ekstrem senaryolara bakalım.
3. Uygulama başına bir küme
Bu yaklaşımda belirli bir uygulamanın tüm örnekleri için ayrı bir küme oluşturursunuz:
Uygulama başına küme
Bu yol “ ilkesinin bir genellemesi olarak değerlendirilebilir.takım başına ayrı küme”, çünkü genellikle bir mühendis ekibi bir veya daha fazla uygulama geliştiriyor.
Bu yaklaşımın artılarına ve eksilerine bakalım.
+ Küme uygulamaya göre ayarlanabilir
Bir uygulamanın özel ihtiyaçları varsa, diğer kümeleri etkilemeden bir kümede uygulanabilirler.
Bu tür ihtiyaçlar GPU çalışanlarını, belirli CNI eklentilerini, bir hizmet ağını veya başka bir hizmeti içerebilir.
Her küme, içinde çalışan uygulamaya göre yalnızca ihtiyaç duyulanları içerecek şekilde özelleştirilebilir.
− Bir kümede farklı ortamlar
Bu yaklaşımın dezavantajı, farklı ortamlardaki uygulama örneklerinin aynı kümede bir arada bulunmasıdır.
Örneğin, uygulamanın üretim sürümü, geliştirme sürümüyle aynı kümede çalışır. Bu aynı zamanda geliştiricilerin uygulamanın üretim sürümünün çalıştırıldığı kümede çalıştığı anlamına da gelir.
Geliştiricilerin eylemleri veya geliştirici sürümündeki aksaklıklar nedeniyle kümede bir arıza meydana gelirse, prod sürümü de potansiyel olarak zarar görebilir; bu, bu yaklaşımın büyük bir dezavantajıdır.
Ve son olarak listemizdeki son senaryo.
4. Ortam başına bir küme
Bu senaryo, her ortam için ayrı bir kümenin tahsis edilmesini içerir:
Ortam başına bir küme
Örneğin, kümeleriniz olabilir dev, test и dürtmeuygulamanın belirli bir ortama ayrılmış tüm örneklerini çalıştıracağınız.
İşte bu yaklaşımın artıları ve eksileri.
+ Ürün ortamının izolasyonu
Bu yaklaşımda tüm ortamlar birbirinden izole edilmiştir. Ancak pratikte bu, üretim ortamında özellikle önemlidir.
Uygulamanın üretim sürümleri artık diğer kümelerde ve ortamlarda olup bitenlerden bağımsızdır.
Bu sayede dev kümesinde aniden bir sorun çıkması durumunda uygulamaların prod sürümleri hiçbir şey olmamış gibi çalışmaya devam edecektir.
+ Küme ortama göre ayarlanabilir
Her küme kendi ortamına göre ayarlanabilir. Örneğin şunları yapabilirsiniz:
- geliştirme kümesinde geliştirme ve hata ayıklama için araçlar yükleyin;
- kümeye test çerçeveleri ve araçları yükleyin test;
- kümede daha güçlü donanım ve ağ kanalları kullanın dürtme.
Bu, hem uygulama geliştirmenin hem de operasyonun verimliliğini artırmanıza olanak tanır.
+ Üretim kümesine erişimi kısıtlama
Bir ürün kümesiyle doğrudan çalışma ihtiyacı nadiren ortaya çıkar, böylece ona erişimi olan kişilerin çevresini önemli ölçüde sınırlayabilirsiniz.
Daha da ileri giderek kişilerin bu kümeye erişimini tamamen reddedebilir ve tüm dağıtımları otomatik bir CI/CD aracı kullanarak gerçekleştirebilirsiniz. Böyle bir yaklaşım, insan hatası riskini tam da en alakalı olduğu yerde en aza indirecektir.
Ve şimdi eksileri hakkında birkaç söz.
− Uygulamalar arasında izolasyon yok
Yaklaşımın temel dezavantajı uygulamalar arasında donanım ve kaynak yalıtımının olmamasıdır.
İlgisiz uygulamalar küme kaynaklarını paylaşır: sistem çekirdeği, işlemci, bellek ve diğer bazı hizmetler.
Daha önce de belirtildiği gibi, bu potansiyel olarak tehlikeli olabilir.
− Uygulama bağımlılıklarının yerelleştirilememesi
Bir uygulamanın özel gereksinimleri varsa, bu gereksinimlerin tüm kümelerde karşılanması gerekir.
Örneğin, bir uygulama GPU gerektiriyorsa her kümenin GPU'lu en az bir çalışan içermesi gerekir (yalnızca o uygulama tarafından kullanılsa bile).
Sonuç olarak, daha yüksek maliyetler ve kaynakların verimsiz kullanımı riskiyle karşı karşıya kalıyoruz.
Sonuç
Belirli bir uygulama grubunuz varsa, bunlar birkaç büyük kümeye veya birçok küçük kümeye yerleştirilebilir.
Makale, tek bir küresel kümelenmeden birkaç küçük ve son derece uzmanlaşmış yaklaşıma kadar çeşitli yaklaşımların artılarını ve eksilerini tartışıyor:
- büyük bir genel küme;
- çok sayıda küçük, yüksek düzeyde uzmanlaşmış kümeler;
- uygulama başına bir küme;
- ortam başına bir küme.
Peki hangi yaklaşımı izlemelisiniz?
Her zaman olduğu gibi, cevap kullanım durumuna bağlıdır: farklı yaklaşımların artılarını ve eksilerini tartmanız ve en uygun seçeneği seçmeniz gerekir.
Ancak seçim yukarıdaki örneklerle sınırlı değildir; bunların herhangi bir kombinasyonunu kullanabilirsiniz!
Örneğin, her takım için birkaç küme düzenleyebilirsiniz: bir geliştirme kümesi (içinde ortamların bulunacağı) dev и test) ve küme için üretim (üretim ortamının bulunacağı yer).
Bu makaledeki bilgilere dayanarak belirli bir senaryoya göre artıları ve eksileri optimize edebilirsiniz. İyi şanlar!
PS
Blogumuzda da okuyun:
- «";
- «";
- «";
- «'.
Kaynak: habr.com