- Glasskube là trình quản lý gói mã nguồn mở cho Kubernetes, được giới thiệu là giúp việc triển khai, cập nhật và cấu hình nhanh hơn 20 lần so với các công cụ như Helm hay Kustomize
- Người dùng có thể triển khai gói qua UI của Glasskube, CLI, hoặc theo cách GitOps, lấy cảm hứng từ sự đơn giản của Homebrew và npm
- Các tính năng chính gồm cài gói từ UI mà không cần tìm kho Helm, nhập cấu hình an toàn theo kiểu dữ liệu, chèn giá trị giữa các gói, cài đặt có nhận biết phụ thuộc, và cập nhật an toàn đã được kiểm thử trước
- Mọi gói Glasskube đều được quản lý dưới dạng tài nguyên tùy chỉnh và có thể xử lý bằng GitOps, đồng thời hỗ trợ nhiều kho và triển khai private package
- Hiện hỗ trợ Kubernetes Dashboard, cert-manager, Ingress-NGINX Controller, Kube Prometheus Stack, Cloud Native PG..., và bản beta có thể cài bằng Homebrew
Vấn đề quản lý gói Kubernetes mà Glasskube muốn giải quyết
- Glasskube là trình quản lý gói mã nguồn mở cho Kubernetes
- Dự án giới thiệu rằng việc triển khai, cập nhật và cấu hình gói trên Kubernetes có thể nhanh hơn 20 lần so với các công cụ như Helm hay Kustomize
- Lấy cảm hứng từ sự đơn giản của Homebrew và npm, người dùng có thể chọn một trong các cách sau
- UI của Glasskube
- CLI của Glasskube
- Triển khai gói trực tiếp thông qua GitOps
- Bối cảnh phát triển đến từ hơn 5 năm làm việc trong hệ sinh thái Kubernetes và liên tục gặp khó khăn với quản lý gói, cấu hình và triển khai
- Trong quy trình hiện có, nhóm phải tốn nhiều thời gian tạo template và viết tài liệu cho các lệnh và khái niệm khó hiểu
- Các công cụ như Homebrew, apt, dnf dễ dùng hơn và ít gây rắc rối hơn, trở thành đối chiếu khi phát triển Glasskube
Luồng cài đặt và cấu hình
brew install glasskube/tap/glasskube
- Các tùy chọn cài đặt khác có trong installation guide
- Sau khi cài CLI, chạy lệnh sau để cài các thành phần cần thiết lên cluster
glasskube bootstrap
- Khi bootstrap cluster hoàn tất, có thể khởi chạy UI của trình quản lý gói
glasskube serve
- Lệnh này sẽ mở
http://localhost:8580 trong trình duyệt mặc định, nơi người dùng có thể duyệt và cài các gói khả dụng
Tính năng UI, cấu hình và quản lý phụ thuộc
- UI của Glasskube tập hợp mọi gói về một nơi, cho phép người dùng cài gói lên cluster mà không cần tự tìm kho Helm riêng
- Cấu hình gói có thể được thiết lập bằng giá trị đầu vào an toàn theo kiểu dữ liệu qua UI hoặc bảng câu hỏi CLI tương tác
- Có thể dễ dàng chèn giá trị từ các gói khác, ConfigMap và Secret
- Dự án đưa ra hướng tiếp cận không dùng các tệp
values.yaml thiếu kiểu dữ liệu và thiếu tài liệu
- Quản lý phụ thuộc cho phép các gói Glasskube được sử dụng và tham chiếu bởi nhiều gói khác
- Các gói phụ thuộc được cài vào đúng namespace
- README mô tả điều này như kiểu “umbrella chart lẽ ra nên hoạt động như vậy ngay từ đầu”
Cập nhật, GitOps và hỗ trợ kho
- Cập nhật gói cho phép xem trước pending update đến phiên bản mong muốn và thực hiện chỉ với một cú nhấp hoặc lệnh CLI
- Mọi bản cập nhật đều được kiểm thử trước bằng bộ test của Glasskube
- Có thể để lại phản hồi và bình luận về gói tại GitHub discussions hoặc ngay trong UI của Glasskube
- Tích hợp GitOps dựa trên cách quản lý mọi gói Glasskube như tài nguyên tùy chỉnh
- Tích hợp Renovate cũng đang được triển khai, issue liên quan nằm tại renovatebot/renovate#29322
- Có thể sử dụng nhiều kho và private package
- Có thể dùng để triển khai các gói dịch vụ nội bộ trong công ty
- Dự án nêu ra kịch bản giúp lập trình viên dễ dàng thiết lập các dịch vụ nội bộ luôn ở trạng thái mới nhất
Kiến trúc cài đặt gói
- Luồng
glasskube install [package] có cấu trúc trong đó UI hoặc CLI sử dụng Client để đồng thời làm việc với kho gói và Kubernetes API
- UI kết nối với Client qua máy chủ cục bộ
http://localhost:8580
- CLI kết nối với Client thông qua cobra CLI
- Trước tiên, Client kiểm tra Package Repo để xác thực gói
- Sau khi xác thực, nó tạo tài nguyên tùy chỉnh
Package trên Kubernetes API
- Bên trong cluster,
PackageController và PackageInfoController thực hiện reconcile
PackageController reconcile Package và tạo PackageInfo nếu cầnPackageInfoController cập nhật package manifest từ kho gói- Manifest đã cập nhật được phản ánh vào
PackageInfo
- Sau đó
PackageController triển khai gói lên Kubernetes
- Kubernetes trả trạng thái gói về cho Client
Các gói được hỗ trợ và thông tin dự án
- Glasskube hiện đã hỗ trợ nhiều gói
- Danh sách đầy đủ các gói đang hỗ trợ và sắp hỗ trợ có tại glasskube.dev/packages
- Dự án liên quan có Glasskube Apps Operator
glasskube/operator
- Có thể gửi vấn đề, bug và yêu cầu tính năng qua Discord hoặc GitHub Issues
- Glasskube được phát hành theo giấy phép Apache 2.0
1 bình luận
Ý kiến trên Hacker News
Đây có thể là một bước đi đúng hướng, nhưng hiện tại vấn đề lớn nhất của việc quản lý gói trên Kubernetes dường như khó có thể được giải quyết chỉ bằng một trình quản lý gói
Điều khó chịu nhất trong thực tế là YAML lồng nhau chồng qua nhiều lớp và kết quả thì không thể đoán trước
Ví dụ, ArgoCD ApplicationSet tạo ra nhiều Application, các Application đó render chart Helm, và bên trong các chart ấy lại có các CRD được những operator tùy ý như Strimzi, Grafana, Vector sử dụng
YAML có cú pháp nghèo nàn và cũng không có tiêu chuẩn cho việc render template, nên khi thay đổi ở tầng trên cùng thì gần như không thể biết chính xác YAML nào thực sự được đưa vào Kubernetes API
Kết cục là mỗi tháng lại phải thử-sai, triển khai blue-green tốn kém, và hàng trăm phút để debug
Tôi nghĩ hướng đi đúng là hỗ trợ ngôn ngữ lập trình đúng nghĩa
Lý tưởng nhất là cần một hệ thống kiểu tĩnh không Turing-complete và đảm bảo kết thúc, và một dạng giống Starlark có kiểu có vẻ phù hợp
Chúng tôi muốn glasskube[bot] đăng bình luận về diff chính xác của các resource thực sự sẽ thay đổi trên mọi cluster gắn với pull request GitOps
Diff này được thực hiện bởi controller chạy bên trong cluster
Có thể xem nó như phân tích của codecov, nhưng chỉ dành cho thay đổi resource
Có vẻ là một cách tiếp cận thú vị cho quản lý gói, và trông khá ổn cho những thứ như cluster kiểu Homebrew
Dù vậy, cá nhân tôi vẫn thích tổ hợp helmfile + Renovate + pipeline, nếu chỉ để giữ tính nhất quán trong repository thôi cũng đáng
Ví dụ, nút
update allnghe khá đáng sợ đối với những cluster có ý nghĩa thực sựNhưng với các dự án cá nhân thì đây vẫn là một công cụ rất hay
Package controller khá giống Tiller của Helm ngày trước, mà đó từng là một vấn đề bảo mật lớn ở nhiều công ty nên đã bị loại bỏ trong Helm 3 và chuyển sang xử lý phía client dựa trên configmap; tôi tò mò dự án này sẽ vượt qua vấn đề đó như thế nào
Bạn cũng có thể cấu hình bằng các cờ
--dry-runvà--output yamltừ CLI rồi đưa vào GitChúng tôi cũng đang làm việc trên pull request hỗ trợ Renovate cập nhật gói: https://github.com/renovatebot/renovate/issues/29322
Helm 3 giờ là công cụ phía client nên bản thân nó không thể tự áp đặt RBAC
OLM đã đưa vào Operator Groups(https://olm.operatorframework.io/docs/advanced-tasks/operato...) để cung cấp quyền hạn ở cấp operator
Có thể đưa thứ tương tự vào gói Glasskube, và dù bản thân Glasskube vẫn sẽ cần quyền khá mạnh, vẫn có thể giới hạn phạm vi gói và thêm quyền chi tiết hơn
Theo truyền thống, gói ứng dụng là các tệp nhị phân bất biến được ghim phiên bản có bao gồm các bước trước và sau khi cài đặt, được build cho một nền tảng và các phụ thuộc cụ thể, và khả năng cấu hình khi cài đặt là cực kỳ hạn chế
Lý do các gói hoạt động tốt là vì chúng được thiết kế cho những môi trường rất cụ thể và giảm thiểu tối đa những gì có thể thay đổi khi cài đặt
Dù vậy, các gói hệ điều hành vẫn liên tục cần lượng lớn công việc kiểm thử, phát triển và vá lỗi ngay cả trong các điều kiện hẹp đó
Việc gói bạn cài đặt lúc này có vẻ dễ dàng là vì có thể đã có hàng trăm giờ công được bỏ ra cho nền tảng hiện tại, các thành phần hiện tại và các phiên bản hiện tại
“Gói” của Kubernetes thực ra không phải là gói, mà gần hơn với một bó chỉ dẫn về các thành phần sẽ được cài đặt và cấu hình, và thường còn bao gồm nhiều bó ứng dụng tách biệt
Sự khác biệt này thể hiện ở hai điểm: “gói” K8s có định nghĩa rất lỏng lẻo nên biến động lớn, và đủ mọi người tạo ra chúng theo đủ mọi cách, đồng thời đưa ra đủ loại giả định về trạng thái của hệ thống đích khi cài đặt
Để một “gói” Kubernetes hoạt động, nhiều lớp phụ thuộc và cấu hình phải khớp với nhau
Phiên bản API K8s, cách các thành phần K8s được cài đặt và chạy, ACL, việc không có sẵn các thành phần hiện hữu có thể xung đột, việc ghim phiên bản của các thành phần và container mà gói cài đặt cùng khả năng tương thích với những thứ khác trong cluster, cũng như cấu hình người dùng — tất cả đều phải khớp
Việc nâng cấp cũng hỗn loạn tương tự vì không có khái niệm cây phát hành ổn định hay rolling release, và nó giống như cài một tệp
.deb,.rpm,.dmgbất kỳ vào hệ điều hành rồi hy vọng mọi thứ sẽ ổnHiện nay không có thứ gì làm được tất cả điều này
Để đóng gói Kubernetes mượt như đóng gói nhị phân theo từng nền tảng, cần cả một cộng đồng maintainer cùng cách tiếp cận rolling release như Homebrew hoặc các nhánh phát hành phiên bản ổn định
Cuối cùng sẽ cần một dự án như ArtifactHub hoặc Homebrew quản lý mọi gói theo một cách thống nhất, nhưng đó là việc rất lớn và có vẻ hoàn toàn không sinh lời
Đây là cấu trúc nhằm lưu toàn bộ cập nhật ở trung tâm và kiểm thử bằng workflow CI/CD để người dùng có thể hưởng các bản nâng cấp mượt mà đã được kiểm thử
Người dùng cũng có thể tự host kho riêng và các gói riêng, nhưng về cơ bản nhóm muốn trực tiếp cung cấp một tập hợp gói có định hướng rõ ràng
Họ cũng đã nghĩ đến việc build phù hợp với các phiên bản Kubernetes hay môi trường khác nhau, và điều đó có lẽ sẽ cần thiết vào một lúc nào đó nếu muốn đưa thêm cấu hình vào ngay từ giai đoạn build
Không chắc liệu trình quản lý gói K8s có thể đơn giản như brew hay apt hay không
Đặc biệt vì giá trị thay đổi theo từng môi trường đích, và gần như mọi người dùng đều có môi trường “snowflake” riêng biệt
Tôi không hứng thú với việc dùng prompt kiểu REPL hay web UI để thiết lập các giá trị đó
Nỗi đau cốt lõi vẫn chưa được giải quyết: viết Helm chart rất khổ sở, phải quản lý giá trị theo từng môi trường, và mong là không phải nối giá trị giữa các chart với nhau
Các platform team đang xây dựng nền tảng dành cho nhà phát triển nội bộ để chuẩn hóa hơn nữa cấu hình Kubernetes trên toàn đội và toàn cluster, đồng thời chỉ cho phép nhà phát triển thực hiện những chỉnh sửa nhỏ
Theo kinh nghiệm của tôi, những cấu hình chắp vá kiểu này cần được giảm bớt, và đó cũng là một trong những lý do Glasskube được tạo ra ngay từ đầu
Tôi đồng ý 100% rằng viết Helm chart rất khổ sở, và chúng tôi muốn thay đổi điều đó trong tương lai
Các gói Glasskube vẫn có thể cấu hình, nhưng cung cấp các giá trị mặc định có ý nghĩa
Có thể dễ dàng tham chiếu giá trị cấu hình của gói khác trong Glasskube, nên không cần phải cung cấp cùng một giá trị nhiều lần
Tôi xây rất nhiều Kubernetes operator và thường xuyên xử lý các vấn đề của Helm và OLM
Trong tài liệu có viết rằng “Glasskube xử lý nâng cấp CRD để CR và operator không bị lệch nhau”, nhưng dù tìm “CRD” trong tài liệu cũng không thấy kết quả cụ thể nào
Đây là một trong những nỗi đau lớn nhất tôi gặp với Helm hiện nay, nên tôi muốn biết liệu các bạn có thể chia sẻ kế hoạch không
[1] <https://stackable.tech/en/>
[2] <https://www.youtube.com/watch?v=Q8OSYOgBdCc>
Việc này được xử lý thông qua Manifest hoặc helm-controller
Tài liệu sẽ được cập nhật
Tôi cho rằng Kubernetes bị giới hạn một cách căn bản bởi mô hình operator quá đơn giản
Tôi thích toàn bộ ý tưởng này, nhưng việc rút gọn toàn bộ mô hình thành “trạng thái hiện tại, trạng thái mong muốn, hành động tiếp theo” thực chất là bất khả thi
Rốt cuộc toàn bộ workflow lại bị dồn vào logic hành động tiếp theo, và vì có quá nhiều operator cùng nhìn vào một trạng thái hệ thống nên rất khó biết các thành phần khác nhau sẽ tương tác với nhau như thế nào
Vấn đề của Helm là một trường hợp con của vấn đề lớn hơn này
Nói ví von thì nó giống các vấn đề mà lập trình frontend gặp phải với DOM
Nếu áp dụng mô hình virtual DOM/reducer như React thì sẽ giúp rất nhiều trong việc giải quyết các vấn đề này
Có trạng thái, mục tiêu, và các nhiễu động trên đường tới mục tiêu; nếu muốn một công cụ mạnh và linh hoạt thì đây là mức trừu tượng phù hợp
Vấn đề là đặc tính vật lý và cách triển khai của máy móc tạo ra khác biệt quá lớn, đến mức chi phí để ảo hóa hoặc mô phỏng điều đó một cách có ý nghĩa là quá cao
Vì vậy, thay vào đó người ta xác minh xem trạng thái cấu hình có hoạt động trên một tập con của cấu trúc vật lý hay không
Cách làm là có các môi trường
dev,staging,prod, rồi dùng triển khai xanh lam/xanh lục, phân tích canary, rollout từng phần, v.v.Nếu cần các công cụ như thế này để dùng K8s thì có lẽ tốt hơn nên dùng một giải pháp khác
Kubernetes không được tạo ra để dùng mà không có kiến thức nền, và nó rất khó
Trừ khi tạo ra một PaaS hoàn chỉnh, rất khó thoát khỏi sự phức tạp đó
Có vẻ công cụ này đang đi sai hướng về mặt marketing
Nó không liên quan nhiều đến Helm
Với tôi, Helm chủ yếu không phải là trình quản lý gói mà là một ngôn ngữ template, và là cách để cấu hình và cài đặt vào cụm K8s thông qua kubeapps, Helm CLI và ArgoCD
Cách tiếp cận này cũng phá vỡ một mô hình IaC rất tốt
Vì sau khi bootstrap ArgoCD, tốt nhất là chỉ tham chiếu đến kho Git
Bản demo không cho thấy cách dùng các tính năng template như hỗ trợ
form, mà chỉ cho thấy những phần khácTôi vẫn có cảm giác Helm có vấn đề gì đó, nên thành thật mà nói tôi thích công cụ này, nhưng với cách tiếp cận hiện tại thì có lẽ nó sẽ thất bại
Các công ty lớn không cần công cụ này, nên sẽ khó đạt được mức độ chấp nhận đủ lớn
Kubeapps và Helm đều hoạt động tốt, và ngay cả khi nói là sẽ thay thế Helm thì có lẽ họ vẫn sẽ giữ hỗ trợ Helm trong thời gian dài
Vấn đề của Helm là độ phức tạp tăng lên khi chart ngày càng lớn
Cấu trúc dồn gần như mọi thứ vào một thư mục
templateslà rất lộn xộn, YAML thì không phù hợp để làm template, cònvalues.yamlthì trở nên quá lớnBạn có thể xem chi tiết về các tùy chọn cấu hình trong tài liệu cấu hình gói: https://glasskube.dev/docs/design/package-config/
Điểm bán hàng là nhanh hơn Helm thì không hấp dẫn lắm
Tôi chưa bao giờ cảm thấy vấn đề của Helm là tốc độ
Trông khá thú vị
Sẽ dễ hiểu hơn nếu có thể giải thích ngắn gọn nó ăn khớp hoặc được so sánh với các công cụ hiện có như ArgoCD như thế nào
Tôi đã xem video và một trong các công cụ cài đặt là Argo, nên rõ ràng nó đang chiếm một ngách khác, nhưng tôi vẫn chưa hiểu ngách đó là gì
Nó thường được dùng để các nhà phát triển xem tình trạng của các ứng dụng cốt lõi của công ty mà không cần quyền truy cập vào cụm
Glasskube tập trung vào các gói mà các ứng dụng cốt lõi đó phụ thuộc vào
Nó quản lý vòng đời của các thành phần hạ tầng, kiểm thử cập nhật và cung cấp lộ trình nâng cấp
Bạn cũng có thể đưa gói Glasskube vào kho GitOps và đồng bộ vào cụm bằng ArgoCD, phần còn lại sẽ do PackageController xử lý