Kubernetes'teki Kafka iyi mi?

Selamlar Habr!

Bir zamanlar konuyu Rusya pazarına ilk tanıtan bizdik Kafka Ve devam et izleyin gelişimi için. Özellikle Kafka ile arasındaki etkileşim konusunu bulduk. Kubernetes. Gözlemlenebilir (ve oldukça dikkatli) makale bu konu geçen yıl Ekim ayında Confluent blogunda Gwen Shapira'nın yazarlığında yayınlanmıştı. Bugün dikkatinizi, başlığında soru işareti olmasına rağmen konuyu daha kapsamlı bir şekilde inceleyen ve metne ilginç bağlantılarla eşlik eden Johann Gyger'in Nisan ayındaki daha yeni bir makalesine çekmek istiyoruz. Eğer yapabiliyorsanız, lütfen “kaos maymunu”nun ücretsiz çevirisini bize bağışlayın!

Giriş

Kubernetes, durum bilgisi olmayan iş yüklerini işleyecek şekilde tasarlanmıştır. Tipik olarak bu tür iş yükleri bir mikro hizmet mimarisi biçiminde sunulur, hafiftirler, yatay olarak iyi ölçeklenirler, 12 faktörlü uygulamaların ilkelerini takip ederler ve devre kesiciler ve kaos maymunlarıyla çalışabilirler.

Kafka ise esasen dağıtılmış bir veritabanı görevi görüyor. Bu nedenle çalışırken devletle uğraşmanız gerekir ve bu bir mikro hizmetten çok daha ağırdır. Kubernetes durum bilgisi olan yükleri destekler, ancak Kelsey Hightower'ın iki tweet'inde işaret ettiği gibi bunların dikkatli bir şekilde ele alınması gerekir:

Bazı insanlar, Kubernetes'i durum bilgisi olan bir iş yüküne aktarırsanız, bunun RDS'ye rakip olabilecek, tamamen yönetilen bir veritabanı haline geleceğini düşünüyor. Bu yanlış. Belki yeterince sıkı çalışırsanız, ek bileşenler eklerseniz ve SRE mühendislerinden oluşan bir ekibin ilgisini çekerseniz, RDS'yi Kubernetes'in üzerine kurabilirsiniz.

Kubernetes'te durum bilgisi olan iş yüklerini çalıştırırken herkesin çok dikkatli olmasını her zaman öneririm. "Kubernetes'te durum bilgisi olan iş yüklerini çalıştırabilir miyim?" diye soran çoğu kişinin Kubernetes'le ve genellikle sordukları iş yüküyle ilgili yeterli deneyimi yoktur.

Peki Kafka'yı Kubernetes'te çalıştırmalı mısınız? Karşı soru: Kafka, Kubernetes olmadan daha iyi çalışacak mı? Bu yüzden bu makalede Kafka ve Kubernetes'in birbirini nasıl tamamladığını ve bunları birleştirmenin ne gibi tuzaklara yol açabileceğini vurgulamak istiyorum.

Tamamlanma zamanı

Temel şey hakkında konuşalım - çalışma zamanı ortamının kendisi

Süreç

Kafka brokerleri CPU dostudur. TLS bir miktar ek yük getirebilir. Ancak Kafka istemcileri şifreleme kullanırlarsa daha fazla CPU yoğunluğuna sahip olabilirler ancak bu, aracıları etkilemez.

Bellek

Kafka simsarları hafızayı yer. JVM yığın boyutu genellikle 4-5 GB ile sınırlıdır, ancak Kafka sayfa önbelleğini çok yoğun kullandığından aynı zamanda çok fazla sistem belleğine de ihtiyacınız olacaktır. Kubernetes'te konteyner kaynağını ve istek sınırlarını buna göre ayarlayın.

Bilgi deposu

Kapsayıcılardaki veri depolaması geçicidir; yeniden başlatıldığında veriler kaybolur. Kafka verileri için bir birim kullanabilirsiniz emptyDiretkisi benzer olacaktır: aracı verileriniz tamamlandıktan sonra kaybolacaktır. Mesajlarınız yine de diğer aracılarda kopya olarak saklanabilir. Bu nedenle, yeniden başlatmanın ardından başarısız olan aracının öncelikle tüm verileri çoğaltması gerekir ve bu işlem çok zaman alabilir.

Bu nedenle uzun vadeli veri depolamayı kullanmalısınız. XFS dosya sistemiyle veya daha doğrusu ext4 ile yerel olmayan uzun vadeli depolama olsun. NFS'yi kullanmayın. Seni uyardım. NFS sürümleri v3 veya v4 çalışmayacaktır. Kısacası Kafka komisyoncusu, NFS'deki "aptalca yeniden adlandırma" sorunu nedeniyle veri dizinini silemezse çökecektir. Eğer seni henüz ikna etmediysem, çok dikkatli bir şekilde bu makaleyi oku. Kubernetes'in yeniden başlatma veya yer değiştirme sonrasında yeni bir düğümü daha esnek bir şekilde seçebilmesi için veri deposu yerel olmamalıdır.

ağ

Çoğu dağıtılmış sistemde olduğu gibi Kafka'nın performansı büyük ölçüde ağ gecikmesini minimumda ve bant genişliğini maksimumda tutmaya bağlıdır. Kullanılabilirliği azaltacağından tüm aracıları aynı düğümde barındırmaya çalışmayın. Bir Kubernetes düğümü başarısız olursa Kafka kümesinin tamamı başarısız olur. Ayrıca Kafka kümesini tüm veri merkezlerine dağıtmayın. Aynı şey Kubernetes kümesi için de geçerli. Bu durumda iyi bir uzlaşma, farklı kullanılabilirlik bölgeleri seçmektir.

Yapılandırma

Düzenli manifestolar

Kubernetes web sitesinde çok iyi bir rehber ZooKeeper'ın bildirimleri kullanarak nasıl yapılandırılacağı hakkında. ZooKeeper Kafka'nın bir parçası olduğundan, burada hangi Kubernetes kavramlarının geçerli olduğunu öğrenmeye başlamak için burası iyi bir yerdir. Bunu anladıktan sonra aynı kavramları Kafka kümesiyle kullanabilirsiniz.

• Altında: Pod, Kubernetes'teki konuşlandırılabilir en küçük birimdir. Bir bölme iş yükünüzü içerir ve bölmenin kendisi de kümenizdeki bir işleme karşılık gelir. Bir bölme bir veya daha fazla kapsayıcı içerir. Topluluktaki her ZooKeeper sunucusu ve Kafka kümesindeki her aracı ayrı bir bölmede çalışacaktır.
• Durumsal Küme: StatefulSet, birden çok durum bilgisi olan iş yükünü işleyen bir Kubernetes nesnesidir ve bu tür iş yükleri koordinasyon gerektirir. StatefulSets, kapsüllerin sıralanması ve benzersizliği konusunda garantiler sağlar.
• Başsız hizmetler: Hizmetler, mantıksal bir ad kullanarak bölmeleri istemcilerden ayırmanıza olanak tanır. Bu durumda Kubernetes yük dengelemeden sorumludur. Ancak ZooKeeper ve Kafka gibi durum bilgisi olan iş yüklerini çalıştırırken istemcilerin belirli bir örnekle iletişim kurması gerekir. Başsız hizmetlerin kullanışlı olduğu yer burasıdır: bu durumda istemcinin hâlâ mantıksal bir adı olacaktır ancak bölmeyle doğrudan iletişime geçmeniz gerekmez.
• Uzun vadeli depolama hacmi: Bu birimler yukarıda bahsedilen yerel olmayan blok kalıcı depolamayı yapılandırmak için gereklidir.

Üzerinde Yolean Kubernetes'te Kafka'yı kullanmaya başlamanıza yardımcı olacak kapsamlı bir bildirim seti sağlar.

Dümen çizelgeleri

Helm, Kubernetes için yum, apt, Homebrew veya Chocolatey gibi işletim sistemi paket yöneticileriyle karşılaştırılabilecek bir paket yöneticisidir. Helm çizelgelerinde açıklanan önceden tanımlanmış yazılım paketlerinin kurulumunu kolaylaştırır. İyi seçilmiş bir Helm grafiği, Kubernetes'te Kafka'yı kullanmak için tüm parametrelerin doğru şekilde nasıl yapılandırılacağına dair zorlu görevi kolaylaştırır. Birkaç Kafka diyagramı var: resmi olanı kuluçka makinesi durumunda, şuradan bir tane var Kavşak, bir tane daha - itibaren Bitnami.

operatörler

Helm'in bazı eksiklikleri olduğundan, başka bir araç önemli ölçüde popülerlik kazanıyor: Kubernetes operatörleri. Operatör yalnızca Kubernetes için yazılım paketlemekle kalmaz, aynı zamanda bu tür yazılımları dağıtmanıza ve yönetmenize de olanak tanır.

Bu liste muhteşem operatörler Kafka için iki operatörden bahsediliyor. Onlardan biri - Strimzi. Strimzi ile Kafka kümenizi birkaç dakika içinde çalışır duruma getirmek kolaydır. Neredeyse hiçbir yapılandırmaya gerek yoktur, ayrıca operatörün kendisi de küme içinde noktadan noktaya TLS şifrelemesi gibi bazı güzel özellikler sağlar. Confluent ayrıca şunları sağlar: kendi operatörü.

Proizvoditelnost

Kafka örneğinizi kıyaslayarak performansı test etmek önemlidir. Bu tür testler, sorunlar ortaya çıkmadan önce potansiyel darboğazları bulmanıza yardımcı olacaktır. Neyse ki Kafka halihazırda iki performans test aracı sunuyor: kafka-producer-perf-test.sh и kafka-consumer-perf-test.sh. Bunlardan aktif olarak yararlanın. Referans olarak, burada açıklanan sonuçlara başvurabilirsiniz. bu gönderi Jay Kreps, ya da odaklan bu degerlendirme Amazon MSK, Stéphane Maarek'ten.

operasyonlar

İzleme

Sistemde şeffaflık çok önemlidir - aksi takdirde sistemde neler olduğunu anlayamazsınız. Bugün bulut yerel tarzında metrik tabanlı izleme sağlayan sağlam bir araç seti var. Bu amaca yönelik iki popüler araç Prometheus ve Grafana'dır. Prometheus, bir JMX dışa aktarıcı kullanarak tüm Java süreçlerinden (Kafka, Zookeeper, Kafka Connect) metrikleri en basit şekilde toplayabilir. cAdvisor metriklerini eklerseniz Kubernetes'te kaynakların nasıl kullanıldığını daha iyi anlayabilirsiniz.

Strimzi'nin Kafka için çok uygun bir Grafana kontrol paneli örneği var. Yeterince kopyalanmayan sektörler veya çevrimdışı olanlar gibi temel ölçümleri görselleştirir. Orada her şey çok açık. Bu ölçümler, kaynak kullanımı ve performans bilgilerinin yanı sıra kararlılık göstergeleri ile tamamlanmaktadır. Böylece hiçbir ücret ödemeden temel Kafka küme izlemesine sahip oluyorsunuz!

Kaynak: Streamzi.io/docs/master/#kafka_dashboard

Tüm bunları müşteri izleme (tüketiciler ve üreticilere ilişkin ölçümler) ve gecikme izleme (bunun için Yuva) ve uçtan uca izleme - bu kullanım için Kafka Monitörü.

Kerestecilik

Günlüğe kaydetme başka bir kritik görevdir. Kafka kurulumunuzdaki tüm kapsayıcıların oturum açtığından emin olun stdout и stderrAyrıca Kubernetes kümenizin tüm günlükleri merkezi bir günlük kaydı altyapısında topladığından emin olun; Elasticsearch.

Fonksiyonel test

Kubernetes, kapsüllerinizin normal şekilde çalışıp çalışmadığını kontrol etmek için canlılık ve hazırlık araştırmalarını kullanır. Canlılık denetimi başarısız olursa Kubernetes bu kapsayıcıyı durduracak ve yeniden başlatma politikası uygun şekilde ayarlanmışsa otomatik olarak yeniden başlatacaktır. Hazırlık denetimi başarısız olursa Kubernetes, kapsülü hizmet isteklerinden yalıtır. Dolayısıyla bu tür durumlarda artık manuel müdahaleye gerek kalmıyor, bu da büyük bir artı.

Güncellemeleri kullanıma sunma

StatefulSets otomatik güncellemeleri destekler: RollingUpdate stratejisini seçerseniz Kafka'nın altındaki her biri sırayla güncellenecektir. Bu sayede kesinti süresi sıfıra indirilebilir.

Ölçeklendirme

Kafka kümesini ölçeklendirmek kolay bir iş değildir. Ancak Kubernetes, bölmeleri belirli sayıda kopyaya ölçeklendirmeyi çok kolaylaştırır; bu, istediğiniz kadar Kafka aracısını bildirimli olarak tanımlayabileceğiniz anlamına gelir. Bu durumda en zor şey, ölçek büyütüldükten sonra veya küçültülmeden önce sektörlerin yeniden atanmasıdır. Yine Kubernetes bu görevde size yardımcı olacaktır.

yönetim

Konu oluşturma ve sektörleri yeniden atama gibi Kafka kümenizi yönetmeyle ilgili görevler, bölmelerinizdeki komut satırı arayüzünü açarak mevcut kabuk komut dosyalarını kullanarak yapılabilir. Ancak bu çözüm pek de güzel değil. Strimzi, konuların farklı bir operatör kullanılarak yönetilmesini destekler. Burada geliştirilebilecek bazı noktalar var.

Yedekle ve yeniden yükle

Artık Kafka'nın kullanılabilirliği aynı zamanda Kubernetes'in kullanılabilirliğine de bağlı olacaktır. Kubernetes kümeniz başarısız olursa en kötü senaryoda Kafka kümeniz de başarısız olur. Murphy yasasına göre bu kesinlikle gerçekleşecek ve veri kaybedeceksiniz. Bu tür riskleri azaltmak için iyi bir yedekleme konseptine sahip olun. MirrorMaker'ı kullanabilirsiniz, başka bir seçenek de bunun için S3'ü kullanmaktır. İleti Zalando'dan.

Sonuç

Küçük ve orta ölçekli Kafka kümeleriyle çalışırken, ek esneklik sağladığı ve operatör deneyimini basitleştirdiği için Kubernetes'i kullanmak kesinlikle faydalıdır. İşlevsel olmayan çok önemli bir gecikme ve/veya aktarım hızı gereksinimleriniz varsa başka bir dağıtım seçeneğini değerlendirmek daha iyi olabilir.

Kaynak: habr.com