Báo cáo dành cho các vấn đề thực tế của việc phát triển một nhà điều hành trong Kubernetes, thiết kế kiến trúc và các nguyên tắc hoạt động cơ bản của nó.
Trong phần đầu tiên của báo cáo, chúng ta sẽ xem xét:
- toán tử trong Kubernetes là gì và tại sao lại cần nó;
- người vận hành đơn giản hóa chính xác việc quản lý các hệ thống phức tạp như thế nào;
- những gì người vận hành có thể và những gì người vận hành không thể.
Tiếp theo, chúng ta chuyển sang thảo luận về cấu trúc bên trong của toán tử. Xem xét kiến trúc và hoạt động của nhà điều hành từng bước. Hãy cùng phân tích chi tiết:
- tương tác giữa người vận hành và Kubernetes;
- những chức năng nào mà toán tử đảm nhận và những gì ủy quyền cho Kubernetes.
Cân nhắc việc quản lý các phân đoạn và bản sao cơ sở dữ liệu trong Kubernetes.
Tiếp theo, chúng ta sẽ thảo luận về vấn đề lưu trữ dữ liệu:
- cách làm việc với Persistent Storage từ quan điểm của nhà điều hành;
- những cạm bẫy khi sử dụng Bộ nhớ cục bộ.
Trong phần cuối của báo cáo, chúng tôi sẽ xem xét các ví dụ thực tế của ứng dụng với Dịch vụ đám mây của Amazon hoặc Google. Báo cáo dựa trên ví dụ về kinh nghiệm phát triển và vận hành của nhà điều hành cho ClickHouse.
Video:
Tên tôi là Vladislav Klimenko. Hôm nay tôi muốn nói về kinh nghiệm của chúng tôi trong việc phát triển và vận hành một toán tử, đây là một toán tử chuyên dùng để quản lý các cụm cơ sở dữ liệu. Ví dụ để quản lý cụm ClickHouse.
Tại sao chúng ta có cơ hội nói về nhà điều hành và ClickHouse?
- Chúng tôi hỗ trợ và phát triển ClickHouse.
- Hiện tại, chúng tôi đang cố gắng từ từ đóng góp vào sự phát triển của ClickHouse. Và chúng tôi đứng thứ hai sau Yandex về số lượng thay đổi được thực hiện trong ClickHouse.
- Chúng tôi đang cố gắng thực hiện các dự án bổ sung cho hệ sinh thái ClickHouse.
Tôi muốn nói về một trong những dự án này. Đây là về nhà điều hành ClickHouse cho Kubernetes.
Trong báo cáo của mình, tôi muốn đề cập đến hai chủ đề:
- Chủ đề đầu tiên là cách toán tử cơ sở dữ liệu ClickHouse của chúng tôi hoạt động trong Kubernetes.
- Chủ đề thứ hai là cách hoạt động của bất kỳ toán tử nào, tức là cách nó tương tác với Kubernetes.
Tuy nhiên, hai câu hỏi này sẽ giao nhau trong báo cáo của tôi.
Ai sẽ quan tâm đến việc nghe những gì tôi đang cố gắng nói?
- Thú vị nhất sẽ là những người khai thác các nhà khai thác.
- Hoặc cho những ai muốn tự làm để hiểu cách thức hoạt động bên trong, cách người vận hành tương tác với Kubernetes và những cạm bẫy nào có thể xuất hiện.
Để hiểu rõ nhất những gì chúng ta sẽ thảo luận hôm nay, thật tuyệt nếu biết Kubernetes hoạt động như thế nào và có nền tảng cơ bản về điện toán đám mây.
ClickHouse là gì? Đây là một cơ sở dữ liệu cột với các chi tiết cụ thể trong xử lý trực tuyến các truy vấn phân tích. Và nó hoàn toàn là mã nguồn mở.
Và chúng ta chỉ cần biết hai điều. Bạn cần biết rằng đây là một cơ sở dữ liệu, vì vậy những gì tôi sắp nói với bạn sẽ áp dụng được cho hầu hết mọi cơ sở dữ liệu. Và thực tế là hệ quản trị cơ sở dữ liệu ClickHouse có tỷ lệ rất tốt mang lại khả năng mở rộng gần như tuyến tính. Và do đó, trạng thái của cụm là trạng thái tự nhiên đối với ClickHouse. Và chúng tôi quan tâm nhất đến việc thảo luận về cách phục vụ cụm ClickHouse trong Kubernetes.
Tại sao anh ta cần ở đó? Tại sao chúng ta không thể tự mình tiếp tục vận hành nó? Và các câu trả lời một phần là kỹ thuật và một phần là tổ chức.
- Trên thực tế, chúng ta ngày càng gặp phải tình huống như vậy khi ở các công ty lớn, hầu hết tất cả các thành phần đều đã có trong Kubernetes. Vẫn còn cơ sở dữ liệu bên ngoài.
- Và ngày càng có nhiều câu hỏi được đặt ra: "Có thể đặt nó bên trong không?". Do đó, các công ty lớn đang cố gắng tạo ra sự thống nhất tối đa trong quản lý để nhanh chóng có thể quản lý kho dữ liệu của họ.
- Và điều này đặc biệt hữu ích nếu bạn cần cơ hội tối đa để lặp lại điều tương tự ở một nơi mới, tức là tính di động tối đa.
Nó dễ hay khó như thế nào? Điều này, tất nhiên, có thể được thực hiện bằng tay. Nhưng điều này không dễ dàng như vậy, bởi vì chúng tôi thêm vào sự phức tạp của việc quản lý Kubernetes, nhưng đồng thời các chi tiết cụ thể của ClickHouse được áp đặt. Và hóa ra một tập hợp như vậy.
Và tất cả cùng nhau, điều này tạo ra một bộ công nghệ khá lớn, vốn đã trở nên khá khó quản lý, bởi vì Kubernetes đưa các vấn đề hàng ngày của nó vào hoạt động và ClickHouse đưa các vấn đề của nó vào hoạt động hàng ngày. Đặc biệt nếu chúng tôi có một số ClickHouse và chúng tôi cần liên tục làm điều gì đó với chúng.
ClickHouse với cấu hình động có một số vấn đề khá lớn tạo ra tải liên tục trên DevOps:
- Khi chúng ta muốn thay đổi một cái gì đó trong ClickHouse chẳng hạn như thêm một bản sao, một phân đoạn, thì chúng ta cần phải quản lý cấu hình.
- Sau đó, thay đổi sơ đồ dữ liệu, vì ClickHouse có một phương pháp bảo vệ cụ thể. Ở đó, cần phải bố trí sơ đồ dữ liệu, bố trí các cấu hình.
- Bạn cần thiết lập giám sát.
- Bộ sưu tập nhật ký cho các phân đoạn mới, cho các bản sao mới.
- Chăm sóc phục hồi.
- Và khởi động lại.
Đây là những công việc thường ngày mà tôi rất muốn tạo điều kiện thuận lợi để vận hành.
Bản thân Kubernetes giúp ích rất nhiều cho hoạt động, nhưng về những thứ cơ bản của hệ thống.
Kubernetes rất giỏi trong việc tạo điều kiện và tự động hóa những thứ như:
- Hồi phục.
- Khởi động lại.
- Quản lý lưu trữ.
Tốt, đó là hướng đi đúng đắn, nhưng anh ấy hoàn toàn không biết cách vận hành một cụm cơ sở dữ liệu.
Tôi muốn nhiều hơn nữa, tôi muốn toàn bộ cơ sở dữ liệu hoạt động cho chúng tôi trong Kubernetes.
Tôi muốn có thứ gì đó giống như một nút lớn màu đỏ thần kỳ mà bạn nhấn và bạn có một cụm được triển khai và duy trì trong suốt vòng đời với các công việc hàng ngày cần được giải quyết. Cụm ClickHouse trong Kubernetes.
Và chúng tôi đã cố gắng đưa ra một giải pháp giúp tạo điều kiện thuận lợi cho công việc. Đây là nhà điều hành ClickHouse cho Kubernetes từ Altinity.
Toán tử là một chương trình có nhiệm vụ chính là quản lý các chương trình khác, nghĩa là nó là một trình quản lý.
Và nó chứa các mẫu hành vi. Bạn có thể gọi nó là kiến thức hệ thống hóa về lĩnh vực chủ đề.
Và nhiệm vụ chính của anh ấy là làm cho cuộc sống của DevOps trở nên dễ dàng hơn và giảm thiểu việc quản lý vi mô để anh ấy (DevOps) đã suy nghĩ theo các thuật ngữ cấp cao, tức là để anh ấy (DevOps) không quản lý vi mô, để anh ấy không định cấu hình thủ công tất cả các chi tiết.
Và chỉ có người điều khiển là một trợ lý rô bốt vật lộn với các nhiệm vụ nhỏ và trợ giúp DevOps.
Tại sao cần có một nhà điều hành? Anh ấy xuất sắc trong hai lĩnh vực:
- Khi một chuyên gia ClickHouse không có đủ kinh nghiệm, nhưng cần phải vận hành ClickHouse, nhà điều hành sẽ hỗ trợ vận hành và cho phép bạn vận hành một cụm ClickHouse với cấu hình khá phức tạp, đồng thời không đi sâu vào chi tiết về cách thức hoạt động của nó bên trong . Bạn chỉ cần giao cho anh ta những nhiệm vụ cấp cao, và nó hoạt động.
- Và nhiệm vụ thứ hai mà nó thể hiện rõ nhất là khi cần tự động hóa một số lượng lớn các nhiệm vụ điển hình. Xóa các tác vụ vi mô khỏi sysadins.
Điều này là cần thiết nhất đối với những người mới bắt đầu hành trình của họ hoặc bởi những người cần tự động hóa nhiều.
Sự khác biệt giữa cách tiếp cận dựa trên người vận hành và các hệ thống khác là gì? Ngoài ra còn có Helm. Nó cũng giúp cài đặt ClickHouse, bạn có thể vẽ biểu đồ điều khiển, thậm chí sẽ cài đặt toàn bộ cụm ClickHouse. Sau đó, sự khác biệt giữa toán tử và từ giống nhau, chẳng hạn như Helm là gì?
Sự khác biệt cơ bản chính là Helm hoàn toàn là về quản lý gói và người vận hành còn tiến xa hơn một bước. Đây là sự hỗ trợ của toàn bộ vòng đời. Đây không chỉ là cài đặt, đây là những công việc hàng ngày bao gồm mở rộng quy mô, phân đoạn, tức là mọi thứ cần được thực hiện trong vòng đời (nếu cần, cả việc loại bỏ) - tất cả điều này đều do người vận hành quyết định. Nó cố gắng tự động hóa và phục vụ toàn bộ vòng đời của phần mềm. Đây là sự khác biệt cơ bản của nó so với các giải pháp khác được trình bày.
Đó là phần giới thiệu, hãy tiếp tục.
Làm thế nào để chúng tôi xây dựng nhà điều hành của chúng tôi? Chúng tôi đang cố gắng giải quyết vấn đề để quản lý cụm ClickHouse dưới dạng một tài nguyên duy nhất.
Ở đây chúng tôi có dữ liệu đầu vào ở phía bên trái của hình ảnh. Đây là YAML với một đặc tả cụm, được chuyển qua kubectl sang Kubernetes một cách cổ điển. Ở đó, người điều hành của chúng tôi nhặt nó lên, thực hiện phép thuật của mình. Và kết quả là, chúng ta có được một sơ đồ như vậy. Đây là triển khai ClickHouse trong Kubernetes.
Và sau đó chúng ta sẽ từ từ xem xét cách thức hoạt động của người vận hành, những tác vụ điển hình nào có thể được giải quyết. Chúng tôi sẽ chỉ xem xét các nhiệm vụ điển hình, bởi vì chúng tôi có thời gian hạn chế. Và nó sẽ không được nói về mọi thứ mà người điều hành có thể quyết định.
Hãy bắt đầu từ thực hành. Dự án của chúng tôi hoàn toàn là nguồn mở nên bạn có thể xem nó hoạt động như thế nào trên GitHub. Và bạn có thể tiếp tục từ những điều cần cân nhắc, nếu bạn chỉ muốn bắt đầu thì bạn có thể bắt đầu với Hướng dẫn bắt đầu nhanh.
Nếu bạn muốn hiểu chi tiết, thì chúng tôi cố gắng duy trì tài liệu ở dạng ít nhiều tốt.
Hãy bắt đầu với một vấn đề thực tế. Nhiệm vụ đầu tiên mà tất cả chúng ta muốn bắt đầu là chạy ví dụ đầu tiên bằng cách nào đó. Làm cách nào để khởi chạy ClickHouse với sự trợ giúp của người điều hành mà thậm chí không biết nó hoạt động như thế nào? Chúng tôi đang viết một bản tuyên ngôn, bởi vì tất cả các giao tiếp với k8s là giao tiếp thông qua bảng kê khai.
Đây là một bản tuyên ngôn phức tạp. Những gì chúng tôi đã đánh dấu màu đỏ là những gì chúng tôi cần tập trung vào. Chúng tôi yêu cầu người vận hành tạo một cụm có tên demo.
Hiện tại, đây là những ví dụ cơ bản. Lưu trữ vẫn chưa được mô tả, nhưng chúng tôi sẽ quay lại lưu trữ sau. Hiện tại, chúng ta sẽ quan sát sự phát triển của cụm trong động lực học.
Chúng tôi đã tạo ra bản tuyên ngôn này. Chúng tôi cung cấp nó cho nhà điều hành của chúng tôi. Anh ấy đã làm việc, anh ấy đã làm phép thuật.
Chúng tôi nhìn vào bảng điều khiển. Ba thành phần được quan tâm - đó là Pod, hai Service-a, StatefulSet.
Nhà điều hành đã làm việc và chúng ta có thể thấy chính xác những gì anh ấy đã tạo ra.
Ông tạo ra một cái gì đó như thế này. Chúng tôi có một StatefulSet, Pod, ConfigMap cho mỗi bản sao, ConfigMap cho toàn bộ cụm. Các dịch vụ nhất thiết là điểm vào cụm.
Dịch vụ là Dịch vụ cân bằng tải trung tâm và có thể cho từng bản sao, cho từng phân đoạn.
Đây là cụm cơ sở của chúng tôi trông giống như thế này. Anh ấy đến từ một nút duy nhất.
Hãy đi xa hơn, chúng ta sẽ làm phức tạp. Bạn cần phải phân đoạn cụm.
Nhiệm vụ của chúng tôi đang phát triển, động lực đang bắt đầu. Chúng tôi muốn thêm một phân đoạn. Chúng tôi theo dõi sự phát triển. Chúng tôi thay đổi đặc điểm kỹ thuật của chúng tôi. Chúng tôi chỉ ra rằng chúng tôi muốn hai mảnh.
Đây là cùng một tệp mà chúng tôi tự động phát triển cùng với sự phát triển của hệ thống. Không có lưu trữ, lưu trữ sẽ được thảo luận thêm, đây là một vấn đề riêng biệt.
Chúng tôi cung cấp cho toán tử YAML và xem điều gì sẽ xảy ra.
Người điều hành đã nghĩ và thực hiện các thực thể sau. Chúng tôi đã có hai Nhóm, ba Dịch vụ và đột nhiên là 2 Bộ trạng thái. Tại sao lại có 2 StatefulSets?
Nó giống như thế này trên sơ đồ - đây là trạng thái ban đầu của chúng tôi, khi chúng tôi có một nhóm.
Nó trở thành như thế này. Cho đến nay, mọi thứ đều đơn giản, nó đã được nhân đôi.
Và tại sao StatefulSet lại trở thành hai? Ở đây chúng ta cần đi lạc đề và thảo luận câu hỏi về cách quản lý Pods trong Kubernetes.
Có một đối tượng gọi là StatefulSet, cho phép bạn tạo một tập hợp các Nhóm từ một mẫu. Yếu tố chính ở đây là Mẫu. Và bạn có thể chạy nhiều Pod trong một StatefulSet theo một mẫu. Và cụm từ khóa ở đây là “một mẫu nhiều Pod”.
Và có một sự cám dỗ lớn để tạo toàn bộ cụm, đóng gói nó vào một StatefulSet. Nó sẽ hoạt động, không có vấn đề gì trong đó. Nhưng có một lưu ý. Nếu chúng tôi muốn tập hợp một cụm không đồng nhất, tức là từ một số phiên bản của ClickHouse, thì chúng tôi bắt đầu có câu hỏi. Có, StatefulSet có thể thực hiện cập nhật cuốn chiếu, nhưng ở đó bạn có thể tung ra một phiên bản mới, giải thích rằng bạn không cần thử quá nhiều nút cùng một lúc.
Nhưng nếu chúng tôi ngoại suy nhiệm vụ và nói rằng chúng tôi muốn tạo một cụm hoàn toàn không đồng nhất và không muốn thay đổi từ phiên bản cũ sang phiên bản mới bằng cách sử dụng bản cập nhật cuốn chiếu, mà chỉ muốn tạo một cụm không đồng nhất cả về các phiên bản khác nhau của ClickHouse và về mặt lưu trữ khác nhau. Ví dụ, chúng tôi muốn tạo một số bản sao trên các đĩa riêng biệt, trên các đĩa chậm, nói chung, để xây dựng hoàn toàn một cụm không đồng nhất. Và do StatefulSet tạo ra một giải pháp được tiêu chuẩn hóa từ một mẫu, nên không có cách nào để thực hiện việc này.
Sau một hồi suy nghĩ, chúng tôi quyết định làm như thế này. Chúng tôi có mỗi bản sao trong StatefulSet của riêng nó. Có một số nhược điểm đối với giải pháp này, nhưng trong thực tế, tất cả đều gói gọn toán tử. Và có rất nhiều lợi ích. Chúng ta có thể xây dựng một cụm hoàn toàn như chúng ta muốn, ví dụ, một cụm hoàn toàn không đồng nhất. Do đó, trong một cụm mà chúng tôi có hai phân đoạn với một bản sao, chúng tôi sẽ có 2 StatefulSets và 2 Pod chính xác vì chúng tôi đã chọn phương pháp này vì những lý do trên về khả năng xây dựng một cụm không đồng nhất.
Hãy quay trở lại các nhiệm vụ thực tế. Trong cụm của chúng tôi, chúng tôi cần định cấu hình người dùng, tức là bạn cần thực hiện một số cấu hình của ClickHouse trong Kubernetes. Nhà điều hành cung cấp tất cả các khả năng cho việc này.
Chúng tôi có thể viết những gì chúng tôi muốn trực tiếp trong YAML. Tất cả các tùy chọn cấu hình được ánh xạ trực tiếp từ YAML này vào cấu hình ClickHouse, sau đó được triển khai trên toàn cụm.
Bạn cũng có thể viết như thế này. Đây là một ví dụ. Mật khẩu có thể được mã hóa. Hoàn toàn tất cả các tùy chọn cấu hình ClickHouse đều được hỗ trợ. Đây chỉ là một ví dụ.
Cấu hình cụm được phân phối dưới dạng ConfigMap. Trên thực tế, quá trình cập nhật Bản đồ cấu hình không diễn ra ngay lập tức, vì vậy nếu có một cụm lớn thì quá trình đẩy cấu hình sẽ mất một khoảng thời gian. Nhưng tất cả điều này là rất thuận tiện để sử dụng.
Chúng tôi làm phức tạp nhiệm vụ. Cụm đang phát triển. Chúng tôi muốn sao chép dữ liệu. Nghĩa là, chúng tôi đã có hai phân đoạn, mỗi phân đoạn một bản sao, người dùng được định cấu hình. Chúng tôi đang phát triển và muốn nhân rộng.
Chúng ta cần gì để sao chép?
Chúng tôi cần ZooKeeper. Trong ClickHouse, bản sao được tạo bằng ZooKeeper. ZooKeeper là cần thiết để các bản sao ClickHouse khác nhau có sự đồng thuận về khối dữ liệu nào nằm trên ClickHouse nào.
ZooKeeper có thể được sử dụng bởi bất kỳ ai. Nếu doanh nghiệp có ZooKeeper bên ngoài thì có thể sử dụng nó. Nếu không, thì bạn có thể cài đặt từ kho lưu trữ của chúng tôi. Có một trình cài đặt làm cho toàn bộ điều này dễ dàng hơn.
Và sơ đồ tương tác của toàn bộ hệ thống hóa ra như thế này. Chúng tôi có Kubernetes làm nền tảng. Nó thực thi câu lệnh ClickHouse. ZooKeeper tôi hình dung ở đây. Và người vận hành tương tác với cả ClickHouse và ZooKeeper. Đó là, một tương tác thu được.
Và tất cả điều này là cần thiết để ClickHouse sao chép thành công dữ liệu sang k8s.
Bây giờ chúng ta hãy xem xét bản thân nhiệm vụ, bảng kê khai để sao chép sẽ trông như thế nào.
Chúng tôi thêm hai phần vào bảng kê khai của mình. Đầu tiên là nơi lấy ZooKeeper, có thể ở bên trong Kubernetes hoặc bên ngoài. Đây chỉ là một mô tả. Và chúng tôi đặt hàng bản sao. Những thứ kia. chúng tôi muốn hai bản sao. Tổng cộng, chúng ta nên có 4 nhóm ở đầu ra. Chúng tôi nhớ về lưu trữ, nó sẽ trở lại một chút nữa. Lưu trữ là một bài hát riêng biệt.
Nó là như thế này.
Nó trở thành như thế này. Bản sao được thêm vào. Thứ 4 không phù hợp, chúng tôi tin rằng có thể có nhiều người trong số họ. Và ZooKeeper được thêm vào bên cạnh. Các mô hình đang trở nên phức tạp hơn.
Và đã đến lúc thêm nhiệm vụ tiếp theo. Chúng tôi sẽ thêm Lưu trữ liên tục.
Đối với Lưu trữ liên tục, chúng tôi có các tùy chọn triển khai khác nhau.
Ví dụ: nếu chúng tôi đang chạy trong một nhà cung cấp đám mây, sử dụng Amazon, Google, thì việc sử dụng lưu trữ đám mây sẽ rất hấp dẫn. Nó rất thuận tiện, nó tốt.
Và có một lựa chọn thứ hai. Cái này dành cho bộ nhớ cục bộ, khi chúng ta có đĩa cục bộ trên mỗi nút. Tùy chọn này khó thực hiện hơn nhiều, nhưng đồng thời nó cũng hiệu quả hơn.
Hãy xem những gì chúng tôi có liên quan đến lưu trữ đám mây.
Có công. Nó rất dễ dàng để cấu hình. Chúng tôi chỉ cần đặt hàng từ một nhà cung cấp đám mây vui lòng cung cấp cho chúng tôi dung lượng lưu trữ như vậy và dung lượng như vậy, loại này và loại như vậy. Các lớp học được vẽ bởi các nhà cung cấp một cách độc lập.
Và có một nhược điểm. Đối với một số người, đây là một thiếu sót không đáng có. Tất nhiên, sẽ có một số lớp phủ hiệu suất. Nó rất thuận tiện để sử dụng, đáng tin cậy, nhưng có một số hạn chế tiềm ẩn về hiệu suất.
Và kể từ khi ClickHouse tập trung vào hiệu suất, thậm chí có thể nói rằng nó vắt kiệt mọi thứ có thể, vì vậy nhiều khách hàng cố gắng vắt kiệt hiệu suất tối đa.
Và để tận dụng tối đa, chúng ta cần lưu trữ cục bộ.
Kubernetes cung cấp ba phần tóm tắt để sử dụng bộ nhớ cục bộ trong Kubernetes. Cái này:
- EmptyDir
- HostPath.
- Địa phương
Xem xét chúng khác nhau như thế nào, chúng giống nhau như thế nào.
Đầu tiên, trong cả ba cách tiếp cận, chúng tôi đều có bộ lưu trữ - đây là những đĩa cục bộ nằm trên cùng một nút k8s vật lý. Nhưng họ có một số khác biệt.
Hãy bắt đầu với cách đơn giản nhất, tức là emptyDir. Nó là gì trong thực tế? Chính chúng tôi là người yêu cầu hệ thống chứa (thường là Docker) từ thông số kỹ thuật của chúng tôi cung cấp cho chúng tôi quyền truy cập vào một thư mục trên đĩa cục bộ.
Trong thực tế, docker tạo một thư mục tạm thời ở đâu đó trong các đường dẫn riêng của nó, gọi nó là một hàm băm dài. Và cung cấp một giao diện để truy cập nó.
Làm thế nào nó sẽ thực hiện về hiệu suất? Điều này sẽ chạy ở tốc độ của đĩa cục bộ, tức là đây là toàn quyền truy cập vào vít của bạn.
Nhưng trường hợp này có nhược điểm của nó. Kiên trì trong trường hợp này là khá đáng ngờ. Ở lần di chuyển đầu tiên của docker với các container, Persistent bị mất. Nếu Kubernetes muốn di chuyển Pod này sang đĩa khác vì lý do nào đó, thì dữ liệu sẽ bị mất.
Cách tiếp cận này tốt cho các bài kiểm tra, vì nó đã hiển thị tốc độ bình thường, nhưng tùy chọn này không phù hợp với những thứ nghiêm trọng.
Do đó, có một cách tiếp cận thứ hai. Đây là hostPath. Nếu bạn nhìn vào slide trước và slide này, bạn chỉ có thể thấy một sự khác biệt. Thư mục của chúng tôi để docker trực tiếp đến nút Kubernetes. Ở đây nhanh hơn một chút. Chúng tôi trực tiếp viết đường dẫn trên hệ thống tệp cục bộ nơi chúng tôi muốn lưu trữ dữ liệu của mình.
Phương pháp này có ưu điểm. Đây đã là một liên tục thực sự và một cổ điển. Trên đĩa của chúng tôi, dữ liệu sẽ được ghi vào một số địa chỉ.
Cũng có những nhược điểm. Đây chính là sự phức tạp trong quản lý. Kubernetes của chúng tôi có thể muốn di chuyển Pod sang một nút vật lý khác. Đây là lúc DevOps phát huy tác dụng. Nó phải giải thích chính xác cho toàn bộ hệ thống rằng bạn chỉ có thể di chuyển các nhóm này đến các nút mà trên đó bạn có thứ gì đó được gắn dọc theo các đường dẫn này và không quá một nút mỗi lần. Nó đủ khó khăn.
Đặc biệt cho những mục đích này, chúng tôi đã tạo các mẫu trong toán tử của mình để ẩn tất cả sự phức tạp này. Và bạn chỉ có thể nói: "Tôi muốn có một phiên bản ClickHouse cho mỗi nút vật lý và dọc theo đường dẫn như vậy."
Nhưng nhu cầu này không chỉ dành cho chúng tôi, vì vậy bản thân các quý ông từ Kubernetes cũng hiểu rằng mọi người muốn có quyền truy cập vào đĩa vật lý, vì vậy họ cung cấp cấp độ thứ ba.
Nó được gọi là địa phương. Thực tế không có sự khác biệt so với slide trước. Chỉ trước đó, cần phải thực hiện thủ công rằng chúng tôi không thể chuyển các nhóm này từ nút này sang nút khác, bởi vì chúng phải được gắn dọc theo đường dẫn như vậy đến đĩa vật lý cục bộ và giờ đây, tất cả kiến thức này được gói gọn trong chính Kubernetes. Và hóa ra việc cấu hình dễ dàng hơn nhiều.
Hãy quay trở lại nhiệm vụ thực tế của chúng ta. Hãy quay lại mẫu YAML. Ở đây chúng tôi có một kho lưu trữ thực sự. Chúng tôi trở lại vấn đề này. Chúng tôi đặt mẫu VolumeClaim cổ điển như trong k8s. Và chúng tôi mô tả loại lưu trữ mà chúng tôi muốn.
Sau đó, k8s sẽ yêu cầu lưu trữ. Phân bổ nó cho chúng tôi trong StatefulSet. Và cuối cùng, nó sẽ nằm trong tay ClickHouse.
Chúng tôi đã có một kế hoạch như vậy. Bộ lưu trữ liên tục của chúng tôi có màu đỏ, dường như gợi ý rằng nó nên được thực hiện.
Và nó chuyển sang màu xanh lá cây. Giờ đây, lược đồ cụm ClickHouse trên k8s đã hoàn tất. Chúng tôi có các phân đoạn, bản sao, ZooKeeper, chúng tôi có Persistent thực, được triển khai theo cách này hay cách khác. Đề án đã có đầy đủ chức năng.
Chúng tôi tiếp tục sống tiếp. Cụm của chúng tôi đang phát triển. Và Aleksey đang thử và phát hành phiên bản mới của ClickHouse.
Một nhiệm vụ thực tế phát sinh - kiểm tra phiên bản ClickHouse mới trên cụm của chúng tôi. Và, tất nhiên, tôi không muốn tung ra tất cả, tôi muốn đặt một phiên bản mới ở một góc xa trong một bản sao, hoặc có thể không phải một phiên bản mới mà là hai phiên bản cùng một lúc, vì chúng ra mắt thường xuyên.
Chúng ta có thể nói gì về điều này?
Ở đây chúng ta chỉ có một cơ hội như vậy. Đây là những mẫu nhóm. Bạn có thể vẽ, toán tử của chúng tôi hoàn toàn cho phép bạn xây dựng một cụm không đồng nhất. Những thứ kia. định cấu hình, bắt đầu từ tất cả các bản sao trong một nhóm, kết thúc bằng từng bản sao cá nhân, phiên bản nào chúng tôi muốn ClickHouse, phiên bản nào chúng tôi muốn lưu trữ. Chúng tôi hoàn toàn có thể định cấu hình cụm theo cấu hình như chúng tôi cần.
Hãy đi sâu hơn vào bên trong một chút. Trước đó, chúng tôi đã nói về cách thức hoạt động của nhà điều hành ClickHouse liên quan đến các chi tiết cụ thể của ClickHouse.
Bây giờ tôi muốn nói một vài lời về cách hoạt động của bất kỳ nhà điều hành nào nói chung, cũng như cách nó tương tác với K8.
Hãy xem xét tương tác với K8 để bắt đầu. Điều gì xảy ra khi chúng ta áp dụng kubectl? Thông qua API, các đối tượng của chúng tôi xuất hiện trong etcd.
Ví dụ: các đối tượng Kubernetes cơ bản: pod, StatefulSet, dịch vụ, v.v. thông qua danh sách.
Tuy nhiên, không có gì vật lý đang xảy ra được nêu ra. Những đối tượng này phải được cụ thể hóa trong một cụm.
Đây là nơi bộ điều khiển đi vào. Bộ điều khiển là một thành phần đặc biệt của k8s có thể hiện thực hóa những mô tả này. Anh ấy biết làm thế nào và phải làm gì về mặt thể chất. Anh ấy biết cách chạy các thùng chứa, những gì cần được cấu hình ở đó để máy chủ hoạt động.
Và nó cụ thể hóa các đối tượng của chúng tôi trong K8s.
Nhưng chúng tôi muốn hoạt động không chỉ với các nhóm, StatefulSets, chúng tôi muốn tạo một ClickHouseInstallation, tức là một đối tượng thuộc loại ClickHouse, để hoạt động với toàn bộ nó. Cho đến nay, không có khả năng như vậy.
Nhưng K8s có cái hay khác. Chúng tôi muốn chúng tôi có một thực thể phức tạp như vậy ở đâu đó, trong đó cụm của chúng tôi sẽ được tập hợp từ các nhóm và StatefulSet.
Và những gì nên được thực hiện cho điều này? Đầu tiên, Custom Resource Definition xuất hiện. Nó là gì? Đây là mô tả cho K8s rằng bạn sẽ có một loại dữ liệu khác mà chúng tôi muốn thêm vào nhóm, StatefulSet, một tài nguyên tùy chỉnh sẽ phức tạp bên trong. Đây là một mô tả của cấu trúc dữ liệu.
Chúng tôi cũng gửi nó qua kubectl apply. Kubernetes vui vẻ nhận nó.
Và bây giờ trong bộ lưu trữ của chúng tôi, đối tượng trong etcd có cơ hội ghi một tài nguyên tùy chỉnh có tên là ClickHouseInstallation.
Nhưng bây giờ, không có gì khác sẽ xảy ra. Đó là, nếu bây giờ chúng ta tạo một tệp YAML mà chúng ta đã xem xét với mô tả về phân đoạn, bản sao và nói “áp dụng kubectl”, thì Kubernetes sẽ chấp nhận nó, đưa nó vào etcd và nói: “Tuyệt, nhưng tôi không biết Làm gì với nó đây. Tôi không biết cách duy trì ClickHouseInstallation."
Theo đó, chúng tôi cần ai đó giúp Kubernetes phục vụ loại dữ liệu mới. Ở bên trái, chúng ta có bộ điều khiển Kubernetes gốc hoạt động với các loại dữ liệu chứng khoán. Và ở bên phải, chúng ta nên có một bộ điều khiển tùy chỉnh có thể hoạt động với các loại dữ liệu tùy chỉnh.
Và theo một cách khác, nó được gọi là toán tử. Tôi đặc biệt lấy nó ở đây cho Kubernetes, vì nó cũng có thể được thực thi bên ngoài K8. Tất nhiên, thông thường nhất, tất cả các câu lệnh đều được thực thi trong Kubernetes, nhưng không có gì ngăn cản nó đứng bên ngoài, vì vậy ở đây nó được đưa ra một cách đặc biệt.
Và đến lượt nó, bộ điều khiển tùy chỉnh, còn được gọi là toán tử, tương tác với Kubernetes thông qua API. Anh ấy đã biết cách tương tác với API. Và anh ấy đã biết cách hiện thực hóa một sơ đồ phức tạp mà chúng tôi muốn tạo từ một tài nguyên tùy chỉnh. Đây chính xác là những gì các nhà điều hành làm.
Người vận hành làm việc như thế nào? Chúng ta hãy nhìn vào phía bên phải để xem anh ấy làm điều đó như thế nào. Chúng tôi sẽ tìm hiểu cách nhà điều hành hiện thực hóa tất cả những điều này và cách tương tác tiếp theo với K8 diễn ra.
Người điều hành là chương trình. Cô ấy là người định hướng sự kiện. Nhà điều hành đăng ký các sự kiện bằng API Kubernetes. API Kubernetes có các điểm đầu vào nơi bạn có thể đăng ký các sự kiện. Và nếu có gì đó thay đổi trong K8 thì Kubernetes sẽ gửi sự kiện cho mọi người, tức là. người đã đăng ký điểm API này sẽ nhận được thông báo.
Toán tử đăng ký các sự kiện và phải thực hiện một số loại phản ứng. Nhiệm vụ của nó là phản ứng với các sự kiện mới nổi.
Sự kiện được tạo ra bởi một số cập nhật. Tệp YAML của chúng tôi đến với mô tả về ClickHouseInstallation. Anh ấy đã truy cập etcd qua ứng dụng kubectl. Một sự kiện đã diễn ra ở đó, kết quả là sự kiện này đã đến với nhà điều hành ClickHouse. Người điều hành đã nhận được mô tả này. Và anh phải làm gì đó. Nếu một bản cập nhật đến với đối tượng ClickHouseInstallation thì bạn cần cập nhật cụm. Và nhiệm vụ của người vận hành là cập nhật cụm.
Anh ta đang làm gì vậy? Đầu tiên, chúng ta cần lập một kế hoạch hành động cho những gì chúng ta sẽ làm với bản cập nhật này. Cập nhật có thể rất nhỏ, tức là. nhỏ trong thực thi YAML, nhưng có thể dẫn đến những thay đổi rất lớn trên cụm. Do đó, người điều hành tạo ra một kế hoạch, và sau đó anh ta tuân theo kế hoạch đó.
Theo kế hoạch này, anh ta bắt đầu đun sôi cấu trúc này bên trong để hiện thực hóa các nhóm, dịch vụ, tức là. để làm nhiệm vụ chính của nó là gì. Nó giống như việc xây dựng một cụm ClickHouse trong Kubernetes.
Bây giờ chúng ta hãy chạm vào một điều thú vị như vậy. Đây là sự phân chia trách nhiệm giữa Kubernetes và nhà điều hành, tức là Kubernetes làm gì, người vận hành làm gì và cách chúng tương tác với nhau.
Kubernetes chịu trách nhiệm về những thứ hệ thống, tức là cho một tập đối tượng cơ bản có thể được hiểu là phạm vi hệ thống. Kubernetes biết cách khởi động nhóm, cách khởi động lại vùng chứa, cách thực hiện gắn ổ đĩa, cách làm việc với ConfigMap, tức là bất cứ điều gì có thể được gọi là một hệ thống.
Các nhà điều hành hoạt động trong lĩnh vực chủ đề. Mỗi toán tử được tạo cho lĩnh vực chủ đề của nó. Chúng tôi làm cho ClickHouse.
Và người vận hành tương tác chính xác về lĩnh vực chủ đề, chẳng hạn như thêm bản sao, tạo sơ đồ, thiết lập giám sát. Có một sự phân chia như vậy.
Chúng ta hãy xem một ví dụ thực tế về cách phân tách mối quan tâm này xảy ra khi chúng ta thực hiện hành động thêm bản sao.
Nhiệm vụ đến với người vận hành - thêm một bản sao. Người điều hành đang làm gì? Người vận hành sẽ tính toán rằng cần phải tạo một StatefulSet mới, trong đó cần mô tả các mẫu như vậy, yêu cầu khối lượng.
Anh ấy đã chuẩn bị tất cả và chuyển nó cho K8. Anh ấy nói rằng anh ấy cần ConfigMap, StatefulSet, Volume. Kubernetes đang hoạt động. Anh ta hiện thực hóa các đơn vị cơ bản mà anh ta vận hành.
Và sau đó nhà điều hành ClickHouse lại xuất hiện. Anh ấy đã có một nhóm vật lý mà bạn có thể làm điều gì đó trên đó. Và nhà điều hành ClickHouse lại hoạt động về lĩnh vực chủ đề. Những thứ kia. Cụ thể, ClickHouse, để bao gồm một bản sao trong một cụm, trước tiên, bạn phải định cấu hình sơ đồ dữ liệu tồn tại trong cụm này. Và, thứ hai, nhận xét này phải được đưa vào giám sát để có thể truy tìm rõ ràng. Nhà điều hành đã thiết lập nó.
Và chỉ sau khi chính ClickHouse đó mới phát huy tác dụng, tức là một thực thể cấp cao hơn. Nó đã là một cơ sở dữ liệu. Nó có phiên bản riêng, bản sao được định cấu hình tiếp theo, sẵn sàng tham gia cụm.
Hóa ra chuỗi thực thi và phân chia trách nhiệm khi thêm một bản sao là đủ dài.
Chúng tôi tiếp tục các nhiệm vụ thực tế của chúng tôi. Nếu cụm đã tồn tại thì bạn có thể di chuyển cấu hình.
Chúng tôi đã tạo ra nó để có thể chuyển qua xml hiện có mà ClickHouse hiểu được.
Bạn có thể tinh chỉnh ClickHouse. Triển khai chỉ được khoanh vùng là những gì tôi đã nói khi giải thích về hostPath, bộ nhớ cục bộ. Đây là cách triển khai được khoanh vùng một cách chính xác.
Nhiệm vụ thực tế tiếp theo là giám sát.
Nếu cụm của chúng tôi thay đổi, thì chúng tôi cần định cấu hình giám sát.
Chúng ta hãy nhìn vào sơ đồ. Chúng tôi đã xem xét các mũi tên màu xanh lá cây ở đây. Bây giờ hãy nhìn vào các mũi tên màu đỏ. Đây là cách chúng tôi muốn theo dõi cụm của chúng tôi. Cách các chỉ số từ cụm ClickHouse đi vào Prometheus, rồi đến Grafana.
Vấn đề với giám sát là gì? Tại sao điều này được trình bày như một số loại thành tích? Khó khăn nằm ở động lực học. Khi chúng tôi có một cụm và nó là tĩnh, thì bạn có thể thiết lập giám sát một lần và không bận tâm nữa.
Nhưng nếu chúng ta có nhiều cụm, hoặc một cái gì đó liên tục thay đổi, thì quá trình này là động. Và liên tục cấu hình lại giám sát là một sự lãng phí tài nguyên và thời gian; thậm chí chỉ là lười biếng. Điều này cần phải được tự động hóa. Khó khăn là ở tính năng động của quá trình. Và người điều hành tự động hóa việc này rất tốt.
Cụm của chúng tôi đã phát triển như thế nào? Lúc đầu anh ấy như thế này.
Sau đó, anh ấy như thế này.
Cuối cùng, anh ấy đã trở thành như thế này.
Và giám sát được thực hiện tự động bởi các nhà điều hành. Điểm vào duy nhất.
Và chúng tôi chỉ nhìn vào lối ra trong bảng điều khiển Grafana, cuộc sống của cụm của chúng tôi sôi sục bên trong như thế nào.
Nhân tiện, bảng điều khiển Grafana cũng được phân phối với nhà điều hành của chúng tôi ngay trong mã nguồn. Bạn có thể kết nối và sử dụng. Ảnh chụp màn hình này đã được trao cho tôi bởi DevOps của chúng tôi.
Chúng ta muốn đi đâu tiếp theo? Cái này:
- Phát triển thử nghiệm tự động hóa. Nhiệm vụ chính là kiểm tra tự động các phiên bản mới.
- Chúng tôi cũng thực sự muốn tự động hóa việc tích hợp với ZooKeeper. Và có kế hoạch tích hợp với nhà điều hành ZooKeeper. Những thứ kia. một toán tử đã được viết cho ZooKeeper và thật hợp lý khi hai toán tử bắt đầu tích hợp để xây dựng một giải pháp thuận tiện hơn.
- Chúng tôi muốn thực hiện kiểm tra cuộc sống phức tạp hơn.
- Tôi đã đánh dấu bằng màu xanh lá cây rằng chúng tôi đang triển khai kế thừa Mẫu - XONG, tức là với bản phát hành tiếp theo của toán tử, chúng tôi sẽ có kế thừa mẫu. Đây là một công cụ mạnh mẽ cho phép bạn xây dựng các cấu hình phức tạp từ các mảnh ghép.
- Và chúng tôi muốn tự động hóa các tác vụ phức tạp. Cái chính là Re-sharding.
Hãy làm một số kết quả trung gian.
Kết quả là chúng ta nhận được gì? Và nó có đáng hay không? Tôi thậm chí có cần cố kéo cơ sở dữ liệu vào Kubernetes và áp dụng toán tử nói chung và toán tử Alitnity nói riêng không.
Ở đầu ra, chúng tôi nhận được:
- Đơn giản hóa đáng kể và tự động hóa cấu hình, triển khai và bảo trì.
- Giám sát tích hợp ngay lập tức.
- Và các mẫu được mã hóa sẵn sàng để sử dụng cho các tình huống phức tạp. Đã có loại hành động để thêm một bản sao không cần phải thực hiện bằng tay. Điều này được thực hiện bởi các nhà điều hành.
Chỉ còn lại câu hỏi cuối cùng. Chúng tôi đã có một cơ sở dữ liệu trong Kubernetes, ảo hóa. Còn về hiệu suất của một giải pháp như vậy, đặc biệt là khi ClickHouse được tối ưu hóa cho hiệu suất thì sao?
Câu trả lời là mọi thứ đều ổn! Tôi sẽ không mô tả chi tiết, đây là chủ đề của một báo cáo riêng.
Nhưng có một dự án như TSBS. Nhiệm vụ chính của nó là gì? Đây là một thử nghiệm hiệu suất cơ sở dữ liệu. Đây là một nỗ lực để so sánh ấm với ấm, mềm với mềm.
Làm thế nào để anh ấy làm việc? Một bộ dữ liệu được tạo ra. Sau đó, tập dữ liệu này trên cùng một tập kiểm tra được chạy trên các cơ sở dữ liệu khác nhau. Và mỗi cơ sở dữ liệu giải quyết một vấn đề theo cách nó có thể. Và sau đó bạn có thể so sánh kết quả.
Nó đã hỗ trợ rất nhiều cơ sở dữ liệu. Tôi đã xác định được ba cái chính. Cái này:
- thang thời giandb.
- FluxDB.
- clickhouse.
Một so sánh cũng được thực hiện với một giải pháp tương tự khác. So sánh với RedShift. Việc so sánh được thực hiện trên Amazon. ClickHouse cũng đi trước mọi người trong vấn đề này.
Những kết luận nào có thể được rút ra từ những gì tôi đã nói?
- DB trong Kubernetes là có thể. Có thể, bạn có thể làm bất cứ điều gì, nhưng nhìn chung có vẻ như bạn có thể làm được. ClickHouse trong Kubernetes chắc chắn có thể thực hiện được với sự trợ giúp của nhà điều hành của chúng tôi.
- Người vận hành giúp tự động hóa các quy trình và thực sự đơn giản hóa cuộc sống.
- Hiệu suất là bình thường.
- Và đối với chúng tôi, dường như nó có thể và nên được sử dụng.
Nguồn mở - tham gia với chúng tôi!
Như tôi đã nói, nhà điều hành là một sản phẩm nguồn mở hoàn toàn, vì vậy sẽ rất tốt nếu số lượng người sử dụng nó là tối đa. Tham gia ngay! Chúng tôi đang chờ đợi tất cả các bạn!
Cảm ơn tất cả các bạn!
câu hỏi
Cảm ơn vì đã báo cáo! Tên tôi là Anton. Tôi đến từ SEMrush. Tôi tự hỏi có chuyện gì xảy ra với việc ghi nhật ký. Chúng tôi nghe về giám sát, nhưng không biết gì về ghi nhật ký, nếu chúng tôi nói về toàn bộ cụm. Ví dụ: chúng tôi có một cụm trên phần cứng. Và chúng tôi sử dụng ghi nhật ký tập trung, chúng tôi thu thập nó thành một đống chung bằng các phương tiện tiêu chuẩn. Và rồi từ đó, chúng tôi nhận được dữ liệu thú vị đối với chúng tôi.
Câu hỏi hay, tức là đăng nhập vào danh sách việc cần làm. Nhà điều hành của chúng tôi chưa tự động hóa việc này. Nó vẫn đang phát triển, dự án vẫn còn khá trẻ. Chúng tôi hiểu sự cần thiết phải đăng nhập. Đây cũng là một chủ đề rất quan trọng. Và nó có lẽ không kém phần quan trọng hơn giám sát. Nhưng đầu tiên trong danh sách thực hiện là giám sát. Sẽ có đăng nhập. Đương nhiên, chúng tôi đang cố gắng tự động hóa tất cả các khía cạnh trong vòng đời của cụm. Do đó, câu trả lời là tại thời điểm này, rất tiếc, nhà điều hành không biết cách thực hiện việc này, nhưng nó nằm trong kế hoạch, chúng tôi sẽ thực hiện. Bạn nào muốn tham gia thì pull request nhé.
Xin chào! Cảm ơn bạn đã báo cáo! Tôi có một câu hỏi tiêu chuẩn liên quan đến Tập liên tục. Khi chúng ta tạo một cấu hình với toán tử này, làm thế nào để toán tử xác định trên nút nào chúng ta có một số đĩa hoặc thư mục? Trước tiên, chúng tôi phải giải thích với anh ấy rằng, vui lòng đặt ClickHouse của chúng tôi chính xác trên các nút có đĩa này?
Theo như tôi hiểu, câu hỏi này là phần tiếp theo của bộ nhớ cục bộ, đặc biệt là phần hostPath của nó. Nó giống như giải thích cho toàn bộ hệ thống rằng nhóm cần phải được khởi chạy chính xác trên một nút như vậy, trên đó chúng ta có một đĩa được kết nối vật lý, được gắn trên một đường dẫn như vậy. Đây là toàn bộ phần mà tôi đã chạm vào rất hời hợt, bởi vì câu trả lời ở đó khá lớn.
Tóm lại, nó trông như thế này. Tất nhiên, chúng ta cần cung cấp các tập này. Hiện tại, không có cung cấp động trong bộ lưu trữ cục bộ, vì vậy DevOps phải tự cắt đĩa, đây là các ổ đĩa này. Và họ phải giải thích việc cung cấp Kubernetes, rằng bạn sẽ có các khối Liên tục của lớp này và lớp kia, được đặt trên các nút như vậy và như vậy. Sau đó, cần phải giải thích cho Kubernetes rằng các nhóm yêu cầu lớp lưu trữ cục bộ như vậy cần được lên lịch theo nhãn chỉ dành cho các nút như vậy và như vậy. Đối với những mục đích này, người vận hành có khả năng gán một số loại nhãn và một nhãn cho mỗi phiên bản máy chủ. Và hóa ra, các nhóm sẽ được Kubernetes định tuyến để chỉ chạy trên các nút đáp ứng các yêu cầu, nhãn, nói một cách đơn giản. Quản trị viên gán nhãn, cung cấp đĩa bằng tay. Và sau đó nó mở rộng quy mô.
Và chỉ có tùy chọn thứ ba cục bộ giúp làm cho nó dễ dàng hơn một chút. Như tôi đã nhấn mạnh, đây là một công việc điều chỉnh tỉ mỉ, cuối cùng sẽ giúp đạt được hiệu suất tối đa.
Tôi có một câu hỏi thứ hai liên quan đến điều này. Kubernetes được hình thành theo cách mà chúng tôi không quan tâm liệu chúng tôi có mất nút hay không. Chúng ta nên làm gì trong trường hợp này nếu chúng ta mất nút nơi chúng ta có phân đoạn?
Đúng vậy, Kubernetes ban đầu được định vị rằng mối quan hệ của chúng ta với các nhóm giống như gia súc, nhưng ở đây mỗi đĩa trở thành một thứ gì đó giống như thú cưng. Có một vấn đề như vậy mà chúng ta không thể ném chúng đi. Và sự phát triển của Kubernetes đang đi theo hướng không thể coi nó hoàn toàn về mặt triết học, như một nguồn tài nguyên bị loại bỏ hoàn toàn.
Bây giờ là một câu hỏi thực tế. Phải làm gì nếu bạn bị mất nút trên đĩa? Ở đây vấn đề được giải quyết ở cấp độ cao hơn. Trong trường hợp của ClickHouse, chúng tôi có các bản sao hoạt động ở cấp độ cao hơn, tức là. ở cấp độ ClickHouse.
bố trí là gì? DevOps chịu trách nhiệm đảm bảo dữ liệu không bị mất. Nó phải thiết lập sao chép đúng cách và phải đảm bảo rằng sao chép đang chạy. Trong bản sao ở cấp độ ClickHouse, dữ liệu phải được sao chép. Đây không phải là nhiệm vụ mà người điều hành giải quyết. Và không phải nhiệm vụ mà Kubernetes tự giải quyết. Đây là ở cấp độ ClickHouse.
Phải làm gì nếu nút sắt của bạn bị rơi ra? Và nó chỉ ra rằng cần phải đặt cái thứ hai, di chuyển đĩa đúng cách trên đó, dán nhãn. Và sau đó, nó sẽ đáp ứng các yêu cầu mà Kubernetes trên nó có thể chạy một phiên bản nhóm. Kubernetes sẽ khởi chạy nó. Số lượng nhóm của bạn không đủ so với nhóm được chỉ định. Nó sẽ đi qua chu kỳ mà tôi đã chỉ ra. Và ở cấp độ cao nhất, ClickHouse sẽ hiểu rằng chúng tôi đã nhập một bản sao, nó vẫn trống và chúng tôi cần bắt đầu chuyển dữ liệu sang nó. Những thứ kia. quá trình này vẫn còn kém tự động.
Cảm ơn bạn đã báo cáo! Khi tất cả những điều khó chịu xảy ra, người vận hành gặp sự cố và khởi động lại, và ngay lúc đó các sự kiện xảy ra, bạn có xử lý việc này bằng cách nào đó không?
Điều gì xảy ra nếu người vận hành gặp sự cố và khởi động lại, phải không?
Đúng. Và tại thời điểm đó các sự kiện đã đến.
Nhiệm vụ phải làm trong trường hợp này được phân chia một phần giữa người vận hành và Kubernetes. Kubernetes có khả năng phát lại một sự kiện đã xảy ra. Anh ấy phát lại. Và nhiệm vụ của người điều hành là đảm bảo rằng khi nhật ký sự kiện được phát lại trên đó, những sự kiện này là bình thường. Và để việc tái diễn của cùng một sự kiện không phá vỡ hệ thống của chúng tôi đối với chúng tôi. Và nhà điều hành của chúng tôi đối phó với nhiệm vụ này.
Xin chào! Cảm ơn bạn đã báo cáo! Dmitry Zavialov, công ty Smedov. Có kế hoạch thêm các tùy chọn tùy chỉnh với haproxy cho người vận hành không? Một số công cụ cân bằng khác cũng thú vị bên cạnh công cụ tiêu chuẩn, để nó thông minh và hiểu rằng ClickHouse là có thật ở đó.
Bạn đang nói về Ingress?
Có, thay Ingress bằng haproxy. Trong haproxy, bạn có thể chỉ định cấu trúc liên kết cụm nơi nó có các bản sao.
Cho đến nay, chúng tôi đã không nghĩ về nó. Nếu bạn cần nó và có thể giải thích lý do tại sao nó cần thiết, thì bạn sẽ có thể thực hiện nó, đặc biệt nếu bạn muốn tham gia. Chúng tôi rất sẵn lòng xem xét lựa chọn này. Câu trả lời ngắn gọn là không, chúng tôi hiện không có chức năng như vậy. Cảm ơn vì mẹo, chúng tôi sẽ xem xét điều này. Và nếu bạn cũng giải thích trường hợp sử dụng và lý do tại sao nó lại cần thiết trong thực tế, chẳng hạn như tạo sự cố trên GitHub, thì sẽ rất tuyệt.
Đã sẵn sàng.
Khỏe. Chúng tôi đang mở cho bất kỳ đề nghị. Và haproxy được đưa vào danh sách việc cần làm. Danh sách việc cần làm đang tăng lên, chưa bị thu hẹp. Nhưng điều này là tốt, nó có nghĩa là sản phẩm đang có nhu cầu.
Nguồn: www.habr.com