Tôi đã không cần Kubernetes, và có lẽ bạn cũng không cần

(benhouston3d.com)

19 điểm bởi GN⁺ 2024-11-28 | 12 bình luận | Chia sẻ qua WhatsApp

Vì sao tôi rời Kubernetes để chọn Google Cloud Run

Bối cảnh áp dụng Kubernetes

Trên nền tảng chỉnh sửa 3D trực tuyến Clara.io ra mắt năm 2013, tôi đã tối ưu hạ tầng bằng máy chủ bare metal, nhưng việc quản lý phần cứng và giám sát đòi hỏi quá nhiều công sức.
Năm 2018, ở dự án Threekit.com, tôi đã chọn Kubernetes. Khi đó Azure, AWS, Docker đều chấp nhận Kubernetes như một tiêu chuẩn và nó đã trở thành xu hướng chính.

Những giới hạn của Kubernetes

Vấn đề chi phí:
- Chi phí thiết lập cụm cơ bản rất lớn, bao gồm node quản lý, cấu hình dự phòng cụm, v.v.
- Tự động mở rộng chậm khiến phải overprovision dịch vụ, phát sinh chi phí cho tài nguyên không dùng đến.
Khó khăn trong quản lý workload:
- Việc lên lịch tác vụ rất phức tạp, và cả scheduler tích hợp lẫn Argo đều kém hiệu quả với khối lượng công việc lớn.
Quá tải vì độ phức tạp:
- Tính năng phong phú khiến cả những việc đơn giản cũng trở nên phức tạp.
- Cần nhân sự DevOps chuyên trách để vận hành Kubernetes, dẫn đến chi phí tăng thêm.

Chuyển sang Google Cloud Run

Cloud Run thay thế sự phức tạp của Kubernetes và cung cấp một môi trường đơn giản hơn, hiệu quả chi phí hơn.

Thiết lập mới

Hạ tầng dựa trên container Docker:
- Bao gồm dịch vụ tự động mở rộng và container cho tác vụ chạy dài hạn.
- Cloud Run tự động hóa việc triển khai container, mở rộng quy mô, xử lý downtime và chạy tác vụ.

Ưu điểm của Cloud Run

Hiệu quả chi phí:
- Tính phí theo thời gian sử dụng CPU và bộ nhớ.
- Dịch vụ nhàn rỗi không phát sinh chi phí.
- Ví dụ: trang Web3D Survey có thể xử lý 500.000 lượt truy cập mỗi tháng với chi phí chỉ $4/tháng.
Tự động mở rộng nhanh và ổn định:
- Mở rộng trong vài giây, nhanh hơn Kubernetes.
- Có thể xử lý nhanh các đợt tăng nhu cầu đột biến.
Không có gánh nặng quản lý Kubernetes:
- Cloud Run dựa trên Borg của Google nên không cần quản lý cụm Kubernetes.
Tác vụ bất đồng bộ đơn giản:
- Dùng Cloud Run Tasks giúp tự động retry và thực thi khối lượng công việc lớn một cách dễ dàng.

Vấn đề tiềm ẩn của Kubernetes: bị khóa vào cụm

Nếu phụ thuộc vào các tính năng của Kubernetes, việc tích hợp hoặc mở rộng sang tài nguyên bên ngoài cụm sẽ trở nên khó khăn.
Điều đó dẫn đến phụ thuộc vào một hạ tầng cụ thể, khiến việc mở rộng và migration phức tạp hơn và tốn kém hơn.

Một số câu hỏi thường gặp về việc dùng Cloud Run

“Bạn không lo bị phụ thuộc vào GCP sao?”

Với thiết lập dựa trên Docker, việc migration sang cloud khác như AWS có thể hoàn thành trong khoảng 1 tuần.
Trên thực tế, ngoài các yếu tố chính trị, rất hiếm khi phải đổi nhà cung cấp cloud.

“Cloud Run rốt cuộc chẳng phải cũng là Managed Kubernetes sao?”

Cloud Run dùng giao diện Knative, nhưng nó chạy trên Borg của Google chứ không phải Kubernetes.
Nó loại bỏ độ phức tạp của Kubernetes và cung cấp một giao diện được đơn giản hóa.

Nhược điểm của workflow hiện tại

Bất tiện trong quản lý tên dịch vụ:
- Cần một lớp trừu tượng để quản lý cấu hình nhất quán giữa môi trường local và server.
- Không có tính năng quản lý tên như của Kubernetes.
Thiếu mô phỏng Cloud Run Task:
- Khi phát triển tác vụ ở local, không có môi trường mô phỏng đơn giản để capture và theo dõi log output.

Kết luận

Cloud Run là giải pháp tối ưu về chi phí, tốc độ, khả năng mở rộng và sự đơn giản
Với doanh nghiệp lớn hoặc các yêu cầu phức tạp, Kubernetes có thể hữu ích, nhưng
Trong những dự án coi trọng sự đơn giản và hiệu quả, Cloud Run thực tế hơn rất nhiều
PS: Có thể giải quyết vấn đề bằng cách thêm các extension cụ thể cho Kubernetes, nhưng điều đó chỉ làm tăng thêm độ phức tạp, và tôi không muốn phụ thuộc vào một môi trường Kubernetes vượt quá những nhu cầu đơn giản của mình

12 bình luận

blurblah 2024-12-01

Làm gì có viên đạn bạc. Chỉ cần dùng cho phù hợp với hoàn cảnh là được thôi haha.
Nếu thấy nó đang thịnh hành mà áp dụng Kubernetes một cách thiếu phê phán thì có thể sẽ rất vất vả, nhưng tôi vẫn nghĩ trong các môi trường có quy mô tương đối lớn thì đây là một công cụ ổn.
Dù có triển khai đi nữa, nếu chỉ triển khai xong rồi để đó thì sẽ không thể dùng nó một cách đúng nghĩa.
Và cũng như bất kỳ công cụ nào khác, nó không thể đáp ứng 100% nhu cầu của nhà phát triển hay người dùng, nên tôi nghĩ mức độ tự động hóa phù hợp là điều bắt buộc.

bungker 2024-11-29

Tôi không cần Kubernetes, và có lẽ bạn cũng không cần.

Chỉ cần dựng xong Kubernetes là từ đó chỉ còn việc hưởng ngọt thôi mà... hu hu

riki3 2024-11-29

Kubernetes là kế sinh nhai của tôi, và đã từng có thời tôi tin rằng đây là đáp án đúng.
Nhưng càng theo thời gian, tôi càng thấy mình gặp phải nhiều vấn đề và lãng phí thời gian.

Tôi vẫn khuyên người khác dùng k8s, nhưng có lẽ sẽ không dùng nó cho dịch vụ của mình. Không chỉ k8s, mà tôi còn mệt mỏi với cả container nói chung.

joon14 2024-11-28

Nếu đang dùng AWS thì có thể hiểu là nó tương tự như ECS không?

tujuc 2024-11-29

Vâng, đúng là như vậy. :)

eclipsense 2024-11-28

Không biết dùng Kubernetes mới là vấn đề; để nói rằng Kubernetes không hay thì có hơi không đúng lắm.

tujuc 2024-11-28

Tôi cũng có suy nghĩ khá giống tác giả.
Công ty của tôi vẫn chưa ở quy mô cần dùng kube.

Việc nghĩ rằng mọi lập trình viên đều có thể quản lý bằng Kube là suy nghĩ của riêng tôi.
Hóa ra việc xây dựng hạ tầng và hướng dẫn để họ có thể giải quyết vấn đề, dù chỉ ở mức còn kém hơn mặt bằng chung của các lập trình viên trong công ty, lại tốt hơn...

doolayer 2024-11-28

???: Tôi không cần AI, và có lẽ các bạn cũng không cần.

ilbanin00 2024-11-28

Bất kỳ sản phẩm nào cũng sẽ có những phần đánh đổi.

bbulbum 2024-11-28

Vì dùng dịch vụ managed nên mình không thực sự cảm thấy việc quản lý có gì khó khăn cả,,
Mình nghĩ công cụ nào nếu dùng ở mức độ phù hợp thì đều hữu ích, nhưng riêng Kubernetes thì có vẻ thường bị chỉ trích chủ yếu vì “có thể cấu hình quá phức tạp”.