![\"Apache](\"https:\/\/inteca.com\/wp-content\/uploads\/2025\/03\/1.png\")
<\/p>\nSystemy komunikacji zdarzeniowej (Message Brokers) umo\u017cliwiaj\u0105 lu\u017ane powi\u0105zanie mi\u0119dzy us\u0142ugami i komponentami w organizacji lub projekcie, zapewniaj\u0105c jednocze\u015bnie asynchroniczn\u0105 komunikacj\u0119, skalowalno\u015b\u0107, wysok\u0105 przepustowo\u015b\u0107, niezawodno\u015b\u0107 oraz bezpiecze\u0144stwo przesy\u0142anych danych.<\/p>\n
Apache Kafka to jeden z najpopularniejszych broker\u00f3w wiadomo\u015bci, znany ze swojej wydajno\u015bci i szeroko stosowany przez firmy takie jak Netflix, Uber czy LinkedIn. Ale czy rzeczywi\u015bcie spe\u0142nia te oczekiwania? Czy zapewnia bezpiecze\u0144stwo danych, skalowalno\u015b\u0107 i niezawodno\u015b\u0107? Czy dzia\u0142a optymalnie od razu po instalacji, czy wymaga dodatkowej konfiguracji?<\/p>\n
W tej sekcji przedstawi\u0119 i kr\u00f3tko om\u00f3wi\u0119 komponenty sk\u0142adaj\u0105ce si\u0119 na typow\u0105 instalacj\u0119 Apache Kafka. Zrozumienie ich dzia\u0142ania u\u0142atwi nam dalsz\u0105 analiz\u0119 funkcjonalno\u015bci i mo\u017cliwo\u015bci konfiguracji Kafki.<\/p>\n
<\/p>\n
Powy\u017cszy diagram przedstawia typowe elementy sk\u0142adowe instalacji Apache Kafka. Kluczowym sk\u0142adnikiem jest klaster Kafka, kt\u00f3ry sk\u0142ada si\u0119 z broker\u00f3w \u2013 serwer\u00f3w odpowiedzialnych za przechowywanie i przetwarzanie danych.<\/p>\n
Klaster zarz\u0105dzany jest przez Apache Zookeeper (od wersji 2.8.0 wprowadzono alternatywne rozwi\u0105zanie \u2013<\/a> Kafka Kraft, kt\u00f3re eliminuje konieczno\u015b\u0107 korzystania z Zookeepera; od wersji 3.5.0 Zookeeper zosta\u0142 oznaczony jako deprecated<\/em>).<\/p>\n Ka\u017cdy broker przechowuje dane w topicach, kt\u00f3re s\u0105 podzielone na partycje. Podzia\u0142 topicu na partycje odgrywa kluczow\u0105 rol\u0119 w skalowalno\u015bci i wydajno\u015bci Kafki, poniewa\u017c umo\u017cliwia r\u00f3wnoleg\u0142e przetwarzanie danych przez wielu konsument\u00f3w.<\/p>\n Podczas zapisywania wiadomo\u015bci do topicu Kafka przypisuje je do konkretnej partycji na podstawie jednej z dw\u00f3ch mo\u017cliwo\u015bci:<\/p>\n W obr\u0119bie pojedynczej partycji Kafka gwarantuje zachowanie kolejno\u015bci wiadomo\u015bci (wed\u0142ug momentu zapisu), natomiast nie zapewnia globalnej kolejno\u015bci mi\u0119dzy r\u00f3\u017cnymi partycjami tego samego topicu. Ka\u017cda wiadomo\u015b\u0107 w partycji posiada unikalny identyfikator zwany offsetem, kt\u00f3ry pozwala na \u015bledzenie przetwarzania danych przez konsument\u00f3w.<\/p>\n Konsumenci Kafka s\u0105 przypisani do grup konsument\u00f3w. Ka\u017cdy konsument w grupie odczytuje wiadomo\u015bci z jednej lub wielu partycji, jednak \u017cadna partycja nie mo\u017ce by\u0107 obs\u0142ugiwana przez wi\u0119cej ni\u017c jednego konsumenta w danej grupie.<\/p>\n Przyk\u0142ady:<\/p>\n Grup\u0119 konsument\u00f3w mo\u017cna traktowa\u0107 jako aplikacj\u0119 Spring Boot lub Quarkus, a pojedynczego konsumenta jako w\u0105tek tej aplikacji. Dlatego podczas planowania przepustowo\u015bci wdra\u017canego systemu nale\u017cy odpowiednio dobra\u0107 liczb\u0119 partycji w topicach \u2013 to w\u0142a\u015bnie liczba partycji okre\u015bla maksymaln\u0105 liczb\u0119 w\u0105tk\u00f3w, kt\u00f3re mog\u0105 r\u00f3wnolegle przetwarza\u0107 wiadomo\u015bci.<\/p>\n Ka\u017cdy broker pe\u0142ni kilka istotnych funkcji:<\/p>\n Kolejnym elementem architektury jest Kafka Connect. To mechanizm umo\u017cliwiaj\u0105cy integracj\u0119 Kafki z innymi systemami, a tym samym komunikacje ze \u015bwiatem zewn\u0119trznym. Sk\u0142ada si\u0119 z dw\u00f3ch typ\u00f3w konektor\u00f3w:<\/p>\n Na rynku dost\u0119pnych jest wiele gotowych konektor\u00f3w. Do najpopularniejszych dostawc\u00f3w nale\u017c\u0105:<\/p>\n Warto zwr\u00f3ci\u0107 uwag\u0119, \u017ce w przypadku Confluent licencja mo\u017ce si\u0119 r\u00f3\u017cni\u0107 w zale\u017cno\u015bci od konektora \u2013 niekt\u00f3re wymagaj\u0105 op\u0142at, inne s\u0105 open source<\/a>. Czasami r\u00f3wnie\u017c konektor source i sink dla tego samego systemu mog\u0105 mie\u0107 r\u00f3\u017cne licencje.<\/p>\n Ciekaw\u0105 opcj\u0105 s\u0105 konektory Lenses.io, kt\u00f3re oferuj\u0105 m.in. konektor JMS \u2013 wykorzystywali\u015bmy go w jednym z naszych projekt\u00f3w.<\/p>\n Ostatnim elementem, przedstawionym na diagramie architektury jest Stream Application. To komponent, kt\u00f3ry pobiera dane z topicu, przetwarza je i zapisuje w topicu docelowym. Pe\u0142ni jednocze\u015bnie rol\u0119 producenta i konsumenta wiadomo\u015bci.<\/p>\n Aplikacje typu Stream Application mog\u0105 by\u0107 tworzone w r\u00f3\u017cnych frameworkach, takich jak:<\/p>\n Typowe operacje realizowane przez Stream Applications obejmuj\u0105:<\/p>\n Ostatnim elementem, przedstawionym na diagramie architektury, jest Stream Application. Jest to komponent, kt\u00f3ry pobiera dane z topicu, przetwarza i wysy\u0142a na topic docelowy. Innymi s\u0142owy grupuje w sobie funkcjonalno\u015b\u0107 konsumenta i producenta Kafka. Aplikacje takie mo\u017cna wytwarza\u0107 w r\u00f3\u017cnych frameworkach np. Spring Boot, Quarkus i mog\u0105 one realizowa\u0107 transformaty wiadomo\u015bci, przeliczenia, agregaty, mog\u0105 \u0142\u0105czy\u0107 komunikaty z kilku topic\u00f3w.<\/p>\n Om\u00f3wione powy\u017cej komponenty stanowi\u0105 podstaw\u0119 architektury Apache Kafka. W kolejnych sekcjach przyjrzymy si\u0119 ich konfiguracji i optymalizacji.<\/p>\n Kafka posiada bogat\u0105 dokumentacj\u0119, a w Internecie mo\u017cna znale\u017a\u0107 wiele dodatkowych materia\u0142\u00f3w na jej temat. Warto na przyk\u0142ad zapozna\u0107 si\u0119 z takimi elementami jak Schema Registry, kt\u00f3re umo\u017cliwia zarz\u0105dzanie schematami wiadomo\u015bci przesy\u0142anych w Kafce, a nie zosta\u0142 om\u00f3wiony powy\u017cej.<\/p>\n Zanim przejdziemy do szczeg\u00f3\u0142owej analizy, warto om\u00f3wi\u0107 kluczowe obszary funkcjonalne, kt\u00f3re powinien zapewnia\u0107 broker wiadomo\u015bci:<\/p>\n W kolejnych sekcjach przeanalizujemy te obszary w kontek\u015bcie Apache Kafka, omawiaj\u0105c jej mo\u017cliwo\u015bci oraz elementy, na kt\u00f3re warto zwr\u00f3ci\u0107 szczeg\u00f3ln\u0105 uwag\u0119, aby unikn\u0105\u0107 problem\u00f3w.<\/p>\n Apache Kafka oferuje r\u00f3\u017cne opcje instalacji. W naszych projektach najcz\u0119\u015bciej wykorzystujemy wdro\u017cenia na klastrach Kubernetes lub RedHat OpenShift, poniewa\u017c zapewniaj\u0105 one wysoki poziom dost\u0119pno\u015bci i bezpiecze\u0144stwa (szczeg\u00f3\u0142owe om\u00f3wienie tych aspekt\u00f3w wykracza poza zakres tego artyku\u0142u).<\/p>\n Jednym z popularnych sposob\u00f3w instalacji Apache Kafka na OpenShift jest Strimzi (strimzi.io<\/a>), dzia\u0142aj\u0105ce zgodnie ze wzorcem Operator (Operator Pattern<\/a>). Strimzi wprowadza zestaw dedykowanych zasob\u00f3w (Custom Resource Definitions \u2013 CRD<\/em>), umo\u017cliwiaj\u0105cych opisanie instalacji klastra Kafka, Kafka Connect, konektor\u00f3w, definiowanie topic\u00f3w oraz zarz\u0105dzanie dost\u0119pami.<\/p>\n Jedn\u0105 z g\u0142\u00f3wnych zalet Strimzi jest znacz\u0105ce uproszczenie instalacji ca\u0142ego ekosystemu Apache Kafka, kt\u00f3ry \u2013 jak om\u00f3wili\u015bmy w sekcji dotycz\u0105cej architektury \u2013 sk\u0142ada si\u0119 z wielu komponent\u00f3w.<\/p>\n W poni\u017cszych przyk\u0142adach do definiowania zasob\u00f3w klastra OpenShift wykorzystujemy szablony Helm (helm.sh<\/a>).<\/p>\n Podstawowym CRD jest CRD typu Kafka, kt\u00f3ry pozwala na instalacj\u0119 klastra Kafka:<\/p>\n W (1) okre\u015blamy zasoby obliczeniowe dla broker\u00f3w Kafka, takie jak \u017c\u0105dane CPU\/RAM oraz limity CPU i RAM. W tym samym CRD mo\u017cemy r\u00f3wnie\u017c okre\u015bli\u0107 parametry instalacji Zookeepera.<\/p>\n W (1) okre\u015blamy zasoby CPU\/RAM przeznaczone dla Zookeepera, a w (2) liczb\u0119 jego instancji.<\/p>\n Dodatkowo, w tym samym CRD mo\u017cemy skonfigurowa\u0107 parametry dyskowe dla Apache Kafka oraz szczeg\u00f3\u0142owe ustawienia konfiguracyjne:<\/p>\n W (1) znajduje si\u0119 definicja storage dla tworzonego klastra Apache Kafka.<\/p>\n W (2) okre\u015blamy szczeg\u00f3\u0142owe parametry konfiguracyjne brokera. W powy\u017cszym przyk\u0142adzie zdefiniowano kilka podstawowych parametr\u00f3w, takich jak: Po za\u0142adowaniu powy\u017cszej konfiguracji do klastra Kubernetes lub OpenShift i jej przetworzeniu przez operatora Strimzi, uzyskamy w pe\u0142ni funkcjonalny klaster Apache Kafka obs\u0142ugiwany przez Zookeepera. Jego dzia\u0142anie mo\u017cna zweryfikowa\u0107 za pomoc\u0105 odpowiednich narz\u0119dzi:<\/p>\n Po wylistowaniu POD\u2019\u00f3w zobaczymy zar\u00f3wno broker\u2019y jak i Zookeeper:<\/p>\n Kolejnym elementem koniecznym do instalacji jest Kafka Connect co mo\u017cemy osi\u0105gn\u0105\u0107 przy pomocy innego CRD dostarczanego przez Strimzi jakim jest KafkaConnect:<\/p>\n W punkcie (1) definiujemy liczb\u0119 instancji wchodz\u0105cych w sk\u0142ad klastra Kafka Connect, (2) okre\u015bla namiar na klaster Apache Kafka. CRD KafkaConnect pozwala tez okre\u015bli\u0107 inne elementy takie jak bezpiecze\u0144stwo, storage, zasoby, parametry konfiguracyjne Zookeeper.<\/p>\n Po wgraniu tego CRD na klaster OpenShift dostaniemy funkcjonalny klaster KafkaConnect co mo\u017cna sprawdzi\u0107 nast\u0119puj\u0105cym poleceniem:<\/p>\n W ten spos\u00f3b sprawnie i szybko zainstalowali\u015bmy klaster Apache Kafka oraz Kafka Connect. Ostatnim krokiem jest wdro\u017cenie przyk\u0142adowego topicu oraz przyk\u0142adowego konektora.<\/p>\n Zacznijmy od definicji topicu, do kt\u00f3rej Strimzi dostarcza dedykowane CRD \u2013 KafkaTopic:<\/p>\n Ten prosty plik pozwala okre\u015bli\u0107: Parametr retencji jest kluczowy w kontek\u015bcie zarz\u0105dzania przestrzeni\u0105 dyskow\u0105 klastra Kafka. R\u00f3\u017cne topici mog\u0105 mie\u0107 ustawione r\u00f3\u017cne warto\u015bci w zale\u017cno\u015bci od potrzeb \u2013 topicom o wi\u0119kszym znaczeniu biznesowym mo\u017cna przypisa\u0107 d\u0142u\u017csz\u0105 retencj\u0119.<\/p>\n Teraz przygotujmy przyk\u0142adow\u0105 definicj\u0119 konektora, korzystaj\u0105c z CRD KafkaConnector.<\/p>\n Ten plik definiuje konektor JMS typu source, kt\u00f3ry odpowiada za odczyt danych z kolejki JMS i przekazanie ich do topicu Kafka:<\/p>\n W ten spos\u00f3b zako\u0144czyli\u015bmy proces<\/a> instalacji klastra Apache Kafka i Kafka Connect, a tak\u017ce wdro\u017cenie przyk\u0142adowego topicu oraz konektora.<\/p>\n Jak wida\u0107, Kafka oferuje wiele mo\u017cliwo\u015bci konfiguracyjnych, a Strimzi umo\u017cliwia ich definiowanie za pomoc\u0105 dedykowanych CRD. Wykorzystanie Helm pozwala na parametryzacj\u0119 tych CRD (poprzez dedykowane pliki Values<\/em>), co umo\u017cliwia utrzymywanie wielu konfiguracji, np. dla \u015brodowisk deweloperskich, testowych i produkcyjnych.<\/p>\n Jedn\u0105 z kluczowych zalet takiego podej\u015bcia do zarz\u0105dzania instalacj\u0105 i konfiguracj\u0105 klastra Kafka jest mo\u017cliwo\u015b\u0107 przechowywania plik\u00f3w konfiguracyjnych (szablon\u00f3w) \u2013 s\u0105 to pliki YAML \u2013 w systemie kontroli wersji w dedykowanym repozytorium. Dzi\u0119ki temu mo\u017cna \u0142atwo audytowa\u0107 zmiany i \u015bledzi\u0107 histori\u0119 modyfikacji.<\/p>\n Taka konfiguracja mo\u017ce by\u0107 nast\u0119pnie wdra\u017cana na \u015brodowiska przy u\u017cyciu pipeline\u2019\u00f3w w narz\u0119dziach takich jak GitLab czy Jenkins. Dodatkowo mo\u017cliwe jest wykorzystanie system\u00f3w automatycznej synchronizacji, np. ArgoCD (https:\/\/argo-cd.readthedocs.io\/en\/stable\/<\/a>), kt\u00f3re monitoruj\u0105 repozytorium pod k\u0105tem zmian i automatycznie propaguj\u0105 je na \u015brodowiska docelowe.<\/p>\n Po om\u00f3wieniu procesu wdra\u017cania i konfiguracji Kafki przejd\u017amy teraz do kwestii bezpiecze\u0144stwa.<\/p>\n Ka\u017cdy system przeznaczony do komunikacji zdarzeniowej powinien zapewnia\u0107 bezpiecze\u0144stwo przesy\u0142anych danych, obejmuj\u0105ce szyfrowanie, uwierzytelnianie i autoryzacj\u0119. W tym zakresie Apache Kafka, zgodnie z oficjaln\u0105 dokumentacj\u0105<\/a>, oferuje nast\u0119puj\u0105ce mechanizmy zabezpiecze\u0144:<\/p>\n Dostosowanie Apache Kafka do spe\u0142nienia wymog\u00f3w bezpiecze\u0144stwa wymaga konfiguracji wielu parametr\u00f3w. Przyk\u0142adowo, konieczne jest skonfigurowanie zabezpieczonego listenera:<\/p>\n oraz wygenerowanie kluczy SSL przy pomocy narz\u0119dzi takich jak keytool. Proces ten wymaga szczeg\u00f3lnej uwagi i koncentracji, ale zdecydowanie jest to konfiguracja kt\u00f3r\u0105 warto wykona\u0107 w celu zapewnienia pe\u0142nego bezpiecze\u0144stwa przesy\u0142anych danych.<\/p>\n Je\u015bli Kafka jest wdra\u017cana na klastrze Kubernetes lub OpenShift i korzysta z Strimzi, konfiguracja uwierzytelniania staje si\u0119 prostsza. Strimzi automatyzuje wiele proces\u00f3w, udost\u0119pniaj\u0105c odpowiednie wpisy w plikach CR (Custom Resource), a tak\u017ce dodatkowe definicje CRD (Custom Resource Definitions), kt\u00f3re upraszczaj\u0105 zarz\u0105dzanie bezpiecze\u0144stwem.<\/p>\n Rozpocznijmy od konfiguracji uwierzytelniania dla brokera \u2013 w pliku definiuj\u0105cym klaster Kafka dost\u0119pne s\u0105 nast\u0119puj\u0105ce opcje:<\/p>\n Po za\u0142adowaniu tej konfiguracji operator Strimzi automatycznie wygeneruje odpowiednie secrety OpenShift, kt\u00f3re b\u0119d\u0105 wykorzystywane do zarz\u0105dzania uwierzytelnianiem i szyfrowaniem komunikacji:<\/p>\n Je\u015bli teraz spojrzymy na wcze\u015bniej przygotowany i wdro\u017cony klaster Kafka Connect, zauwa\u017cymy, \u017ce nie b\u0119dzie on m\u00f3g\u0142 po\u0142\u0105czy\u0107 si\u0119 z brokerem Kafka. Aby przywr\u00f3ci\u0107 komunikacj\u0119 mi\u0119dzy tymi komponentami, konieczne jest dostosowanie konfiguracji Kafka Connect, uwzgl\u0119dniaj\u0105c aspekty zwi\u0105zane z bezpiecze\u0144stwem.<\/p>\n W tym celu nale\u017cy wprowadzi\u0107 odpowiednie zmiany w pliku CR (Custom Resource) dla KafkaConnect:<\/p>\n Pozostaje jednak kluczowe pytanie: sk\u0105d Kafka Connect w miejscu oznaczonym (1) we\u017amie certyfikat? Przecie\u017c nigdzie nie definiowali\u015bmy secretu kafka-connect-tls-user.<\/p>\n Odpowied\u017a jest prosta \u2013 ten certyfikat reprezentuje u\u017cytkownika lub aplikacj\u0119, kt\u00f3ra \u0142\u0105czy si\u0119 z brokerem Kafka. Strimzi dostarcza w tym celu dedykowany CRD o nazwie KafkaUser, kt\u00f3ry pozwala na zdefiniowanie takiego u\u017cytkownika:<\/p>\n Przyjrzyjmy si\u0119 zawarto\u015bci tego pliku:<\/p>\n Po za\u0142adowaniu tej definicji operator Strimzi automatycznie wygeneruje odpowiedni secret, kt\u00f3ry Kafka Connect wykorzysta do uwierzytelnienia w brokerze i kt\u00f3ry b\u0119dzie zrozumia\u0142y dla brokera:<\/p>\n Je\u015bli aplikacja (KafkaUser) korzystaj\u0105ca z takiego certyfikatu spr\u00f3buje wykona\u0107 na brokerze operacj\u0119 niedozwolon\u0105 (czyli tak\u0105, kt\u00f3rej nie uwzgl\u0119dnili\u015bmy w definicji KafkaUser), broker automatycznie j\u0105 zablokuje. W logach zobaczymy wtedy komunikat o b\u0142\u0119dzie:<\/p>\n Powy\u017cszy b\u0142\u0105d wskazuje, \u017ce u\u017cytkownik kafka-connect-tls-user nie posiada uprawnie\u0144 do pobierania informacji o klastrze. Jest to oczekiwane zachowanie, poniewa\u017c nie nadali\u015bmy mu takiego dost\u0119pu w konfiguracji.<\/p>\n Aby usun\u0105\u0107 ten b\u0142\u0105d, musimy doda\u0107 odpowiednie uprawnienie do pliku konfiguracyjnego:<\/p>\n W przedstawionym przyk\u0142adzie pojawia si\u0119 nowy typ zasobu reprezentuj\u0105cy klaster Kafka.<\/p>\n Jak wida\u0107, Apache Kafka oferuje szerokie mo\u017cliwo\u015bci konfiguracyjne w zakresie bezpiecze\u0144stwa \u2013 od uwierzytelniania, przez szyfrowanie, a\u017c po autoryzacj\u0119. Je\u015bli korzystamy z Strimzi, konfiguracja tych mechanizm\u00f3w staje si\u0119 znacznie prostsza, poniewa\u017c wiele element\u00f3w jest generowanych automatycznie przez operatora Strimzi.<\/p>\n Potwierdzili\u015bmy zatem, \u017ce pod wzgl\u0119dem bezpiecze\u0144stwa Apache Kafka to rozwi\u0105zanie klasy enterprise, kt\u00f3re spe\u0142ni wymagania nawet najbardziej rygorystycznych departament\u00f3w bezpiecze\u0144stwa.<\/p>\n Przejd\u017amy teraz do analizy wysokiej dost\u0119pno\u015bci Kafki i metod zapewnienia jej niezawodno\u015bci.<\/p>\n Systemy komunikacji zdarzeniowej odpowiadaj\u0105 za przesy\u0142anie komunikat\u00f3w mi\u0119dzy wieloma systemami i us\u0142ugami. Im wi\u0119cej komponent\u00f3w polega na takiej komunikacji, tym wi\u0119ksze znaczenie ma rola brokera w ca\u0142ym przep\u0142ywie informacji.<\/p>\n Co jednak stanie si\u0119 w przypadku awarii brokera? Czy mo\u017ce on sta\u0107 si\u0119 pojedynczym punktem awarii (Single Point of Failure, SPOF)? Odpowied\u017a brzmi: tak \u2013 je\u015bli system jest<\/a> \u017ale rozmieszczony i skonfigurowany, mo\u017ce sta\u0107 si\u0119 SPOF.<\/p>\n Jak zatem Apache Kafka radzi sobie z tym wyzwaniem?<\/p>\n Podstawowym mechanizmem zapewniaj\u0105cym wysok\u0105 dost\u0119pno\u015b\u0107 w Kafce jest replikacja. Replikacja oznacza, \u017ce dane z partycji topicu s\u0105 przechowywane na r\u00f3\u017cnych w\u0119z\u0142ach klastra. W przypadku awarii jednego z w\u0119z\u0142\u00f3w jego rol\u0119 mog\u0105 przej\u0105\u0107 inne w\u0119z\u0142y, poniewa\u017c dane s\u0105 replikowane.<\/p>\n Poni\u017cszy diagram ilustruje ten proces:<\/p>\n Klaster Kafka sk\u0142ada si\u0119 z trzech broker\u00f3w. Na poni\u017cszym diagramie kolorem niebieskim zaznaczono lider\u00f3w partycji. Przyk\u0142adowo, Broker 1 pe\u0142ni rol\u0119 lidera partycji 0 w topicu 1 i odpowiada za replikacj\u0119 danych tej partycji na inne w\u0119z\u0142y klastra:<\/p>\n W\u0119z\u0142y Broker 2 i Broker 3 s\u0105 nazywane in-sync replicas (ISR), czyli synchronizowanymi replikami. W przypadku awarii Brokera 1, jeden z broker\u00f3w in-sync zostanie automatycznie wybrany nowym liderem partycji 0 dla topicu 1, co pozwoli klientom na nieprzerwane korzystanie z topicu. Dzi\u0119ki temu mechanizmowi Kafka zapewnia odporno\u015b\u0107 na awarie.<\/p>\n Dodatkowo, je\u015bli Kafka jest wdra\u017cana na klastrze OpenShift, kt\u00f3ry jest rozmieszczony w podziale na dwa centra danych (g\u0142\u00f3wnym \u2013 Data Center i zapasowym \u2013 Disaster Recovery Center), mo\u017cna wymusi\u0107 odpowiednie rozmieszczenie broker\u00f3w, aby zwi\u0119kszy\u0107 dost\u0119pno\u015b\u0107 systemu. W\u0119z\u0142y trafiaj\u0105 w tym wypadku r\u00f3wnie\u017c do zapasowego centrum co zwi\u0119ksza dost\u0119pno\u015b\u0107 naszej instalacji. W tym celu warto skorzysta\u0107 z konfiguracji przynale\u017cno\u015bci (affinity), kt\u00f3ra umo\u017cliwia kontrol\u0119 nad tym, gdzie uruchamiane s\u0105 poszczeg\u00f3lne w\u0119z\u0142y klastra.<\/p>\n Kolejnym kluczowym elementem zapewnienia niezawodno\u015b\u0107 jest mo\u017cliwo\u015b\u0107 odtworzenia systemu po awarii oraz tworzenie kopii zapasowych. W tym zakresie dost\u0119pnych jest kilka metod:<\/p>\n Cz\u0119\u015b\u0107 os\u00f3b wykorzystuje narz\u0119dzie Kafka Mirror Maker, kt\u00f3re pozwala na replikacj\u0119 danych mi\u0119dzy klastrami Kafka. W tym modelu mamy klaster podstawowy, oraz klaster zapasowy – rozmieszczony w innym miejscu. MirrorMaker jest u\u017cywany do synchronizacji danych mi\u0119dzy tymi klastrami. W przypadku awarii klastra podstawowego, ruch zostanie przekierowywany\u00a0 do klastra zapasowego.<\/p>\n W przypadku instalacji na klastrze OpenShift, gdy dyski klastra Kafka s\u0105 dostarczane przez OpenShift, pojawia si\u0119 mo\u017cliwo\u015b\u0107 tworzenia ich kopii zapasowych (ang. Persistent Volume Claim<\/em>) za pomoc\u0105 tzw. snapshot\u00f3w. Jednym z narz\u0119dzi umo\u017cliwiaj\u0105cych to dzia\u0142anie jest Commvault<\/a>. W jednym z projekt\u00f3w Inteca sprawdzali\u015bmy, czy mo\u017cliwe jest wykonanie kopii zapasowej PVC klastra Kafka bez konieczno\u015bci wy\u0142\u0105czania jego w\u0119z\u0142\u00f3w. Sama kopia zapasowa przebieg\u0142a bez problem\u00f3w, jednak odtworzenie danych okaza\u0142o si\u0119 problematyczne i nie zawsze ko\u0144czy\u0142o si\u0119 powodzeniem. G\u0142\u00f3wnym wyzwaniem by\u0142a sp\u00f3jno\u015b\u0107 danych po przywr\u00f3ceniu.<\/p>\n Aby skutecznie korzysta\u0107 z takich narz\u0119dzi do tworzenia kopii zapasowych, warto rozwa\u017cy\u0107 wy\u0142\u0105czenie klastra Kafka na czas wykonywania snapshotu. Cho\u0107 wi\u0105\u017ce si\u0119 to z kr\u00f3tkotrwa\u0142\u0105 niedost\u0119pno\u015bci\u0105 systemu, mo\u017ce znacz\u0105co zwi\u0119kszy\u0107 niezawodno\u015b\u0107 procesu przywracania danych.<\/p>\n Opcj\u0105 kt\u00f3ra jest cz\u0119sto wykorzystywana w przypadku tworzenia kopii zapasowej Apache Kafka jest tworzenie kopii zapasowej poprzez wys\u0142anie danych do S3. W tym podej\u015bciu w ramach Kafka Connect u\u017cywany jest konektor S3 typu sink, kt\u00f3ry pobiera dane z topic\u00f3w i wysy\u0142a do S3 (konektor S3 source jest wy\u0142\u0105czony):<\/p>\n W momencie przywr\u00f3cenia dzia\u0142ania systemu po awarii, konektory zmieniaj\u0105 sw\u00f3j stan i nast\u0119puje odczytanie danych z kopii zapasowej (konektor sink jest wy\u0142\u0105czony a source w\u0142\u0105czony):<\/p>\n Po przywr\u00f3ceniu danych z kopii zapasowej konektory wracaj\u0105 do ustawienia pierwotnego. Nale\u017cy tutaj zaznaczy\u0107 \u017ce zmiany stan\u00f3w konektor\u00f3w w momencie odtwarzania z backupu oraz po odtworzeniu s\u0105 operacjami manualnymi, czynno\u015bciami administracyjnymi.<\/p>\n Opisane wy\u017cej podej\u015bcie to cz\u0119sto wykorzystywane rozwi\u0105zanie do tworzenia kopii zapasowych dla Apache Kafka. Nale\u017cy jednak zwr\u00f3ci\u0107 uwag\u0119 na jeden istotny fakt a mianowicie odpowiednie odtworzenie danych i przywr\u00f3cenie offset\u00f3w dla grup konsument\u00f3w:<\/p>\n Przedstawimy to na przyk\u0142adzie:<\/p>\n Konsument odczytuje dane z topicu 1. Z partycji 0 pobra\u0142 i przetworzy\u0142 wiadomo\u015b\u0107 0, podobnie jak dla partycji 1. Po przetworzeniu konsument informuje broker \u017ce te wiadomo\u015bci s\u0105 ju\u017c przetworzone i ta informacja jest zapisywana w specjalnym, wewn\u0119trznym topicu Kafka o nazwie __consumer_offsets. Wiadomo\u015b\u0107 1 z partycji 0 nie zosta\u0142a potwierdzona tzn. offset grupy dla tej partycji jest mniejszy ni\u017c offset tej wiadomo\u015bci.<\/p>\n Je\u015bli po awarii odczytamy dane z kopii zapasowej, a podczas ich odtwarzania wiadomo\u015bci zamieni\u0105 swoje partycje lub kolejno\u015b\u0107, zapisane informacje o tym, gdzie dany konsument zako\u0144czy\u0142 przetwarzanie, stan\u0105 si\u0119 bezu\u017cyteczne. Co wi\u0119cej, ich u\u017cycie mo\u017ce prowadzi\u0107 do b\u0142\u0119d\u00f3w.<\/p>\n Na przyk\u0142ad, je\u015bli po przywr\u00f3ceniu partycja 1 zawiera zar\u00f3wno wiadomo\u015b\u0107 fioletow\u0105, jak i pomara\u0144czow\u0105, a partycja 0 jedynie wiadomo\u015b\u0107 zielon\u0105, mog\u0105 wyst\u0105pi\u0107 nast\u0119puj\u0105ce problemy:<\/p>\n Dlatego niezwykle istotne jest, aby podczas odtwarzania zachowa\u0107 zar\u00f3wno poprawne przypisanie wiadomo\u015bci do partycji, jak i ich kolejno\u015b\u0107. Kluczowe jest r\u00f3wnie\u017c odwzorowanie stanu przetwarzania poszczeg\u00f3lnych grup konsument\u00f3w, czyli ich offset\u00f3w.<\/p>\n Jakich konektor\u00f3w mo\u017cna u\u017cy\u0107 do implementacji takiej kopii zapasowej?<\/p>\n Confluent dostarcza odpowiednie konektory, np. Confluent S3 Source Connector<\/a>. Nale\u017cy jednak pami\u0119ta\u0107, \u017ce wymagaj\u0105 one licencji.<\/p>\n Alternatyw\u0105 s\u0105 opensource\u2019owe konektory Apache Camel S3 Sink oraz Source, jednak maj\u0105 one pewne ograniczenia implementacyjne:<\/p>\n Z tego wzgl\u0119du ich produkcyjne u\u017cycie wymaga dostosowania, np. poprzez implementacj\u0119 dedykowanego transformatora wiadomo\u015bci dla konektora sink (ang. Single Message Transformations), kt\u00f3ry b\u0119dzie propagowa\u0107 informacj\u0119 o partycji i offsecie do S3. Oraz drugiego transformatora dla konektora source, kt\u00f3ry u\u017cyje informacji o partycji i offsecie, zapisanych w S3 do poprawnego przywr\u00f3cenia wiadomo\u015bci.<\/p>\n Om\u00f3wili\u015bmy elementy zwi\u0105zane z wysok\u0105 dost\u0119pno\u015bci\u0105 oraz kopi\u0105 zapasow\u0105. Przejd\u017amy do kwestii monitorowania naszej instalacji Kafki na \u015brodowisku produkcyjnym.<\/p>\n Dla ka\u017cdego systemu komunikacji zdarzeniowej istotne jest monitorowanie jego dzia\u0142ania produkcyjnego aby chroni\u0107 si\u0119 przed takimi problemami jak utrata danych, przestoje w przetwarzaniu czy niewystarczaj\u0105ca wydajno\u015b\u0107 przetwarzania. Apache Kafka z racji swojej architektury i sposobu dzia\u0142ania wymaga monitorowania stanu\u00a0 klastra, utylizacji zasob\u00f3w, replikacji, konektor\u00f3w oraz wydajno\u015bci przetwarzania.<\/p>\n Apache Kafka potrafi wystawi\u0107 te informacje do Prometheus (https:\/\/prometheus.io\/<\/a>), sk\u0105d te dane mo\u017cna pobra\u0107 i wizualizowa\u0107 na przyk\u0142ad przy u\u017cyciu Grafana (https:\/\/grafana.com\/<\/a>).<\/p>\n Aby zrealizowa\u0107 taki monitoring, w przypadku instalacji klastra Kafka na OpenShift, mo\u017cna zdefiniowa\u0107 odpowiedni PodMonitor czyli byt pochodz\u0105cy z Prometheus Operator, kt\u00f3ry jest wbudowany w platform\u0119 OpenShift:<\/p>\n Po wgraniu tej definicji i skonfigurowaniu Grafana otrzymamy nast\u0119puj\u0105cy widok:<\/p>\n Znajduj\u0105 si\u0119 tu takie informacje jak:<\/p>\nCzym jest partycjonowanie i kolejno\u015b\u0107 wiadomo\u015bci?<\/h3>\n
\n
![\"\"](\"https:\/\/inteca.com\/wp-content\/uploads\/2025\/03\/2.png\")
<\/p>\nCzym jest grupa konsument\u00f3w i r\u00f3wnoleg\u0142e przetwarzanie?<\/h3>\n
![\"\"](\"https:\/\/inteca.com\/wp-content\/uploads\/2025\/03\/3.png\")
<\/p>\n\n
![\"\"](\"https:\/\/inteca.com\/wp-content\/uploads\/2025\/03\/4.png\")
<\/p>\n\n
![\"\"](\"https:\/\/inteca.com\/wp-content\/uploads\/2025\/03\/5.png\")
<\/p>\n\n
Rola brokera w klastrze Kafka<\/h3>\n
\n
Czym jest Kafka Connect? Jak kafka integruje si\u0119 z innymi systemami?<\/h3>\n
\n
\n
Znaczenie Stream Application \u2013 przetwarzanie danych w Kafce<\/h3>\n
\n
\n
Obszary funkcjonalne Apache Kafka<\/h2>\n
\n
Wdra\u017canie i konfiguracja Kafka<\/h2>\n
Instalacja klastra Apache Kafka<\/h3>\n
apiVersion: kafka.strimzi.io\/v1beta2\nkind: Kafka\nmetadata:\n\u00a0 name: {{ include \"broker.fullname\" . }}\n\u00a0 labels:\n\u00a0 \u00a0 {{- include \"broker.labels\" . | nindent 4 }}\nspec:\n\u00a0 kafka:\n\u00a0 \u00a0 resources: (1)\n\u00a0 \u00a0 \u00a0 requests:\n\u00a0 \u00a0 \u00a0 \u00a0 cpu: {{ .Values.kafka.resources.requests.cpu }}\n\u00a0 \u00a0 \u00a0 \u00a0 memory: {{ .Values.kafka.resources.requests.memory }}\n\u00a0 \u00a0 \u00a0 limits:\n\u00a0 \u00a0 \u00a0 \u00a0 cpu: {{ .Values.kafka.resources.limits.cpu }}\n\u00a0 \u00a0 \u00a0 \u00a0 memory: {{ .Values.kafka.resources.limits.memory }}\n\u00a0 \u00a0 version: 3.4.0\n\u00a0 \u00a0 replicas: {{ .Values.kafka.replicas}} (2)\n\n\u2026<\/pre>\n
\nW (2) definiujemy liczb\u0119 broker\u00f3w, kt\u00f3re b\u0119d\u0105 tworzy\u0107 klaster Apache Kafka.<\/p>\n\u00a0 zookeeper:\n\u00a0 \u00a0 resources: (1)\n\u00a0 \u00a0 \u00a0 requests:\n\u00a0 \u00a0 \u00a0 \u00a0 cpu: {{ .Values.zookeeper.resources.requests.cpu }}\n\u00a0 \u00a0 \u00a0 \u00a0 memory: {{ .Values.zookeeper.resources.requests.memory }}\n\u00a0 \u00a0 \u00a0 limits:\n\u00a0 \u00a0 \u00a0 \u00a0 cpu: {{ .Values.zookeeper.resources.limits.cpu }}\n\u00a0 \u00a0 \u00a0 \u00a0 memory: {{ .Values.zookeeper.resources.limits.memory }}\n\u00a0 \u00a0 replicas: {{ .Values.zookeeper.replicas }} (2)<\/pre>\n\u00a0 \u00a0 storage: (1)\n\u00a0 \u00a0 \u00a0 type: jbod\n\u00a0 \u00a0 \u00a0 volumes:\n\u00a0 \u00a0 \u00a0 - id: 0\n\u00a0 \u00a0 \u00a0 \u00a0 type: persistent-claim\n\u00a0 \u00a0 \u00a0 \u00a0 size: {{ .Values.kafka.storage.size }}\n\u00a0 \u00a0 \u00a0 \u00a0 deleteClaim: true\n\u00a0 \u00a0 \u00a0 \u00a0 class: {{ .Values.kafka.storage.class }}\n\u00a0 \u00a0 \u00a0 - id: 1\n\u00a0 \u00a0 \u00a0 \u00a0 type: persistent-claim\n\u00a0 \u00a0 \u00a0 \u00a0 size: {{ .Values.kafka.storage.size }}\n\u00a0 \u00a0 \u00a0 \u00a0 deleteClaim: true\n\u00a0 \u00a0 \u00a0 \u00a0 class: {{ .Values.kafka.storage.class }}\n\u00a0 \u00a0 config: (2)\n\u00a0 \u00a0 \u00a0message.max.bytes:{{ .Values.kafka.config.messageMaxBytes }} (3)\n\u00a0 \u00a0 \u00a0num.partitions:{{.Values.kafka.config.defaultNumPartitions }}(4)\n\u00a0 \u00a0 \u00a0log.retention.hours:{{.Values.kafka.config.logRetentionHours}}(5)\n\u00a0 \u00a0 \u00a0num.network.threads: {{.Values.kafka.config.networkThreads }} (6)\n\u00a0 \u00a0 \u00a0num.io.threads: {{.Values.kafka.config.ioThreads }} (7)<\/pre>\n
\n\u2022 (3) maksymalny rozmiar wiadomo\u015bci,
\n\u2022 (4) domy\u015blna liczba partycji,
\n\u2022 (5) domy\u015blna retencja dla topic\u00f3w,
\n\u2022 (6) liczba w\u0105tk\u00f3w sieciowych,
\n\u2022 (7) liczba w\u0105tk\u00f3w I\/O.<\/p>\n![\"\"](\"https:\/\/inteca.com\/wp-content\/uploads\/2025\/03\/6.png\")
<\/p>\n![\"\"](\"https:\/\/inteca.com\/wp-content\/uploads\/2025\/03\/7.png\")
<\/p>\n![\"\"](\"https:\/\/inteca.com\/wp-content\/uploads\/2025\/03\/8.png\")
<\/p>\napiVersion: kafka.strimzi.io\/v1beta2\nkind: KafkaConnect\nmetadata:\n\u00a0 name: connect-cluster-{{ include \"broker.fullname\" . }}\n\u00a0 annotations:\n\u00a0 \u00a0 strimzi.io\/use-connector-resources: \"true\"\nspec:\n\u00a0 image:{{ .Values.kafkaConnect.image.repository}}:{{ .Values.kafkaConnect.image.tag}}\n\u00a0 replicas: {{ .Values.kafkaConnect.replicas}} (1)\n\u00a0 bootstrapServers: {{ include \"broker.fullname\" . }}-kafka-bootstrap:9093 (2)<\/pre>\n![\"\"](\"https:\/\/inteca.com\/wp-content\/uploads\/2025\/03\/9.png\")
<\/p>\napiVersion: kafka.strimzi.io\/v1beta2\nkind: KafkaTopic\nmetadata:\n\u00a0 name: {{ .Values.kafkaTopics.file.data.name }} (1)\n\u00a0 labels:\n\u00a0 \u00a0 strimzi.io\/cluster: {{ .Values.kafkaTopics.cluster }}\nspec:\n\u00a0 partitions: {{.Values.kafkaTopics.file.data.partitions }} (2)\n\u00a0 replicas: {{.Values.kafkaTopics.file.data.replicas }} (3)\n\u00a0 config:\n\u00a0 \u00a0retention.ms:{{.Values.kafkaTopics.file.data.config.retention}} (4)<\/pre>\n
\n\u2022 (1) Nazw\u0119 topicu.
\n\u2022 (2) Liczb\u0119 partycji topicu \u2013 je\u015bli nie zostanie podana, Kafka u\u017cyje domy\u015blnej warto\u015bci skonfigurowanej na poziomie brokera (zgodnie z opisem CRD dla klastra Kafka).
\n\u2022 (3) Liczb\u0119 replik topicu \u2013 okre\u015bla, ile kopii danych powinno by\u0107 przechowywanych w klastrze.
\n\u2022 (4) Retencj\u0119 topicu \u2013 czas przechowywania danych przed ich usuni\u0119ciem. Wiadomo\u015bci starsze ni\u017c okre\u015blona warto\u015b\u0107 b\u0119d\u0105 usuwane.<\/p>\napiVersion: kafka.strimzi.io\/v1beta2\nkind: KafkaConnector\nmetadata:\n\u00a0 \u00a0 name: jmssourceconnector-{{ $connector.name }}\n\u00a0 \u00a0 labels:\n\u00a0 \u00a0 \u00a0 \u00a0 strimzi.io\/cluster: {{ $.Values.kafkaConnectors.kccluster }}\nspec:\n\u00a0 \u00a0 class: com.datamountaineer.streamreactor.connect.jms.source.JMSSourceConnector (1)\n\u00a0 \u00a0 tasksMax: {{ .Values.connector.tasksMax }} (2)\n\u00a0 \u00a0 autoRestart:\n\u00a0 \u00a0 \u00a0 \u00a0 enabled: {{ $.Values.connector.autoRestart }} (3)\n\u00a0 \u00a0 config: (4)\n\u00a0 \u00a0 \u00a0 \u00a0 connect.jms.connection.factory: {{ .Values.connector.connectionFactory \u00a0}}\n\u00a0 \u00a0 \u00a0 \u00a0 connect.jms.destination.selector: {{ .Values.connector.selector }}\n\u00a0 \u00a0 \u00a0 \u00a0 connect.jms.initial.context.factory:{{.Values.connector.contextFactoryClass }}\n\u00a0 \u00a0 \u00a0 \u00a0 connect.jms.kcql: INSERT INTO test_topic SELECT * FROM {{ .Values .connector.queue }} WITHTYPE QUEUE\n\u00a0 \u00a0 \u00a0 \u00a0 connect.jms.queues: {{ .Values.connector.queue }}\n\u00a0 \u00a0 \u00a0 \u00a0 connect.jms.url: {{ .Values.connector.urls }}\n\u00a0 \u00a0 \u00a0 \u00a0 connect.progess.enabled: {{ .Values.connector.progessEnabled }}\n\u00a0 \u00a0 \u00a0 \u00a0 connect.jms.scale.type: {{ .Values.scaleType }}\n\u00a0 \u00a0 \u00a0 \u00a0 connect.jms.username: {{ .Values.username }}\n\u00a0 \u00a0 \u00a0 \u00a0 connect.jms.password: {{ .Values.password }}<\/pre>\n\n
Bezpiecze\u0144stwo systemu komunikacji zdarzeniowej<\/h2>\n
\n
listeners=BROKER:\/\/localhost:9092\nlistener.security.protocol.map=BROKER:SASL_SSL,CONTROLLER:SASL_SSL<\/pre>\n
apiVersion: kafka.strimzi.io\/v1beta2\nkind: Kafka\nmetadata:\n\u00a0 name: {{ include \"broker.fullname\" . }}\n\u00a0 labels:\n\u00a0 \u00a0 {{- include \"broker.labels\" . | nindent 4 }}\nspec:\n\u00a0 kafka:\n\u00a0 \u00a0 \u2026\n\u00a0 \u00a0 listeners: (1)\n\u00a0 \u00a0 \u00a0 - name: tls (2)\n\u00a0 \u00a0 \u00a0 \u00a0 port: 9093\n\u00a0 \u00a0 \u00a0 \u00a0 type: internal\n\u00a0 \u00a0 \u00a0 \u00a0 tls: true\n\u00a0 \u00a0 \u00a0 \u00a0 authentication:\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 type: tls \u00a0 \u00a0 \u00a0 \u00a0\n\u00a0 \u00a0 \u00a0 - name: external (3)\n\u00a0 \u00a0 \u00a0 \u00a0 port: 9094\n\u00a0 \u00a0 \u00a0 \u00a0 type: route\n\u00a0 \u00a0 \u00a0 \u00a0 tls: true \u00a0 \u00a0 \u00a0 \n\u00a0 \u00a0 \u00a0 \u00a0 authentication:\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 type: tls\n\n\u00a0\u00a0\u00a0\u00a0 \u2026<\/pre>\n\n
![\"\"](\"https:\/\/inteca.com\/wp-content\/uploads\/2025\/03\/10.png\")
<\/p>\napiVersion: kafka.strimzi.io\/v1beta2\nkind: KafkaConnect\nmetadata:\n\u00a0 name: connect-cluster-{{ include \"broker.fullname\" . }}\nspec:\n\u00a0 rack:\n\u00a0 \u2026\n\u00a0 bootstrapServers:{{include \"broker.fullname\" .}}-kafka-bootstrap:9093\n\u00a0 authentication: (1)\n\u00a0 \u00a0 type: tls\n\u00a0 \u00a0 certificateAndKey:\n\u00a0 \u00a0 \u00a0 secretName: kafka-connect-tls-user\n\u00a0 \u00a0 \u00a0 certificate: user.crt\n\u00a0 \u00a0 \u00a0 key: user.key\n\u00a0 tls: (2)\n\u00a0 \u00a0 trustedCertificates:\n\u00a0 \u00a0 \u00a0 - secretName: {{ include \"broker.fullname\" . }}-cluster-ca-cert\n\u00a0 \u00a0 \u00a0 \u00a0 certificate: ca.crt<\/pre>\n\n
apiVersion: kafka.strimzi.io\/v1beta2\nkind: KafkaUser\nmetadata:\n\u00a0 name: kafka-connect-tls-user\n\u00a0 labels:\n\u00a0 \u00a0 strimzi.io\/cluster: {{ include \"broker.fullname\" . }}\nspec:\n\u00a0 authentication: (1)\n\u00a0 \u00a0 type: tls\n\u00a0 authorization:(2)\n\u00a0 \u00a0 type: simple\n\u00a0 \u00a0 acls:\n\u00a0 \u00a0 \u00a0 - resource: (3)\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 type: topic (3.1)\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 name: event-data (3.2)\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 patternType: literal (3.3)\n\u00a0 \u00a0 \u00a0 \u00a0 operations: (3.4)\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 - Create\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 - Describe\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 - DescribeConfigs\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 - Read\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 - Write\n\u00a0 \u00a0 \u00a0 \u00a0 host: \"*\" (3.5)\n\u00a0 \u00a0 \u00a0 # consumer group aws s3 sink connector\n\u00a0 \u00a0 \u00a0 - resource: \n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 type: group (4)\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 name: connect-sinkconnector\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 patternType: literal\n\u00a0 \u00a0 \u00a0 \u00a0 operations:\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 - Create\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 - Describe\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 - Read\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 - Write\n\u00a0 \u00a0 \u00a0 \u00a0 host: \"*\"<\/pre>\n\n
\n
![\"\"](\"https:\/\/inteca.com\/wp-content\/uploads\/2025\/03\/11.png\")
<\/p>\n2024-10-02 13:42:21,932 INFO Principal = User:CN=kafka-connect-tls-user is Denied Operation = Describe from host = 10.253.23.147 on resource = Cluster:LITERAL:kafka-cluster for request = ListPartitionReassignments with resourceRefCount = 1<\/pre>\n
- resource:\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 type: cluster\n\u00a0 \u00a0 \u00a0 \u00a0 operations:\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 - Describe\n\u00a0 \u00a0 \u00a0 \u00a0 host: \"*\"<\/pre>\n
Wysoka dost\u0119pno\u015b\u0107 oraz odtwarzanie po awarii<\/h2>\n
![\"\"](\"https:\/\/inteca.com\/wp-content\/uploads\/2025\/03\/12.png\")
<\/p>\n\n
affinity:\n\u00a0\u00a0 nodeAffinity:\n\u00a0\u00a0\u00a0\u00a0\u00a0 requiredDuringSchedulingIgnoredDuringExecution:\n\n \u00a0\u00a0\u00a0\u00a0 \u2026<\/pre>\n
\n
\n
\n
![\"\"](\"https:\/\/inteca.com\/wp-content\/uploads\/2025\/03\/13.png\")
<\/p>\n![\"\"](\"https:\/\/inteca.com\/wp-content\/uploads\/2025\/03\/14.png\")
<\/p>\n\n
![\"\"](\"https:\/\/inteca.com\/wp-content\/uploads\/2025\/03\/15.png\")
<\/p>\n\n
\n
Monitorowanie dzia\u0142ania Kafka<\/h2>\n
apiVersion: monitoring.coreos.com\/v1\nkind: PodMonitor\nmetadata:\n\u00a0 name: kafka-resources-metrics\n\u00a0 labels:\n\u00a0 \u00a0 app: strimzi\nspec:\n\u00a0 selector:\n\u00a0 \u00a0 matchExpressions:\n\u00a0 \u00a0 \u00a0 - key: \"strimzi.io\/kind\"\n\u00a0 \u00a0 \u00a0 \u00a0 operator: In\n\u00a0 \u00a0 \u00a0 \u00a0 values: [\"Kafka\", \"KafkaConnect\", \"KafkaMirrorMaker\", \"KafkaMirrorMaker2\"]\n\u00a0 namespaceSelector:\n\u00a0 \u00a0 matchNames:\n\u00a0 \u00a0 \u00a0 - {{ .Release.Namespace }}\n\u00a0 podMetricsEndpoints:\n\u00a0 - path: \/metrics\n\u00a0 \u00a0 port: tcp-prometheus\n\u00a0 \u00a0 interval: 1m\n\u00a0 \u00a0 relabelings:\n\u00a0 \u00a0 - separator: ;\n\u00a0 \u00a0 \u00a0 regex: __meta_kubernetes_pod_label_(strimzi_io_.+)\n\u00a0 \u00a0 \u00a0 replacement: $1\n\u00a0 \u00a0 \u00a0 action: labelmap\n\n\u00a0\u00a0\u00a0\u00a0 \u2026<\/pre>\n![\"\"](\"https:\/\/inteca.com\/wp-content\/uploads\/2025\/03\/16.png\")
<\/p>\n
![\"\"](\"https:\/\/inteca.com\/wp-content\/uploads\/2025\/03\/17.png\")
<\/p>\n![\"\"](\"https:\/\/inteca.com\/wp-content\/uploads\/2025\/03\/18.png\")
<\/p>\n![\"\"](\"https:\/\/inteca.com\/wp-content\/uploads\/2025\/03\/19.png\")
<\/p>\n