Kubernetes дээр Кафка сайн уу?

Сайн байна уу, Хабр!

Нэгэн цагт бид Оросын зах зээлд энэ сэдвийг анхлан нэвтрүүлж байсан Kaфка мөн үргэлжлүүл мөр түүний хөгжлийн төлөө. Ялангуяа бид Кафка хоёрын харилцан үйлчлэлийн сэдвийг олсон Kubernetes. Ажиглах боломжтой (мөн маш болгоомжтой) нийтлэл Энэ сэдвийг өнгөрсөн оны аравдугаар сард Гвен Шапирагийн зохиогчийн дор Confluent блог дээр нийтэлсэн. Өнөөдөр бид та бүхний анхаарлыг XNUMX-р сард бичсэн Иоганн Гигерийн сүүлийн үеийн нийтлэлд анхаарлаа хандуулахыг хүсч байна, тэр хэдийгээр гарчигт асуултын тэмдэггүй ч гэсэн сэдвийг илүү нягт нямбай судалж, текстийг сонирхолтой холбоосоор дагалддаг. Боломжтой бол "chaos monkey"-ийн үнэгүй орчуулгыг уучлаарай!

Танилцуулга

Kubernetes нь харьяалалгүй ажлын ачааллыг зохицуулах зориулалттай. Ихэвчлэн ийм ажлын ачааллыг бичил үйлчилгээний архитектур хэлбэрээр танилцуулдаг, тэдгээр нь хөнгөн жинтэй, хэвтээ байдлаар сайн масштабтай, 12 хүчин зүйлийн хэрэглээний зарчмуудыг дагаж мөрддөг, таслуур болон эмх замбараагүй сармагчинтай ажиллах боломжтой.

Харин Кафка үндсэндээ тархсан мэдээллийн сангийн үүрэг гүйцэтгэдэг. Тиймээс, ажиллахдаа та төртэй харьцах ёстой бөгөөд энэ нь микро үйлчилгээнээс хамаагүй хүнд юм. Кубернетес нь төлөвтэй ачааллыг дэмждэг боловч Келси Хайтауэр хоёр жиргээнд дурдсанчлан тэдгээрийг болгоомжтой авч үзэх хэрэгтэй:

Зарим хүмүүс хэрэв та Кубернетесийг төлөвтэй ажлын ачаалалд оруулбал энэ нь RDS-тэй өрсөлдөхүйц бүрэн удирддаг мэдээллийн сан болно гэж боддог. Энэ бол буруу. Магадгүй, хэрэв та хангалттай шаргуу ажиллаж, нэмэлт бүрэлдэхүүн хэсгүүдийг нэмж, SRE инженерүүдийн багийг татах юм бол Kubernetes дээр RDS бүтээх боломжтой болно.

Kubernetes дээр төлөвтэй ажлын ачааллыг ажиллуулахдаа хүн бүр маш болгоомжтой байхыг би үргэлж зөвлөж байна. "Би Kubernetes дээр төлөвтэй ажлын ачааллыг ажиллуулж болох уу" гэж асуудаг ихэнх хүмүүс Кубернетестэй ажиллах хангалттай туршлагагүй байдаг бөгөөд ихэнхдээ тэдний асууж буй ажлын ачаалалтай байдаг.

Тэгэхээр та Кафкаг Кубернетес дээр ажиллуулах ёстой юу? Эсрэг асуулт: Кафка Кубернетесгүйгээр илүү сайн ажиллах уу? Тийм ч учраас би энэ нийтлэлд Кафка, Кубернетес хоёр бие биенээ хэрхэн нөхөж, нэгтгэх нь ямар бэрхшээл тулгарч болохыг онцлон харуулахыг хүсч байна.

Дуусгах хугацаа

Үндсэн зүйлийн талаар ярилцъя - ажиллах цагийн орчин өөрөө

үйл явц

Кафка брокерууд CPU-д ээлтэй байдаг. TLS нь зарим нэмэлт зардал оруулж болзошгүй. Гэсэн хэдий ч, Кафка үйлчлүүлэгчид шифрлэлт ашигладаг бол CPU-ийн ачаалал ихтэй байж болох ч энэ нь брокеруудад нөлөөлөхгүй.

санах ойн

Кафкагийн брокерууд ой санамжийг иддэг. JVM овоолгын хэмжээ нь ихэвчлэн 4-5 ГБ хүртэл хязгаарлагддаг боловч Кафка хуудасны кэшийг маш их ашигладаг тул танд маш их системийн санах ой хэрэгтэй болно. Kubernetes-д чингэлэгийн нөөцийг тохируулж, үүний дагуу хязгаарыг хүс.

Мэдээллийн дэлгүүр

Контейнерт өгөгдөл хадгалах нь түр зуурынх бөгөөд дахин эхлүүлэх үед өгөгдөл устах болно. Кафкагийн мэдээллийн хувьд та эзлэхүүнийг ашиглаж болно emptyDir, үр нөлөө нь ижил байх болно: таны брокерын мэдээлэл дууссаны дараа устах болно. Таны мессежийг бусад брокер дээр хуулбар хэлбэрээр хадгалах боломжтой. Тиймээс, дахин эхлүүлсний дараа бүтэлгүйтсэн брокер эхлээд бүх өгөгдлийг хуулбарлах ёстой бөгөөд энэ үйл явц нь маш их цаг хугацаа шаарддаг.

Ийм учраас та урт хугацааны өгөгдөл хадгалах ашиглах хэрэгтэй. Энэ нь XFS файлын систем эсвэл илүү нарийвчлалтай ext4 бүхий орон нутгийн бус урт хугацааны хадгалалт байх болтугай. NFS бүү ашигла. Би чамд анхааруулсан. NFS v3 эсвэл v4 хувилбарууд ажиллахгүй. Товчхондоо, Кафка брокер нь NFS дахь "тэнэг нэр солих" асуудлаас болж өгөгдлийн санг устгаж чадахгүй бол гацах болно. Хэрэв би чамайг ятгаж амжаагүй бол маш болгоомжтой байгаарай энэ нийтлэлийг уншина уу. Дата хадгалах газар нь орон нутгийн бус байх ёстой бөгөөд ингэснээр Кубернетес дахин эхлүүлэх эсвэл нүүлгэн шилжүүлсний дараа шинэ зангилааг илүү уян хатан сонгох боломжтой болно.

Сүлжээ

Ихэнх тархсан системүүдийн нэгэн адил Кафкагийн гүйцэтгэл нь сүлжээний хоцролтыг хамгийн бага, зурвасын өргөнийг хамгийн дээд хэмжээнд байлгахаас ихээхэн хамаардаг. Бүх брокеруудыг нэг цэг дээр байрлуулах гэж бүү оролдоорой, учир нь энэ нь хүртээмжийг бууруулна. Хэрэв Кубернетес зангилаа бүтэлгүйтвэл Кафка кластер бүхэлдээ бүтэлгүйтэх болно. Мөн Кафка кластерыг бүх мэдээллийн төвүүдэд тарааж болохгүй. Kubernetes кластерт мөн адил хамаарна. Энэ тохиолдолд сайн буулт бол өөр өөр бэлэн бүсийг сонгох явдал юм.

Тохиргоо

Тогтмол манифестууд

Kubernetes вэбсайтад байна маш сайн хөтөч манифест ашиглан ZooKeeper-г хэрхэн тохируулах талаар. ZooKeeper нь Кафкагийн нэг хэсэг учраас Kubernetes-ийн үзэл баримтлалыг эндээс олж мэдэхэд тохиромжтой газар юм. Үүнийг ойлгосны дараа та Кафка кластертай ижил ойлголтуудыг ашиглаж болно.

• Нь: Под бол Кубернетес дэх хамгийн жижиг байрлуулж болох нэгж юм. Под нь таны ажлын ачааллыг агуулдаг бөгөөд энэ нь өөрөө таны кластер дахь процесстой тохирч байна. Дотор нь нэг буюу хэд хэдэн сав агуулдаг. Чуулга дахь ZooKeeper сервер бүр болон Кафка кластер дахь брокер бүр тусдаа pod-д ажиллана.
• Stateful Set: StatefulSet нь хэд хэдэн төлөвтэй ажлын ачааллыг зохицуулдаг Kubernetes объект бөгөөд ийм ачаалал нь зохицуулалт шаарддаг. StatefulSets нь хонхорцог захиалга болон тэдгээрийн өвөрмөц байдлын талаар баталгаа өгдөг.
• Толгойгүй үйлчилгээ: Үйлчилгээнүүд нь логик нэр ашиглан үйлчлүүлэгчдээс pods салгах боломжийг танд олгоно. Энэ тохиолдолд Кубернетес ачааллыг тэнцвэржүүлэх үүрэгтэй. Гэсэн хэдий ч ZooKeeper, Kafka зэрэг төлөвтэй ажлын ачааллыг ажиллуулах үед үйлчлүүлэгчид тодорхой жишээтэй харилцах шаардлагатай болдог. Энд толгойгүй үйлчилгээ хэрэгтэй болно: энэ тохиолдолд үйлчлүүлэгч логик нэртэй хэвээр байх болно, гэхдээ та подтой шууд холбоо барих шаардлагагүй болно.
• Урт хугацааны хадгалалтын хэмжээ: Эдгээр эзлэхүүнүүд нь дээр дурдсан орон нутгийн бус блок байнгын хадгалах санг тохируулахад шаардлагатай.

дээр Йолеан Kubernetes дээрх Кафкатай танилцаж эхлэхэд тань туслах манифестуудын иж бүрэн багцыг өгдөг.

Жолооны графикууд

Helm бол yum, apt, Homebrew эсвэл Chocolatey зэрэг үйлдлийн системийн багц менежерүүдтэй харьцуулах боломжтой Kubernetes-ийн багц менежер юм. Энэ нь Helm диаграммд тодорхойлсон урьдчилан тодорхойлсон програм хангамжийн багцуудыг суулгахад хялбар болгодог. Сайн сонгосон Helm диаграм нь Кафка-г Kubernetes дээр ашиглахын тулд бүх параметрүүдийг хэрхэн зөв тохируулах зэрэг хэцүү ажлыг хялбар болгодог. Кафкагийн хэд хэдэн диаграм байдаг: албан ёсны нэг нь байрладаг инкубаторын нөхцөлд, нэг нь байна Нүүрс, дахиад нэг - -аас Бхайтами.

Операторууд

Helm нь тодорхой дутагдалтай тул өөр нэг хэрэгсэл нь ихээхэн алдартай болж байна: Kubernetes операторууд. Оператор нь зөвхөн Kubernetes-д зориулсан програм хангамжийг багцлаад зогсохгүй ийм програм хангамжийг байршуулж, удирдах боломжийг танд олгоно.

Жагсаалтад гайхалтай операторууд Кафкагийн хоёр операторыг дурьдсан. Тэдний нэг - Стримзи. Strimzi-ийн тусламжтайгаар Кафка кластераа хэдхэн минутын дотор ажиллуулахад хялбар байдаг. Бараг ямар ч тохиргоо хийх шаардлагагүй, үүнээс гадна оператор өөрөө кластер доторх цэгээс цэг рүү TLS шифрлэлт гэх мэт сайхан боломжуудыг өгдөг. Confluent мөн хангадаг өөрийн оператор.

Бүтээмж

Кафкагийн жишээг харьцуулах замаар гүйцэтгэлийг шалгах нь чухал юм. Ийм туршилтууд нь асуудал гарахаас өмнө болзошгүй саад бэрхшээлийг олоход тусална. Аз болоход Кафка гүйцэтгэлийг шалгах хоёр хэрэгслийг аль хэдийн хангасан байна: kafka-producer-perf-test.sh и kafka-consumer-perf-test.sh. Тэдгээрийг идэвхтэй ашигла. Лавлагааны хувьд та-д тайлбарласан үр дүнгээс лавлаж болно энэ бичлэг Жей Крепс, эсвэл анхаарлаа төвлөрүүл энэ тойм Стефан Маарекийн Amazon MSK.

Үйл ажиллагаа

Хяналт шинжилгээ

Систем дэх ил тод байдал нь маш чухал бөгөөд өөрөөр хэлбэл та түүнд юу болж байгааг ойлгохгүй байх болно. Өнөөдөр үүлэн оригинал хэв маягаар хэмжүүрт суурилсан хяналтыг хангадаг хатуу хэрэгсэл бий. Энэ зорилгоор хоёр алдартай хэрэгсэл бол Prometheus болон Grafana юм. Prometheus нь JMX экспортлогч ашиглан Java-ийн бүх процессуудаас (Кафка, Зоокер, Кафка Холбогч) хэмжигдэхүүнүүдийг хамгийн энгийн аргаар цуглуулж чаддаг. Хэрэв та cAdvisor хэмжигдэхүүнийг нэмбэл Kubernetes-д нөөцийг хэрхэн ашиглаж байгааг илүү сайн ойлгох боломжтой.

Strimzi-д Кафкад зориулсан Графана хяналтын самбарын маш тохиромжтой жишээ бий. Энэ нь жишээлбэл дутуу хуулбарлагдсан эсвэл офлайн байгаа салбаруудын тухай гол хэмжүүрүүдийг дүрслэн харуулдаг. Тэнд бүх зүйл маш тодорхой байна. Эдгээр хэмжүүрүүд нь нөөцийн ашиглалт, гүйцэтгэлийн мэдээлэл, тогтвортой байдлын үзүүлэлтүүдээр нэмэгддэг. Тиймээс та Кафка кластерын үндсэн мониторингийг үнэгүй авах болно!

Эх сурвалж: streamzi.io/docs/master/#kafka_dashboard

Энэ бүгдийг үйлчлүүлэгчийн хяналт (хэрэглэгч ба үйлдвэрлэгчийн хэмжүүр), мөн хоцрогдлын хяналт (үүнд байдаг) -аар нөхөх нь сайхан байх болно. Бурроо) болон төгсгөлийн хяналт - энэ хэрэглээнд зориулагдсан Кафка Монитор.

Мод бэлтгэх

Мод бэлтгэх нь бас нэг чухал ажил юм. Таны Кафка суулгацын бүх контейнер нэвтэрсэн эсэхийг шалгаарай stdout и stderr, мөн түүнчлэн таны Kubernetes кластер бүх бүртгэлийг нэгдсэн бүртгэл хөтлөх төв дэд бүтцэд оруулах, жишээ нь. Elasticsearch.

Функциональ шалгалт

Кубернетес таны хонхорцог хэвийн ажиллаж байгаа эсэхийг шалгахын тулд амьд байдал, бэлэн байдлын датчик ашигладаг. Амжилттай байдлын шалгалт амжилтгүй болвол Кубернетес тэр контейнерийг зогсоож, дахин эхлүүлэх бодлогыг зохих ёсоор тохируулсан тохиолдолд автоматаар дахин эхлүүлэх болно. Хэрэв бэлэн байдлын шалгалт амжилтгүй болвол Кубернетес нь pod-ыг үйлчилгээний хүсэлтээс тусгаарладаг. Тиймээс ийм тохиолдолд гарын авлагын хөндлөнгийн оролцоо огт шаардлагагүй болсон нь том давуу тал юм.

Шинэчлэлтүүдийг хүргэж байна

StatefulSets автомат шинэчлэлтийг дэмждэг: хэрвээ та RollingUpdate стратегийг сонговол Кафкагийн доор тус бүр нь ээлжлэн шинэчлэгдэх болно. Ийм байдлаар зогсолтыг тэг болгож бууруулж болно.

Дэмжих

Кафка кластерыг масштаблах нь тийм ч хялбар ажил биш юм. Гэсэн хэдий ч Kubernetes нь pods-ыг тодорхой тооны хуулбар болгон хуваахад маш хялбар болгодог бөгөөд энэ нь та хүссэнээрээ олон Кафка брокерийг тунхаглалтайгаар тодорхойлж болно гэсэн үг юм. Энэ тохиолдолд хамгийн хэцүү зүйл бол масштабыг нэмэгдүүлэхийн дараа эсвэл багасгахын өмнө салбаруудыг дахин хуваарилах явдал юм. Дахин хэлэхэд Кубернетес танд энэ ажилд туслах болно.

Захиргаа

Сэдэв үүсгэх, секторуудыг дахин хуваарилах зэрэг Кафка кластераа удирдахтай холбоотой даалгавруудыг одоо байгаа бүрхүүлийн скриптүүдийг ашиглан өөрийн pods дахь тушаалын мөрийн интерфейсийг нээх замаар хийж болно. Гэсэн хэдий ч, энэ шийдэл нь тийм ч үзэсгэлэнтэй биш юм. Strimzi нь өөр оператор ашиглан сэдвүүдийг удирдахыг дэмждэг. Энд сайжруулах зүйл бий.

Нөөцлөлт болон нөхөн сэргээх

Одоо Кафка байгаа эсэх нь Kubernetes-ийн бэлэн эсэхээс хамаарна. Хэрэв таны Kubernetes кластер бүтэлгүйтвэл хамгийн муу тохиолдолд таны Кафка кластер бас бүтэлгүйтэх болно. Мерфигийн хуулийн дагуу энэ нь гарцаагүй тохиолдох бөгөөд та өгөгдлийг алдах болно. Энэ төрлийн эрсдлийг бууруулахын тулд нөөцлөх сайн ойлголттой байх хэрэгтэй. Та MirrorMaker ашиглаж болно, өөр сонголт бол үүнд тайлбарласны дагуу S3 ашиглах явдал юм бичлэг Заландогаас.

дүгнэлт

Жижиг болон дунд хэмжээний Кафка кластеруудтай ажиллахдаа нэмэлт уян хатан байдлыг хангаж, операторын туршлагыг хялбаршуулдаг тул Kubernetes-ийг ашиглах нь гарцаагүй. Хэрэв танд маш чухал функциональ бус хоцрогдол ба/эсвэл дамжуулах чадварын шаардлага байгаа бол байршуулах өөр сонголтыг авч үзэх нь дээр.

Эх сурвалж: www.habr.com