Veritabanı kümelerini yönetmek için Kubernetes'te operatör. Vladislav Klimenko (Altinity, 2019)

Rapor, Kubernetes'te bir operatör geliştirme, mimarisini tasarlama ve temel çalışma ilkelerine ilişkin pratik konulara ayrılmıştır.

Raporun ilk bölümünde şunları ele alacağız:

• Kubernetes'te operatör nedir ve neden gereklidir;
• operatörün karmaşık sistemlerin yönetimini tam olarak nasıl basitleştirdiği;
• operatörün yapabilecekleri ve yapamayacakları.

Şimdi operatörün iç yapısını tartışmaya geçelim. Operatörün mimarisine ve işleyişine adım adım bakalım. Gelin detaylı olarak bakalım:

• operatör ve Kubernetes arasındaki etkileşim;
• operatörün hangi işlevleri üstlendiği ve Kubernetes'e hangi işlevleri devrettiği.

Kubernetes'te parçaları ve veritabanı kopyalarını yönetmeye bakalım.
Daha sonra veri depolama sorunlarını tartışacağız:

• operatörün bakış açısından Kalıcı Depolama ile nasıl çalışılacağı;
• Yerel Depolamayı kullanmanın tuzakları.

Raporun son bölümünde pratik uygulama örneklerini ele alacağız. clickhouse operatörü Amazon veya Google Cloud Service'ten. Rapor, ClickHouse için bir operatörün geliştirme ve işletim deneyimi örneğine dayanmaktadır.

Video:

Benim adım Vladislav Klimenko. Bugün bir operatör geliştirme ve çalıştırma konusundaki deneyimimiz hakkında konuşmak istedim ve bu, veritabanı kümelerini yönetmek için uzmanlaşmış bir operatör. Örneğin ClickHouse operatörü ClickHouse kümesini yönetmek için.

Neden operatör ve ClickHouse hakkında konuşma fırsatımız var?

• ClickHouse'u destekliyor ve geliştiriyoruz.
• Şu anda yavaş yavaş ClickHouse'un gelişimine katkı sağlamaya çalışıyoruz. ClickHouse'da yapılan değişiklik miktarı açısından da Yandex'den sonra ikinci sıradayız.
• ClickHouse ekosistemi için ek projeler yapmaya çalışıyoruz.

Sizlere bu projelerden birinden bahsetmek istiyorum. Bu, Kubernetes için ClickHouse operatörüyle ilgilidir.

Raporumda iki konuya değinmek istiyorum:

• İlk konu ClickHouse veritabanı yönetimi operatörümüzün Kubernetes'te nasıl çalıştığıdır.
• İkinci konu herhangi bir operatörün nasıl çalıştığı, yani Kubernetes ile nasıl etkileşime girdiğidir.

Ancak bu iki soru raporum boyunca kesişecek.

Anlatmaya çalıştığım şeyi kim dinlemekle ilgilenir?

• Operatörleri işletenlerin en çok ilgisini çekecektir.
• Veya dahili olarak nasıl çalıştığını, operatörün Kubernetes ile nasıl etkileşime girdiğini ve hangi tuzakların ortaya çıkabileceğini anlamak için kendilerininkini yapmak isteyenler için.

Bugün tartışacağımız konuyu en iyi şekilde anlamak için Kubernetes'in nasıl çalıştığını bilmek ve bazı temel bulut eğitimlerini almak iyi bir fikirdir.

ClickHouse nedir? Bu, analitik sorguların çevrimiçi işlenmesi için belirli özelliklere sahip sütunlu bir veritabanıdır. Ve tamamen açık kaynaktır.

Ve bizim için sadece iki şeyi bilmek önemlidir. Bunun bir veritabanı olduğunu bilmeniz gerekiyor, dolayısıyla anlatacaklarım hemen hemen her veritabanına uygulanabilir. ClickHouse DBMS'nin çok iyi ölçeklendirilmesi gerçeği neredeyse doğrusal ölçeklenebilirlik sağlar. Dolayısıyla küme durumu ClickHouse için doğal bir durumdur. Ve biz en çok Kubernetes'te ClickHouse kümesine nasıl hizmet verileceğini tartışmakla ilgileniyoruz.

Neden orada ona ihtiyaç var? Neden bunu kendimiz çalıştırmaya devam edemiyoruz? Cevaplar kısmen teknik, kısmen de organizasyoneldir.

• Uygulamada, büyük şirketlerde neredeyse tüm bileşenlerin zaten Kubernetes'te olduğu bir durumla giderek daha fazla karşılaşıyoruz. Veritabanları dışarıda kalır.
• Ve şu soru giderek daha fazla soruluyor: "Bu içeriye yerleştirilebilir mi?" Bu nedenle büyük şirketler veri ambarlarını hızlı bir şekilde yönetebilmek için maksimum yönetim birliğini sağlamaya çalışıyor.
• Ve bu özellikle aynı şeyi yeni bir yerde tekrarlamak için maksimum fırsata, yani maksimum taşınabilirliğe ihtiyacınız varsa yardımcı olur.

Ne kadar kolay veya zor? Bu elbette elle yapılabilir. Ancak bu o kadar basit değil, çünkü Kubernetes'in kendisini yönetme karmaşıklığına sahibiz, ancak aynı zamanda ClickHouse'un özellikleri de üst üste bindiriliyor. Ve böyle bir toplama ortaya çıkıyor.

Ve bunların tümü bir araya geldiğinde, yönetimi oldukça zorlaşan oldukça geniş bir teknoloji seti ortaya çıkıyor, çünkü Kubernetes kendi gündelik sorunlarını operasyona getiriyor ve ClickHouse da kendi sorunlarını günlük operasyona getiriyor. Özellikle birden fazla ClickHouse'umuz varsa ve onlarla sürekli bir şeyler yapmamız gerekiyorsa.

Dinamik bir yapılandırmayla ClickHouse, DevOps'ta sabit bir yük oluşturan oldukça fazla sayıda soruna sahiptir:

• ClickHouse'da bir şeyi değiştirmek istediğimizde, örneğin bir kopya veya parça eklemek istediğimizde, yapılandırmayı yönetmemiz gerekir.
• Ardından ClickHouse'un belirli bir parçalama yöntemi olduğundan veri şemasını değiştirin. Orada veri şemasını hazırlamanız, konfigürasyonları düzenlemeniz gerekiyor.
• İzlemeyi ayarlamanız gerekir.
• Yeni kopyalar için yeni parçalar için günlükler toplanıyor.
• Restorasyona dikkat edin.
• Ve yeniden başlatın.

Bunlar gerçekten kullanımını kolaylaştırmak istediğim rutin görevler.

Kubernetes'in kendisi operasyonda iyi yardımcı olur, ancak temel sistem konularında.

Kubernetes aşağıdaki gibi şeyleri kolaylaştırma ve otomatikleştirme konusunda iyidir:

• Kurtarma.
• Tekrar başlat.
• Depolama sistemi yönetimi.

Bu iyi, doğru yön bu, ancak bir veritabanı kümesinin nasıl çalıştırılacağı konusunda hiçbir fikri yok.

Daha fazlasını istiyoruz, tüm veritabanının Kubernetes'te çalışmasını istiyoruz.

Bastığınız büyük, sihirli kırmızı bir düğmeye benzer bir şey almak istiyorum ve çözülmesi gereken günlük görevlerin bulunduğu bir küme, tüm yaşam döngüsü boyunca konuşlandırılır ve korunur. Kubernetes'teki ClickHouse kümesi.

Biz de işi kolaylaştıracak bir çözüm üretmeye çalıştık. Bu, Altinity'den Kubernetes için bir ClickHouse operatörüdür.

Operatör, asıl görevi diğer programları yönetmek olan bir programdır, yani yöneticidir.

Ve davranış kalıplarını içerir. Buna konu alanıyla ilgili kodlanmış bilgi diyebilirsiniz.

Ve asıl görevi, DevOps'un ömrünü kolaylaştırmak ve mikro yönetimi azaltmaktır, böylece o (DevOps) zaten üst düzey terimlerle düşünebilir, yani o (DevOps) mikro yönetimle meşgul olmaz, böylece yapılandırmaz. tüm ayrıntıları manuel olarak

Ve yalnızca operatör, mikro görevlerle ilgilenen ve DevOps'a yardımcı olan robotik bir asistandır.

Neden bir operatöre ihtiyacınız var? Özellikle iki alanda iyi performans gösteriyor:

• ClickHouse ile ilgilenen uzmanın yeterli deneyimi olmadığı ancak zaten ClickHouse'u çalıştırması gerektiği durumlarda, operatör işlemi kolaylaştırır ve nasıl çalıştığı hakkında çok fazla ayrıntıya girmeden oldukça karmaşık bir konfigürasyona sahip bir ClickHouse kümesini çalıştırmanıza izin verir. içeri. Ona sadece üst düzey görevler veriyorsunuz ve işe yarıyor.
• Ve en iyi performansı gösterdiği ikinci görev, çok sayıda tipik görevi otomatikleştirmenin gerekli olduğu zamandır. Mikro görevleri sistem yöneticilerinden kaldırır.

Buna en çok ya yolculuğuna yeni başlayanlar ya da çok fazla otomasyon yapması gerekenler ihtiyaç duyuyor.

Operatör bazlı yaklaşımın diğer sistemlerden farkı nedir? Helm var. Ayrıca ClickHouse'un kurulmasına da yardımcı olur; hatta tüm bir ClickHouse kümesinin kurulmasını sağlayacak dümen grafikleri çizebilirsiniz. O halde operatör ile aynısı, örneğin Helm arasındaki fark nedir?

Temel temel fark, Helm'in paket yönetimi olması ve Operatörün bir adım daha ileri gitmesidir. Bu, tüm yaşam döngüsü için bir destektir. Bu sadece kurulum değil, bunlar ölçeklendirmeyi, parçalamayı, yani yaşam döngüsü boyunca yapılması gereken her şeyi (gerekirse silmeyi de) içeren günlük görevlerdir - bunların hepsine operatör tarafından karar verilir. Tüm yazılım yaşam döngüsünü otomatikleştirmeye ve sürdürmeye çalışır. Sunulan diğer çözümlerden temel farkı budur.

Bu giriş kısmıydı, devam edelim.

Operatörümüzü nasıl oluşturacağız? ClickHouse kümesini tek kaynak olarak yönetmek için konuya yaklaşmaya çalışıyoruz.

Burada resmin sol tarafında giriş verilerimiz var. Bu, kubectl aracılığıyla klasik şekilde Kubernetes'e iletilen küme spesifikasyonuna sahip YAML'dir. Orada operatörümüz onu alıyor ve sihrini yapıyor. Ve çıktıda aşağıdaki şemayı elde ediyoruz. Bu, ClickHouse'un Kubernetes'teki bir uygulamasıdır.

Daha sonra yavaş yavaş operatörün tam olarak nasıl çalıştığına, hangi tipik görevlerin çözülebileceğine bakacağız. Zamanımız sınırlı olduğundan yalnızca tipik görevleri ele alacağız. Ve operatörün karar verebileceği her şey tartışılmayacaktır.

Pratikten başlayalım. Projemiz tamamen açık kaynak olduğundan GitHub'da nasıl çalıştığını görebilirsiniz. Ve eğer sadece başlatmak istiyorsanız Hızlı Başlangıç ​​Kılavuzu ile başlayabileceğiniz hususlarından hareket edebilirsiniz.

Ayrıntılı olarak anlamak istiyorsanız, belgeleri aşağı yukarı düzgün bir biçimde tutmaya çalışıyoruz.

Pratik bir problemle başlayalım. Hepimizin başlamak istediği ilk görev, ilk örneği bir şekilde çalıştırmaktır. Nasıl çalıştığını gerçekten bilmesem bile ClickHouse'u operatörü kullanarak nasıl başlatabilirim? Bir manifesto yazıyoruz çünkü... K8'lerle olan tüm iletişim, bildirimler aracılığıyla iletişimdir.

Bu çok karmaşık bir manifesto. Kırmızıyla işaretlediğimiz şey, odaklanmamız gereken şey. Operatörden demo adında bir küme oluşturmasını istiyoruz.

Bunlar şimdilik temel örnekler. Depolama henüz açıklanmadı ancak biraz sonra depolamaya döneceğiz. Şimdilik kümenin gelişim dinamiklerini gözlemleyeceğiz.

Bu manifestoyu biz hazırladık. Operatörümüze besliyoruz. Çalıştı, sihir yaptı.

Konsola bakıyoruz. Üç bileşen ilgi çekicidir: bir Pod, iki Hizmet ve bir StatefulSet.

Operatör çalıştı ve tam olarak ne yarattığını görebiliyoruz.

Bunun gibi bir şey yaratıyor. Her kopya için bir StatefulSet, Pod, ConfigMap, tüm küme için ConfigMap'imiz var. Hizmetler kümeye giriş noktaları olarak gereklidir.

Hizmetler, merkezi Yük Dengeleyici Hizmetidir ve her kopya ve her parça için de kullanılabilir.

Temel kümemiz buna benzer. Tek bir düğümden geliyor.

Daha ileri gidelim ve işleri karmaşıklaştıralım. Kümeyi parçalamamız gerekiyor.

Görevlerimiz artıyor, dinamikler başlıyor. Bir parça eklemek istiyoruz. Gelişmeyi takip ediyoruz. Şartnamemizi değiştiriyoruz. İki parça istediğimizi belirtiyoruz.

Bu, sistemin büyümesiyle birlikte dinamik olarak gelişen dosyanın aynısıdır. Depolama no, depolama daha detaylı tartışılacak, bu ayrı bir konu.

YAML operatörünü besliyoruz ve ne olacağını görüyoruz.

Operatör aşağıdaki varlıkları düşündü ve yaptı. Zaten iki Pod'umuz, üç Hizmetimiz ve aniden 2 StatefulSet'imiz var. Neden 2 StatefulSets?

Diyagramda durum şöyleydi; bu, bir bölmeye sahip olduğumuz ilk durumumuzdu.

Bu hale geldi. Şimdiye kadar her şey basit, kopyalandı.

Peki neden iki tane StatefulSet oluştu? Burada Kubernetes'te Pod'ların nasıl yönetildiği sorusunu biraz açıp tartışmamız gerekiyor.

Bir şablondan bir Pod kümesi oluşturmanıza olanak tanıyan StatefulSet adında bir nesne vardır. Buradaki anahtar faktör Şablondur. Ayrıca tek bir StatefulSet'teki tek şablonu kullanarak birçok Pod'u başlatabilirsiniz. Ve buradaki anahtar ifade "bir şablon için birçok Kapsül"dür.

Ve kümenin tamamını tek bir StatefulSet'e sığdırmak için büyük bir istek vardı. Çalışacaktır, bunda hiçbir sorun yok. Ancak bir uyarı var. ClickHouse'un çeşitli versiyonlarından oluşan heterojen bir küme oluşturmak istiyorsak, sorular ortaya çıkmaya başlar. Evet, StatefulSet sürekli bir güncelleme yapabilir ve orada yeni bir sürüm sunabilir, aynı anda çok sayıda düğümden fazlasını denememeniz gerektiğini açıklayabilirsiniz.

Ancak görevi tahmin edersek ve tamamen heterojen bir küme oluşturmak istediğimizi ve sürekli güncelleme kullanarak eski sürümden yenisine geçmek istemediğimizi, ancak yalnızca hem terimler hem de terimler açısından heterojen bir küme oluşturmak istediğimizi söylersek ClickHouse'un farklı sürümleri ve farklı depolama açısından. Örneğin, tamamen heterojen bir küme oluşturmak için genel olarak yavaş disklerde ayrı disklerde bazı kopyalar yapmak istiyoruz. StatefulSet tek bir şablondan standartlaştırılmış bir çözüm oluşturduğundan bunu yapmanın bir yolu yoktur.

Biraz düşündükten sonra bu şekilde yapmamıza karar verildi. Her kopyanın kendi StatefulSet'inde var. Bu çözümün bazı dezavantajları vardır ancak pratikte tamamı operatör tarafından kapsanmaktadır. Ve pek çok avantajı var. Tam olarak istediğimiz kümeyi, örneğin tamamen heterojen bir kümeyi oluşturabiliriz. Bu nedenle, bir kopyaya sahip iki parçaya sahip olduğumuz bir kümede, tam olarak 2 StatefulSets ve 2 Pod'a sahip olacağız çünkü heterojen bir küme oluşturabilmek için yukarıda belirtilen nedenlerden dolayı bu yaklaşımı seçtik.

Pratik sorunlara dönelim. Kümemizde kullanıcıları yapılandırmamız gerekiyor; Kubernetes'te ClickHouse'un bazı yapılandırmalarını yapmanız gerekir. Operatör bunun için tüm olanakları sağlar.

YAML'da direkt olarak istediğimizi yazabiliyoruz. Tüm yapılandırma seçenekleri doğrudan bu YAML'den ClickHouse yapılandırmalarına eşlenir ve bunlar daha sonra kümenin her yerine dağıtılır.

Bunu bu şekilde yazabilirsiniz. Bu örneğin. Şifre şifrelenebilir. Kesinlikle tüm ClickHouse yapılandırma seçenekleri desteklenir. İşte sadece bir örnek.

Küme yapılandırması bir ConfigMap olarak dağıtılır. Uygulamada, ConfigMap güncellemesi anında gerçekleşmez, bu nedenle küme büyükse konfigürasyonu aktarma işlemi biraz zaman alır. Ancak tüm bunların kullanımı çok uygundur.

Görevi karmaşıklaştıralım. Küme gelişiyor. Verileri çoğaltmak istiyoruz. Yani, zaten her biri bir kopya olmak üzere iki parçamız var ve kullanıcılar yapılandırılmış. Büyüyoruz ve çoğaltma yapmak istiyoruz.

Çoğaltma için neye ihtiyacımız var?

ZooKeeper'a ihtiyacımız var. ClickHouse'da çoğaltma ZooKeeper kullanılarak oluşturulur. Farklı ClickHouse replikalarının hangi veri bloklarının hangi ClickHouse üzerinde olduğu konusunda fikir birliğine varabilmesi için ZooKeeper'a ihtiyaç vardır.

ZooKeeper herkes tarafından kullanılabilir. İşletmenin harici bir ZooKeeper'ı varsa kullanılabilir. Değilse, depomuzdan yükleyebilirsiniz. Her şeyi kolaylaştıran bir yükleyici var.

Ve tüm sistemin etkileşim diyagramı şu şekilde ortaya çıkıyor. Platform olarak Kubernetes'e sahibiz. ClickHouse operatörünü çalıştırır. ZooKeeper'ı burada hayal ettim. Operatör hem ClickHouse hem de ZooKeeper ile etkileşime giriyor. Yani etkileşim sonuçları.

Ve tüm bunlar ClickHouse'un k8'lerdeki verileri başarılı bir şekilde çoğaltması için gereklidir.

Şimdi görevin kendisine, çoğaltma bildiriminin nasıl görüneceğine bakalım.

Manifestimize iki bölüm ekliyoruz. Birincisi, Kubernetes'in içinde veya dışında olabilecek ZooKeeper'ın nereden alınacağıdır. Bu sadece bir açıklamadır. Ve kopyalarını sipariş ediyoruz. Onlar. iki kopya istiyoruz. Toplamda çıkışta 4 podumuz olmalı. Depolamayı hatırlıyoruz, biraz sonra geri gelecek. Depolama ayrı bir hikaye.

Bu böyleydi.

Bu şekilde olur. Replikalar eklendi. 4'üncü sığmadı, orada çok sayıda olabileceğini düşünüyoruz. Ve ZooKeeper da yan tarafa eklendi. Planlar giderek daha karmaşık hale geliyor.

Ve bir sonraki görevi eklemenin zamanı geldi. Kalıcı Depolama ekleyeceğiz.

Kalıcı Depolama için çeşitli seçeneklerimiz var.

Örneğin Amazon, Google kullanarak bir bulut sağlayıcısında çalışıyorsak, bulut depolamayı kullanma konusunda büyük bir cazibemiz var. Çok kullanışlı, iyi.

Ve ikinci bir seçenek daha var. Bu, her düğümde yerel disklerimiz olduğunda yerel depolama içindir. Bu seçeneğin uygulanması çok daha zordur, ancak aynı zamanda daha verimlidir.

Bakalım bulut depolamayla ilgili elimizde neler var.

Avantajları var. Yapılandırması çok kolaydır. Bulut sağlayıcısından bize şu ve şu kapasitede, şu sınıfta depolama vermesini sipariş ediyoruz. Sınıflar sağlayıcılar tarafından bağımsız olarak planlanır.

Ve bir dezavantajı var. Bazıları için bu kritik olmayan bir dezavantajdır. Elbette bazı performans sorunları olacaktır. Kullanımı çok uygun ve güvenilirdir ancak bazı potansiyel performans dezavantajları da vardır.

Ve çünkü ClickHouse özellikle üretkenliğe odaklanıyor, hatta elinden gelen her şeyi sıkıştırdığı bile söylenebilir, bu yüzden birçok müşteri maksimum üretkenliği elden çıkarmaya çalışıyor.

Ve bundan en iyi şekilde yararlanmak için yerel depolamaya ihtiyacımız var.

Kubernetes, Kubernetes'te yerel depolamayı kullanmak için üç soyutlama sağlar. Bu:

• Boş Dizin
• Ana Bilgisayar Yolu.
• Yerel

Nasıl farklı olduklarına ve nasıl benzer olduklarına bakalım.

İlk olarak, her üç yaklaşımda da depolama alanımız var - bunlar aynı fiziksel k8s düğümünde bulunan yerel disklerdir. Ama aralarında bazı farklılıklar var.

En basit olanla başlayalım, yani emptyDir. Pratikte bu nedir? Spesifikasyonumuzda konteynerizasyon sisteminden (çoğunlukla Docker'dan) yerel diskteki bir klasöre erişim sağlamasını istiyoruz.

Uygulamada Docker, kendi yolları üzerinde bir yerde geçici bir klasör oluşturur ve onu uzun karma olarak adlandırır. Ve ona erişmek için bir arayüz sağlar.

Bu performans açısından nasıl çalışacak? Bu, yerel disk hızında çalışacaktır; Bu, vidanıza tam erişimdir.

Ancak bu davanın bir dezavantajı var. Kalıcılık bu konuda oldukça şüphelidir. Docker konteynerlerle ilk kez hareket ettiğinde Persistent kaybolur. Kubernetes herhangi bir nedenle bu Pod'u başka bir diske taşımak isterse veriler kaybolacaktır.

Bu yaklaşım testler için iyidir çünkü zaten normal hız göstermektedir, ancak ciddi bir şey için bu seçenek uygun değildir.

Bu nedenle ikinci bir yaklaşım daha var. Bu hostPath'tir. Önceki slayta ve buna bakarsanız, yalnızca bir fark görebilirsiniz. Klasörümüz Docker'dan doğrudan Kubernetes düğümüne taşındı. Burada biraz daha basit. Yerel dosya sistemi üzerinde verilerimizi depolamak istediğimiz yolu doğrudan belirtiyoruz.

Bu yöntemin avantajları vardır. Bu zaten gerçek bir Kalıcıdır ve bu konuda klasiktir. Verileri bazı adreslerdeki diske kaydetmiş olacağız.

Dezavantajları da var. Bu yönetimin karmaşıklığıdır. Kubernet'lerimiz Pod'u başka bir fiziksel düğüme taşımak isteyebilir. İşte DevOps'un devreye girdiği yer burasıdır. Tüm sisteme, bu bölmelerin yalnızca bu yollar boyunca bir şeyin monte edildiği düğümlere taşınabileceğini ve aynı anda birden fazla düğüm olamayacağını doğru bir şekilde açıklaması gerekir. Oldukça zor.

Özellikle bu amaçlara yönelik olarak tüm bu karmaşıklığı gizlemek adına operatörümüzde şablonlar yaptık. Ve basitçe şöyle diyebilirsiniz: "Her fiziksel düğüm için ve falan yol boyunca bir ClickHouse örneğine sahip olmak istiyorum."

Ancak bu ihtiyaca ihtiyacı olan tek kişi biz değiliz, dolayısıyla Kubernetes'teki beyler de insanların fiziksel disklere erişim sahibi olmak istediklerini anlıyor ve bu nedenle üçüncü bir katman sağlıyorlar.

Yerel denir. Önceki slayttan neredeyse hiçbir farkı yok. Daha önce bu bölmeleri düğümden düğüme aktaramayacağımızı manuel olarak doğrulamak gerekiyordu çünkü bunların yerel bir fiziksel diske giden bir yol boyunca bağlanması gerekiyor, ancak şimdi tüm bu bilgi Kubernetes'in kendisinde kapsüllenmiş durumda. Ve yapılandırmanın çok daha kolay olduğu ortaya çıktı.

Pratik sorunumuza dönelim. YAML şablonuna dönelim. Burada gerçek bir depolama alanımız var. Geri döndük. Klasik VolumeClaim şablonunu k8s'deki gibi ayarladık. Ve nasıl bir depolama istediğimizi anlatıyoruz.

Bundan sonra k8'ler depolama talebinde bulunacaktır. StatefulSet'te bize tahsis edecek. Ve sonunda ClickHouse'un emrinde olacak.

Bu planımız vardı. Kalıcı Depolamamız kırmızıydı ve bu da yapılması gerektiğini ima ediyor gibiydi.

Ve yeşile dönüyor. Artık k8s'deki ClickHouse küme şeması tamamen tamamlandı. Parçalarımız, kopyalarımız, ZooKeeper'ımız var, öyle ya da böyle uygulanan gerçek bir Kalıcımız var. Program halihazırda tamamen işlevseldir.

Yaşamaya devam ediyoruz. Grubumuz gelişiyor. Ve Alexey, ClickHouse'un yeni bir sürümünü dener ve yayınlar.

ClickHouse'un yeni sürümünü kümemizde test etmek gibi pratik bir görev ortaya çıkıyor. Ve doğal olarak, hepsini yaymak istemezsiniz; uzak köşede bir yerde yeni bir sürümü tek bir kopyaya koymak istersiniz ve belki bir yeni sürüm değil, aynı anda iki sürüm koymak istersiniz, çünkü bunlar sıklıkla ortaya çıkar.

Bu konuda ne söyleyebiliriz?

İşte tam da böyle bir fırsatımız var. Bunlar kapsül şablonlarıdır. Operatörümüzün tamamen heterojen bir küme oluşturmanıza izin verdiğini yazabilirsiniz. Onlar. Bir gruptaki tüm replikalardan başlayıp her kişisel replikayla biten, ClickHouse'un hangi sürümünü istediğimizi, hangi sürümü depolamak istediğimizi yapılandırın. Cluster’ı tam olarak ihtiyacımız olan konfigürasyonla yapılandırabiliyoruz.

İçeriye biraz daha derine inelim. Bundan önce ClickHouse operatörünün ClickHouse özelliklerine göre nasıl çalıştığından bahsetmiştik.

Şimdi herhangi bir operatörün genel olarak nasıl çalıştığına ve K8'lerle nasıl etkileşime girdiğine dair birkaç söz söylemek istiyorum.

Önce K8'lerle etkileşime bakalım. Kubectl başvurusu yaptığımızda ne olur? Nesnelerimiz API aracılığıyla etcd'de görünür.

Örneğin, temel Kubernetes nesneleri: listede pod, StatefulSet, service vb.

Aynı zamanda henüz fiziksel hiçbir şey olmuyor. Bu nesnelerin kümede gerçekleştirilmesi gerekir.

Bu amaçla bir denetleyici belirir. Kontrolör bu açıklamaları gerçekleştirebilecek özel bir k8s bileşenidir. Fiziksel olarak nasıl ve ne yapacağını biliyor. Konteynerlerin nasıl çalıştırılacağını, sunucunun çalışması için orada nelerin yapılandırılması gerektiğini biliyor.

Ve nesnelerimizi K8'lerde somutlaştırıyor.

Ancak biz sadece pod'lar ve StatefulSet'lerle çalışmak istemiyoruz, onunla tek bir bütün olarak çalışabilmek için bir ClickHouseInstallation yani ClickHouse türünde bir nesne oluşturmak istiyoruz. Şu ana kadar böyle bir ihtimal yok.

Ancak K8'lerin şöyle güzel bir özelliği var. Kümemizin bölmelerden ve StatefulSet'ten birleştirileceği bu karmaşık varlığa benzer bir yere sahip olmamızı istiyoruz.

Peki bunun için ne yapılması gerekiyor? İlk olarak Özel Kaynak Tanımı devreye giriyor. Ne olduğunu? Bu, K8'ler için, bir veri türüne daha sahip olacağınız, içinde karmaşık olacak olan StatefulSet adlı bölmeye özel bir kaynak eklemek istediğimizin bir açıklamasıdır. Bu veri yapısının açıklamasıdır.

Ayrıca oraya kubectl application aracılığıyla da gönderiyoruz. Kubernetes bunu memnuniyetle kabul etti.

Ve artık depolama alanımızda,etcd'deki nesne ClickHouseInstallation adlı özel bir kaynağı kaydetme olanağına sahip.

Ama şimdilik başka bir şey olmayacak. Yani, kırıkları ve replikaları tanımlamak için incelediğimiz YAML dosyasını şimdi oluşturup "kubectl Apply" dersek Kubernetes bunu kabul edecek, vbd'ye koyacak ve şöyle diyecektir: "Harika, ama ne yapacağımı bilmiyorum" Bununla birlikte. ClickHouseInstallation'ın bakımını nasıl yapacağımı bilmiyorum."

Buna göre Kubernetes'in yeni veri türünü sunmasına yardımcı olacak birine ihtiyacımız var. Sol tarafta yerel veri türleriyle çalışan yerel bir Kubernetes denetleyicimiz var. Sağ tarafta ise özel veri türleriyle çalışabilen özel bir denetleyicimiz olmalıdır.

Ve başka bir şekilde buna operatör denir. K8'lerin dışında da çalıştırılabileceği için buraya özellikle Kubernetes olarak ekledim. Elbette çoğu zaman, tüm operatörler Kubernetes'te yürütülür, ancak hiçbir şey onun dışarıda durmasını engellemez, bu yüzden burada özel olarak dışarıya taşınır.

Ayrıca operatör olarak da bilinen özel denetleyici, API aracılığıyla Kubernetes ile etkileşime girer. API ile nasıl etkileşim kuracağını zaten biliyor. Ve özel bir kaynaktan yapmak istediğimiz karmaşık devrenin nasıl hayata geçirileceğini zaten biliyor. Operatörün yaptığı da tam olarak budur.

Operatör nasıl çalışır? Bunu nasıl yaptığını görmek için sağ tarafa bakalım. Operatörün tüm bunları nasıl gerçekleştirdiğini ve K8'lerle daha fazla etkileşimin nasıl gerçekleştiğini öğrenelim.

Operatör bir programdır. Olay odaklıdır. Operatör, Kubernetes API'yi kullanarak etkinliklere abone olur. Kubernetes API'de etkinliklere abone olabileceğiniz giriş noktaları bulunur. K8'lerde bir şeyler değişirse Kubernetes herkese etkinlik gönderir; Bu API noktasına abone olan herkes bildirim alacaktır.

Operatör olaylara abone olur ve bir tür tepki vermelidir. Görevi ortaya çıkan olaylara yanıt vermektir.

Etkinlikler belirli güncellemeler tarafından oluşturulur. ClickHouseInstallation'ın açıklamasını içeren YAML dosyamız geldi. Kubectl application aracılığıyla etcd'ye gitti. Orada bir olay tetiklendi ve bunun sonucunda bu olay ClickHouse operatörüne geldi. Operatör bu açıklamayı aldı. Ve bir şeyler yapması gerekiyor. ClickHouseInstallation nesnesi için güncelleme geldiyse kümeyi güncellemeniz gerekir. Operatörün görevi de kümeyi güncellemektir.

O ne yapıyor? Öncelikle bu güncellemeyle neler yapacağımıza dair bir eylem planı oluşturmamız gerekiyor. Güncellemeler çok küçük olabilir; YAML yürütmesinde küçüktür ancak kümede çok büyük değişiklikler gerektirebilir. Bu nedenle operatör bir plan oluşturur ve sonra ona sadık kalır.

Bu plana göre baklaları, hizmetleri yani. asıl görevi ne ise onu yap. Kubernetes'te bir ClickHouse kümesinin nasıl oluşturulacağı budur.

Şimdi böyle ilginç bir konuya değinelim. Bu, Kubernetes ile operatör arasındaki bir sorumluluk paylaşımıdır; Kubernetes'in ne yaptığı, operatörün ne yaptığı ve birbirleriyle nasıl etkileşimde bulundukları.

Kubernetes sistem olaylarından sorumludur; sistem kapsamı olarak yorumlanabilecek temel bir nesne kümesi için. Kubernetes, pod'ların nasıl başlatılacağını, konteynerlerin nasıl yeniden başlatılacağını, birimlerin nasıl bağlanacağını, ConfigMap ile nasıl çalışılacağını biliyor. sistem denilebilecek her şey.

Operatörler alan adlarında çalışır. Her operatör kendi konu alanı için yapılmıştır. Bunu ClickHouse için yaptık.

Ve operatör, bir kopya ekleme, diyagram oluşturma, izlemeyi ayarlama gibi konu alanı açısından tam olarak etkileşime girer. Bu bir bölünmeyle sonuçlanır.

Çoğaltma ekleme eylemini yaptığımızda bu sorumluluk paylaşımının nasıl gerçekleştiğine dair pratik bir örneğe bakalım.

Operatör bir kopya eklemek için bir görev alır. Operatör ne yapar? Operatör, bu tür şablonların, hacim taleplerinin açıklanması gereken yeni bir StatefulSet'in oluşturulması gerektiğini hesaplayacaktır.

Hepsini hazırlayıp K8'lere aktarıyor. ConfigMap, StatefulSet, Volume'a ihtiyacı olduğunu söylüyor. Kubernetes çalışıyor. Birlikte çalıştığı temel birimleri somutlaştırır.

Ve sonra ClickHouse operatörü tekrar devreye giriyor. Zaten üzerinde bir şeyler yapabileceği fiziksel bir kapsülü var. Ve ClickHouse operatörü yine alan adı terimleriyle çalışıyor. Onlar. Özellikle ClickHouse, bir kümeye bir kopya eklemek için öncelikle bu kümede bulunan veri şemasını yapılandırmanız gerekir. İkinci olarak, bu kopyanın açıkça izlenebilmesi için izlemeye dahil edilmesi gerekir. Operatör bunu zaten yapılandırıyor.

Ve ancak bundan sonra ClickHouse devreye giriyor, yani. başka bir üst düzey varlık. Bu zaten bir veritabanı. Kendi örneğine, kümeye katılmaya hazır başka bir yapılandırılmış kopyaya sahiptir.

Bir kopya eklerken uygulama zincirinin ve sorumluluk paylaşımının oldukça uzun olduğu ortaya çıktı.

Pratik görevlerimize devam ediyoruz. Zaten bir kümeniz varsa yapılandırmayı taşıyabilirsiniz.

ClickHouse'un anladığı mevcut xml'i yapıştırabilmeniz için bunu yaptık.

ClickHouse'a ince ayar yapabilirsiniz. HostPath'i, yerel depolamayı açıklarken bahsettiğim şey sadece bölgelere ayrılmış dağıtımdı. Bölgelere ayrılmış dağıtımın doğru şekilde nasıl yapılacağı budur.

Bir sonraki pratik görev izlemedir.

Kümemizin değişmesi durumunda izlemeyi periyodik olarak yapılandırmamız gerekir.

Diyagrama bakalım. Buradaki yeşil oklara zaten bakmıştık. Şimdi kırmızı oklara bakalım. Kümemizi bu şekilde izlemek istiyoruz. ClickHouse kümesindeki ölçümler Prometheus'a ve ardından Grafana'ya nasıl giriyor?

İzlemenin zorluğu nedir? Bu neden bir çeşit başarı olarak sunuluyor? Zorluk dinamiklerde yatıyor. Bir kümemiz olduğunda ve bu küme statik olduğunda, izlemeyi bir kez ayarlayabiliriz ve artık uğraşmayız.

Ancak çok sayıda kümemiz varsa veya bir şeyler sürekli değişiyorsa süreç dinamiktir. İzlemeyi sürekli olarak yeniden yapılandırmak kaynak ve zaman kaybıdır; hatta sadece tembellik. Bunun otomatikleştirilmesi gerekiyor. Zorluk sürecin dinamiklerinde yatmaktadır. Ve operatör bunu çok iyi bir şekilde otomatikleştiriyor.

Kümemiz nasıl gelişti? Başlangıçta öyleydi.

Sonra böyle oldu.

Sonunda bu hale geldi.

Ve izleme operatör tarafından otomatik olarak yapılır. Tek giriş noktası.

Ve tam çıkışta Grafana kontrol paneline bakıyoruz ve kümemizin yaşamının içeride nasıl kaynadığını görüyoruz.

Bu arada, Grafana kontrol paneli de doğrudan operatörümüzle birlikte kaynak koduyla dağıtılıyor. Bağlanıp kullanabilirsiniz. DevOps'umuz bana bu ekran görüntüsünü verdi.

Bundan sonra nereye gitmek isteriz? Bu:

• Test otomasyonunu geliştirin. Ana görev, yeni sürümlerin otomatik olarak test edilmesidir.
• Ayrıca ZooKeeper ile entegrasyonu gerçekten otomatikleştirmek istiyoruz. ZooKeeper operatörüyle entegrasyon planları da var. Onlar. ZooKeeper için bir operatör yazılmıştır ve iki operatörün daha uygun bir çözüm oluşturmak için entegre olmaya başlaması mantıklıdır.
• Daha karmaşık yaşamsal belirtiler yapmak istiyoruz.
• Şablonların devralınmasına yaklaştığımızı yeşil renkle vurguladım - TAMAMLANDI, yani operatörün bir sonraki sürümünde zaten şablonların mirasına sahip olacağız. Bu, parçalardan karmaşık konfigürasyonlar oluşturmanıza olanak tanıyan güçlü bir araçtır.
• Ve karmaşık görevlerin otomasyonunu istiyoruz. Bunlardan en önemlisi Yeniden Parçalamadır.

Bazı ara sonuçları ele alalım.

Sonuç olarak ne elde ederiz? Ve yapmaya değer mi, değmez mi? Veritabanını Kubernetes'e sürüklemeye çalışmak ve genel olarak operatörü, özel olarak da Alitnity operatörünü kullanmak gerekli mi?

Çıktıda şunu elde ederiz:

• Yapılandırma, dağıtım ve bakımın önemli ölçüde basitleştirilmesi ve otomasyonu.
• Anında yerleşik izleme.
• Ve karmaşık durumlar için kullanıma hazır kodlanmış şablonlar. Replika ekleme gibi bir işlemin manuel olarak yapılmasına gerek yoktur. Bunu operatör yapar.

Son bir soru kaldı. Kubernetes'te zaten bir veritabanımız var, sanallaştırma. Özellikle ClickHouse performans için optimize edildiğinden böyle bir çözümün performansı ne olacak?

Cevap her şey yolunda! Detaylara girmeyeceğim, bu ayrı bir raporun konusu.

Ama TSBS diye bir proje var. Ana görevi nedir? Bu bir veritabanı performans testidir. Bu, sıcak ile sıcak, yumuşak ile yumuşak arasında bir karşılaştırma girişimidir.

Nasıl çalışıyor? Bir veri seti oluşturulur. Daha sonra bu veri seti aynı testler kullanılarak farklı veritabanlarında çalıştırılır. Ve her veritabanı bir sorunu kendi bildiği yöntemle çözer. Daha sonra sonuçları karşılaştırabilirsiniz.

Zaten çok sayıda veritabanını destekliyor. Üç ana tanesini belirledim. Bu:

• Zaman ÖlçeğiDB.
• InfluxDB.
• ClickHouse.

Benzer bir çözümle de karşılaştırma yapıldı. RedShift ile karşılaştırma. Karşılaştırma Amazon'da yapıldı. ClickHouse bu konuda da herkesin çok ilerisinde.

Söylediklerimden ne gibi sonuçlar çıkarılabilir?

• Kubernetes'te veritabanı mümkündür. Muhtemelen her şey mümkün, ancak genel olarak mümkün gibi görünüyor. Operatörümüzün yardımıyla Kubernetes'te ClickHouse kesinlikle mümkündür.
• Operatör süreçlerin otomatikleştirilmesine yardımcı olur ve hayatı gerçekten kolaylaştırır.
• Performans normaldir.
• Ve bize öyle geliyor ki bu kullanılabilir ve kullanılmalıdır.

Açık kaynak - bize katılın!

Daha önce de söylediğim gibi operatör tamamen açık kaynaklı bir ürün, dolayısıyla maksimum sayıda kişi kullansa çok iyi olur. Bize katılın! Hepinizi bekliyoruz!

Teşekkür ederim!

sorular

Rapor için teşekkürler! Benim adım Anton. Ben SEMrush'lıyım. Günlük tutmanın ne durumda olduğunu merak ediyorum. Kümenin tamamı hakkında konuşursak, izlemeyi duyuyoruz, ancak günlüğe kaydetmeyle ilgili hiçbir şey yok. Örneğin donanım konusunda bir küme oluşturduk. Ve standart araçları kullanarak bunları ortak bir yığın halinde toplayan merkezi günlük kaydı kullanıyoruz. Ve oradan bizi ilgilendiren verileri alıyoruz.

Güzel soru, yani yapılacaklar listesine giriş yapmak. Operatörümüz bunu henüz otomatikleştirmiyor. Hala gelişiyor, proje hala oldukça genç. Günlüğe kaydetme ihtiyacını anlıyoruz. Bu da çok önemli bir konudur. Ve muhtemelen izlemekten daha az önemli değildir. Ancak uygulama listesinin ilk sırasında izleme vardı. Loglama olacak. Doğal olarak kümenin yaşamının tüm yönlerini otomatikleştirmeye çalışıyoruz. Dolayısıyla cevap şu ki şu anda operatör maalesef bunu nasıl yapacağını bilmiyor ama planlarda var, yapacağız. Katılmak istiyorsanız lütfen isteği çekin.

Merhaba! Rapor için teşekkürler! Kalıcı Hacimlerle ilgili standart bir sorum var. Bu operatörle bir konfigürasyon oluşturduğumuzda, operatör belirli bir diskin veya klasörün hangi düğüme eklendiğini nasıl belirler? Öncelikle ona ClickHouse'umuzu diski olan bu düğümlere yerleştirmemizi rica ediyoruz.

Anladığım kadarıyla bu soru yerel depolamanın, özellikle de hostPath kısmının devamı niteliğinde. Bu, tüm sisteme, şu veya bu yol boyunca monte edilmiş fiziksel olarak bağlı bir diske sahip olduğumuz şu veya bu düğümde kapsülün başlatılması gerektiğini açıklamak gibidir. Bu, çok yüzeysel olarak değindiğim bir bölüm çünkü oradaki cevap oldukça büyük.

Kısaca şuna benziyor. Doğal olarak bu hacimleri sağlamamız gerekiyor. Şu anda yerel depolamada dinamik bir provizyon bulunmadığından DevOps'un bu birimleri diskleri kendisinin kesmesi gerekiyor. Ve Kubernetes'in, şu ve bu düğümlerde bulunan şu ve bu sınıftan Kalıcı hacimlere sahip olacağınızı açıklamaları gerekir. O zaman Kubernetes'e, falan yerel depolama sınıfı gerektiren bölmelerin, etiketler kullanılarak yalnızca şu ve bu düğümlere yönlendirilmesi gerektiğini açıklamanız gerekecek. Bu amaçlar doğrultusunda, operatör bir tür etiket ve ana bilgisayar örneği başına bir etiket atama yeteneğine sahiptir. Ve pod'ların Kubernetes tarafından yalnızca basit anlamda gereksinimleri, etiketleri karşılayan düğümlerde çalışacak şekilde yönlendirileceği ortaya çıktı. Yöneticiler etiketleri manuel olarak atar ve disklerin hazırlığını yapar. Ve sonra ölçeklenir.

Ve üçüncü seçenek olan yerel, bunu biraz daha kolaylaştırmaya yardımcı oluyor. Daha önce de vurguladığım gibi, bu, sonuçta maksimum performansın elde edilmesine yardımcı olan, ayarlama konusunda özenli bir çalışmadır.

Bununla ilgili ikinci bir sorum var. Kubernetes, bir düğümü kaybedip kaybetmememiz bizim için önemli olmayacak şekilde tasarlandı. Parçamızın takıldığı düğümü kaybedersek bu durumda ne yapmalıyız?

Evet, Kubernetes başlangıçta kapsüllerimizle olan ilişkimizin sığır gibi olduğu yönünde konumlandırılmıştı, ancak burada her disk bir evcil hayvan gibi oluyor. Öyle bir sorun var ki bunları bir kenara atamayız. Ve Kubernetes'in gelişimi, sanki tamamen atılmış bir kaynakmış gibi, onu tamamen felsefi olarak ele almanın imkansız olduğu yöne doğru gidiyor.

Şimdi pratik bir soruya geçelim. Diskin bulunduğu düğümü kaybederseniz ne yapmalısınız? Burada sorun daha üst düzeyde çözülüyor. ClickHouse örneğinde daha yüksek düzeyde çalışan kopyalarımız var. ClickHouse düzeyinde.

Sonuçta ortaya çıkan eğilim nedir? DevOps, verilerin kaybolmamasını sağlamaktan sorumludur. Çoğaltmayı doğru şekilde ayarlamalı ve çoğaltmanın çalıştığından emin olmalıdır. ClickHouse düzeyindeki kopyanın kopyalanmış verileri olması gerekir. Bu operatörün çözeceği bir sorun değil. Ve Kubernetes'in kendisinin çözdüğü sorun değil. Bu ClickHouse düzeyindedir.

Demir düğümünüz düşerse ne yapmalısınız? Ve ikinci bir tane kurmanız, diski uygun şekilde hazırlamanız ve etiketleri uygulamanız gerekeceği ortaya çıktı. Bundan sonra Kubernetes'in üzerinde bir bulut sunucusu podunu başlatabilmesi gereksinimlerini karşılayacak. Kubernetes bunu başlatacak. Pod sayınız belirtilen sayıyı karşılamaya yetmiyor. Gösterdiğim döngüden geçecek. Ve en üst düzeyde ClickHouse, bir kopyaya girdiğimizi, bunun hala boş olduğunu ve ona veri aktarmaya başlamamız gerektiğini anlayacaktır. Onlar. Bu süreç henüz tam olarak otomatikleştirilmemiştir.

Rapor için teşekkürler! Her türlü kötü şey olduğunda, operatör çöküp yeniden başlatıldığında ve o anda olaylar geldiğinde, bunu bir şekilde halledebiliyor musunuz?

Operatör çöküp yeniden başlatılırsa ne olur, değil mi?

Evet. Ve o anda olaylar geldi.

Bu durumda ne yapılacağı görevi kısmen operatör ile Kubernetes arasında paylaşılıyor. Kubernetes, meydana gelen bir olayı yeniden oynatma yeteneğine sahiptir. Tekrar oynatıyor. Operatörün görevi ise olay günlüğü kendisine tekrar oynatıldığında bu olayların önemsiz olmasını sağlamaktır. Ve böylece aynı olayın tekrar tekrar yaşanması sistemimizi bozmaz. Ve operatörümüz bu görevle başa çıkıyor.

Merhaba! Rapor için teşekkürler! Dmitry Zavyalov, şirket Smedova. Operatöre haproxy ile yapılandırma yeteneği ekleme planları var mı? Standart olanın yanı sıra başka bir dengeleyiciyle de ilgilenirim, böylece akıllı olur ve ClickHouse'un gerçekten orada olduğunu anlar.

Ingress'ten mi bahsediyorsun?

Evet, Ingress'i haproxy ile değiştirin. Haproxy'de kopyaların bulunduğu kümenin topolojisini belirleyebilirsiniz.

Henüz bunu düşünmedik. İhtiyacınız varsa ve neden gerekli olduğunu açıklayabiliyorsanız, özellikle katılmak istiyorsanız bunu uygulamak mümkün olacaktır. Seçeneği değerlendirmekten memnuniyet duyarız. Kısa cevap hayır, şu anda böyle bir işlevselliğe sahip değiliz. İpucu için teşekkürler, bu konuyu inceleyeceğiz. Ayrıca kullanım durumunu ve pratikte buna neden ihtiyaç duyulduğunu da açıklarsanız, örneğin GitHub'da sorunlar yaratırsanız, bu harika olacaktır.

Zaten var.

İyi. Her türlü öneriye açığız. Ve yapılacaklar listesine haproxy eklendi. Yapılacaklar listesi büyüyor, henüz küçülmüyor. Ama bu iyi, ürünün talep edildiği anlamına geliyor.

Kaynak: habr.com