Canine - Nền tảng mã nguồn mở giúp Kubernetes dễ dùng như Heroku

 (github.com/czhu12)
33 điểm bởi GN⁺ 2025-06-18 | 1 bình luận | Chia sẻ qua WhatsApp
  • Nền tảng mã nguồn mở được tạo ra để ngay cả lập trình viên solo cũng có thể dễ dàng sử dụng Kubernetes, mang lại sự tiện lợi tương tự Heroku
    • Hoạt động trong môi trường Docker và Docker Compose, có thể cài đặt và chạy bằng các lệnh đơn giản
  • Được phát triển nhằm giải quyết vấn đề chi phí IT tăng ngoài dự kiến từng gặp ở các startup trước đây
  • Theo đuổi sự đơn giản bằng cách chỉ phơi bày các thành phần cốt lõi như Ingress, Services, Deployments, Pods, CronJobs thay vì các tính năng phức tạp
  • Có thể triển khai gần như mọi ứng dụng mã nguồn mở thông qua Helm, đồng thời cũng có thể rời khỏi Canine bằng cách tải xuống cấu hình YAML
  • Bổ sung cả những tính năng Kubernetes không có sẵn mặc định như tài khoản, triển khai, dashboard, hướng tới một nền tảng phát triển phù hợp cho các nhóm nhỏ

Tổng quan

  • Canine là nền tảng triển khai Kubernetes mã nguồn mở, được thiết kế để giúp triển khai ứng dụng dễ dàng như Heroku
  • Chạy trên cụm Kubernetes riêng và khi cần có thể tải xuống cấu hình YAML để vận hành theo hướng phi tập trung
  • Chỉ phơi bày các tài nguyên cốt lõi như Ingress, Services, Deployments, Pods, CronJobs, mang lại trải nghiệm sử dụng đơn giản và trực quan

Nhận thức vấn đề: cấu trúc phức tạp và chi phí tăng vọt

  • Từ kinh nghiệm vận hành startup trước đây, chi phí IT đã tăng nhanh hơn rất nhiều so với dự tính
  • Chi phí chủ yếu tăng theo độ phức tạp của tổ chức và số lượng dịch vụ tích hợp, nhiều khi không liên quan đến lượng dùng server hay tài nguyên tính toán
  • Các công cụ bên thứ ba như sau tích lũy dần và khiến chi phí IT tăng mạnh:
    • Các công cụ dữ liệu như Looker, Redshift, Databricks, DBT Cloud, FiveTran
    • Các công cụ giám sát như Datadog, New Relic, Sentry
    • Các công cụ hạ tầng như Google Maps API, AWS
  • Dù một phần có thể thay thế bằng mã nguồn mở, họ vẫn ngần ngại áp dụng vì gánh nặng xây dựng hạ tầng vận hành như monitoring, health check, cảnh báo

Tiềm năng và giới hạn của Kubernetes

  • Kubernetes là nền tảng có thể mở rộng từ một node đơn lẻ đến hàng nghìn cluster, đồng thời được cung cấp như tiêu chuẩn trên hầu hết các cloud
  • Tuy nhiên với người mới và các nhóm nhỏ, nó vẫn bị xem là một hệ thống phức tạp và dễ hỏng
  • Đặc biệt, chỉ một sai sót như xóa CoreDNS cũng có thể khiến toàn bộ cluster ngừng hoạt động
  • Khi chi phí và độ phức tạp vận hành tích lũy, các PaaS trừu tượng hóa trước đây lại có thể trở thành lực cản

Đặc điểm của Canine

  • Chỉ phơi bày các tính năng tối thiểu cần thiết của Kubernetes để đảm bảo tính đơn giản và khả năng kiểm soát
  • Những phần còn thiếu được bổ sung bằng các tính năng như sau:
    • Quản lý tài khoản
    • Quản lý triển khai
    • Chạy script one-off đơn giản
    • Dashboard số liệu
  • Thông qua nền tảng triển khai trực quan, ngay cả người mới cũng có thể dễ dàng triển khai ứng dụng vào môi trường Kubernetes
  • Chỉ cần chuẩn bị Docker và Docker Compose là có thể cài đặt và chạy chỉ với một lệnh
  • Cung cấp môi trường quản trị dựa trên UI giúp giảm gánh nặng cấu hình và bảo trì phức tạp của Kubernetes
  • Có thể dễ dàng triển khai cả các ứng dụng mã nguồn mở như Sentry thông qua tích hợp Helm

Di chuyển và mức độ tự do

  • Canine được đặt lên trên Kubernetes hiện có để sử dụng, nên cũng dễ rời bỏ
  • Toàn bộ cấu hình có thể được tải xuống dưới dạng YAML, giúp việc chuyển sang nền tảng khác sau này trở nên dễ dàng

Tầm quan trọng và điểm khác biệt

  • So với các công cụ Kubernetes thông thường, nó cung cấp UI thân thiện hơn với người mới cùng quy trình cài đặt dễ dàng
  • Mang trải nghiệm sử dụng tương tự Heroku vào hệ sinh thái Kubernetes, từ đó hạ thấp đáng kể rào cản gia nhập
  • Với nền tảng mã nguồn mở, có thể mở rộng linh hoạt và cải tiến theo hướng cộng đồng
  • Được kỳ vọng mang lại hiệu quả lớn ở chỗ các nhóm phát triển nhỏ hoặc startup cũng có thể dễ dàng tận dụng các ưu điểm của Kubernetes
  • Có thể tự do sử dụng, phân phối và chỉnh sửa theo Apache 2.0 License

Bài viết liên quan

1 bình luận

 
GN⁺ 2025-06-18
Ý kiến trên Hacker News

  • Tôi là kiểu người luôn tìm kiếm giải pháp tốt hơn để tái tạo “trải nghiệm giống Heroku” trên máy chủ của mình, nên thực sự rất vui khi thấy dự án này
    Tài liệu Kubernetes của Canine cực kỳ dễ tiếp cận, có cảm giác thân thiện nhất trong số những gì tôi từng xem
    Khi đọc tài liệu tôi nảy ra thắc mắc: tôi đã hy vọng có thể dùng Canine cả trên môi trường K8s managed như Digital Ocean, nhưng đọc xong lại có ấn tượng rằng phải tự quản lý cụm K8s
    Có vài câu hỏi như sau

    1. Khi tạo một “Cluster” trên Hetzner, đó có phải là một cụm K8s thực sự trải trên nhiều máy, hay chỉ là phân chia ảo trên một máy duy nhất?
    2. Nếu chạy script cài đặt trên các máy chủ khác thì chúng có join vào cluster để host pod theo kiểu phân tán thật sự không?
    3. Có thể gắn Canine vào một cụm K8s managed đã tồn tại sẵn để triển khai không?
    • Hiện tại Canine hỗ trợ hai kiểu cấu hình
      1. Chạy trên một VPS Hetzner duy nhất
      2. Dùng trên một cụm Kubernetes đã được dựng sẵn
        Thông thường, cách 1 dùng cho app staging/phát triển, còn cách 2 dùng cho app production
        Với cách 2, bạn quản lý số node trên Digital Ocean hoặc nơi tương tự, rồi Kubernetes sẽ tự reschedule workload và dùng autoscale
        Có vẻ đây là trọng tâm của câu hỏi, nhưng Canine hiện chưa hỗ trợ tự tạo cụm multi-node trực tiếp trên môi trường Hetzner
        Có cả Terraform của Hetzner để tạo cụm K8s, nhưng Canine hiện chưa tích hợp sẵn phần đó
        Sau khi cải thiện UI v.v. thì tôi cũng có quan tâm đến việc này
        Hiện tại, giả định là hoặc bạn dùng theo hướng dẫn cài K3s trên một VPS duy nhất, hoặc bạn đã có sẵn cluster để dùng
        Link tham khảo: terraform-hcloud-kube-hetzner

  • Với tư cách là người tin rằng rất cần những dự án như thế này, tôi thực sự ủng hộ
    Nếu là hôm nay thì tôi có lẽ sẽ cân nhắc Canine hoặc Dokploy (tôi cũng nghĩ Docker Swarm là một công nghệ bị đánh giá thấp)
    Một góp ý: phần “vì sao không nên dùng Canine” ban đầu có vẻ như sẽ rất thẳng thắn và mới mẻ, nhưng lại hơi mang sắc thái mỉa mai nên khiến tôi không thoải mái
    Tôi nghĩ chỉ cần viết rõ ràng, thành thật về các nhược điểm thực tế như phải tự mua và quản lý server, nếu bị sập thì tự chịu trách nhiệm, và đây là sản phẩm giai đoạn đầu do một người phát triển là đủ

    • Tôi tò mò không biết tình hình bảo trì và hỗ trợ của Docker Swarm hiện giờ ra sao
      Tôi từng ngừng theo dõi nó vài năm trước vì có vẻ như đội Docker lúc đó đã dừng phát triển

    • Tôi viết như vậy là để khác biệt với các landing page khác, nhưng tôi thực sự rất cảm kích phản hồi từ người dùng thật
      Tôi sẽ thử làm lại

  • Chia sẻ một danh sách tổng hợp nhiều nền tảng PaaS đang tồn tại
    awesome-paas

  • Câu hỏi dành cho OP
    Tôi tò mò về bối cảnh khiến bạn bắt đầu làm dự án này
    Tôi cũng có mong muốn thử xây một thứ gì đó phức tạp từ đầu đến cuối, nhưng đến nay mới chỉ làm API và tích hợp với React
    Tôi muốn biết bạn đã chia một ý tưởng phức tạp thành các đầu việc thực tế như thế nào để biến nó thành một dự án mã nguồn mở đến mức là “phương án thay thế Heroku”
    Tôi gần như không có kinh nghiệm dùng Heroku, nên nếu là tôi thì chắc sẽ phải nhìn vào mấy trang pricing để đoán “cần triển khai tính năng gì”, và tôi hơi lo cách đó có thể không hiệu quả

  • Một lựa chọn thay thế Heroku dựa trên Kubernetes nghe khá thú vị
    Nhưng nếu để dùng nó mà tôi vẫn phải hiểu K8s hay Helm chart, thì với tôi nó thực ra không phải là một lựa chọn thay thế Heroku
    Dĩ nhiên tôi hiểu rằng tùy góc nhìn của người vận hành thì mọi thứ có thể đơn giản như kiểu echo hello
    Nhưng khi tôi chỉ muốn đưa thứ gì đó lên thật nhanh, tôi thậm chí còn không muốn phải nghĩ đến cụm từ “Kubernetes và Helm chart”

    • Đó chính là mục tiêu của Canine
      Người dùng thậm chí không cần biết Kubernetes tồn tại, mà vẫn tận dụng được hệ sinh thái trưởng thành của nó
      Khi nào cần tính năng mạnh hơn, bạn cũng có thể mở trực tiếp những thứ chuyên sâu như Kubernetes API để dùng

  • Một góp ý nhỏ
    Kubernetes không chạy container Docker mà chạy container theo chuẩn Open Container Initiative (OCI)
    Docker là một thương hiệu

    • Thêm một góp ý nhỏ nữa:
      Canine Kubernetes Crash Course có nói là “hỗ trợ 10.000 server”
      Nhưng tài liệu chính thức ghi rằng Kubernetes chính thức hỗ trợ tối đa 5.000 node
      tham khảo tài liệu chính thức của Kubernetes
      Dĩ nhiên có thể làm các cụm lớn hơn nhiều, nhưng khi đó sẽ cần tùy biến rất mạnh tay (ví dụ thay toàn bộ API registry, v.v.)
      Workload dĩ nhiên cũng ảnh hưởng
      Kubernetes vẫn còn khá xa mới có thể nói là hỗ trợ cluster cực lớn ngay out-of-the-box, nhưng đang tiến bộ qua từng bản phát hành

    • Tôi không thích nếu bị bắt buộc phải dùng Docker
      Giờ tôi chủ yếu vận hành bằng podman hoặc containerd thay vì Docker

  • Làm dự án này cực kỳ vui, và đây là quãng thời gian phát triển thú vị nhất đời tôi
    Cảm giác nắm trọn mọi “tầng của stack công nghệ” trong tay là điều tuyệt nhất
    Từ Rails app, hạ tầng Canine, máy chủ Raspberry Pi cho đến cả ISP tôi đang dùng
    Tôi đã có trải nghiệm tự mình quản lý tất cả rồi đưa ứng dụng lên chạy

  • Trên website ghi license là MIT License 2024
    Nhưng trên GitHub lại ghi là Apache License
    So với việc năm có đúng hay không thì loại license khác nhau mới là điểm quan trọng hơn
    Tôi muốn biết license thực sự áp dụng là gì

  • Trong self-hosting, tôi muốn có một điểm trung gian giữa Docker và K8s nên cũng từng tự tìm thứ tương tự
    Tôi cũng cân nhắc Nomad, nhưng nó vẫn hơi phức tạp hơn dead simple Docker và hệ sinh thái cũng chưa đủ tốt
    Cuối cùng homelab của tôi chỉ chạy Docker, chấp nhận downtime khi deploy
    Tôi tò mò Canine trừu tượng hóa K8s đến mức nào trong production
    Liệu rồi có lúc vẫn phải nhìn vào bên trong không, vì tôi là người mới với K8s nên không rõ liệu điểm cân bằng đó có thực sự khả thi không

    • Tôi cũng đang phát triển một công cụ nằm giữa Docker và Kubernetes
      uncloud
      Mục tiêu là cung cấp CLI kiểu Docker và khả năng multi-machine/production kiểu Docker Compose, nhưng vẫn giữ sự đơn giản mà không cần control plane để vận hành
      Dù vẫn đang phát triển, mục tiêu là bạn phải có thể dễ dàng hiểu chuyện gì đang diễn ra ở mọi lớp, và việc troubleshooting cũng phải dễ

  • Tôi thực sự thích concept này
    K8s là công nghệ tuyệt vời, nhưng chính sự phức tạp của nó lại là rào cản gia nhập
    Nhìn qua tài liệu công khai thì có vẻ bạn hiểu rất rõ bản chất vấn đề
    Tôi đoán nó sẽ càng hữu ích hơn trong mảng self-hosting, nơi các giải pháp như PVE, Microcloud, Cockpit rất phổ biến
    Tôi đang có một chiếc N100 NUC ở nhà để không, và giờ thấy muốn bỏ qua Microcloud để thử Canine

    • Helm đôi khi khá phiền
      Tôi thường bị lẫn giữa những giá trị nào sửa trong values.yaml rồi sẽ được áp dụng, và những giá trị nào phải thiết lập ngay từ đầu
      Có những chart Helm cài ra quá nhiều service, đến mức tôi không biết những gì có thể restart và nên restart vào lúc nào
      Trong khi đó, Kubernetes lõi lại cho trải nghiệm rất dễ chịu với các stateless job

    • Dạo này tôi không còn hiểu “độ phức tạp” của K8s xuất phát từ đâu nữa
      Ngày trước từng có chuyện kiểu dùng kubespray để setup mất hai tiếng
      Còn bây giờ dùng công cụ như rke thì chỉ cần một file yaml và một SSH key là cũng có thể tạo cluster rồi