Cách di chuyển lên đám mây trong hai giờ nhờ Kubernetes và tự động hóa

Cách di chuyển lên đám mây trong hai giờ nhờ Kubernetes và tự động hóa

Công ty URUS đã thử Kubernetes dưới nhiều hình thức khác nhau: triển khai độc lập trên kim loại trần, trong Google Cloud, sau đó chuyển nền tảng của nó sang đám mây Mail.ru Cloud Solutions (MCS). Igor Shishkin kể về cách họ chọn nhà cung cấp đám mây mới và cách họ di chuyển sang nhà cung cấp đó trong hai giờ kỷ lục (t3ran), quản trị viên hệ thống cấp cao tại URUS.

URUS làm gì?

Có nhiều cách để cải thiện chất lượng môi trường đô thị, và một trong số đó là làm cho nó thân thiện với môi trường. Đây chính xác là những gì URUS - công ty Dịch vụ Kỹ thuật số Thông minh đang thực hiện. Tại đây, họ triển khai các giải pháp giúp doanh nghiệp giám sát các chỉ số môi trường quan trọng và giảm tác động tiêu cực đến môi trường. Các cảm biến thu thập dữ liệu về thành phần không khí, độ ồn và các thông số khác, sau đó gửi chúng đến nền tảng URUS-Ekomon thống nhất để phân tích và đưa ra khuyến nghị.

Cách URUS hoạt động từ bên trong

Khách hàng điển hình của URUS là một công ty nằm trong hoặc gần khu dân cư. Đây có thể là nhà máy, bến cảng, kho đường sắt hoặc bất kỳ cơ sở nào khác. Nếu khách hàng của chúng tôi đã nhận được cảnh báo, bị phạt vì ô nhiễm môi trường hoặc muốn ít gây tiếng ồn hơn, giảm lượng khí thải độc hại, họ sẽ đến gặp chúng tôi và chúng tôi đã cung cấp cho họ giải pháp giám sát môi trường có sẵn.

Cách di chuyển lên đám mây trong hai giờ nhờ Kubernetes và tự động hóa
Biểu đồ giám sát nồng độ H2S cho thấy lượng phát thải thường xuyên vào ban đêm từ một nhà máy gần đó

Các thiết bị mà chúng tôi sử dụng tại URUS chứa một số cảm biến thu thập thông tin về hàm lượng của một số loại khí, mức độ tiếng ồn và dữ liệu khác để đánh giá tình hình môi trường. Số lượng cảm biến chính xác luôn được xác định bởi nhiệm vụ cụ thể.

Cách di chuyển lên đám mây trong hai giờ nhờ Kubernetes và tự động hóa
Tùy thuộc vào đặc thù của phép đo, các thiết bị có cảm biến có thể được đặt trên tường của các tòa nhà, cột điện và những nơi tùy ý khác. Mỗi thiết bị như vậy sẽ thu thập thông tin, tổng hợp và gửi đến cổng nhận dữ liệu. Ở đó, chúng tôi lưu dữ liệu để lưu trữ lâu dài và xử lý trước dữ liệu để phân tích tiếp theo. Ví dụ đơn giản nhất về kết quả phân tích mà chúng tôi nhận được là chỉ số chất lượng không khí, còn được gọi là AQI.

Song song đó, nhiều dịch vụ khác hoạt động trên nền tảng của chúng tôi, nhưng chúng chủ yếu mang tính chất dịch vụ. Ví dụ: dịch vụ thông báo sẽ gửi thông báo đến khách hàng nếu bất kỳ thông số nào được giám sát (ví dụ: hàm lượng CO2) vượt quá giá trị cho phép.

Cách chúng tôi lưu trữ dữ liệu. Câu chuyện về Kubernetes trên kim loại trần

Dự án giám sát môi trường URUS có một số kho dữ liệu. Trong một, chúng tôi giữ dữ liệu “thô” - những gì chúng tôi nhận được trực tiếp từ chính thiết bị. Bộ lưu trữ này là một băng “từ tính”, giống như trên các băng cassette cũ, có lịch sử của tất cả các chỉ số. Loại lưu trữ thứ hai được sử dụng cho dữ liệu được xử lý trước - dữ liệu từ thiết bị, được làm giàu bằng siêu dữ liệu về kết nối giữa các cảm biến và chỉ số đọc của chính thiết bị, liên kết với các tổ chức, địa điểm, v.v. Thông tin này cho phép bạn đánh giá linh hoạt mức độ hoạt động của một chỉ báo cụ thể thay đổi trong một khoảng thời gian nhất định. Chúng tôi sử dụng bộ lưu trữ dữ liệu “thô”, cùng với những mục đích khác, làm bản sao lưu và khôi phục dữ liệu đã được xử lý trước, nếu có nhu cầu như vậy.

Khi chúng tôi tìm cách giải quyết vấn đề lưu trữ của mình vài năm trước, chúng tôi có hai lựa chọn nền tảng: Kubernetes và OpenStack. Nhưng vì cái sau trông khá quái dị (chỉ cần nhìn vào kiến ​​trúc của nó để thấy rõ điều này), nên chúng tôi đã quyết định sử dụng Kubernetes. Một lập luận khác có lợi cho nó là việc kiểm soát phần mềm tương đối đơn giản, khả năng cắt linh hoạt hơn ngay cả các nút phần cứng tùy theo tài nguyên.

Song song với việc làm chủ Kubernetes, chúng tôi cũng nghiên cứu các cách lưu trữ dữ liệu, trong khi vẫn giữ tất cả bộ nhớ trong Kubernetes trên phần cứng của riêng mình, chúng tôi đã nhận được kiến ​​thức chuyên môn xuất sắc. Mọi thứ chúng tôi có khi đó đều có trên Kubernetes: bộ lưu trữ đầy đủ trạng thái, hệ thống giám sát, CI/CD. Kubernetes đã trở thành nền tảng tất cả trong một cho chúng tôi.

Nhưng chúng tôi muốn hợp tác với Kubernetes như một dịch vụ chứ không tham gia vào việc hỗ trợ và phát triển nó. Ngoài ra, chúng tôi không thích việc phải tốn bao nhiêu tiền để duy trì nó trên kim loại trần và chúng tôi cần phát triển liên tục! Ví dụ: một trong những nhiệm vụ đầu tiên là tích hợp bộ điều khiển Kubernetes Ingress vào cơ sở hạ tầng mạng của tổ chức chúng tôi. Đây là một nhiệm vụ phức tạp, đặc biệt khi xét đến thời điểm đó chưa có gì sẵn sàng cho việc quản lý tài nguyên theo chương trình như bản ghi DNS hoặc phân bổ địa chỉ IP. Sau đó chúng tôi bắt đầu thử nghiệm việc lưu trữ dữ liệu bên ngoài. Chúng tôi chưa bao giờ bắt tay vào triển khai bộ điều khiển PVC, nhưng ngay cả khi đó, rõ ràng đây là một lĩnh vực công việc rộng lớn đòi hỏi các chuyên gia tận tâm.

Chuyển sang Google Cloud Platform là giải pháp tạm thời

Chúng tôi nhận ra rằng điều này không thể tiếp tục và đã chuyển dữ liệu của chúng tôi từ kim loại thô sang Google Cloud Platform. Trên thực tế, vào thời điểm đó không có nhiều lựa chọn thú vị cho một công ty Nga: ngoài Google Cloud Platform, chỉ có Amazon cung cấp dịch vụ tương tự, nhưng chúng tôi vẫn quyết định dựa trên giải pháp từ Google. Sau đó, đối với chúng tôi, nó có vẻ mang lại lợi nhuận kinh tế cao hơn, gần với Upstream hơn, chưa kể thực tế rằng bản thân Google cũng là một loại PoC Kubernetes trong Sản xuất.

Vấn đề lớn đầu tiên xuất hiện khi lượng khách hàng của chúng tôi ngày càng tăng. Khi có nhu cầu lưu trữ dữ liệu cá nhân, chúng tôi đứng trước sự lựa chọn: hoặc chúng tôi làm việc với Google và vi phạm luật pháp Nga hoặc chúng tôi đang tìm kiếm giải pháp thay thế ở Liên bang Nga. Nhìn chung, sự lựa chọn là có thể đoán trước được. 🙂

Chúng tôi thấy dịch vụ đám mây lý tưởng như thế nào

Khi bắt đầu tìm kiếm, chúng tôi đã biết mình muốn nhận được gì từ nhà cung cấp đám mây trong tương lai. Chúng tôi đang tìm kiếm dịch vụ gì:

  • Nhanh chóng và linh hoạt. Như vậy, chúng ta có thể nhanh chóng thêm một nút mới hoặc triển khai thứ gì đó bất cứ lúc nào.
  • Không tốn kém. Chúng tôi rất lo lắng về vấn đề tài chính vì nguồn lực của chúng tôi có hạn. Chúng tôi đã biết rằng chúng tôi muốn hợp tác với Kubernetes và bây giờ nhiệm vụ là giảm thiểu chi phí của nó để tăng hoặc ít nhất là duy trì hiệu quả của việc sử dụng giải pháp này.
  • tự động. Chúng tôi đã lên kế hoạch làm việc với dịch vụ thông qua API mà không cần người quản lý và các cuộc gọi điện thoại hoặc các tình huống mà chúng tôi cần nâng hàng chục nút theo cách thủ công ở chế độ khẩn cấp. Vì hầu hết các quy trình của chúng tôi đều được tự động hóa nên chúng tôi mong đợi điều tương tự từ dịch vụ đám mây.
  • Với máy chủ ở Liên bang Nga. Tất nhiên, chúng tôi đã lên kế hoạch tuân thủ luật pháp của Nga và cùng loại 152-FZ đó.

Vào thời điểm đó, có rất ít nhà cung cấp Kubernetes aaS ở Nga và khi chọn nhà cung cấp, điều quan trọng là chúng tôi không được thỏa hiệp các ưu tiên của mình. Nhóm Giải pháp Đám mây Mail.ru, người mà chúng tôi đã bắt đầu làm việc và vẫn đang cộng tác, đã cung cấp cho chúng tôi dịch vụ hoàn toàn tự động, với sự hỗ trợ API và bảng điều khiển tiện lợi bao gồm Horizon - với nó, chúng tôi có thể nhanh chóng tăng số lượng nút tùy ý.

Cách chúng tôi di chuyển sang MCS trong hai giờ

Trong những động thái như vậy, nhiều công ty phải đối mặt với khó khăn và thất bại, nhưng trong trường hợp của chúng tôi thì không. Chúng tôi thật may mắn: vì chúng tôi đã làm việc trên Kubernetes trước khi quá trình di chuyển bắt đầu nên chúng tôi chỉ cần sửa ba tệp và khởi chạy dịch vụ của mình trên nền tảng đám mây mới, MCS. Hãy để tôi nhắc bạn rằng vào thời điểm đó chúng tôi cuối cùng đã rời bỏ kim loại trần và sống trên Nền tảng đám mây của Google. Do đó, quá trình di chuyển chỉ mất không quá hai giờ, cộng thêm một chút thời gian (khoảng một giờ) để sao chép dữ liệu từ thiết bị của chúng tôi. Trước đó, chúng tôi đã sử dụng Spinnaker (dịch vụ CD nhiều đám mây để cung cấp Phân phối liên tục). Chúng tôi cũng nhanh chóng thêm nó vào cụm mới và tiếp tục hoạt động như bình thường.

Nhờ tự động hóa các quy trình phát triển và CI/CD, Kubernetes tại URUS được xử lý bởi một chuyên gia (và đó là tôi). Ở một giai đoạn nào đó, một quản trị viên hệ thống khác đã làm việc với tôi, nhưng sau đó hóa ra là chúng tôi đã tự động hóa tất cả quy trình chính và ngày càng có nhiều nhiệm vụ hơn trong phần sản phẩm chính của chúng tôi và việc hướng nguồn lực vào việc này là điều hợp lý.

Chúng tôi đã nhận được những gì chúng tôi mong đợi từ nhà cung cấp đám mây vì chúng tôi bắt đầu hợp tác mà không hề ảo tưởng. Nếu có bất kỳ sự cố nào, chúng chủ yếu là về mặt kỹ thuật và những sự cố đó có thể dễ dàng được giải thích bằng sự mới mẻ tương đối của dịch vụ. Điều chính là nhóm MCS nhanh chóng loại bỏ những thiếu sót và trả lời nhanh chóng các câu hỏi trong trình nhắn tin.

Nếu tôi so sánh trải nghiệm của mình với Google Cloud Platform, trong trường hợp của họ, tôi thậm chí còn không biết nút phản hồi ở đâu vì đơn giản là không cần đến nó. Và nếu có vấn đề gì xảy ra, chính Google sẽ đơn phương gửi thông báo. Nhưng trong trường hợp của MCS, tôi nghĩ lợi thế lớn là họ càng gần gũi với khách hàng Nga - cả về mặt địa lý và tinh thần.

Chúng ta thấy cách làm việc với đám mây trong tương lai

Giờ đây, công việc của chúng tôi gắn chặt với Kubernetes và nó hoàn toàn phù hợp với chúng tôi từ quan điểm về các nhiệm vụ cơ sở hạ tầng. Do đó, chúng tôi không có kế hoạch di chuyển từ bất cứ đâu, mặc dù chúng tôi liên tục giới thiệu các phương pháp và dịch vụ mới để đơn giản hóa các tác vụ thông thường và tự động hóa các tác vụ mới, tăng tính ổn định và độ tin cậy của dịch vụ... Chúng tôi hiện đang triển khai dịch vụ Chaos Monkey (cụ thể là , chúng tôi sử dụng Chaoskube, nhưng điều này không thay đổi khái niệm: ), vốn được Netflix tạo ra ban đầu. Chaos Monkey thực hiện một điều đơn giản: nó xóa một nhóm Kubernetes ngẫu nhiên vào một thời điểm ngẫu nhiên. Điều này là cần thiết để dịch vụ của chúng tôi hoạt động bình thường với số lượng trường hợp n–1, vì vậy chúng tôi tự rèn luyện để chuẩn bị cho mọi vấn đề.

Bây giờ tôi thấy việc sử dụng các giải pháp của bên thứ ba - cùng nền tảng đám mây - là điều đúng đắn duy nhất đối với các công ty trẻ. Thông thường, khi bắt đầu hành trình, họ bị hạn chế về nguồn lực, cả nhân lực lẫn tài chính, đồng thời việc xây dựng và duy trì đám mây hoặc trung tâm dữ liệu của riêng mình quá tốn kém và tốn nhiều công sức. Các nhà cung cấp đám mây cho phép bạn giảm thiểu các chi phí này; bạn có thể nhanh chóng nhận được từ họ các tài nguyên cần thiết để vận hành các dịch vụ tại chỗ và ngay bây giờ và thanh toán cho các tài nguyên này sau khi thực tế. Đối với công ty URUS, hiện tại chúng tôi vẫn trung thành với Kubernetes trên đám mây. Nhưng ai biết được, chúng ta có thể phải mở rộng về mặt địa lý hoặc thực hiện các giải pháp dựa trên một số thiết bị cụ thể. Hoặc có thể lượng tài nguyên được tiêu thụ sẽ phù hợp với Kubernetes của riêng họ trên kim loại trần, giống như ngày xưa. 🙂

Những điều chúng tôi học được khi làm việc với các dịch vụ đám mây

Chúng tôi bắt đầu sử dụng Kubernetes trên kim loại trần và thậm chí ở đó nó vẫn hoạt động tốt theo cách riêng của nó. Nhưng điểm mạnh của nó đã được bộc lộ chính xác dưới dạng thành phần aaS trên đám mây. Nếu bạn đặt mục tiêu và tự động hóa mọi thứ nhiều nhất có thể, bạn sẽ có thể tránh được sự ràng buộc của nhà cung cấp và việc di chuyển giữa các nhà cung cấp đám mây sẽ mất vài giờ và các tế bào thần kinh sẽ vẫn ở bên chúng ta. Chúng tôi có thể tư vấn cho các công ty khác: nếu bạn muốn triển khai dịch vụ (đám mây) của riêng mình, với nguồn lực hạn chế và tốc độ phát triển tối đa, hãy bắt đầu ngay bây giờ bằng cách thuê tài nguyên đám mây và xây dựng trung tâm dữ liệu của bạn sau khi Forbes viết về bạn.

Nguồn: www.habr.com

Thêm một lời nhận xét