Này Habr!
Chúng tôi đại diện cho nhóm nền tảng Exness. Trước đây, các đồng nghiệp của chúng tôi đã viết một bài về . Hôm nay, chúng tôi muốn chia sẻ kinh nghiệm di chuyển dịch vụ sang Kubernetes.
Để bắt đầu, chúng tôi cung cấp cho bạn một số con số để bạn hiểu rõ hơn về những gì sẽ được thảo luận:
- Bộ phận phát triển của chúng tôi bao gồm hơn 100 người, trong đó có hơn 10 nhóm khác nhau với các quy trình QA, DevOps và Scrum tự cung cấp. Ngăn xếp phát triển - Python, PHP, C++, Java và Golang.
- Kích thước của môi trường thử nghiệm và sản xuất là khoảng 2000 container mỗi môi trường. Họ đang chạy Rancher v1.6 trên nền tảng ảo hóa của riêng họ và trong VMware.
Động lực
Như người ta vẫn nói, không có gì tồn tại mãi mãi và Rancher đã thông báo ngừng hỗ trợ phiên bản 1.6 cách đây khá lâu. Đúng vậy, trong hơn ba năm, chúng tôi đã học được cách chuẩn bị và giải quyết các vấn đề phát sinh, nhưng chúng tôi ngày càng thường xuyên phải đối mặt với những vấn đề không bao giờ có thể khắc phục được. Rancher 1.6 cũng có một hệ thống hợp nhất để cấp quyền, nơi bạn có thể làm hầu hết mọi thứ hoặc không làm gì cả.
Mặc dù ảo hóa độc quyền cung cấp khả năng kiểm soát tốt hơn đối với việc lưu trữ dữ liệu và tính bảo mật của nó, nhưng nó gây ra chi phí vận hành khó chấp nhận do sự tăng trưởng không ngừng của công ty, số lượng dự án và yêu cầu đối với chúng.
Chúng tôi muốn tuân theo các tiêu chuẩn IaC và nếu cần, có được công suất một cách nhanh chóng, ở bất kỳ vị trí địa lý nào và không có sự khóa của nhà cung cấp, đồng thời có thể nhanh chóng từ bỏ nó.
Các bước đầu tiên
Trước hết, chúng tôi muốn dựa vào các công nghệ và giải pháp hiện đại cho phép các nhóm có chu kỳ phát triển nhanh hơn và giảm thiểu chi phí vận hành khi tương tác với nền tảng cung cấp sức mạnh.
Tất nhiên, điều đầu tiên chúng tôi nghĩ đến là Kubernetes, nhưng chúng tôi không hào hứng và đã nghiên cứu một chút để xem liệu đó có phải là lựa chọn đúng đắn hay không. Chúng tôi chỉ đánh giá các giải pháp nguồn mở và trong một cuộc chiến không công bằng, Kubernetes đã chiến thắng vô điều kiện.
Tiếp theo là vấn đề chọn công cụ để tạo cụm. Chúng tôi đã so sánh các giải pháp phổ biến nhất: kops, kubespray, kubeadm.
Để bắt đầu, đối với chúng tôi, kubeadm dường như là một con đường quá phức tạp, giống như một nhà phát minh ra “xe đạp” và kops không có đủ tính linh hoạt.
Và người chiến thắng là:
Chúng tôi bắt đầu thử nghiệm ảo hóa và AWS của riêng mình, cố gắng tạo lại thứ gì đó gần giống với mẫu quản lý tài nguyên trước đây của chúng tôi, nơi mọi người đều chia sẻ cùng một “cụm”. Và bây giờ chúng tôi có cụm 10 máy ảo nhỏ đầu tiên, một vài trong số đó được đặt tại AWS. Chúng tôi bắt đầu cố gắng di chuyển các đội đến đó, mọi thứ dường như đều “tốt” và câu chuyện có thể kết thúc, nhưng...
Vấn đề đầu tiên
Ansible là những gì kubespray được xây dựng trên đó, nó không phải là một công cụ cho phép bạn theo dõi IaC: khi vận hành/ngắt kết nối các nút, đã xảy ra sự cố liên tục và cần phải có một số loại can thiệp và khi sử dụng các hệ điều hành khác nhau, playbook sẽ hoạt động khác nhau. . Khi số lượng nhóm và nút trong cụm tăng lên, chúng tôi bắt đầu nhận thấy rằng playbook ngày càng mất nhiều thời gian hơn để hoàn thành và kết quả là kỷ lục của chúng tôi là 3,5 giờ, còn bạn thì sao? 🙂
Và có vẻ như kubespray chỉ là Ansible, và mọi thứ thoạt nhìn đều rõ ràng, nhưng:
Khi bắt đầu hành trình, nhiệm vụ chỉ là triển khai các năng lực trong AWS và trên ảo hóa, nhưng sau đó, như thường lệ, các yêu cầu đã thay đổi.
Do đó, rõ ràng là mô hình kết hợp các tài nguyên vào một hệ thống điều phối cũ của chúng tôi là không phù hợp - trong trường hợp các cụm ở rất xa và được quản lý bởi các nhà cung cấp khác nhau.
Hơn nữa. Khi tất cả các nhóm làm việc trong cùng một cụm, các dịch vụ khác nhau có NodeSelector được cài đặt không chính xác có thể di chuyển đến máy chủ “nước ngoài” của một nhóm khác và sử dụng tài nguyên ở đó, và nếu vết bẩn được thiết lập, sẽ liên tục có yêu cầu rằng dịch vụ này hoặc dịch vụ khác không hoạt động, không được phân phối chính xác do yếu tố con người. Một vấn đề khác là tính toán chi phí, đặc biệt là xem xét các vấn đề trong việc phân phối dịch vụ giữa các nút.
Một câu chuyện riêng là việc cấp quyền cho nhân viên: mỗi đội đều muốn đứng đầu cụm và quản lý hoàn toàn cụm đó, điều này có thể gây ra sự sụp đổ hoàn toàn vì các đội về cơ bản là độc lập với nhau.
Phải làm gì?
Cân nhắc những điều trên và mong muốn các đội độc lập hơn, chúng tôi đưa ra kết luận đơn giản: một đội - một cụm.
Vì vậy, chúng tôi có cái thứ hai:
Và sau đó là cụm thứ ba:
Sau đó, chúng tôi bắt đầu suy nghĩ: giả sử trong một năm, nhóm của chúng tôi sẽ có nhiều hơn một cụm? Ví dụ: ở các khu vực địa lý khác nhau hoặc dưới sự kiểm soát của các nhà cung cấp khác nhau? Và một số người trong số họ sẽ muốn có thể nhanh chóng triển khai một cụm tạm thời cho một số thử nghiệm.
Kubernetes đầy đủ sẽ đến! Hóa ra đây là một loại MultiKubernetes.
Đồng thời, tất cả chúng ta sẽ cần bằng cách nào đó duy trì tất cả các cụm này, có thể dễ dàng quản lý quyền truy cập vào chúng, cũng như tạo các cụm mới và ngừng hoạt động các cụm cũ mà không cần can thiệp thủ công.
Đã một thời gian trôi qua kể từ khi chúng tôi bắt đầu hành trình trong thế giới Kubernetes và chúng tôi quyết định kiểm tra lại các giải pháp hiện có. Hóa ra nó đã có trên thị trường - Rancher 2.2.
Ở giai đoạn nghiên cứu đầu tiên của chúng tôi, Rancher Labs đã phát hành phiên bản 2 đầu tiên, nhưng mặc dù nó có thể được nâng lên rất nhanh bằng cách khởi chạy một vùng chứa mà không phụ thuộc vào bên ngoài với một vài tham số hoặc sử dụng Biểu đồ HELM chính thức, nhưng nó có vẻ thô thiển. cho chúng tôi và chúng tôi không biết liệu chúng tôi có thể dựa vào quyết định này để biết liệu nó sẽ được phát triển hay sẽ nhanh chóng bị loại bỏ. Mô hình cụm = số lần nhấp chuột trong bản thân giao diện người dùng cũng không phù hợp với chúng tôi và chúng tôi không muốn bị ràng buộc với RKE vì đây là một công cụ khá tập trung.
Phiên bản Rancher 2.2 đã có giao diện dễ sử dụng hơn và cùng với các phiên bản trước, có rất nhiều tính năng thú vị, chẳng hạn như tích hợp với nhiều nhà cung cấp bên ngoài, một điểm phân phối quyền và tệp kubeconfig duy nhất, khởi chạy kubectl hình ảnh với các quyền của bạn trong giao diện người dùng, các không gian tên lồng nhau hay còn gọi là dự án.
Ngoài ra còn có một cộng đồng đã được thành lập xung quanh Rancher 2 và một nhà cung cấp tên là HashiCorp Terraform đã được thành lập để quản lý cộng đồng đó, điều này đã giúp chúng tôi kết hợp mọi thứ lại với nhau.
Chuyện gì đã xảy ra thế
Kết quả là, chúng tôi đã có một cụm nhỏ chạy Rancher, có thể truy cập được vào tất cả các cụm khác, cũng như nhiều cụm được kết nối với nó, quyền truy cập vào bất kỳ cụm nào trong số đó có thể được cấp chỉ bằng cách thêm người dùng vào thư mục ldap, bất kể nó nằm ở đâu và nó sử dụng tài nguyên của nhà cung cấp nào.
Bằng cách sử dụng gitlab-ci và Terraform, một hệ thống đã được tạo cho phép bạn tạo một cụm gồm bất kỳ cấu hình nào trong các nhà cung cấp đám mây hoặc cơ sở hạ tầng của riêng chúng tôi và kết nối chúng với Rancher. Tất cả điều này được thực hiện theo kiểu IaC, trong đó mỗi cụm được mô tả bởi một kho lưu trữ và trạng thái của nó được lập phiên bản. Đồng thời, hầu hết các mô-đun được kết nối từ kho lưu trữ bên ngoài nên tất cả những gì còn lại là truyền các biến hoặc mô tả cấu hình tùy chỉnh của bạn cho các phiên bản, giúp giảm tỷ lệ lặp lại mã.
Tất nhiên, hành trình của chúng tôi còn lâu mới kết thúc và vẫn còn nhiều nhiệm vụ thú vị ở phía trước, chẳng hạn như một điểm làm việc duy nhất với nhật ký và số liệu của bất kỳ cụm nào, lưới dịch vụ, gitop để quản lý tải trong nhiều cụm, v.v. Chúng tôi hy vọng bạn thấy trải nghiệm của chúng tôi thú vị!
Bài viết được viết bởi A. Antipov, A. Ganush, Kỹ sư nền tảng.
Nguồn: www.habr.com