Xin chào, Habr!
Có một thời, chúng tôi là người đầu tiên giới thiệu chủ đề này tới thị trường Nga và tiếp tục cho sự phát triển của nó. Đặc biệt, chúng tôi tìm thấy chủ đề tương tác giữa Kafka và . Có thể quan sát (và khá cẩn thận) chủ đề này đã được xuất bản trên blog Confluent vào tháng XNUMX năm ngoái dưới quyền tác giả của Gwen Shapira. Hôm nay chúng tôi muốn thu hút sự chú ý của bạn đến một bài báo gần đây hơn từ tháng XNUMX của Johann Gyger, người, mặc dù không có dấu chấm hỏi trong tiêu đề, nhưng vẫn xem xét chủ đề này một cách thực chất hơn, kèm theo văn bản những liên kết thú vị. Xin vui lòng tha thứ cho chúng tôi về bản dịch miễn phí của “khỉ hỗn loạn” nếu bạn có thể!
Giới thiệu
Kubernetes được thiết kế để xử lý khối lượng công việc không trạng thái. Thông thường, những khối lượng công việc như vậy được trình bày dưới dạng kiến trúc microservice, nhẹ, có quy mô tốt theo chiều ngang, tuân theo nguyên tắc của ứng dụng 12 yếu tố và có thể hoạt động với bộ ngắt mạch và khỉ hỗn loạn.
Mặt khác, Kafka về cơ bản hoạt động như một cơ sở dữ liệu phân tán. Vì vậy, khi làm việc bạn phải xử lý state và nó nặng hơn rất nhiều so với microservice. Kubernetes hỗ trợ tải trạng thái, nhưng như Kelsey Hightower đã chỉ ra trong hai tweet, chúng cần được xử lý cẩn thận:
Một số người cảm thấy rằng nếu bạn đưa Kubernetes vào một khối lượng công việc có trạng thái, nó sẽ trở thành một cơ sở dữ liệu được quản lý hoàn toàn cạnh tranh với RDS. Cái này sai. Có thể, nếu bạn làm việc đủ chăm chỉ, thêm các thành phần bổ sung và thu hút đội ngũ kỹ sư SRE, bạn sẽ có thể xây dựng RDS trên Kubernetes.
Tôi luôn khuyên mọi người nên hết sức thận trọng khi chạy khối lượng công việc có trạng thái trên Kubernetes. Hầu hết những người hỏi “tôi có thể chạy khối lượng công việc có trạng thái trên Kubernetes không” đều không có đủ kinh nghiệm với Kubernetes và thường có khối lượng công việc mà họ đang hỏi.
Vậy bạn có nên chạy Kafka trên Kubernetes không? Câu hỏi ngược lại: Kafka sẽ hoạt động tốt hơn nếu không có Kubernetes? Đó là lý do tại sao tôi muốn nhấn mạnh trong bài viết này cách Kafka và Kubernetes bổ sung cho nhau và những cạm bẫy có thể xảy ra khi kết hợp chúng.
Thời gian hoàn thành
Hãy nói về điều cơ bản - chính môi trường thời gian chạy
quá trình
Các nhà môi giới Kafka thân thiện với CPU. TLS có thể đưa ra một số chi phí. Tuy nhiên, máy khách Kafka có thể sử dụng nhiều CPU hơn nếu chúng sử dụng mã hóa, nhưng điều này không ảnh hưởng đến nhà môi giới.
ký ức
Các nhà môi giới Kafka ăn hết trí nhớ. Kích thước vùng heap JVM thường bị giới hạn ở mức 4-5 GB, nhưng bạn cũng sẽ cần nhiều bộ nhớ hệ thống vì Kafka sử dụng bộ nhớ đệm trang rất nhiều. Trong Kubernetes, hãy đặt giới hạn tài nguyên vùng chứa và yêu cầu tương ứng.
Kho dữ liệu
Việc lưu trữ dữ liệu trong vùng chứa chỉ là tạm thời - dữ liệu sẽ bị mất khi khởi động lại. Đối với dữ liệu Kafka, bạn có thể sử dụng một tập emptyDirvà hiệu ứng sẽ tương tự: dữ liệu nhà môi giới của bạn sẽ bị mất sau khi hoàn thành. Tin nhắn của bạn vẫn có thể được lưu trữ trên các nhà môi giới khác dưới dạng bản sao. Do đó, sau khi khởi động lại, nhà môi giới bị lỗi trước tiên phải sao chép tất cả dữ liệu và quá trình này có thể mất rất nhiều thời gian.
Đây là lý do tại sao bạn nên sử dụng lưu trữ dữ liệu lâu dài. Hãy để nó là bộ lưu trữ dài hạn không cục bộ với hệ thống tệp XFS hay chính xác hơn là ext4. Đừng sử dụng NFS. Tao đã cảnh cáo mày rồi. Phiên bản NFS v3 hoặc v4 sẽ không hoạt động. Nói tóm lại, nhà môi giới Kafka sẽ gặp sự cố nếu không thể xóa thư mục dữ liệu do vấn đề "đổi tên ngu ngốc" trong NFS. Nếu tôi chưa thuyết phục được bạn, hãy thật cẩn thận . Kho lưu trữ dữ liệu phải không cục bộ để Kubernetes có thể chọn nút mới linh hoạt hơn sau khi khởi động lại hoặc di dời.
Сеть
Giống như hầu hết các hệ thống phân tán, hiệu suất của Kafka phụ thuộc nhiều vào việc giữ độ trễ mạng ở mức tối thiểu và băng thông ở mức tối đa. Đừng cố gắng lưu trữ tất cả các nhà môi giới trên cùng một nút, vì điều này sẽ làm giảm tính khả dụng. Nếu nút Kubernetes bị lỗi thì toàn bộ cụm Kafka sẽ bị lỗi. Ngoài ra, không phân tán cụm Kafka trên toàn bộ trung tâm dữ liệu. Điều tương tự cũng xảy ra với cụm Kubernetes. Một sự thỏa hiệp tốt trong trường hợp này là chọn các vùng sẵn có khác nhau.
Cấu hình
Tuyên ngôn thường xuyên
Trang web Kubernetes có về cách định cấu hình ZooKeeper bằng tệp kê khai. Vì ZooKeeper là một phần của Kafka nên đây là nơi tốt để bắt đầu làm quen với những khái niệm Kubernetes nào được áp dụng ở đây. Khi bạn hiểu điều này, bạn có thể sử dụng các khái niệm tương tự với cụm Kafka.
- ở dưới: Nhóm là đơn vị có thể triển khai nhỏ nhất trong Kubernetes. Nhóm chứa khối lượng công việc của bạn và bản thân nhóm đó tương ứng với một quy trình trong cụm của bạn. Một pod chứa một hoặc nhiều container. Mỗi máy chủ ZooKeeper trong nhóm và mỗi nhà môi giới trong cụm Kafka sẽ chạy trong một nhóm riêng biệt.
- Bộ trạng thái: StatefulSet là một đối tượng Kubernetes xử lý nhiều khối lượng công việc có trạng thái và những khối lượng công việc như vậy cần có sự phối hợp. StatefulSets cung cấp sự đảm bảo về thứ tự của các nhóm và tính duy nhất của chúng.
- Dịch vụ không đầu: Dịch vụ cho phép bạn tách nhóm khỏi máy khách bằng tên logic. Kubernetes trong trường hợp này chịu trách nhiệm cân bằng tải. Tuy nhiên, khi vận hành các khối lượng công việc có trạng thái, chẳng hạn như ZooKeeper và Kafka, khách hàng cần giao tiếp với một phiên bản cụ thể. Đây là lúc các dịch vụ không có đầu phát huy tác dụng: trong trường hợp này, máy khách vẫn sẽ có tên logic nhưng bạn sẽ không phải liên hệ trực tiếp với nhóm.
- Dung lượng lưu trữ dài hạn: Cần có các ổ đĩa này để định cấu hình bộ lưu trữ liên tục theo khối không cục bộ được đề cập ở trên.
Trên Cung cấp một bộ bảng kê khai toàn diện để giúp bạn bắt đầu với Kafka trên Kubernetes.
Biểu đồ mũ bảo hiểm
Helm là trình quản lý gói dành cho Kubernetes có thể so sánh với các trình quản lý gói hệ điều hành như yum, apt, Homebrew hoặc Chocolatey. Nó giúp dễ dàng cài đặt các gói phần mềm được xác định trước được mô tả trong biểu đồ Helm. Biểu đồ Helm được chọn tốt sẽ giúp nhiệm vụ khó khăn về cách định cấu hình chính xác tất cả các tham số để sử dụng Kafka trên Kubernetes trở nên dễ dàng. Có một số sơ đồ Kafka: sơ đồ chính thức nằm ở , có một từ , một cái nữa - từ .
Người vận hành
Vì Helm có những thiếu sót nhất định nên một công cụ khác đang trở nên phổ biến đáng kể: toán tử Kubernetes. Nhà điều hành không chỉ đóng gói phần mềm cho Kubernetes mà còn cho phép bạn triển khai và quản lý phần mềm đó.
Trong danh sách Hai toán tử cho Kafka được đề cập. Một trong số chúng - . Với Strimzi, thật dễ dàng để thiết lập và chạy cụm Kafka của bạn trong vài phút. Hầu như không cần cấu hình, ngoài ra, bản thân nhà điều hành còn cung cấp một số tính năng hay, chẳng hạn như mã hóa TLS điểm-điểm trong cụm. Hợp lưu cũng cung cấp .
Năng suất
Điều quan trọng là kiểm tra hiệu suất bằng cách đo điểm chuẩn cho phiên bản Kafka của bạn. Những thử nghiệm như vậy sẽ giúp bạn tìm ra những điểm nghẽn tiềm ẩn trước khi vấn đề xảy ra. May mắn thay, Kafka đã cung cấp hai công cụ kiểm tra hiệu suất: kafka-producer-perf-test.sh и kafka-consumer-perf-test.sh. Hãy tích cực sử dụng chúng. Để tham khảo, bạn có thể tham khảo kết quả được mô tả trong Jay Kreps, hoặc tập trung vào Amazon MSK của Stéphane Maarek.
Hoạt động
Giám sát
Tính minh bạch trong hệ thống là rất quan trọng - nếu không bạn sẽ không hiểu chuyện gì đang xảy ra trong đó. Ngày nay, có một bộ công cụ vững chắc cung cấp khả năng giám sát dựa trên số liệu theo kiểu gốc trên nền tảng đám mây. Hai công cụ phổ biến cho mục đích này là Prometheus và Grafana. Prometheus có thể thu thập số liệu từ tất cả các quy trình Java (Kafka, Zookeeper, Kafka Connect) bằng cách sử dụng trình xuất JMX - theo cách đơn giản nhất. Nếu thêm số liệu cAdvisor, bạn có thể hiểu đầy đủ hơn cách sử dụng tài nguyên trong Kubernetes.
Strimzi có một ví dụ rất tiện lợi về bảng điều khiển Grafana dành cho Kafka. Nó trực quan hóa các số liệu chính, chẳng hạn như về các lĩnh vực chưa được nhân rộng hoặc những lĩnh vực ngoại tuyến. Mọi thứ đều rất rõ ràng ở đó. Các số liệu này được bổ sung bằng thông tin về hiệu suất và sử dụng tài nguyên cũng như các chỉ số về độ ổn định. Vì vậy, bạn nhận được giám sát cụm Kafka cơ bản mà không mất gì!
Nguồn:
Sẽ thật tuyệt nếu bổ sung tất cả điều này bằng tính năng giám sát khách hàng (số liệu về người tiêu dùng và nhà sản xuất), cũng như giám sát độ trễ (đối với điều này, có ) và giám sát từ đầu đến cuối - cho mục đích sử dụng này .
ghi nhật ký
Ghi nhật ký là một nhiệm vụ quan trọng khác. Đảm bảo tất cả các vùng chứa trong bản cài đặt Kafka của bạn đều được ghi vào stdout и stderrvà cũng đảm bảo rằng cụm Kubernetes của bạn tổng hợp tất cả nhật ký vào cơ sở hạ tầng ghi nhật ký trung tâm, ví dụ: .
Kiểm tra chức năng
Kubernetes sử dụng các đầu dò hoạt động và mức độ sẵn sàng để kiểm tra xem nhóm của bạn có chạy bình thường hay không. Nếu kiểm tra mức độ hoạt động không thành công, Kubernetes sẽ dừng vùng chứa đó rồi tự động khởi động lại nếu chính sách khởi động lại được đặt tương ứng. Nếu quá trình kiểm tra mức độ sẵn sàng không thành công, Kubernetes sẽ tách nhóm khỏi các yêu cầu dịch vụ. Vì vậy, trong những trường hợp như vậy, sự can thiệp thủ công hoàn toàn không còn cần thiết nữa, đây là một điểm cộng lớn.
Triển khai các bản cập nhật
StatefulSets hỗ trợ cập nhật tự động: nếu bạn chọn chiến lược RollingUpdate, mỗi chiến lược trong Kafka sẽ lần lượt được cập nhật. Bằng cách này, thời gian chết có thể giảm xuống bằng không.
Mở rộng quy mô
Mở rộng quy mô cụm Kafka không phải là một nhiệm vụ dễ dàng. Tuy nhiên, Kubernetes giúp dễ dàng mở rộng quy mô nhóm thành một số lượng bản sao nhất định, điều đó có nghĩa là bạn có thể khai báo bao nhiêu nhà môi giới Kafka tùy thích. Điều khó khăn nhất trong trường hợp này là chỉ định lại các lĩnh vực sau khi mở rộng quy mô hoặc trước khi thu nhỏ quy mô. Một lần nữa, Kubernetes sẽ giúp bạn thực hiện nhiệm vụ này.
quản lý
Các tác vụ liên quan đến quản lý cụm Kafka của bạn, chẳng hạn như tạo chủ đề và gán lại các lĩnh vực, có thể được thực hiện bằng cách sử dụng các tập lệnh shell hiện có bằng cách mở giao diện dòng lệnh trong nhóm của bạn. Tuy nhiên, giải pháp này không đẹp lắm. Strimzi hỗ trợ quản lý chủ đề bằng toán tử khác. Có một số chỗ để cải thiện ở đây.
Sao lưu và khôi phục
Bây giờ tính khả dụng của Kafka cũng sẽ phụ thuộc vào tính khả dụng của Kubernetes. Nếu cụm Kubernetes của bạn bị lỗi thì trong trường hợp xấu nhất, cụm Kafka của bạn cũng sẽ bị lỗi. Theo định luật Murphy thì điều này chắc chắn sẽ xảy ra và bạn sẽ bị mất dữ liệu. Để giảm thiểu loại rủi ro này, hãy có một kế hoạch dự phòng tốt. Bạn có thể sử dụng MirrorMaker, một tùy chọn khác là sử dụng S3 cho việc này, như được mô tả trong phần này từ Zalando.
Kết luận
Khi làm việc với các cụm Kafka vừa và nhỏ, chắc chắn nên sử dụng Kubernetes vì nó cung cấp thêm tính linh hoạt và đơn giản hóa trải nghiệm của người vận hành. Nếu bạn có các yêu cầu rất đáng kể về độ trễ phi chức năng và/hoặc thông lượng thì tốt hơn nên xem xét một số tùy chọn triển khai khác.
Nguồn: www.habr.com