Küp üzerinde küp, metakümeler, petekler, kaynak dağıtımı

Pirinç. 1. Alibaba Cloud'daki Kubernetes ekosistemi

Kubernetes için Alibaba Bulut Konteyner Hizmeti (ACK), 2015 yılından bu yana Alibaba Bulut'ta en hızlı büyüyen bulut hizmetlerinden biri oldu. Çok sayıda müşteriye hizmet veriyor ve aynı zamanda Alibaba'nın dahili altyapısını ve şirketin diğer bulut hizmetlerini de destekliyor.

Birinci sınıf bulut sağlayıcılarının benzer konteyner hizmetlerinde olduğu gibi, en önemli önceliklerimiz güvenilirlik ve kullanılabilirliktir. Bu sayede onbinlerce Kubernetes kümesi için ölçeklenebilir ve küresel olarak erişilebilir bir platform oluşturuldu.

Bu yazımızda bulut altyapısı üzerinde çok sayıda Kubernetes kümesini yönetme deneyimimizi ve altta yatan platformun mimarisini paylaşacağız.

Giriş

Kubernetes, buluttaki çeşitli iş yükleri için fiili standart haline geldi. Şekil 1'de gösterildiği gibi. Yukarıdaki Şekil 10'e göre giderek daha fazla Alibaba Bulut uygulaması Kubernetes kümelerinde çalışıyor: durum bilgisi olan ve durum bilgisi olmayan uygulamaların yanı sıra uygulama yöneticileri. Kubernetes yönetimi, altyapıyı oluşturan ve bakımını yapan mühendisler için her zaman ilginç ve ciddi bir tartışma konusu olmuştur. Alibaba Cloud gibi bulut sağlayıcıları söz konusu olduğunda ölçeklendirme konusu ön plana çıkıyor. Bu ölçekte Kubernetes kümeleri nasıl yönetilir? 000 düğümlü büyük Kubernetes kümelerini yönetmeye yönelik en iyi uygulamaları zaten ele aldık. Elbette bu ilginç bir ölçeklendirme problemidir. Ancak başka bir ölçek daha var: miktar kümelerin kendisi.

Bu konuyu birçok ACK kullanıcısıyla tartıştık. Çoğu, yüzlerce olmasa da düzinelerce küçük veya orta ölçekli Kubernetes kümesini çalıştırmayı seçiyor. Bunun iyi nedenleri var: Potansiyel hasarı sınırlamak, kümeleri farklı ekipler için ayırmak, test için sanal kümeler oluşturmak. ACK, bu kullanım modeliyle küresel bir kitleye hizmet vermeyi hedefliyorsa 20'den fazla bölgede çok sayıda kümeyi güvenilir ve verimli bir şekilde yönetmelidir.

Pirinç. 2. Çok sayıda Kubernetes kümesini yönetme sorunları

Bu ölçekte kümeleri yönetmenin temel zorlukları nelerdir? Şekilde gösterildiği gibi ele alınması gereken dört konu vardır:

• Heterojenlik

ACK, standart, sunucusuz, Edge, Windows ve diğerleri dahil olmak üzere çeşitli küme türlerini desteklemelidir. Farklı kümeler farklı seçenekler, bileşenler ve barındırma modelleri gerektirir. Bazı müşterilerin kendi özel durumları için kişiselleştirme konusunda yardıma ihtiyacı vardır.

• Çeşitli küme boyutları

Kümelerin boyutları, birkaç bölmeli birkaç düğümden, binlerce bölmeli onbinlerce düğüme kadar değişir. Kaynak gereksinimleri de büyük ölçüde farklılık gösterir. Yanlış kaynak tahsisi performansı etkileyebilir ve hatta başarısızlığa neden olabilir.

• Farklı versiyonlar

Kubernetes çok hızlı gelişiyor. Birkaç ayda bir yeni sürümler yayınlanır. Müşteriler her zaman yeni özellikleri denemeye isteklidir. Bu nedenle test yükünü Kubernetes'in yeni sürümlerine, üretim yükünü ise stabil sürümlere yüklemek istiyorlar. Bu gereksinimi karşılamak için ACK, istikrarlı sürümleri korurken müşterilere sürekli olarak Kubernetes'in yeni sürümlerini sunmalıdır.

• Güvenlik Uyumluluğu

Kümeler farklı bölgelere dağılmıştır. Bu nedenle çeşitli güvenlik gereksinimlerine ve resmi düzenlemelere uymaları gerekir. Örneğin, Avrupa'daki bir kümenin GDPR uyumlu olması gerekirken, Çin'deki bir finansal bulutun ek koruma katmanlarına sahip olması gerekir. Bu gereksinimler zorunludur ve bulut platformunun müşterileri için büyük riskler oluşturduğundan bunların göz ardı edilmesi kabul edilemez.

ACK platformu yukarıdaki sorunların çoğunu çözmek için tasarlanmıştır. Şu anda dünya çapında 10 binden fazla Kubernetes kümesini güvenilir ve istikrarlı bir şekilde yönetmektedir. Birkaç temel tasarım/mimari ilkesi de dahil olmak üzere bunun nasıl başarıldığına bakalım.

Dizayn

Küp üstü küp ve petek

Merkezi hiyerarşiden farklı olarak hücre tabanlı mimari, genellikle bir platformu tek bir veri merkezinin ötesine ölçeklendirmek veya olağanüstü durum kurtarma kapsamını genişletmek için kullanılır.

Alibaba Cloud'daki her bölge birkaç bölgeden (AZ) oluşur ve genellikle belirli bir veri merkezine karşılık gelir. Büyük bir bölgede (örneğin Huangzhou), genellikle ACK çalıştıran binlerce Kubernetes istemci kümesi bulunur.

ACK, bu Kubernetes kümelerini Kubernetes'in kendisini kullanarak yönetir; bu, istemci Kubernetes kümelerini yönetmek için çalışan bir Kubernetes metakümemiz olduğu anlamına gelir. Bu mimariye aynı zamanda “kube-on-kube” (KoK) da denir. KoK mimarisi, küme dağıtımının basit ve belirleyici olması nedeniyle istemci kümelerinin yönetimini basitleştirir. Daha da önemlisi yerel Kubernetes özelliklerini yeniden kullanabiliriz. Örneğin, API sunucularını dağıtım yoluyla yönetmek, birden fazla vbd'yi yönetmek için etcd operatörünü kullanmak. Böyle bir yineleme her zaman özel bir zevk getirir.

İstemci sayısına bağlı olarak bir bölgede birkaç Kubernetes meta kümesi dağıtılır. Bu metakümelere hücreler diyoruz. Tüm bölgenin arızalanmasına karşı koruma sağlamak için ACK, tek bir bölgedeki çoklu etkin dağıtımları destekler: metaküme, Kubernetes istemci kümesi ana bileşenlerini birden çok bölgeye dağıtır ve bunları aynı anda, yani çoklu etkin modda çalıştırır. Master'ın güvenilirliğini ve verimliliğini sağlamak için ACK, bileşenlerin yerleşimini optimize eder ve API sunucusu ile vb.'nin birbirine yakın olmasını sağlar.

Bu model Kubernetes'i verimli, esnek ve güvenilir bir şekilde yönetmenize olanak tanır.

Metaküme kaynak planlaması

Daha önce de belirttiğimiz gibi, her bölgedeki metakümelerin sayısı istemci sayısına bağlıdır. Peki hangi noktada yeni bir metaküme eklenmeli? Bu tipik bir kaynak planlama problemidir. Kural olarak, mevcut metakümeler tüm kaynaklarını tükettiğinde yeni bir tane oluşturmak gelenekseldir.

Örneğin ağ kaynaklarını ele alalım. KoK mimarisinde, istemci kümelerindeki Kubernetes bileşenleri bir meta kümede bölmeler olarak dağıtılır. Kullanırız Terway (Şekil 3), Alibaba Cloud tarafından konteyner ağ yönetimi için geliştirilen yüksek performanslı bir eklentidir. Zengin bir dizi güvenlik politikası sağlar ve Alibaba Bulut Elastik Ağ Arayüzü (ENI) aracılığıyla müşterilerin sanal özel bulutlarına (VPC'ler) bağlanmanıza olanak tanır. Ağ kaynaklarını bir metakümedeki düğümler, bölmeler ve hizmetler arasında etkili bir şekilde dağıtmak için bunların sanal özel bulutların metakümesi içindeki kullanımını dikkatle izlemeliyiz. Ağ kaynakları sona erdiğinde yeni bir hücre oluşturulur.

Her bir meta kümedeki en uygun müşteri kümesi sayısını belirlemek için maliyetlerimizi, yoğunluk gereksinimlerimizi, kaynak kotamızı, güvenilirlik gereksinimlerimizi ve istatistiklerimizi de dikkate alırız. Yeni bir metaküme oluşturma kararı tüm bu bilgilere dayanarak verilir. Küçük kümelerin gelecekte büyük ölçüde genişleyebileceğini, dolayısıyla küme sayısı değişmese bile kaynak tüketiminin artabileceğini lütfen unutmayın. Genellikle her kümenin büyümesi için yeterli boş alan bırakırız.

Pirinç. 3. Terway ağ mimarisi

Sihirbaz bileşenlerini istemci kümeleri genelinde ölçeklendirme

Sihirbaz bileşenlerinin farklı kaynak ihtiyaçları vardır. Bunlar, kümedeki düğümlerin ve bölmelerin sayısına, APIServer ile etkileşime giren standart olmayan denetleyicilerin/operatörlerin sayısına bağlıdır.

ACK'da her Kubernetes istemci kümesinin boyutu ve çalışma zamanı gereksinimleri farklılık gösterir. Sihirbaz bileşenlerini yerleştirmek için evrensel bir yapılandırma yoktur. Büyük bir istemci için yanlışlıkla düşük bir kaynak sınırı belirlersek, kümesi yükle baş edemeyecektir. Tüm kümeler için ihtiyatlı bir şekilde yüksek bir sınır belirlerseniz kaynaklar israf edilir.

ACK, güvenilirlik ve maliyet arasında ince bir denge bulmak için bir tür sistemi kullanıyor. Yani üç tip küme tanımlıyoruz: küçük, orta ve büyük. Her türün ayrı bir kaynak tahsis profili vardır. Tür, sihirbaz bileşenlerinin yüküne, düğüm sayısına ve diğer faktörlere göre belirlenir. Küme türü zamanla değişebilir. ACK bu faktörleri sürekli olarak izler ve buna göre yukarı/aşağı tipleme yapabilir. Küme türü değiştirildiğinde kaynak tahsisi, minimum kullanıcı müdahalesiyle otomatik olarak güncellenir.

Bu değişikliklerin daha sorunsuz gerçekleşmesi ve ekonomik açıdan daha anlamlı olması için bu sistemi daha ayrıntılı ölçeklendirme ve daha hassas tür güncellemesiyle geliştirmeye çalışıyoruz.

Pirinç. 4. Akıllı çok aşamalı tip anahtarlama

Müşteri kümelerinin geniş ölçekte gelişimi

Önceki bölümlerde çok sayıda Kubernetes kümesini yönetmenin bazı yönleri ele alınıyordu. Ancak çözülmesi gereken başka bir sorun daha var: kümelerin evrimi.

Kubernetes, bulut dünyasının “Linux'udur”. Sürekli güncellenmekte ve daha modüler hale gelmektedir. Müşterilerimize sürekli olarak yeni sürümler sunmalı, güvenlik açıklarını düzeltmeli ve mevcut kümeleri güncellemeli, ayrıca çok sayıda ilgili bileşeni (CSI, CNI, Cihaz Eklentisi, Zamanlayıcı Eklentisi ve diğerleri) yönetmeliyiz.

Örnek olarak Kubernetes bileşen yönetimini ele alalım. Başlangıç ​​olarak, tüm bu bağlantılı bileşenlerin kaydedilmesi ve yönetilmesi için merkezi bir sistem geliştirdik.

Pirinç. 5. Esnek ve takılabilir bileşenler

İlerlemeden önce güncellemenin başarılı olduğundan emin olmanız gerekir. Bunu yapmak için bileşenlerin işlevselliğini kontrol etmek için bir sistem geliştirdik. Kontrol, güncellemeden önce ve sonra gerçekleştirilir.

Pirinç. 6. Küme bileşenlerinin ön kontrolü

Bu bileşenleri hızlı ve güvenilir bir şekilde güncellemek için sürekli bir dağıtım sistemi, kısmi ilerleme (gri tonlama), duraklatmalar ve diğer işlevler desteğiyle çalışır. Standart Kubernetes denetleyicileri bu kullanım durumu için pek uygun değildir. Bu nedenle, küme bileşenlerini yönetmek için bir eklenti ve bir yardımcı kontrol modülü (sepet yönetimi) dahil olmak üzere bir dizi özel denetleyici geliştirdik.

Örneğin BroadcastJob denetleyicisi, her çalışan makinedeki bileşenleri güncellemek veya her makinedeki düğümleri kontrol etmek için tasarlanmıştır. Yayın işi, DaemonSet gibi kümedeki her düğümde bir bölme çalıştırır. Ancak DaemonSet, pod'u her zaman uzun süre çalışır durumda tutarken BroadcastJob onu daraltır. Yayın denetleyicisi ayrıca yeni katılan düğümlerde bölmeler başlatır ve düğümleri gerekli bileşenlerle başlatır. Haziran 2019'da şirket bünyesinde kullandığımız OpenKruise otomasyon motorunun kaynak kodunu açtık.

Pirinç. 7. OpenKurise Yayın görevinin tüm düğümlerde yürütülmesini organize eder

Müşterilerin doğru küme yapılandırmalarını seçmelerine yardımcı olmak için Sunucusuz, Uç, Windows ve Çıplak Metal profilleri de dahil olmak üzere önceden tanımlanmış bir dizi profil de sağlıyoruz. Ortam genişledikçe ve müşterilerimizin ihtiyaçları arttıkça, sıkıcı kurulum sürecini basitleştirmek için daha fazla profil ekleyeceğiz.

Pirinç. 8. Çeşitli senaryolar için gelişmiş ve esnek küme profilleri

Veri merkezlerinde küresel gözlemlenebilirlik

Aşağıdaki şek. 9, Alibaba Bulut Konteyner bulut hizmeti dünya çapında yirmi bölgede konuşlandırıldı. Bu ölçek göz önüne alındığında, ACK'nin temel hedeflerinden biri, çalışan kümelerin durumunu kolayca izlemek ve böylece bir istemci kümesinin bir sorunla karşılaşması durumunda duruma hızlı bir şekilde yanıt verebilmemizi sağlamaktır. Başka bir deyişle, tüm bölgelerdeki müşteri kümelerinden gerçek zamanlı olarak verimli ve güvenli bir şekilde istatistik toplamanıza ve sonuçları görsel olarak sunmanıza olanak sağlayacak bir çözüm bulmanız gerekir.

Pirinç. 9. Alibaba Bulut Konteyner hizmetinin yirmi bölgede küresel dağıtımı

Birçok Kubernetes izleme sistemi gibi biz de ana aracımız olarak Prometheus'u kullanıyoruz. Her metaküme için Prometheus aracıları aşağıdaki ölçümleri toplar:

• Ana bilgisayar kaynakları (CPU, bellek, disk vb.) ve ağ bant genişliği gibi işletim sistemi ölçümleri.
• Kube-apserver, kube-controller-manager ve kube-scheduler gibi metacluster ve istemci kümesi yönetim sistemine yönelik ölçümler.
• Kubernetes-state-metrics ve cadvisor'dan alınan ölçümler.
• Disk yazma süresi, veritabanı boyutu, düğümler arasındaki bağlantıların verimi vb. gibi vbd ölçümleri.

Küresel istatistikler tipik bir çok katmanlı toplama modeli kullanılarak toplanır. Her metakümeden gelen izleme verileri ilk önce her bölgede toplanır ve ardından genel resmi gösteren merkezi bir sunucuya gönderilir. Her şey federasyon mekanizmasıyla çalışıyor. Her veri merkezindeki bir Prometheus sunucusu, o veri merkezinden ölçümleri toplar ve merkezi Prometheus sunucusu, izleme verilerinin toplanmasından sorumludur. AlertManager, merkezi Prometheus'a bağlanır ve gerekirse DingTalk, e-posta, SMS vb. aracılığıyla uyarılar gönderir. Görselleştirme - Grafana kullanılarak.

Şekil 10'da izleme sistemi üç düzeye ayrılabilir:

• Sınır seviyesi

Merkeze en uzak katman. Prometheus Edge Sunucusu her meta kümede çalışır ve aynı ağ etki alanı içindeki meta ve istemci kümelerinden ölçümler toplar.

• Kademeli seviye

Prometheus kaskad katmanının işlevi, birden fazla bölgeden izleme verilerini toplamaktır. Bu sunucular Çin, Asya, Avrupa ve Amerika gibi daha büyük coğrafi birimler seviyesinde çalışmaktadır. Kümeler büyüdükçe bölge bölünebilir ve ardından her yeni büyük bölgede kademeli düzeyde bir Prometheus sunucusu görünecektir. Bu stratejiyle gerektiği gibi sorunsuz bir şekilde ölçeklendirebilirsiniz.

• Merkezi seviye

Merkezi Prometheus sunucusu tüm kademeli sunuculara bağlanır ve son veri toplama işlemini gerçekleştirir. Güvenilirlik açısından, farklı bölgelerde aynı kademeli sunuculara bağlanan iki merkezi Prometheus örneği oluşturuldu.

Pirinç. 10. Prometheus federasyon mekanizmasını temel alan küresel çok düzeyli izleme mimarisi

Özet

Kubernetes tabanlı bulut çözümleri sektörümüzü dönüştürmeye devam ediyor. Alibaba Bulut konteyner hizmeti güvenli, güvenilir ve yüksek performanslı barındırma sağlar; en iyi Kubernetes bulut barındırma hizmetlerinden biridir. Alibaba Bulut ekibi, Açık Kaynak ve açık kaynak topluluğunun ilkelerine güçlü bir şekilde inanmaktadır. Bulut teknolojilerinin işletilmesi ve yönetilmesi alanındaki bilgi birikimimizi mutlaka paylaşmaya devam edeceğiz.

Kaynak: habr.com