Czy Kafka na Kubernetesie jest dobry?

Pozdrawiam, Habro!

Swego czasu jako pierwsi wprowadziliśmy ten temat na rynek rosyjski Kafka i kontynuuj tor dla jego rozwoju. W szczególności znaleźliśmy temat interakcji między Kafką a Kubernetes. Obserwowalne (i dość ostrożne) artykuł temat ten został opublikowany na blogu Confluent już w październiku ubiegłego roku pod redakcją Gwen Shapiry. Dziś zwracamy uwagę na nowszy, kwietniowy artykuł Johanna Gygera, który choć nie bez znaku zapytania w tytule, bada temat w sposób bardziej merytoryczny, opatrzony tekstem ciekawymi linkami. Proszę, wybacz nam darmowe tłumaczenie „małpy chaosu”, jeśli możesz!

Wprowadzenie

Kubernetes został zaprojektowany do obsługi obciążeń bezstanowych. Zazwyczaj takie obciążenia są prezentowane w formie architektury mikrousługowej, są lekkie, dobrze skalują się w poziomie, są zgodne z zasadami aplikacji 12-czynnikowych i mogą współpracować z wyłącznikami automatycznymi i małpami chaosu.

Z drugiej strony Kafka działa zasadniczo jako rozproszona baza danych. Dlatego podczas pracy musisz radzić sobie ze stanem, a jest to znacznie cięższe niż mikrousługa. Kubernetes obsługuje obciążenia stanowe, ale jak Kelsey Hightower wskazuje w dwóch tweetach, należy się z nimi obchodzić ostrożnie:

Niektórzy uważają, że jeśli włączysz Kubernetes do obciążenia stanowego, stanie się on w pełni zarządzaną bazą danych, która może konkurować z RDS. To jest źle. Być może, jeśli będziesz wystarczająco ciężko pracować, dodać dodatkowe komponenty i przyciągnąć zespół inżynierów SRE, będziesz w stanie zbudować RDS na Kubernetesie.

Zawsze zalecam wszystkim zachowanie szczególnej ostrożności podczas uruchamiania obciążeń stanowych na platformie Kubernetes. Większość osób pytających „czy mogę uruchamiać obciążenia stanowe na Kubernetesie” nie ma wystarczającego doświadczenia z Kubernetesem i często z obciążeniem, o które pytają.

Czy zatem warto uruchomić Kafkę na Kubernetesie? Pytanie przeciwne: czy Kafka będzie działać lepiej bez Kubernetesa? Dlatego w tym artykule chcę podkreślić, jak Kafka i Kubernetes uzupełniają się i jakie pułapki mogą wiązać się z ich połączeniem.

Czas realizacji

Porozmawiajmy o rzeczy podstawowej – samym środowisku wykonawczym

proces

Brokerzy Kafka są przyjaźni dla procesora. TLS może powodować pewne obciążenie. Jednak klienci Kafki mogą zużywać więcej procesora, jeśli używają szyfrowania, ale nie ma to wpływu na brokerów.

Память

Brokerzy Kafki zjadają pamięć. Rozmiar sterty JVM jest zwykle ograniczony do 4-5 GB, ale będziesz potrzebować także dużo pamięci systemowej, ponieważ Kafka bardzo intensywnie wykorzystuje pamięć podręczną stron. W Kubernetes ustaw odpowiednio limity zasobów kontenera i żądań.

Magazyn danych

Przechowywanie danych w kontenerach jest efemeryczne — dane zostaną utracone po ponownym uruchomieniu. W przypadku danych Kafki możesz użyć woluminu emptyDir, a efekt będzie podobny: po zakończeniu dane Twojego brokera zostaną utracone. Twoje wiadomości mogą być nadal przechowywane u innych brokerów jako repliki. Dlatego po ponownym uruchomieniu broker, który uległ awarii, musi najpierw zreplikować wszystkie dane, a proces ten może zająć dużo czasu.

Dlatego warto korzystać z długoterminowego przechowywania danych. Niech będzie to nielokalny magazyn długoterminowy z systemem plików XFS, a dokładniej ext4. Nie używaj NFS-a. Ostrzegałem cię. Wersje NFS v3 lub v4 nie będą działać. Krótko mówiąc, broker Kafka ulegnie awarii, jeśli nie będzie mógł usunąć katalogu danych z powodu problemu „głupiej zmiany nazwy” w NFS. Jeśli jeszcze Cię nie przekonałem, to bardzo ostrożnie przeczytaj ten artykuł. Magazyn danych powinien być nielokalny, aby Kubernetes mógł bardziej elastycznie wybierać nowy węzeł po ponownym uruchomieniu lub relokacji.

Sieć

Podobnie jak w przypadku większości systemów rozproszonych, wydajność Kafki w dużym stopniu zależy od utrzymywania opóźnień sieci na minimalnym poziomie i maksymalnej przepustowości. Nie próbuj hostować wszystkich brokerów w tym samym węźle, ponieważ zmniejszy to dostępność. Jeśli węzeł Kubernetes ulegnie awarii, cały klaster Kafka ulegnie awarii. Nie należy także rozpraszać klastra Kafka w całych centrach danych. To samo dotyczy klastra Kubernetes. Dobrym kompromisem w tym przypadku jest wybór różnych stref dostępności.

Konfiguracja

Regularne manifesty

Witryna Kubernetes ma bardzo dobry przewodnik o tym, jak skonfigurować ZooKeepera za pomocą manifestów. Ponieważ ZooKeeper jest częścią Kafki, jest to dobre miejsce, aby rozpocząć zapoznawanie się z koncepcjami Kubernetesa, które mają tutaj zastosowanie. Gdy to zrozumiesz, możesz użyć tych samych koncepcji w przypadku klastra Kafka.

• pod: Pod to najmniejsza jednostka, którą można wdrożyć w Kubernetes. Pod zawiera obciążenie, a sam zasobnik odpowiada procesowi w klastrze. Kapsuła zawiera jeden lub więcej pojemników. Każdy serwer ZooKeeper w zestawie i każdy broker w klastrze Kafka będą działać w oddzielnym zasobniku.
• Zestaw stanowy: A StatefulSet to obiekt Kubernetes, który obsługuje wiele obciążeń stanowych, a takie obciążenia wymagają koordynacji. StatefulSets zapewniają gwarancje dotyczące kolejności podów i ich unikalności.
• Usługi bez głowy: Usługi umożliwiają odłączanie podów od klientów przy użyciu nazwy logicznej. Kubernetes w tym przypadku odpowiada za równoważenie obciążenia. Jednak podczas obsługi obciążeń stanowych, takich jak ZooKeeper i Kafka, klienci muszą komunikować się z określoną instancją. Tutaj z pomocą przychodzą usługi headless: w tym przypadku klient nadal będzie miał logiczną nazwę, ale nie będziesz musiał bezpośrednio kontaktować się z podem.
• Długoterminowa objętość przechowywania: Te woluminy są potrzebne do skonfigurowania wspomnianej powyżej nielokalnej pamięci trwałej blokowej.

Na Yolean Zawiera kompleksowy zestaw manifestów, które pomogą Ci rozpocząć pracę z platformą Kafka na platformie Kubernetes.

Wykresy steru

Helm to menedżer pakietów dla Kubernetes, który można porównać do menedżerów pakietów systemu operacyjnego, takich jak yum, apt, Homebrew lub Chocolatey. Ułatwia instalację predefiniowanych pakietów oprogramowania opisanych w tabelach Helma. Dobrze dobrany wykres Helma sprawia, że ​​trudne zadanie prawidłowego skonfigurowania wszystkich parametrów w celu użycia Kafki na Kubernetesie staje się proste. Istnieje kilka diagramów Kafki: oficjalny znajduje się w stanie inkubatora, jest jeden z Dopływ, jeszcze jeden - od Bitnami.

Operatorzy

Ponieważ Helm ma pewne braki, znaczną popularność zyskuje kolejne narzędzie: operatorzy Kubernetes. Operator nie tylko pakuje oprogramowanie dla Kubernetesa, ale także umożliwia jego wdrożenie i zarządzanie nim.

Na liście niesamowici operatorzy Wspomniano o dwóch operatorach dla Kafki. Jeden z nich - Strimzi. Dzięki Strimzi możesz łatwo uruchomić klaster Kafka w ciągu kilku minut. Praktycznie nie jest wymagana żadna konfiguracja, ponadto sam operator udostępnia kilka fajnych funkcji, na przykład szyfrowanie TLS punkt-punkt w obrębie klastra. Confluent zapewnia również własnego operatora.

produktywność

Ważne jest, aby przetestować wydajność, porównując instancję platformy Kafka. Takie testy pomogą Ci znaleźć potencjalne wąskie gardła, zanim pojawią się problemy. Na szczęście Kafka udostępnia już dwa narzędzia do testowania wydajności: kafka-producer-perf-test.sh и kafka-consumer-perf-test.sh. Korzystaj z nich aktywnie. Dla porównania możesz zapoznać się z wynikami opisanymi w ten post Jay Kreps, czyli skup się na ta recenzja Amazon MSK autorstwa Stéphane’a Maarka.

operacje

Monitorowanie

Przejrzystość w systemie jest bardzo ważna – inaczej nie zrozumiesz, co się w nim dzieje. Obecnie istnieje solidny zestaw narzędzi zapewniający monitorowanie oparte na metrykach w natywnym stylu chmury. 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) za pomocą eksportera JMX - w najprostszy sposób. Jeśli dodasz metryki cAdvisor, możesz pełniej zrozumieć, w jaki sposób zasoby są wykorzystywane w Kubernetes.

Strimzi ma bardzo wygodny przykład dashboardu Grafana dla Kafki. Wizualizuje kluczowe wskaźniki, na przykład dotyczące sektorów niedostatecznie zreplikowanych lub tych, które są offline. Wszystko jest tam bardzo jasne. Metryki te uzupełniają informacje o wykorzystaniu zasobów i wydajności, a także wskaźniki stabilności. Otrzymujesz więc podstawowe monitorowanie klastrów Kafki za darmo!

Źródło: streamzi.io/docs/master/#kafka_dashboard

Dobrze byłoby to wszystko uzupełnić o monitoring klientów (metryki dotyczące konsumentów i producentów), a także monitoring opóźnień (do tego służy Nora) i kompleksowe monitorowanie - w tym celu Monitor Kafki.

Logowanie

Rejestrowanie to kolejne ważne zadanie. Upewnij się, że wszystkie kontenery w instalacji Kafki są zalogowane stdout и stderr, a także upewnij się, że klaster Kubernetes agreguje wszystkie dzienniki w centralnej infrastrukturze rejestrowania, np. Elasticsearch.

Testowanie funkcjonalne

Kubernetes używa sond żywotności i gotowości, aby sprawdzić, czy Twoje pody działają normalnie. Jeśli sprawdzenie żywotności nie powiedzie się, Kubernetes zatrzyma ten kontener, a następnie automatycznie go zrestartuje, jeśli zostaną odpowiednio ustawione zasady ponownego uruchamiania. Jeśli sprawdzenie gotowości nie powiedzie się, Kubernetes izoluje pod od żądań obsługi. Zatem w takich przypadkach ręczna interwencja nie jest już w ogóle wymagana, co jest dużym plusem.

Wdrażanie aktualizacji

StatefulSets obsługują automatyczne aktualizacje: jeśli wybierzesz strategię RollingUpdate, każdy element w Kafce zostanie po kolei zaktualizowany. W ten sposób czas przestojów można zredukować do zera.

skalowanie

Skalowanie klastra Kafki nie jest łatwym zadaniem. Jednak Kubernetes bardzo ułatwia skalowanie podów do określonej liczby replik, co oznacza, że ​​możesz deklaratywnie zdefiniować dowolną liczbę brokerów Kafka. Najtrudniejszą rzeczą w tym przypadku jest ponowne przypisanie sektorów po zwiększeniu lub przed zmniejszeniu. Ponownie Kubernetes pomoże Ci w tym zadaniu.

administracja

Zadania związane z administrowaniem klastrem Kafka, takie jak tworzenie tematów i ponowne przypisywanie sektorów, można wykonać przy użyciu istniejących skryptów powłoki, otwierając interfejs wiersza poleceń w swoich podach. Jednak to rozwiązanie nie jest zbyt piękne. Strimzi obsługuje zarządzanie tematami za pomocą innego operatora. Jest tu trochę do poprawy.

Kopii zapasowych i odzyskiwania

Teraz dostępność Kafki będzie zależała także od dostępności Kubernetesa. Jeśli Twój klaster Kubernetes ulegnie awarii, w najgorszym przypadku Twój klaster Kafka również ulegnie awarii. Zgodnie z prawem Murphy'ego na pewno tak się stanie i utracisz dane. Aby zmniejszyć tego typu ryzyko, należy mieć dobry pomysł na tworzenie kopii zapasowych. Możesz użyć MirrorMakera, inną opcją jest użycie do tego S3, jak opisano w this Poczta z Zalando.

wniosek

Pracując z małymi i średnimi klastrami Kafki, zdecydowanie warto skorzystać z Kubernetesa, ponieważ zapewnia on dodatkową elastyczność i upraszcza pracę operatora. Jeśli masz bardzo duże, niefunkcjonalne wymagania dotyczące opóźnień i/lub przepustowości, lepszym rozwiązaniem może być rozważenie innej opcji wdrożenia.

Źródło: www.habr.com