Tạo nền tảng kubernetes trên Pinterest

Trong những năm qua, 300 triệu người dùng của Pinterest đã tạo ra hơn 200 tỷ ghim trên hơn 4 tỷ bảng. Để phục vụ đội quân người dùng và cơ sở nội dung rộng lớn này, cổng thông tin đã phát triển hàng nghìn dịch vụ, từ các dịch vụ vi mô có thể được xử lý bởi một vài CPU cho đến các khối nguyên khối khổng lồ chạy trên toàn bộ nhóm máy ảo. Và rồi thời điểm công ty đổ dồn vào k8s đã đến. Tại sao “khối lập phương” trông đẹp trên Pinterest? Bạn sẽ tìm hiểu về điều này từ bản dịch của chúng tôi về một bài báo gần đây từ blog Pinterest kỹ thuật.

Tạo nền tảng kubernetes trên Pinterest

Vì vậy, có hàng trăm triệu người dùng và hàng trăm tỷ lượt ghim. Để phục vụ đội quân người dùng và cơ sở nội dung rộng lớn này, chúng tôi đã phát triển hàng nghìn dịch vụ, từ các dịch vụ vi mô có thể được xử lý bởi một vài CPU cho đến các khối nguyên khối khổng lồ chạy trên toàn bộ nhóm máy ảo. Ngoài ra, chúng tôi có nhiều khung công tác khác nhau cũng có thể yêu cầu quyền truy cập CPU, bộ nhớ hoặc I/O.

Trong việc duy trì kho công cụ này, nhóm phát triển phải đối mặt với một số thách thức:

  • Không có cách thống nhất để các kỹ sư vận hành môi trường sản xuất. Các dịch vụ không trạng thái, các dịch vụ có trạng thái và các dự án đang được phát triển tích cực dựa trên các nhóm công nghệ hoàn toàn khác nhau. Điều này dẫn đến việc phải tạo ra toàn bộ khóa đào tạo dành cho kỹ sư và cũng làm phức tạp nghiêm trọng công việc của nhóm cơ sở hạ tầng của chúng tôi.
  • Các nhà phát triển có đội máy ảo riêng tạo ra gánh nặng rất lớn cho quản trị viên nội bộ. Kết quả là, những thao tác đơn giản như cập nhật hệ điều hành hoặc AMI phải mất hàng tuần, hàng tháng. Điều này dẫn đến khối lượng công việc tăng lên trong các tình huống dường như hoàn toàn hàng ngày.
  • Khó khăn trong việc tạo ra các công cụ quản lý cơ sở hạ tầng toàn cầu dựa trên các giải pháp hiện có. Tình hình còn phức tạp hơn bởi việc tìm ra chủ sở hữu của các máy ảo không hề dễ dàng. Nghĩa là, chúng tôi không biết liệu khả năng này có thể được khai thác một cách an toàn để vận hành ở các phần khác trong cơ sở hạ tầng của chúng tôi hay không.

Hệ thống điều phối container là một cách để thống nhất quản lý khối lượng công việc. Chúng mở ra cơ hội tăng tốc độ phát triển và đơn giản hóa việc quản lý cơ sở hạ tầng vì tất cả các nguồn lực liên quan đến dự án đều được quản lý bởi một hệ thống tập trung.

Tạo nền tảng kubernetes trên Pinterest

Hình 1: Các ưu tiên về cơ sở hạ tầng (độ tin cậy, năng suất và hiệu quả của nhà phát triển).

Nhóm Nền tảng quản lý đám mây tại Pinterest đã phát hiện ra K8 vào năm 2017. Đến nửa đầu năm 2017, chúng tôi đã ghi lại hầu hết các khả năng sản xuất của mình, bao gồm API và tất cả các máy chủ web của chúng tôi. Sau đó, chúng tôi đã tiến hành đánh giá kỹ lưỡng các hệ thống khác nhau để điều phối các giải pháp container, xây dựng các cụm và làm việc với chúng. Đến cuối năm 2017, chúng tôi quyết định sử dụng Kubernetes. Nó khá linh hoạt và được hỗ trợ rộng rãi trong cộng đồng nhà phát triển.

Đến nay, chúng tôi đã xây dựng các công cụ khởi động cụm của riêng mình dựa trên Kops và di chuyển các thành phần cơ sở hạ tầng hiện có như mạng, bảo mật, số liệu, ghi nhật ký, quản lý danh tính và lưu lượng truy cập sang Kubernetes. Chúng tôi cũng đã triển khai một hệ thống mô hình hóa khối lượng công việc cho tài nguyên của mình, độ phức tạp của hệ thống này không được các nhà phát triển biết đến. Hiện tại, chúng tôi đang tập trung vào việc đảm bảo tính ổn định của cụm, mở rộng quy mô và kết nối các khách hàng mới.

Kubernetes: Cách Pinterest

Bắt đầu với Kubernetes ở quy mô Pinterest như một nền tảng mà các kỹ sư của chúng tôi yêu thích có rất nhiều thách thức.

Là một công ty lớn, chúng tôi đã đầu tư rất nhiều vào các công cụ cơ sở hạ tầng. Ví dụ bao gồm các công cụ bảo mật xử lý việc xử lý chứng chỉ và phân phối khóa, các thành phần kiểm soát lưu lượng, hệ thống khám phá dịch vụ, các thành phần hiển thị cũng như các thành phần gửi nhật ký và số liệu. Tất cả điều này được thu thập vì một lý do: chúng tôi đã trải qua quá trình thử và sai thông thường và do đó chúng tôi muốn tích hợp tất cả thiết bị này vào cơ sở hạ tầng mới trên Kubernetes thay vì phát minh lại bánh xe cũ trên nền tảng mới. Cách tiếp cận này về tổng thể đã đơn giản hóa quá trình di chuyển vì tất cả hỗ trợ ứng dụng đều đã tồn tại và không cần phải tạo từ đầu.

Mặt khác, các mô hình dự báo tải trong chính Kubernetes (chẳng hạn như triển khai, công việc và bộ Daemon) là không đủ cho dự án của chúng tôi. Những vấn đề về khả năng sử dụng này là rào cản lớn cho việc chuyển sang Kubernetes. Ví dụ: chúng tôi đã nghe các nhà phát triển dịch vụ phàn nàn về cài đặt đăng nhập bị thiếu hoặc không chính xác. Chúng tôi cũng gặp phải việc sử dụng công cụ tạo mẫu không chính xác khi hàng trăm bản sao được tạo ra với cùng đặc điểm kỹ thuật và tác vụ, dẫn đến các sự cố gỡ lỗi ác mộng.

Việc duy trì các phiên bản khác nhau trong cùng một cụm cũng rất khó khăn. Hãy tưởng tượng sự phức tạp của bộ phận hỗ trợ khách hàng nếu bạn cần làm việc đồng thời trên nhiều phiên bản của cùng một môi trường thời gian chạy, với tất cả các vấn đề, lỗi và bản cập nhật của chúng.

Thuộc tính người dùng và bộ điều khiển Pinterest

Để giúp các kỹ sư của chúng tôi triển khai Kubernetes dễ dàng hơn cũng như đơn giản hóa và tăng tốc cơ sở hạ tầng, chúng tôi đã phát triển các định nghĩa tài nguyên tùy chỉnh (CRD) của riêng mình.

CRD cung cấp các chức năng sau:

  1. Kết hợp các tài nguyên Kubernetes gốc khác nhau để chúng hoạt động như một khối lượng công việc duy nhất. Ví dụ: tài nguyên PinterestService bao gồm triển khai, dịch vụ đăng nhập và bản đồ cấu hình. Điều này cho phép các nhà phát triển không phải lo lắng về việc thiết lập DNS.
  2. Thực hiện hỗ trợ ứng dụng cần thiết. Người dùng chỉ cần tập trung vào đặc tả vùng chứa theo logic nghiệp vụ của họ, trong khi bộ điều khiển CRD triển khai tất cả các vùng chứa init, biến môi trường và thông số kỹ thuật nhóm cần thiết. Điều này mang lại mức độ thoải mái khác nhau về cơ bản cho các nhà phát triển.
  3. Bộ điều khiển CRD cũng quản lý vòng đời của tài nguyên gốc và cải thiện tính sẵn sàng gỡ lỗi. Điều này bao gồm việc điều chỉnh các thông số kỹ thuật mong muốn và thực tế, cập nhật trạng thái CRD và duy trì nhật ký sự kiện, v.v. Nếu không có CRD, các nhà phát triển sẽ buộc phải quản lý nhiều tài nguyên, điều này sẽ chỉ làm tăng khả năng xảy ra lỗi.

Dưới đây là ví dụ về PinterestService và tài nguyên nội bộ do bộ điều khiển của chúng tôi quản lý:

Tạo nền tảng kubernetes trên Pinterest

Như bạn có thể thấy ở trên, để hỗ trợ vùng chứa tùy chỉnh, chúng tôi cần tích hợp vùng chứa init và một số tiện ích bổ sung để cung cấp bảo mật, khả năng hiển thị và lưu lượng truy cập mạng. Ngoài ra, chúng tôi đã tạo các mẫu bản đồ cấu hình và triển khai hỗ trợ cho các mẫu PVC cho các tác vụ hàng loạt, cũng như theo dõi nhiều biến môi trường để theo dõi danh tính, mức tiêu thụ tài nguyên và thu gom rác.

Thật khó để tưởng tượng rằng các nhà phát triển muốn viết các tệp cấu hình này bằng tay mà không có sự hỗ trợ của CRD, chứ chưa nói đến việc duy trì và gỡ lỗi cấu hình thêm.

Quy trình triển khai ứng dụng

Tạo nền tảng kubernetes trên Pinterest

Hình ảnh trên cho thấy cách triển khai tài nguyên tùy chỉnh Pinterest vào cụm Kubernetes:

  1. Các nhà phát triển tương tác với cụm Kubernetes của chúng tôi thông qua CLI và giao diện người dùng.
  2. Các công cụ CLI/UI truy xuất các tệp YAML cấu hình quy trình làm việc và các thuộc tính bản dựng khác (cùng ID phiên bản) từ Artifactory rồi gửi chúng đến Dịch vụ gửi công việc. Bước này đảm bảo rằng chỉ các phiên bản sản xuất mới được phân phối đến cụm.
  3. JSS là cửa ngõ cho nhiều nền tảng khác nhau, bao gồm cả Kubernetes. Tại đây, người dùng được xác thực, hạn ngạch được cấp và cấu hình CRD của chúng tôi được kiểm tra một phần.
  4. Sau khi kiểm tra CRD ở phía JSS, thông tin sẽ được gửi đến API nền tảng k8s.
  5. Bộ điều khiển CRD của chúng tôi giám sát các sự kiện trên tất cả tài nguyên người dùng. Nó chuyển đổi CR thành tài nguyên k8 gốc, thêm các mô-đun cần thiết, đặt các biến môi trường thích hợp và thực hiện công việc hỗ trợ khác để đảm bảo các ứng dụng người dùng trong vùng chứa có đủ hỗ trợ cơ sở hạ tầng.
  6. Sau đó, bộ điều khiển CRD chuyển dữ liệu nhận được đến API Kubernetes để bộ lập lịch có thể xử lý dữ liệu đó và đưa vào sản xuất.

Ghi: Luồng công việc triển khai trước khi phát hành này được tạo cho những người dùng đầu tiên của nền tảng k8s mới. Chúng tôi hiện đang trong quá trình tinh chỉnh quy trình này để tích hợp hoàn toàn với CI/CD mới của mình. Điều này có nghĩa là chúng tôi không thể cho bạn biết mọi thứ liên quan đến Kubernetes. Chúng tôi mong muốn được chia sẻ kinh nghiệm của mình và tiến trình của nhóm theo hướng này trong bài đăng blog tiếp theo, “Xây dựng nền tảng CI/CD cho Pinterest”.

Các loại tài nguyên đặc biệt

Dựa trên nhu cầu cụ thể của Pinterest, chúng tôi đã phát triển các CRD sau để phù hợp với các quy trình công việc khác nhau:

  • PinterestService là các dịch vụ không trạng thái đã hoạt động trong một thời gian dài. Nhiều hệ thống cốt lõi của chúng tôi dựa trên một tập hợp các dịch vụ như vậy.
  • PinterestJobSet mô hình hóa các công việc hàng loạt theo chu kỳ đầy đủ. Một tình huống phổ biến trên Pinterest là nhiều công việc chạy song song cùng một vùng chứa, bất kể các quy trình tương tự khác.
  • PinterestCronJob được sử dụng rộng rãi cùng với các tải nhỏ định kỳ. Đây là trình bao bọc cho hoạt động cron gốc với các cơ chế hỗ trợ của Pinterest chịu trách nhiệm về bảo mật, lưu lượng truy cập, nhật ký và số liệu.
  • PinterestDaemon bao gồm các Daemon cơ sở hạ tầng. Gia đình này tiếp tục phát triển khi chúng tôi bổ sung thêm hỗ trợ cho các cụm của mình.
  • PinterestTrainingJob mở rộng sang các quy trình Tensorflow và Pytorch, cung cấp mức hỗ trợ thời gian chạy giống như tất cả các CRD khác. Vì Pinterest tích cực sử dụng Tensorflow và các hệ thống máy học khác nên chúng tôi có lý do để xây dựng một CRD riêng xung quanh chúng.

Chúng tôi cũng đang làm việc trên PinterestStatefulSet, sẽ sớm được điều chỉnh cho phù hợp với kho dữ liệu và các hệ thống có trạng thái khác.

Hỗ trợ thời gian chạy

Khi một nhóm ứng dụng chạy trên Kubernetes, nó sẽ tự động nhận được chứng chỉ để nhận dạng chính nó. Chứng chỉ này được sử dụng để truy cập vào bộ lưu trữ bí mật hoặc để liên lạc với các dịch vụ khác thông qua mTLS. Trong khi đó, Bộ cấu hình khởi tạo vùng chứa và Daemon sẽ tải xuống tất cả các phần phụ thuộc cần thiết trước khi chạy ứng dụng được chứa trong vùng chứa. Khi mọi thứ đã sẵn sàng, sidecar giao thông và Daemon sẽ đăng ký địa chỉ IP của mô-đun với Zookeeper của chúng tôi để khách hàng có thể khám phá nó. Tất cả điều này sẽ hoạt động vì mô-đun mạng đã được cấu hình trước khi ứng dụng được khởi chạy.

Trên đây là những ví dụ điển hình về hỗ trợ thời gian chạy cho khối lượng công việc. Các loại khối lượng công việc khác có thể yêu cầu hỗ trợ hơi khác một chút, nhưng tất cả đều ở dạng sidecar cấp nhóm, Daemon cấp nút hoặc cấp máy ảo. Chúng tôi đảm bảo rằng tất cả điều này được triển khai trong cơ sở hạ tầng quản lý và nhất quán trên các ứng dụng, điều này cuối cùng giúp giảm đáng kể gánh nặng về công việc kỹ thuật và hỗ trợ khách hàng.

Kiểm tra và QA

Chúng tôi đã xây dựng quy trình thử nghiệm toàn diện trên cơ sở hạ tầng thử nghiệm Kubernetes hiện có. Những thử nghiệm này áp dụng cho tất cả các cụm của chúng tôi. Quy trình của chúng tôi đã trải qua nhiều lần sửa đổi trước khi trở thành một phần của cụm sản phẩm.

Ngoài hệ thống kiểm tra, chúng tôi còn có hệ thống giám sát và cảnh báo liên tục theo dõi trạng thái của các thành phần hệ thống, mức tiêu thụ tài nguyên và các chỉ số quan trọng khác, chỉ thông báo cho chúng tôi khi cần có sự can thiệp của con người.

Giải pháp thay thế

Chúng tôi đã xem xét một số lựa chọn thay thế cho tài nguyên tùy chỉnh, chẳng hạn như bộ điều khiển truy cập đột biến và hệ thống mẫu. Tuy nhiên, tất cả đều có những thách thức vận hành đáng kể, vì vậy chúng tôi đã chọn con đường CRD.

Bộ điều khiển tiếp nhận đột biến được sử dụng để giới thiệu sidecar, biến môi trường và hỗ trợ thời gian chạy khác. Tuy nhiên, nó phải đối mặt với nhiều vấn đề khác nhau, chẳng hạn như ràng buộc tài nguyên và quản lý vòng đời, trong đó những vấn đề như vậy không phát sinh trong CRD.

Lưu ý: Các hệ thống mẫu như biểu đồ Helm cũng được sử dụng rộng rãi để chạy các ứng dụng có cấu hình tương tự. Tuy nhiên, ứng dụng công việc của chúng tôi quá đa dạng để có thể quản lý bằng các mẫu. Ngoài ra trong quá trình triển khai liên tục sẽ có quá nhiều lỗi khi sử dụng template.

Công việc sắp tới

Chúng tôi hiện đang xử lý tải hỗn hợp trên tất cả các cụm của mình. Để hỗ trợ các quy trình thuộc nhiều loại và quy mô khác nhau, chúng tôi hoạt động trong các lĩnh vực sau:

  • Một tập hợp các cụm phân phối các ứng dụng lớn trên các cụm khác nhau để có khả năng mở rộng và ổn định.
  • Đảm bảo tính ổn định của cụm, khả năng mở rộng và khả năng hiển thị để tạo kết nối ứng dụng và SLA.
  • Quản lý tài nguyên và hạn ngạch để các ứng dụng không xung đột với nhau và quy mô của cụm được chúng tôi kiểm soát.
  • Nền tảng CI/CD mới để hỗ trợ và triển khai các ứng dụng trên Kubernetes.

Nguồn: www.habr.com

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