Witamy, Habr!
Kiedyś jako pierwsi wprowadziliśmy na rynek rosyjski temat i kontynuujemy jego rozwój. Szczególnie interesujący wydał się nam temat interakcji między Kafka a . Przegląd (dość ostrożny) na ten temat ukazał się na blogu firmy Confluent już w październiku ubiegłego roku autorstwa Gwen Shapiro. Dzisiaj chcemy zwrócić uwagę na świeższy, kwietniowy artykuł Johann’a Gygera, który, choć nie obyło się bez znaku zapytania w tytule, omawia temat w bardziej szczególny sposób, towarzysząc tekstowi ciekawymi linkami. Proszę o wybaczenie za luźne tłumaczenie „chaos monkey”, jeśli będzie to możliwe!
Wprowadzenie
Kubernetes jest przeznaczony do pracy z obciążeniami, które nie przechowują stanu. Zazwyczaj takie obciążenia mają formę architektury mikrousługowej, są lekkie, dobrze poddają się poziomemu skalowaniu, przestrzegają zasad aplikacji 12-factor, pozwalają na pracę z automatycznymi wyłącznikami (circuit breaker) oraz małpami chaosu (chaos monkeys).
Kafka z drugiej strony w zasadzie pełni rolę rozproszonej bazy danych. W związku z tym, pracując z nią, musisz radzić sobie z stanem, a ten jest znacznie cięższy niż mikrousługa. Kubernetes obsługuje obciążenia z zachowaniem stanu, ale jak zauważa Kelsey Hightower w swoich dwóch tweetach, należy z nimi obchodzić się ostrożnie:
Niektórzy mają wrażenie, że jeśli zastosujesz Kubernetes na obciążeniu z zachowaniem stanu, zamienia się on w w pełni zarządzaną bazę danych, zdolną konkurować z RDS. To nieprawda. Może, jeżeli się wystarczająco napracujesz, dodasz dodatkowe komponenty i zaangażujesz zespół SRE-inżynierów, uda się skonfigurować RDS na Kubernetes.
Zawsze wszystkim zalecam zachowanie wyjątkowej ostrożności przy uruchamianiu obciążeń z zachowaniem stanu na Kubernetes. Większość osób, które się pytają, „czy mogę uruchomić obciążenia z zachowaniem stanu na Kubernetes”, nie ma wystarczającego doświadczenia w pracy z Kubernetes, a często także z tym obciążeniem, o które pytają.
Czy warto uruchamiać Kafka na Kubernetes? Pytanie pomocnicze: czy Kafka będzie działać lepiej bez Kubernetes? Dlatego w tym artykule chciałbym podkreślić, jak Kafka i Kubernetes się uzupełniają oraz jakie pułapki mogą się pojawić przy ich połączeniu.
Czas wykonania
Porozmawiajmy o podstawowej kwestii — o środowisku wykonawczym jako takim
Proces
Brokerzy Kafka są przydatni w pracy z CPU. TLS może wprowadzać pewne koszty. Klienci Kafka mogą jednak bardziej obciążać CPU, jeśli korzystają z szyfrowania, ale nie wpływa to na brokerów.
Pamięć
Brokerzy Kafka pochłaniają pamięć. Rozmiar stosu JVM zwykle powinien być ograniczony do 4–5 GB, ale potrzebujesz również dużo pamięci systemowej, ponieważ Kafka bardzo aktywnie wykorzystuje pamięć podręczną. W Kubernetes odpowiednio ustawiaj limity kontenera dla zasobów i zapotrzebowań.
Przechowywanie danych
Przechowywanie danych w kontenerach jest efemeryczne – dane są tracone podczas restartu. Dla danych Kafka można używać woluminu, a efekt będzie podobny: dane twojego brokera zostaną utracone po zakończeniu. Twoje wiadomości mogą nadal być przechowywane na innych brokerach jako repliki. Dlatego po restarcie uszkodzony broker powinien najpierw zreplikować wszystkie dane, co może zająć trochę czasu. emptyDir, a efekt będzie analogiczny: dane twojego brokera zostaną utracone po zakończeniu. Twoje wiadomości mogą nadal być przechowywane na innych brokerach jako repliki. Dlatego po restarcie uszkodzony broker powinien najpierw zreplikować wszystkie dane, co może zająć trochę czasu.
Dlatego należy używać trwałego przechowywania danych. Niech to będzie nielokalne trwałe przechowywanie z systemem plików XFS lub, dokładniej, ext4. Nie używaj NFS. Ostrzegam cię. NFS w wersjach v3 lub v4 nie będzie działać. W skrócie, broker Kafka zakończy działanie, jeśli nie będzie mógł usunąć katalogu z danymi z powodu problemu z "głupimi zmianami nazw", co dotyczy NFS. Jeśli jeszcze cię nie przekonałem, bardzo uważnie . Przechowywanie danych powinno być nielokalne, aby Kubernetes mógł bardziej elastycznie wybrać nowy węzeł po restarcie lub relokacji.
Sieć
Podobnie jak w przypadku większości rozproszonych systemów, wydajność Kafka w dużym stopniu zależy od minimalizacji opóźnień sieciowych i maksymalizacji szerokości pasma. Nie próbuj umieszczać wszystkich brokerów na tym samym węźle, ponieważ wpłynie to na dostępność. Jeśli wystąpi awaria węzła Kubernetes, to cały klaster Kafka też zawiedzie. Nie rozprzestrzeniaj także klastra Kafka na całe centra danych. To samo dotyczy klastra Kubernetes. Dobrym kompromisem jest wybór różnych stref dostępności.
Konfiguracja
Zwykłe manifesty
Na stronie Kubernetes znajduje się na temat konfigurowania ZooKeepera za pomocą manifestów. Ponieważ ZooKeeper jest częścią Kafka, od tego warto zacząć zapoznawanie się z tym, jakie koncepcje Kubernetes są tutaj zastosowane. Zrozumienie tego pozwoli ci wykorzystać te same koncepcje z klastrem Kafka.
- Pod: pod - to minimalna jednostka wdrażalna w Kubernetes. Pod zawiera twoje obciążenie robocze, a sam pod odpowiada procesowi w twoim klastrze. W podzie znajduje się jeden lub więcej kontenerów. Każdy serwer ZooKeeper w zespole i każdy broker w klastrze Kafka będą działać w osobnym podzie.
- StatefulSet: StatefulSet - to obiekt Kubernetes, który pracuje z wieloma obciążeniami roboczymi wymagającymi zachowania stanu, a takie obciążenia wymagają koordynacji. StatefulSet zapewnia gwarancje dotyczące uporządkowania podów i ich unikalności.
- Usługi bezgłowe: Usługi pozwalają odłączać pody od klientów za pomocą logicznej nazwy. Kubernetes w tym przypadku odpowiada za równoważenie obciążenia. Jednak przy operacjach z obciążeniami roboczymi zachowującymi stan, jak w przypadku ZooKeepera i Kafka, klienci muszą wymieniać informacje z konkretnym instancją. Tutaj przydają się usługi bezgłowe: w takim przypadku klient wciąż ma logiczną nazwę, ale nie można się bezpośrednio zwracać do podu.
- Wolumen do długoterminowego przechowywania: takie wolumeny są potrzebne do konfiguracji nielokalnego blokowego długoterminowego przechowywania, o którym była mowa wcześniej.
Na zapewnia kompleksowy zestaw manifestów, które ułatwiają rozpoczęcie pracy z Kafka na Kubernetes.
Diagramy Helm
Helm to menedżer pakietów dla Kubernetes, który można porównać do menedżerów pakietów dla systemów operacyjnych, takich jak yum, apt, Homebrew czy Chocolatey. Dzięki niemu wygodnie zainstalujesz wcześniej określone pakiety oprogramowania opisane w wykresach Helm. Dobrze dobrany wykres Helm ułatwia złożone zadanie: jak prawidłowo skonfigurować wszystkie parametry do używania Kafka na Kubernetes. Istnieje kilka wykresów Kafka: oficjalny znajduje się , jest jeden od , jeszcze jeden – od .
Operatory
Ponieważ Helm ma pewne wady, rosnącą popularność zyskuje inne narzędzie: operatory Kubernetes. Operator nie tylko pakuje oprogramowanie dla Kubernetes, ale także umożliwia jego wdrażanie oraz zarządzanie nim.
Na liście wspomniane są dwa operatory dla Kafka. Jeden z nich to . Przy pomocy Strimzi nie ma trudności w uruchomieniu klastra Kafka w zaledwie kilka minut. Prawie żadnej konfiguracji nie trzeba wprowadzać, ponadto sam operator oferuje kilka przyjemnych funkcji, takich jak szyfrowanie TLS typu "punkt-punkt" wewnątrz klastra. Confluent również oferuje .
Wydajność
Bardzo ważne jest testowanie wydajności, zaopatrując posiadany egzemplarz Kafka w punkty kontrolne. Takie testy pomogą ci zidentyfikować potencjalne wąskie gardła, zanim wystąpią problemy. Na szczęście Kafka już zapewnia dwa narzędzia do testowania wydajności: kafka-producer-perf-test.sh i kafka-consumer-perf-test.sh. Korzystaj z nich aktywnie. Dla informacji możesz porównać wyniki opisane w Jay'a Krepsa, lub kierować się Amazon MSK od Stéphane Maarek.
Operacje
Monitoring
Przejrzystość w systemie jest bardzo ważna – w przeciwnym razie nie zrozumiesz, co się w nim dzieje. Dziś istnieje solidny zestaw narzędzi zapewniających monitorowanie oparte na metrykach w stylu cloud native. Dwa popularne narzędzia do tego celu to – Prometheus i Grafana. Prometheus może zbierać metryki ze wszystkich procesów Java (Kafka, Zookeeper, Kafka Connect) z pomocą eksportera JMX – w najprostszy sposób. Jeśli dołożysz metryki cAdvisor, będziesz mieć pełniejszy obraz tego, jak w Kubernetes wykorzystywane są zasoby.
Strimzi ma bardzo przydatny przykład dashboardu Grafana dla Kafka. Wizualizuje kluczowe metryki, takie jak niedoreplikowane sekcje lub te, które są offline. Wszystko jest tam bardzo przejrzyste. Te metryki są uzupełnione informacjami o wykorzystaniu zasobów i wydajności, a także wskaźnikami stabilności. W ten sposób otrzymujesz podstawowy monitoring klastra Kafka zupełnie za darmo!
Źródło:
Wszystko to warto by było uzupełnić monitoringiem klientów (metryki dotyczące konsumentów i producentów), a także monitoringiem opóźnień (do tego służy ) i kompleksowym monitoringiem – w tym celu użyj .
Rejestrowanie
Logowanie to kolejna kluczowa czynność. Upewnij się, że wszystkie kontenery w twojej instalacji Kafka są logowane do stdout i stderr, a także zadbaj o to, aby twój klaster Kubernetes agregował wszystkie logi w centralnej infrastrukturze logowania, na przykład w .
Sprawdzenie działania
Kubernetes używa sond „żywotności” (liveness) i gotowości (readiness), aby sprawdzić, czy twoje pody działają prawidłowo. Jeśli test żywotności nie powiedzie się, Kubernetes zatrzyma ten kontener, a następnie automatycznie go ponownie uruchomi, jeśli polityka ponownego uruchamiania jest ustawiona odpowiednio. Jeśli test gotowości nie powiedzie się, Kubernetes izoluje ten pod od obsługi żądań. Dzięki temu w takich przypadkach nie jest już potrzebna żadna interwencja ręczna, co jest dużym plusem.
Wydawanie aktualizacji
StatefulSet obsługują automatyczne aktualizacje: przy wyborze strategii RollingUpdate każdy pod Kafka będzie aktualizowany jeden po drugim. Dzięki temu można zredukować czas przestojów do zera.
Skalowanie
Skalowanie klastra Kafka to niełatwe zadanie. Jednak w Kubernetes bardzo łatwo jest skalować pody do określonej liczby replik, co oznacza, że możesz deklaratywnie określić tyle brokerów Kafka, ile chcesz. Najtrudniejsze w tej kwestii jest przepisanie sekcji po skalowaniu w górę lub przed skalowaniem w dół. Ponownie, w tej kwestii pomoże ci Kubernetes.
Administracja
Zarządzanie swoim klastrem Kafka, w szczególności tworzenie tematów oraz przypisywanie sektorów, można realizować za pomocą dostępnych skryptów powłoki, otwierając interfejs wiersza poleceń w swoich podach. Jednakże, takie rozwiązanie nie jest zbyt estetyczne. Strimzi wspiera zarządzanie tematami za pomocą innego operatora. Tutaj jest też co rozwijać.
Kopia zapasowa i przywracanie
Teraz dostępność Kafka będzie zależała również od dostępności Kubernetes. Jeśli Twój klaster Kubernetes ulegnie awarii, to w najgorszym przypadku zawiedzie także klaster Kafka. Zgodnie z prawem Murphy'ego, najprawdopodobniej to się zdarzy i stracisz dane. Aby zmniejszyć ryzyko takiego sytuacji, dobrze przemyśl koncepcję kopii zapasowej. Można skorzystać z MirrorMakera, inną opcją jest użycie S3, jak opisano w tym od Zalando.
Podsumowanie
Pracując z małymi lub średnimi klastrami Kafka, zdecydowanie warto korzystać z Kubernetes, ponieważ zapewnia to dodatkową elastyczność i ułatwia pracę z operatorami. Jeśli masz do czynienia z poważnymi wymaganiami niefunkcjonalnymi, dotyczącymi opóźnienia i/lub przepustowości, być może lepiej rozważyć inne opcje wdrożenia.
Źródło: habr.com
