Salam, Habr!
Bir vaxtlar mövzunu Rusiya bazarına ilk təqdim edən biz olmuşuq və davam edin inkişafı üçün. Xüsusilə Kafka ilə qarşılıqlı əlaqə mövzusunu tapdıq . Müşahidə edilə bilən (və olduqca diqqətli) bu mövzu keçən ilin oktyabrında Qven Şapiranın müəllifliyi ilə Confluent bloqunda dərc edilib. Bu gün diqqətinizi, başlıqda sual işarəsi olmadan olmasa da, mətni maraqlı keçidlərlə müşayiət edərək mövzunu daha məzmunlu şəkildə araşdıran Johann Gyger-in aprel ayında dərc olunmuş daha yeni məqaləsinə cəlb etmək istərdik. Zəhmət olmasa "xaos meymunu"nun pulsuz tərcüməsini bağışlayın!
Giriş
Kubernetes vətəndaşlığı olmayan iş yüklərini idarə etmək üçün nəzərdə tutulmuşdur. Tipik olaraq, bu cür iş yükləri mikroservis arxitekturası şəklində təqdim olunur, onlar yüngüldür, üfüqi şəkildə yaxşı ölçülür, 12 faktorlu tətbiqlərin prinsiplərinə əməl edir və elektrik açarları və xaos meymunları ilə işləyə bilir.
Kafka isə əslində paylanmış verilənlər bazası kimi çıxış edir. Beləliklə, işləyərkən dövlətlə məşğul olmalısınız və bu, mikroservisdən qat-qat ağırdır. Kubernetes statistik yükləri dəstəkləyir, lakin Kelsey Hightower iki tvitdə qeyd etdiyi kimi, onlarla ehtiyatlı davranılmalıdır:
Bəzi insanlar hesab edirlər ki, Kubernetes-i dövlət iş yükünə çevirsəniz, o, RDS ilə rəqabət aparan tam idarə olunan verilənlər bazasına çevrilir. Bu səhvdir. Bəlkə də kifayət qədər çalışsanız, əlavə komponentlər əlavə etsəniz və SRE mühəndislərindən ibarət komanda cəlb etsəniz, Kubernetes-in üstündə RDS qura biləcəksiniz.
Mən həmişə hər kəsə Kubernetes-də statistik iş yükləri işləyərkən həddindən artıq ehtiyatlı olmağı tövsiyə edirəm. “Kubernetes-də dövlət iş yükünü işlədə bilərəm” deyə soruşan insanların çoxu Kubernetes və tez-tez soruşduqları iş yükü ilə kifayət qədər təcrübəyə malik deyillər.
Beləliklə, Kafkanı Kubernetes-də idarə etməlisiniz? Əks sual: Kafka Kubernetessiz daha yaxşı işləyəcəkmi? Buna görə də bu məqalədə Kafka və Kubernetesin bir-birini necə tamamladığını və onları birləşdirərkən hansı tələlərin ola biləcəyini vurğulamaq istəyirəm.
Tamamlanma vaxtı
Gəlin əsas şey haqqında danışaq - iş vaxtı mühitinin özü
proses
Kafka brokerləri CPU dostudur. TLS bəzi əlavə xərclər təqdim edə bilər. Bununla belə, Kafka müştəriləri şifrələmədən istifadə etsələr daha CPU intensiv ola bilər, lakin bu, brokerlərə təsir etmir.
yaddaş
Kafka dəllalları yaddaşı yeyirlər. JVM yığın ölçüsü adətən 4-5 GB ilə məhdudlaşır, lakin Kafka səhifə keşindən çox istifadə etdiyi üçün sizə çoxlu sistem yaddaşı da lazım olacaq. Kubernetes-də konteyner resursu təyin edin və buna uyğun olaraq məhdudiyyətlər tələb edin.
Məlumat anbarı
Konteynerlərdə məlumatların saxlanması efemerdir - yenidən işə salındıqda məlumatlar itirilir. Kafka məlumatları üçün bir həcmdən istifadə edə bilərsiniz emptyDir, və təsir oxşar olacaq: başa çatdıqdan sonra broker məlumatlarınız itiriləcək. Mesajlarınız hələ də replika kimi digər brokerlərdə saxlanıla bilər. Buna görə də, yenidən başladıqdan sonra uğursuz broker əvvəlcə bütün məlumatları təkrarlamalıdır və bu proses çox vaxt apara bilər.
Buna görə uzunmüddətli məlumat saxlama müddətindən istifadə etməlisiniz. XFS fayl sistemi və ya daha dəqiq desək, ext4 ilə yerli olmayan uzunmüddətli saxlama olsun. NFS istifadə etməyin. Mən sizə xəbərdarlıq etdim. NFS v3 və ya v4 versiyaları işləməyəcək. Qısacası, Kafka brokeri NFS-də "axmaq adının dəyişdirilməsi" probleminə görə məlumat qovluğunu silə bilmədikdə qəzaya uğrayacaq. Əgər səni hələ də inandırmamışamsa, çox diqqətlə . Məlumat anbarı qeyri-lokal olmalıdır ki, Kubernetes yenidən başladıqdan və ya yerdəyişmədən sonra yeni qovşağı daha çevik şəkildə seçə bilsin.
Şəbəkə
Əksər paylanmış sistemlərdə olduğu kimi, Kafkanın performansı şəbəkə gecikməsini minimumda və ötürmə qabiliyyətini maksimumda saxlamaqdan çox asılıdır. Bütün brokerləri eyni qovşaqda yerləşdirməyə çalışmayın, çünki bu, mövcudluğu azaldacaq. Kubernetes nodu uğursuz olarsa, bütün Kafka klasteri uğursuz olacaq. Həmçinin, Kafka klasterini bütün məlumat mərkəzləri arasında yaymayın. Eyni şey Kubernetes klasterinə də aiddir. Bu vəziyyətdə yaxşı bir kompromis müxtəlif mövcudluq zonalarını seçməkdir.
Konfiqurasiya
Daimi manifestlər
Kubernetes saytında var manifestlərdən istifadə edərək ZooKeeper-i necə konfiqurasiya etmək haqqında. ZooKeeper Kafkanın bir hissəsi olduğu üçün bura Kubernetes konsepsiyalarının burada tətbiq olunduğu ilə tanış olmaq üçün yaxşı yerdir. Bunu başa düşdükdən sonra eyni anlayışları Kafka çoxluğu ilə istifadə edə bilərsiniz.
- Altında: Pod Kubernetes-də yerləşdirilə bilən ən kiçik bölmədir. Pod sizin iş yükünüzü ehtiva edir və pod özü klasterinizdəki prosesə uyğundur. Bir pod bir və ya daha çox konteynerdən ibarətdir. Ansambldakı hər bir ZooKeeper serveri və Kafka klasterindəki hər bir broker ayrıca podda işləyəcək.
- Stateful Set: StatefulSet birdən çox statuslu iş yükünü idarə edən Kubernetes obyektidir və belə iş yükləri koordinasiya tələb edir. StatefulSets podların sifarişi və onların unikallığı ilə bağlı zəmanət verir.
- Başsız xidmətlər: Xidmətlər məntiqi addan istifadə edərək müştərilərdən podları ayırmağa imkan verir. Bu vəziyyətdə Kubernetes yük balansına cavabdehdir. Bununla belə, ZooKeeper və Kafka kimi statuslu iş yükləri işləyərkən müştərilər xüsusi instansiya ilə əlaqə saxlamalıdırlar. Başsız xidmətlərin lazımlı olduğu yer budur: bu halda müştərinin hələ də məntiqi adı olacaq, lakin siz birbaşa pod ilə əlaqə saxlamağınız lazım olmayacaq.
- Uzunmüddətli saxlama həcmi: Bu həcmlər yuxarıda qeyd olunan qeyri-yerli blok davamlı yaddaşı konfiqurasiya etmək üçün lazımdır.
Haqqında Kubernetes-də Kafka ilə başlamağa kömək etmək üçün hərtərəfli manifestlər dəsti təqdim edir.
Sükan qrafikləri
Helm, yum, apt, Homebrew və ya Chocolatey kimi OS paket menecerləri ilə müqayisə edilə bilən bir Kubernetes üçün paket meneceridir. Bu, Helm diaqramlarında təsvir edilmiş əvvəlcədən təyin edilmiş proqram paketlərini quraşdırmağı asanlaşdırır. Yaxşı seçilmiş Helm diaqramı, Kubernetes-də Kafkadan istifadə etmək üçün bütün parametrləri düzgün konfiqurasiya etmək kimi çətin tapşırığı asanlaşdırır. Bir neçə Kafka diaqramı var: rəsmi olanı yerləşir , biri var , daha biri - dən .
Operatorlar
Helmin müəyyən çatışmazlıqları olduğundan, başqa bir alət xeyli populyarlıq qazanır: Kubernetes operatorları. Operator təkcə Kubernetes üçün proqram paketləri hazırlamır, həm də bu cür proqram təminatını yerləşdirməyə və onu idarə etməyə imkan verir.
В списке Kafka üçün iki operator qeyd olunur. Onlardan biri - . Strimzi ilə Kafka klasterinizi bir neçə dəqiqə ərzində işə salmaq asandır. Faktiki olaraq heç bir konfiqurasiya tələb olunmur, əlavə olaraq, operatorun özü bəzi gözəl xüsusiyyətlər təqdim edir, məsələn, klaster daxilində nöqtədən nöqtəyə TLS şifrələməsi. Confluent də təmin edir .
Məhsuldarlıq
Kafka nümunənizi müqayisə edərək performansı yoxlamaq vacibdir. Bu cür testlər problemlər yaranmazdan əvvəl sizə potensial darboğazları tapmağa kömək edəcək. Xoşbəxtlikdən, Kafka artıq iki performans test aləti təqdim edir: kafka-producer-perf-test.sh и kafka-consumer-perf-test.sh. Onlardan aktiv istifadə edin. İstinad üçün aşağıda təsvir olunan nəticələrə müraciət edə bilərsiniz Jay Kreps, və ya diqqət Stephane Maarek tərəfindən Amazon MSK.
Əməliyyatlar
Monitorinq
Sistemdə şəffaflıq çox vacibdir - əks halda siz orada nə baş verdiyini başa düşməyəcəksiniz. Bu gün bulud yerli üslubunda ölçülərə əsaslanan monitorinqi təmin edən möhkəm bir alət dəsti var. Bu məqsədlə iki məşhur vasitə Prometey və Grafanadır. Prometheus JMX ixracatçısından istifadə edərək bütün Java proseslərindən (Kafka, Zookeeper, Kafka Connect) ölçüləri toplaya bilər - ən sadə şəkildə. Əgər cAdvisor ölçülərini əlavə etsəniz, Kubernetes-də resursların necə istifadə edildiyini daha yaxşı başa düşə bilərsiniz.
Strimzidə Kafka üçün Grafana tablosunun çox əlverişli nümunəsi var. O, əsas ölçüləri, məsələn, az təkrarlanan və ya oflayn olan sektorlar haqqında vizuallaşdırır. Orada hər şey çox aydındır. Bu ölçülər resursdan istifadə və performans məlumatları, həmçinin sabitlik göstəriciləri ilə tamamlanır. Beləliklə, əsas Kafka klasterinin monitorinqini heç bir şey üçün əldə edirsiniz!
Mənbə:
Bütün bunları müştəri monitorinqi (istehlakçılar və istehsalçılar üzrə göstəricilər), habelə gecikmə monitorinqi (bunun üçün var) ilə əlavə etmək yaxşı olardı. ) və başdan sona monitorinq - bu istifadə üçün .
Giriş
Giriş başqa bir kritik vəzifədir. Kafka quraşdırmanızdakı bütün konteynerlərin daxil olduğundan əmin olun stdout и stderr, həmçinin Kubernetes klasterinizin bütün qeydləri mərkəzi giriş infrastrukturuna birləşdirməsini təmin edin, məs. .
Funksional yoxlama
Kubernetes, podların normal işlədiyini yoxlamaq üçün canlılıq və hazırlıq zondlarından istifadə edir. Canlılıq yoxlanışı uğursuz olarsa, Kubernetes həmin konteyneri dayandıracaq və yenidən başlatma siyasəti müvafiq olaraq təyin edilərsə, onu avtomatik olaraq yenidən işə salacaq. Hazırlıq yoxlanışı uğursuz olarsa, Kubernetes podu xidmət sorğularından təcrid edir. Beləliklə, belə hallarda əl ilə müdaxilə artıq tələb olunmur, bu da böyük bir artıdır.
Yeniləmələrin yayılması
StatefulSets avtomatik yeniləmələri dəstəkləyir: RollingUpdate strategiyasını seçsəniz, Kafka altında hər biri öz növbəsində yenilənəcək. Bu yolla, dayanma müddəti sıfıra endirilə bilər.
Ölçəkləmə
Kafka klasterini miqyaslaşdırmaq asan məsələ deyil. Bununla belə, Kubernetes podları müəyyən sayda replikaya qədər genişləndirməyi çox asanlaşdırır, yəni siz istədiyiniz qədər Kafka brokerini deklarativ olaraq müəyyən edə bilərsiniz. Bu vəziyyətdə ən çətin şey, miqyasını artırdıqdan sonra və ya azaltmadan əvvəl sektorları yenidən təyin etməkdir. Yenə Kubernetes bu işdə sizə kömək edəcək.
İdarə
Mövzuların yaradılması və sektorların yenidən təyin edilməsi kimi Kafka klasterinizin idarə edilməsi ilə bağlı tapşırıqlar podlarınızda komanda xətti interfeysini açmaqla mövcud shell skriptlərindən istifadə etməklə həyata keçirilə bilər. Ancaq bu həll çox gözəl deyil. Strimzi fərqli operatordan istifadə edərək mövzuları idarə etməyi dəstəkləyir. Burada təkmilləşdirmə üçün bir yer var.
Rezervnoe kopirovanie və imkan
İndi Kafkanın mövcudluğu Kubernetes-in mövcudluğundan da asılı olacaq. Kubernetes klasteriniz uğursuz olarsa, ən pis halda Kafka klasteriniz də uğursuz olacaq. Mörfi qanununa görə, bu, mütləq baş verəcək və siz məlumatları itirəcəksiniz. Bu tip riskləri azaltmaq üçün yaxşı ehtiyat konsepsiyasına sahib olun. Siz MirrorMaker-dən istifadə edə bilərsiniz, başqa bir seçim isə burada təsvir olunduğu kimi bunun üçün S3-dən istifadə etməkdir Zalandodan.
Nəticə
Kiçik və orta ölçülü Kafka klasterləri ilə işləyərkən, əlavə rahatlıq təmin etdiyi və operator təcrübəsini asanlaşdırdığı üçün Kubernetes-dən istifadə etməyə mütləq dəyər. Çox əhəmiyyətli qeyri-funksional gecikmə və/və ya ötürmə qabiliyyəti tələbləriniz varsa, o zaman başqa yerləşdirmə variantını nəzərdən keçirmək daha yaxşı olar.
Mənbə: www.habr.com