Bản chất của câu chuyện về trình quản lý gói phổ biến nhất dành cho Kubernetes có thể được mô tả bằng biểu tượng cảm xúc:
- hộp là Helm (thứ gần gũi nhất với phiên bản Emoji mới nhất);
- khóa - bảo mật;
- người đàn ông nhỏ bé là giải pháp cho vấn đề.
Trên thực tế, mọi thứ sẽ phức tạp hơn một chút và câu chuyện chứa đầy các chi tiết kỹ thuật về Cách làm cho Helm an toàn.
- Tóm tắt ngắn gọn Helm là gì phòng trường hợp bạn chưa biết hoặc quên. Nó giải quyết được những vấn đề gì và nó nằm ở đâu trong hệ sinh thái.
- Hãy nhìn vào kiến trúc Helm. Sẽ không có cuộc trò chuyện nào về bảo mật và cách làm cho một công cụ hoặc giải pháp trở nên an toàn hơn nếu không hiểu kiến trúc của thành phần.
- Hãy thảo luận về các thành phần Helm.
- Câu hỏi hóc búa nhất là tương lai - phiên bản mới của Helm 3.
Mọi thứ trong bài viết này đều áp dụng cho Helm 2. Phiên bản này hiện đang được sản xuất và rất có thể là phiên bản bạn đang sử dụng và đây là phiên bản có chứa các rủi ro bảo mật.
Về diễn giả: Alexander Khayorov () đã phát triển được 10 năm, giúp cải thiện nội dung và tham gia ủy ban . Hiện anh ấy làm việc tại Chainstack với tư cách là trưởng nhóm phát triển - đây là sự kết hợp giữa người quản lý phát triển và người chịu trách nhiệm cung cấp các bản phát hành cuối cùng. Tức là nó nằm trên chiến trường, nơi mọi thứ diễn ra từ việc tạo ra sản phẩm đến vận hành sản phẩm.
Chainstack là một công ty khởi nghiệp nhỏ, đang phát triển tích cực với sứ mệnh giúp khách hàng quên đi cơ sở hạ tầng và sự phức tạp khi vận hành các ứng dụng phi tập trung; nhóm phát triển được đặt tại Singapore. Đừng yêu cầu Chainstack bán hoặc mua tiền điện tử mà hãy đề nghị nói chuyện về các khuôn khổ blockchain doanh nghiệp và họ sẽ vui vẻ trả lời bạn.
Quản lý
Đây là trình quản lý gói (biểu đồ) cho Kubernetes. Cách trực quan và phổ biến nhất để đưa các ứng dụng vào cụm Kubernetes.
Tất nhiên, chúng tôi đang nói về một cách tiếp cận mang tính cấu trúc và công nghiệp hơn là tạo các bảng kê khai YAML của riêng bạn và viết các tiện ích nhỏ.
Helm là thứ tốt nhất hiện có và phổ biến.
Tại sao lại là Helm? Chủ yếu là vì nó được hỗ trợ bởi CNCF. Cloud Native là một tổ chức lớn và là công ty mẹ của các dự án Kubernetes, etcd, Fluentd và các dự án khác.
Một thực tế quan trọng khác là Helm là một dự án rất phổ biến. Khi tôi bắt đầu nói về cách đảm bảo an toàn cho Helm vào tháng 2019 năm 12, dự án đã nhận được hàng nghìn sao trên GitHub. Đến tháng XNUMX đã có XNUMX nghìn người trong số họ.
Nhiều người quan tâm đến Helm, vì vậy ngay cả khi chưa sử dụng nó, bạn cũng sẽ được hưởng lợi khi biết về tính bảo mật của nó. An toàn là quan trọng.
Nhóm Helm cốt lõi được hỗ trợ bởi Microsoft Azure và do đó là một dự án khá ổn định, không giống như nhiều dự án khác. Việc phát hành Helm 3 Alpha 2 vào giữa tháng XNUMX cho thấy có khá nhiều người làm việc trong dự án và họ có mong muốn cũng như nghị lực để phát triển và cải thiện Helm.
Helm giải quyết một số vấn đề gốc rễ của việc quản lý ứng dụng trong Kubernetes.
- Bao bì ứng dụng. Ngay cả một ứng dụng như “Hello, World” trên WordPress cũng đã bao gồm một số dịch vụ và bạn muốn đóng gói chúng lại với nhau.
- Quản lý sự phức tạp đi kèm với việc quản lý các ứng dụng này.
- Vòng đời không kết thúc sau khi ứng dụng được cài đặt hoặc triển khai. Nó tiếp tục tồn tại, nó cần được cập nhật và Helm sẽ hỗ trợ việc này và cố gắng đưa ra các biện pháp và chính sách phù hợp cho việc này.
Đóng bao nó được tổ chức một cách rõ ràng: có siêu dữ liệu hoàn toàn phù hợp với công việc của một trình quản lý gói thông thường dành cho Linux, Windows hoặc MacOS. Tức là một kho lưu trữ, các phần phụ thuộc vào các gói khác nhau, thông tin meta cho ứng dụng, cài đặt, tính năng cấu hình, lập chỉ mục thông tin, v.v. Helm cho phép bạn lấy và sử dụng tất cả những thứ này cho các ứng dụng.
Quản lý phức tạp. Nếu bạn có nhiều ứng dụng cùng loại thì cần phải tham số hóa. Các mẫu xuất phát từ điều này, nhưng để tránh phải nghĩ ra cách tạo mẫu của riêng mình, bạn có thể sử dụng những gì Helm cung cấp sẵn.
Quản lý vòng đời ứng dụng - theo tôi, đây là câu hỏi thú vị nhất và chưa được giải đáp. Đây là lý do tại sao tôi đến Helm ngày trước. Chúng tôi cần theo dõi vòng đời của ứng dụng và muốn chuyển CI/CD và chu trình ứng dụng của mình sang mô hình này.
Helm cho phép bạn:
- quản lý việc triển khai, giới thiệu khái niệm về cấu hình và sửa đổi;
- thực hiện khôi phục thành công;
- sử dụng hook cho các sự kiện khác nhau;
- thêm các bước kiểm tra ứng dụng bổ sung và phản hồi kết quả của chúng.
Hơn nữa Mũ bảo hiểm có “pin” - một số lượng lớn những thứ thú vị có thể được đưa vào dưới dạng plugin, giúp đơn giản hóa cuộc sống của bạn. Các plugin có thể được viết độc lập, chúng khá tách biệt và không yêu cầu kiến trúc hài hòa. Nếu bạn muốn triển khai một cái gì đó, tôi khuyên bạn nên thực hiện nó như một plugin và sau đó có thể đưa nó vào thượng nguồn.
Helm dựa trên ba khái niệm chính:
- Kho lưu trữ biểu đồ — mô tả và mảng tham số hóa có thể có cho bảng kê khai của bạn.
- Config —tức là các giá trị sẽ được áp dụng (văn bản, giá trị số, v.v.).
- Phát hành tập hợp hai thành phần phía trên và chúng cùng nhau biến thành Bản phát hành. Các bản phát hành có thể được lập phiên bản, nhờ đó đạt được vòng đời có tổ chức: nhỏ tại thời điểm cài đặt và lớn tại thời điểm nâng cấp, hạ cấp hoặc khôi phục.
kiến trúc mũ bảo hiểm
Sơ đồ mô tả một cách khái niệm kiến trúc cấp cao của Helm.
Hãy để tôi nhắc bạn rằng Helm có liên quan đến Kubernetes. Vì vậy, chúng ta không thể thiếu cụm Kubernetes (hình chữ nhật). Thành phần kube-apiserver nằm trên master. Không có Helm, chúng ta có Kubeconfig. Helm mang đến một tệp nhị phân nhỏ, nếu bạn có thể gọi nó như vậy, tiện ích Helm CLI, được cài đặt trên máy tính, máy tính xách tay, máy tính lớn - trên bất kỳ thứ gì.
Nhưng điều này là không đủ. Helm có một thành phần máy chủ tên là Tiller. Nó đại diện cho lợi ích của Helm trong cụm; nó là một ứng dụng trong cụm Kubernetes, giống như bất kỳ ứng dụng nào khác.
Thành phần tiếp theo của Chart Repo là một kho lưu trữ các biểu đồ. Có một kho lưu trữ chính thức và có thể có một kho lưu trữ riêng của một công ty hoặc dự án.
Tương tác
Hãy xem cách các thành phần kiến trúc tương tác khi chúng ta muốn cài đặt một ứng dụng bằng Helm.
- Chúng tôi đang nói
Helm install, truy cập kho lưu trữ (Chart Repo) và lấy biểu đồ Helm.
- Tiện ích Helm (Helm CLI) tương tác với Kubeconfig để tìm ra cụm nào cần liên hệ.
- Sau khi nhận được thông tin này, tiện ích sẽ đề cập đến Tiller, nằm trong cụm của chúng tôi, như một ứng dụng.
- Tiller gọi Kube-apiserver để thực hiện các hành động trong Kubernetes, tạo một số đối tượng (dịch vụ, nhóm, bản sao, bí mật, v.v.).
Tiếp theo, chúng ta sẽ làm phức tạp sơ đồ để xem vectơ tấn công mà toàn bộ kiến trúc Helm nói chung có thể bị phơi nhiễm. Và sau đó chúng tôi sẽ cố gắng bảo vệ cô ấy.
Véc tơ tấn công
Điểm yếu tiềm ẩn đầu tiên là API đặc quyền-người sử dụng. Là một phần của kế hoạch, đây là một hacker đã giành được quyền truy cập quản trị viên vào Helm CLI.
Người dùng API không có đặc quyền cũng có thể gây nguy hiểm nếu nó ở đâu đó gần đó. Người dùng như vậy sẽ có bối cảnh khác, ví dụ: anh ta có thể được cố định trong một không gian tên cụm trong cài đặt Kubeconfig.
Vectơ tấn công thú vị nhất có thể là một quy trình nằm bên trong một cụm ở đâu đó gần Tiller và có thể truy cập vào nó. Đây có thể là một máy chủ web hoặc microservice xem môi trường mạng của cụm.
Một biến thể tấn công kỳ lạ nhưng ngày càng phổ biến liên quan đến Chart Repo. Một biểu đồ được tạo bởi một tác giả vô đạo đức có thể chứa các tài nguyên không an toàn và bạn sẽ hoàn thành nó bằng cách tin tưởng vào nó. Hoặc nó có thể thay thế biểu đồ mà bạn tải xuống từ kho lưu trữ chính thức và chẳng hạn như tạo một tài nguyên dưới dạng chính sách và nâng cấp quyền truy cập của nó.
Chúng ta hãy cố gắng chống lại các cuộc tấn công từ cả bốn phía này và tìm ra vấn đề ở đâu trong kiến trúc Helm và ở đâu có lẽ không có vấn đề gì.
Hãy phóng to sơ đồ, thêm nhiều phần tử hơn nhưng vẫn giữ nguyên tất cả các thành phần cơ bản.
Helm CLI giao tiếp với Chart Repo, tương tác với Kubeconfig và công việc được chuyển đến cụm thành thành phần Tiller.
Tiller được đại diện bởi hai đối tượng:
- Tiller-triển khai svc, hiển thị một dịch vụ nhất định;
- Nhóm triển khai máy xới (trong sơ đồ là một bản sao duy nhất trong một bản sao), trên đó toàn bộ tải chạy, truy cập vào cụm.
Các giao thức và sơ đồ khác nhau được sử dụng để tương tác. Từ quan điểm bảo mật, chúng tôi quan tâm nhất đến:
- Cơ chế mà Helm CLI truy cập vào kho lưu trữ biểu đồ: giao thức nào, có xác thực không và có thể thực hiện những gì với nó.
- Giao thức mà Helm CLI, sử dụng kubectl, giao tiếp với Tiller. Đây là một máy chủ RPC được cài đặt bên trong cụm.
- Bản thân Tiller có thể truy cập được vào các vi dịch vụ nằm trong cụm và tương tác với máy chủ Kube-apiserver.
Hãy thảo luận về tất cả các lĩnh vực này theo thứ tự.
RBAC
Không có ích gì khi nói về bất kỳ bảo mật nào cho Helm hoặc bất kỳ dịch vụ nào khác trong cụm trừ khi RBAC được bật.
Có vẻ như đây không phải là khuyến nghị mới nhất, nhưng tôi chắc chắn rằng nhiều người vẫn chưa kích hoạt RBAC ngay cả trong quá trình sản xuất, bởi vì nó rất phức tạp và rất nhiều thứ cần phải cấu hình. Tuy nhiên, tôi khuyến khích bạn làm điều này.
— luật sư trang web cho RBAC. Nó chứa một lượng lớn tài liệu thú vị sẽ giúp bạn thiết lập RBAC, cho thấy lý do tại sao nó tốt và về cơ bản cách sử dụng nó trong sản xuất.
Tôi sẽ cố gắng giải thích cách Tiller và RBAC hoạt động. Tiller hoạt động bên trong cụm theo một tài khoản dịch vụ nhất định. Thông thường, nếu RBAC không được cấu hình thì đây sẽ là superuser. Ở cấu hình cơ bản, Tiller sẽ là quản trị viên. Đây là lý do tại sao người ta thường nói rằng Tiller là một đường hầm SSH tới cụm của bạn. Trên thực tế, điều này là đúng, vì vậy bạn có thể sử dụng một tài khoản dịch vụ chuyên dụng riêng thay vì Tài khoản dịch vụ mặc định trong sơ đồ trên.
Khi bạn khởi tạo Helm và cài đặt nó trên máy chủ lần đầu tiên, bạn có thể đặt tài khoản dịch vụ bằng cách sử dụng --service-account. Điều này sẽ cho phép bạn sử dụng người dùng với các quyền tối thiểu được yêu cầu. Đúng vậy, bạn sẽ phải tạo một “vòng hoa” như vậy: Vai trò và Ràng buộc vai trò.
Thật không may, Helm sẽ không làm điều này cho bạn. Bạn hoặc quản trị viên cụm Kubernetes của bạn cần chuẩn bị trước một bộ Vai trò và Ràng buộc vai trò cho tài khoản dịch vụ để vượt qua Helm.
Câu hỏi đặt ra - sự khác biệt giữa Vai trò và ClusterRole là gì? Sự khác biệt là ClusterRole hoạt động cho tất cả các không gian tên, không giống như Vai trò và Vai trò thông thường, chỉ hoạt động cho một không gian tên chuyên biệt. Bạn có thể định cấu hình chính sách cho toàn bộ cụm và tất cả các không gian tên hoặc được cá nhân hóa cho từng không gian tên riêng lẻ.
Điều đáng nói là RBAC giải quyết được một vấn đề lớn khác. Thật không may, nhiều người phàn nàn rằng Helm không phải là chế độ đa nhiệm (không hỗ trợ chế độ đa nhiệm). Nếu một số nhóm sử dụng một cụm và sử dụng Helm thì về cơ bản là không thể thiết lập chính sách và giới hạn quyền truy cập của họ trong cụm này vì có một tài khoản dịch vụ nhất định mà Helm chạy dưới đó và nó tạo ra tất cả tài nguyên trong cụm từ bên dưới nó , điều này đôi khi rất bất tiện. Điều này đúng - giống như chính tệp nhị phân, giống như quy trình, Helm Tiller không có khái niệm về đa nhiệm.
Tuy nhiên, có một cách tuyệt vời cho phép bạn chạy Tiller nhiều lần trong một cụm. Không có vấn đề gì với điều này, Tiller có thể được khởi chạy ở mọi không gian tên. Do đó, bạn có thể sử dụng RBAC, Kubeconfig làm bối cảnh và giới hạn quyền truy cập vào Helm đặc biệt.
Nó sẽ trông giống thế này.
Ví dụ: có hai Kubeconfig có ngữ cảnh dành cho các nhóm khác nhau (hai không gian tên): Nhóm X dành cho nhóm phát triển và cụm quản trị viên. Cụm quản trị có Tiller rộng riêng, nằm trong không gian tên hệ thống Kube, một tài khoản dịch vụ nâng cao tương ứng. Và một không gian tên riêng cho nhóm phát triển, họ sẽ có thể triển khai dịch vụ của mình vào một không gian tên đặc biệt.
Đây là một cách tiếp cận khả thi, Tiller không quá ham quyền lực đến mức ảnh hưởng lớn đến ngân sách của bạn. Đây là một trong những giải pháp nhanh chóng.
Vui lòng định cấu hình Tiller riêng biệt và cung cấp ngữ cảnh cho Kubeconfig cho nhóm, cho một nhà phát triển cụ thể hoặc cho môi trường: Dev, Staging, Production (có thể nghi ngờ rằng mọi thứ sẽ nằm trên cùng một cụm, tuy nhiên, điều này có thể được thực hiện).
Tiếp tục câu chuyện của chúng ta, hãy chuyển từ RBAC và nói về Bản đồ cấu hình.
Bản đồ cấu hình
Helm sử dụng ConfigMaps làm kho lưu trữ dữ liệu. Khi chúng ta nói về kiến trúc, không có cơ sở dữ liệu nào có thể lưu trữ thông tin về các bản phát hành, cấu hình, quá trình khôi phục, v.v. ConfigMaps được sử dụng cho việc này.
Vấn đề chính với ConfigMaps đã được biết - về nguyên tắc chúng không an toàn; không thể lưu trữ dữ liệu nhạy cảm. Chúng ta đang nói về mọi thứ không nên vượt ra ngoài dịch vụ, chẳng hạn như mật khẩu. Cách cơ bản nhất đối với Helm lúc này là chuyển từ sử dụng ConfigMaps sang bí mật.
Việc này được thực hiện rất đơn giản. Ghi đè cài đặt Máy xới và chỉ định rằng bộ lưu trữ sẽ là bí mật. Sau đó, với mỗi lần triển khai, bạn sẽ không nhận được Bản đồ cấu hình mà là một bí mật.
Bạn có thể lập luận rằng bản thân bí mật là một khái niệm xa lạ và không an toàn lắm. Tuy nhiên, điều đáng hiểu là chính các nhà phát triển Kubernetes đang làm việc này. Bắt đầu từ phiên bản 1.10, tức là. Từ khá lâu rồi, ít nhất là trên các đám mây công cộng, người ta đã có thể kết nối bộ lưu trữ chính xác để lưu trữ bí mật. Nhóm hiện đang tìm cách phân phối tốt hơn quyền truy cập vào các bí mật, nhóm riêng lẻ hoặc các thực thể khác.
Tốt hơn là chuyển Storage Helm sang các bí mật và đến lượt chúng, chúng được bảo mật tập trung.
Tất nhiên là nó sẽ vẫn còn giới hạn lưu trữ dữ liệu là 1 MB. Helm ở đây sử dụng etcd làm bộ lưu trữ phân tán cho ConfigMaps. Và ở đó họ cho rằng đây là đoạn dữ liệu phù hợp để nhân rộng, v.v. Có một cuộc thảo luận thú vị về vấn đề này trên Reddit, tôi khuyên bạn nên tìm cuốn sách thú vị này để đọc vào cuối tuần hoặc đọc đoạn trích .
Kho lưu trữ biểu đồ
Biểu đồ dễ bị tổn thương nhất về mặt xã hội và có thể trở thành nguồn gốc của “Người ở giữa”, đặc biệt nếu bạn sử dụng giải pháp chứng khoán. Trước hết, chúng ta đang nói về các kho lưu trữ được hiển thị qua HTTP.
Bạn chắc chắn cần phải hiển thị Helm Repo qua HTTPS - đây là lựa chọn tốt nhất và không tốn kém.
Chú ý đến cơ chế chữ ký biểu đồ. Công nghệ này đơn giản như địa ngục. Đây chính là thứ bạn sử dụng trên GitHub, một máy PGP thông thường có khóa chung và khóa riêng. Hãy thiết lập và đảm bảo rằng, có các khóa cần thiết và ký mọi thứ, rằng đây thực sự là biểu đồ của bạn.
Ngoài ra, Khách hàng Helm hỗ trợ TLS (không phải theo nghĩa HTTP phía máy chủ mà là TLS chung). Bạn có thể sử dụng khóa máy chủ và máy khách để liên lạc. Thành thật mà nói, tôi không sử dụng cơ chế như vậy vì tôi không thích chứng chỉ lẫn nhau. Về cơ bản, - công cụ chính để thiết lập Helm Repo cho Helm 2 - cũng hỗ trợ xác thực cơ bản. Bạn có thể sử dụng xác thực cơ bản nếu thuận tiện và yên tĩnh hơn.
Ngoài ra còn có một plugin , cho phép bạn lưu trữ Kho lưu trữ biểu đồ trên Google Cloud Storage. Điều này khá thuận tiện, hoạt động tốt và khá an toàn vì tất cả các cơ chế được mô tả đều được tái chế.
Nếu bạn bật HTTPS hoặc TLS, sử dụng mTLS và bật xác thực cơ bản để giảm thiểu rủi ro hơn nữa, bạn sẽ có được kênh liên lạc an toàn với Helm CLI và Chart Repo.
API gRPC
Bước tiếp theo rất quan trọng - để bảo mật Tiller, nằm trong cụm và một mặt là máy chủ, mặt khác nó tự truy cập vào các thành phần khác và cố gắng giả vờ là ai đó.
Như tôi đã nói, Tiller là một dịch vụ cung cấp gRPC, ứng dụng khách Helm truy cập nó thông qua gRPC. Tất nhiên, theo mặc định, TLS bị tắt. Tại sao điều này được thực hiện là một câu hỏi gây tranh cãi, đối với tôi, có vẻ như nó đơn giản hóa việc thiết lập ngay từ đầu.
Để sản xuất và thậm chí là dàn dựng, tôi khuyên bạn nên bật TLS trên gRPC.
Theo tôi, không giống như mTLS dành cho biểu đồ, điều này phù hợp ở đây và được thực hiện rất đơn giản - tạo cơ sở hạ tầng PQI, tạo chứng chỉ, khởi chạy Tiller, chuyển chứng chỉ trong quá trình khởi tạo. Sau này, bạn có thể thực thi tất cả các lệnh Helm, tự hiển thị chứng chỉ và khóa riêng đã được tạo.
Bằng cách này, bạn sẽ tự bảo vệ mình khỏi mọi yêu cầu gửi đến Tiller từ bên ngoài cụm.
Vì vậy, chúng tôi đã bảo mật kênh kết nối với Tiller, chúng tôi đã thảo luận về RBAC và điều chỉnh các quyền của máy chủ Kubernetes apiserver, giảm miền mà nó có thể tương tác.
Mũ bảo vệ
Chúng ta hãy nhìn vào sơ đồ cuối cùng. Đó là cùng một kiến trúc với các mũi tên giống nhau.
Bây giờ tất cả các kết nối có thể được vẽ một cách an toàn bằng màu xanh lá cây:
- đối với Chart Repo, chúng tôi sử dụng TLS hoặc mTLS và xác thực cơ bản;
- mTLS dành cho Tiller và được hiển thị dưới dạng dịch vụ gRPC với TLS, chúng tôi sử dụng chứng chỉ;
- cụm sử dụng tài khoản dịch vụ đặc biệt với Vai trò và Ràng buộc vai trò.
Chúng tôi đã bảo mật đáng kể cụm này, nhưng ai đó thông minh đã nói:
“Chỉ có thể có một giải pháp an toàn tuyệt đối - một chiếc máy tính đã tắt, được đặt trong một hộp bê tông và được binh lính canh gác.”
Có nhiều cách khác nhau để thao tác dữ liệu và tìm các vectơ tấn công mới. Tuy nhiên, tôi tin tưởng rằng những khuyến nghị này sẽ đạt được tiêu chuẩn cơ bản của ngành về an toàn.
tiền thưởng
Phần này không liên quan trực tiếp đến bảo mật nhưng cũng sẽ hữu ích. Tôi sẽ chỉ cho bạn một số điều thú vị mà ít người biết. Ví dụ: cách tìm kiếm biểu đồ - chính thức và không chính thức.
Trong kho lưu trữ Hiện có khoảng 300 biểu đồ và hai luồng: ổn định và ươm tạo. Bất cứ ai đóng góp đều biết rõ việc đi từ vườn ươm đến chuồng ổn định khó khăn như thế nào và việc bay ra khỏi chuồng dễ dàng như thế nào. Tuy nhiên, đây không phải là công cụ tốt nhất để tìm kiếm biểu đồ cho Prometheus và bất kỳ thứ gì khác mà bạn thích, vì một lý do đơn giản - nó không phải là một cổng nơi bạn có thể tìm kiếm các gói một cách thuận tiện.
Nhưng có một dịch vụ , điều này giúp việc tìm biểu đồ trở nên thuận tiện hơn nhiều. Quan trọng nhất, có nhiều kho lưu trữ bên ngoài hơn và gần 800 bùa có sẵn. Ngoài ra, bạn có thể kết nối kho lưu trữ của mình nếu vì lý do nào đó mà bạn không muốn gửi biểu đồ của mình về trạng thái ổn định.
Hãy thử hub.helm.sh và cùng nhau phát triển nó. Dịch vụ này nằm trong dự án Helm và bạn thậm chí có thể đóng góp cho giao diện người dùng của nó nếu bạn là nhà phát triển giao diện người dùng và chỉ muốn cải thiện giao diện.
Tôi cũng muốn thu hút sự chú ý của bạn đến Tích hợp API nhà môi giới dịch vụ mở. Nghe có vẻ rườm rà và không rõ ràng nhưng nó giải quyết được vấn đề mà ai cũng gặp phải. Hãy để tôi giải thích bằng một ví dụ đơn giản.
Có một cụm Kubernetes mà chúng tôi muốn chạy một ứng dụng cổ điển - WordPress. Nói chung, cần có cơ sở dữ liệu để có đầy đủ chức năng. Có nhiều giải pháp khác nhau, chẳng hạn như bạn có thể khởi chạy dịch vụ đầy đủ trạng thái của riêng mình. Việc này không thuận tiện lắm nhưng nhiều người vẫn làm.
Những người khác, như chúng tôi tại Chainstack, sử dụng cơ sở dữ liệu được quản lý như MySQL hoặc PostgreSQL cho máy chủ của họ. Đó là lý do tại sao cơ sở dữ liệu của chúng tôi được đặt ở đâu đó trên đám mây.
Nhưng có một vấn đề nảy sinh: chúng tôi cần kết nối dịch vụ của mình với cơ sở dữ liệu, tạo phiên bản cơ sở dữ liệu, chuyển thông tin xác thực và bằng cách nào đó quản lý nó. Tất cả điều này thường được thực hiện thủ công bởi quản trị viên hệ thống hoặc nhà phát triển. Và không có vấn đề gì khi có ít ứng dụng. Khi có rất nhiều trong số họ, bạn cần một sự kết hợp. Có một chiếc máy gặt như vậy - đó là Nhà môi giới dịch vụ. Nó cho phép bạn sử dụng một plugin đặc biệt cho cụm đám mây công cộng và đặt hàng tài nguyên từ nhà cung cấp thông qua Nhà môi giới, như thể đó là một API. Để làm điều này, bạn có thể sử dụng các công cụ Kubernetes gốc.
Nó rất đơn giản. Ví dụ: Bạn có thể truy vấn MySQL được quản lý trong Azure với tầng cơ sở (có thể đặt cấu hình tầng này). Sử dụng API Azure, cơ sở dữ liệu sẽ được tạo và chuẩn bị sử dụng. Bạn không cần phải can thiệp vào việc này, plugin sẽ chịu trách nhiệm về việc này. Ví dụ: OSBA (plugin Azure) sẽ trả lại thông tin xác thực cho dịch vụ và chuyển nó cho Helm. Bạn sẽ có thể sử dụng WordPress với MySQL trên nền tảng đám mây, hoàn toàn không phải xử lý cơ sở dữ liệu được quản lý và không phải lo lắng về các dịch vụ đầy đủ trạng thái bên trong.
Có thể nói rằng Helm hoạt động như một chất kết dính, một mặt cho phép bạn triển khai các dịch vụ, mặt khác tiêu thụ tài nguyên của các nhà cung cấp đám mây.
Bạn có thể viết plugin của riêng mình và sử dụng toàn bộ câu chuyện này tại chỗ. Sau đó, bạn sẽ chỉ có plugin của riêng mình cho nhà cung cấp Đám mây của công ty. Tôi khuyên bạn nên thử phương pháp này, đặc biệt nếu bạn có quy mô lớn và muốn nhanh chóng triển khai nhà phát triển, dàn dựng hoặc toàn bộ cơ sở hạ tầng cho một tính năng. Điều này sẽ giúp hoạt động vận hành hoặc DevOps của bạn trở nên dễ dàng hơn.
Một phát hiện khác mà tôi đã đề cập là plugin helm-gcs, cho phép bạn sử dụng Google-buckets (bộ lưu trữ đối tượng) để lưu trữ biểu đồ Helm.
Bạn chỉ cần bốn lệnh để bắt đầu sử dụng nó:
- cài đặt plugin;
- bắt đầu nó;
- đặt đường dẫn đến nhóm nằm trong gcp;
- xuất bản biểu đồ theo cách tiêu chuẩn.
Điều thú vị là phương thức gcp gốc sẽ được sử dụng để ủy quyền. Bạn có thể sử dụng tài khoản dịch vụ, tài khoản nhà phát triển, bất cứ điều gì bạn muốn. Nó rất thuận tiện và không tốn chi phí vận hành. Nếu bạn cũng như tôi, đề cao triết lý opsless thì điều này sẽ rất thuận tiện, đặc biệt là đối với các đội nhỏ.
Giải pháp thay thế
Helm không phải là giải pháp quản lý dịch vụ duy nhất. Có rất nhiều câu hỏi xung quanh nó, có lẽ đó là lý do tại sao phiên bản thứ ba lại xuất hiện nhanh đến vậy. Tất nhiên có những lựa chọn thay thế.
Đây có thể là các giải pháp chuyên biệt, ví dụ như Ksonnet hoặc Metaparticle. Bạn có thể sử dụng các công cụ quản lý cơ sở hạ tầng cổ điển của mình (Ansible, Terraform, Chef, v.v.) cho các mục đích tương tự mà tôi đã nói.
Cuối cùng cũng có một giải pháp , sự nổi tiếng của họ ngày càng tăng.
Operator Framework là lựa chọn thay thế Helm hàng đầu để xem xét.
Nó có nguồn gốc từ CNCF và Kubernetes nhiều hơn, nhưng rào cản gia nhập cao hơn nhiều, bạn cần lập trình nhiều hơn và mô tả các bảng kê khai ít hơn.
Có nhiều tiện ích bổ sung khác nhau, chẳng hạn như Bản nháp, Giàn giáo. Chúng làm cho cuộc sống dễ dàng hơn rất nhiều, chẳng hạn như chúng đơn giản hóa chu trình gửi và khởi chạy Helm để các nhà phát triển triển khai môi trường thử nghiệm. Tôi sẽ gọi họ là những người trao quyền.
Đây là biểu đồ trực quan về vị trí của mọi thứ.
Trên trục x là mức độ kiểm soát cá nhân của bạn đối với những gì đang xảy ra, trên trục y là mức độ tự nhiên của Kubernetes. Helm phiên bản 2 rơi vào đâu đó ở giữa. Ở phiên bản 3, không nhiều lắm nhưng cả khả năng kiểm soát và mức độ nguyên bản đều đã được cải thiện. Các giải pháp ở cấp độ Ksonnet vẫn còn kém hơn ngay cả Helm 2. Tuy nhiên, chúng đáng để xem xét để biết trên thế giới này còn có những gì. Tất nhiên, trình quản lý cấu hình sẽ nằm dưới sự kiểm soát của bạn, nhưng nó hoàn toàn không có nguồn gốc từ Kubernetes.
Operator Framework hoàn toàn có nguồn gốc từ Kubernetes và cho phép bạn quản lý nó một cách tinh tế và cẩn thận hơn nhiều (nhưng hãy nhớ về cấp độ đầu vào). Đúng hơn, điều này phù hợp cho một ứng dụng chuyên biệt và tạo ra khả năng quản lý cho nó, thay vì một máy thu hoạch hàng loạt để đóng gói một số lượng lớn ứng dụng bằng Helm.
Bộ mở rộng chỉ cần cải thiện khả năng kiểm soát một chút, bổ sung quy trình làm việc hoặc cắt giảm các đường dẫn CI/CD.
Tương lai của Helm
Tin vui là Helm 3 sắp ra mắt. Phiên bản alpha của Helm 3.0.0-alpha.2 đã được phát hành, bạn có thể dùng thử. Nó khá ổn định, nhưng chức năng vẫn còn hạn chế.
Tại sao bạn cần Helm 3? Trước hết đây là câu chuyện về sự biến mất của Tiller, như một thành phần. Như bạn đã hiểu, đây là một bước tiến lớn, bởi vì từ quan điểm về tính bảo mật của kiến trúc, mọi thứ đều được đơn giản hóa.
Khi Helm 2 được tạo ra, vào khoảng thời gian Kubernetes 1.8 hoặc thậm chí sớm hơn, nhiều khái niệm vẫn còn non nớt. Ví dụ: khái niệm CRD hiện đang được triển khai tích cực và Helm sẽ sử dụng CRDđể lưu trữ các cấu trúc. Chỉ có thể sử dụng máy khách và không duy trì phần máy chủ. Theo đó, hãy sử dụng các lệnh Kubernetes gốc để làm việc với các cấu trúc và tài nguyên. Đây là một bước tiến lớn.
Sẽ xuất hiện hỗ trợ cho kho lưu trữ OCI gốc (Sáng kiến container mở). Đây là một sáng kiến lớn và Helm quan tâm chủ yếu đến việc đăng biểu đồ của mình. Ví dụ, Docker Hub hỗ trợ nhiều tiêu chuẩn OCI. Tôi không đoán, nhưng có lẽ các nhà cung cấp kho lưu trữ Docker cổ điển sẽ bắt đầu cho bạn cơ hội lưu trữ biểu đồ Helm của mình.
Câu chuyện gây tranh cãi đối với tôi là hỗ trợ lua, như một công cụ tạo khuôn mẫu để viết tập lệnh. Tôi không phải là người hâm mộ Lua nhiều nhưng đây sẽ là một tính năng hoàn toàn tùy chọn. Tôi đã kiểm tra điều này 3 lần - việc sử dụng Lua sẽ không cần thiết. Do đó, những ai muốn có thể sử dụng Lua, những người thích cờ vây, hãy tham gia trại khổng lồ của chúng tôi và sử dụng go-tmpl cho việc này.
Cuối cùng, điều tôi chắc chắn đã thiếu là sự xuất hiện lược đồ và xác thực kiểu dữ liệu. Sẽ không còn vấn đề gì với int hoặc chuỗi nữa, không cần phải bọc số 0 trong dấu ngoặc kép. Một lược đồ JSONS sẽ xuất hiện cho phép bạn mô tả rõ ràng điều này cho các giá trị.
Sẽ được làm lại rất nhiều mô hình hướng sự kiện. Nó đã được mô tả về mặt khái niệm. Nhìn vào nhánh Helm 3, bạn sẽ thấy có bao nhiêu sự kiện, hook cũng như những thứ khác đã được thêm vào, điều này sẽ đơn giản hóa rất nhiều và mặt khác, thêm quyền kiểm soát đối với các quy trình triển khai và phản ứng đối với chúng.
Helm 3 sẽ đơn giản hơn, an toàn hơn và thú vị hơn, không phải vì chúng ta không thích Helm 2 mà vì Kubernetes đang trở nên tiên tiến hơn. Theo đó, Helm có thể sử dụng sự phát triển của Kubernetes và tạo ra những nhà quản lý xuất sắc cho Kubernetes trên đó.
Một tin tốt nữa là Alexander Khayorov sẽ nói với bạn, Hãy để chúng tôi nhắc bạn rằng hội nghị về tích hợp các quy trình phát triển, thử nghiệm và vận hành sẽ được tổ chức tại Moscow Ngày 30 tháng 1 và ngày XNUMX tháng XNUMX. Bạn vẫn có thể làm điều đó cho đến ngày 20 tháng XNUMX và cho chúng tôi biết về trải nghiệm của bạn với giải pháp nhiệm vụ của phương pháp DevOps.
Theo dõi các điểm kiểm tra hội nghị và tin tức tại и .
Nguồn: www.habr.com