# Cloud Run: đưa dịch vụ container lên Google Cloud của khách mà không cần dựng cụm

> Cloud Run giúp bạn khỏi mất nhiều ngày chờ xin dựng cụm, nhưng đổi lại bạn phải lo cold start và trả lời các câu hỏi về mạng ngay từ buổi họp đầu tiên.

Bản gốc: https://fdetimes.net/vi/cong-cu/cloud-run-gcp-trien-khai-dich-vu-cho-khach/

Thử hình dung: khách cấp cho bạn một project Google Cloud, một service account và hai tuần để chạy pilot. Không ai trong đội của họ muốn vận hành thêm một cụm Kubernetes. Trong tình huống này, Cloud Run thường là đường ngắn nhất, nhưng bạn chỉ nên chọn nó khi đã biết nó có thể hỏng ở đâu.

Google mô tả Cloud Run là nền tảng ứng dụng được quản lý hoàn toàn, chạy được code, function hoặc container. Với FDE, điểm đáng giá nhất là tài liệu khẳng định bạn không cần tạo cụm hay quản lý hạ tầng mà vẫn làm được việc.

Khi làm việc tại chỗ khách, mỗi ngày không phải đi xin quyền dựng hạ tầng là thêm một ngày dành cho bài toán thật.

## Service chờ request, job chạy tới khi xong

Service đứng chờ request gửi tới. Job dành cho các tác vụ song song hoá được, chạy thủ công hoặc theo lịch cho tới khi xong.

Một bài blog năm 2019 của Google coi Cloud Run là nơi lý tưởng cho microservice container không trạng thái, tức loại không cần các tính năng Kubernetes như namespace hay quản lý node. Bài đã cũ nên chi tiết sản phẩm có thể đã khác. Dù vậy, "dịch vụ này có giữ trạng thái không?" vẫn là câu nên hỏi đầu tiên.

## Một pilot cụ thể, đi từng bước

Thử hình dung khách là một công ty bảo hiểm cần trích xuất thông tin từ hồ sơ bồi thường. Bạn có hai phần: một API nhận file từ hệ thống nội bộ, và một tác vụ ban đêm xử lý lại toàn bộ hồ sơ tồn đọng. API là một Cloud Run service, còn tác vụ ban đêm là một Cloud Run job chạy theo lịch.

Image của bạn nên nằm ở đâu? Google khuyến nghị Artifact Registry và nói chỉ nên dùng Docker Hub cho các image phổ biến. Image do bạn tự build cho khách không thuộc nhóm đó, nên hãy đẩy nó vào Artifact Registry ngay trong project của khách.

Một chi tiết nhỏ nhưng hữu ích: Cloud Run nhập image vào lúc deploy và không kéo lại từ registry mỗi khi khởi động instance mới. Nhờ vậy, nếu registry gặp trục trặc đúng lúc dịch vụ cần scale lên thì việc scale cũng không bị ảnh hưởng. Đây là điều nên ghi vào runbook bàn giao cho đội vận hành của khách.

## Khách muốn dịch vụ nằm trong mạng nội bộ

Công ty bảo hiểm nào cũng sẽ hỏi: hồ sơ khách hàng có đi qua internet không? Câu trả lời nằm ở cài đặt ingress. Ở chế độ All, mọi request đều được nhận, kể cả request từ internet gọi thẳng tới URL run.app.

Ở chế độ Internal, request từ các nguồn khác, kể cả internet, không tới được dịch vụ qua URL run.app, URL tùy chỉnh hay domain tùy chỉnh.

Vì vậy, ngay buổi họp đầu tiên, hãy hỏi khách hệ thống nào sẽ gọi API của bạn và nó nằm ở đâu trong mạng của họ. Sau đó đối chiếu câu trả lời với định nghĩa nguồn internal trong tài liệu ingress, đừng đợi tới ngày go-live mới làm.

## Co về 0: tiết kiệm, nhưng phải trả bằng cold start

Khi service không có request nào, Cloud Run gỡ luôn cả instance cuối cùng. Vì thế request mới tới sẽ cần một instance mới, và tài liệu Google xác nhận có lúc request phải chờ instance khởi động xong mới được xử lý. Một bài blog năm 2020 của Google cũng thừa nhận các nền tảng serverless từ lâu chấp nhận đánh đổi độ trễ của phản hồi đầu tiên.

Theo tài liệu, request có thể phải chờ tối đa 3,5 lần thời gian khởi động trung bình của instance, hoặc 10 giây, tùy giá trị nào lớn hơn. Ví dụ, nếu container của bạn khởi động trung bình mất 2 giây thì 3,5 lần là 7 giây.

Con số này nhỏ hơn 10, nên request có thể phải chờ tới 10 giây. Nếu buổi demo sáng thứ Hai là request đầu tiên sau cả cuối tuần, người phải chờ chính là khách.

Một lịch gọi "làm ấm" chạy trước giờ demo cũng không đủ chắc chắn, vì nếu sau lần gọi đó không còn request nào thì instance cuối cùng vẫn có thể bị gỡ.

Cách Google khuyến nghị để giảm cold start là đặt minimum instances. Một hướng dẫn độc lập trên blog của OneUptime nhắc đến cái giá: các instance chờ sẵn không xử lý request được tính tiền ở mức thấp hơn, nhưng không miễn phí.

Với buổi demo quan trọng, bạn đang đổi một ít chi phí lấy độ trễ, và nên nói rõ khoản đánh đổi này với người duyệt ngân sách của khách.

## Khi nào nên dừng lại và chọn GKE

Kiến trúc tham chiếu của Google so sánh Cloud Run với GKE Autopilot và ghi rõ một đánh đổi: Cloud Run không hỗ trợ Kubernetes. Nếu ứng dụng của khách cần namespace hay quản lý node, đừng cố ép nó lên Cloud Run.

**Điểm mấu chốt:** Hãy hỏi sớm xem ứng dụng có cần Kubernetes không; câu trả lời quyết định nó chạy ở đâu.

## Những lỗi dễ mắc ở pilot đầu tiên

Phần lớn rắc rối với Cloud Run không nằm ở bản thân công cụ mà ở những câu hỏi không được đặt ra đủ sớm.

| Lỗi | Vì sao gây hại | Làm gì thay |
|---|---|---|
| Dùng service cho tác vụ batch | Việc chạy tới khi xong là phần của job | Tách việc xử lý hàng loạt thành job, chạy thủ công hoặc theo lịch |
| Hỏi muộn xem ai sẽ gọi dịch vụ | Với ingress Internal, internet không gọi được URL run.app | Hỏi ngay buổi họp đầu và kiểm tra trước go-live |
| Tin vào lịch "làm ấm" mà không thử | Instance vẫn có thể bị gỡ khi không còn request | Cân nhắc min instances, diễn tập và đo request đầu tiên |
| Để image riêng trên Docker Hub | Google chỉ khuyên dùng Docker Hub cho image phổ biến | Dùng Artifact Registry |
| Ép ứng dụng cần Kubernetes lên Cloud Run | Cloud Run không hỗ trợ Kubernetes | Xem GKE Autopilot cho phần đó |

## Học gì trước

Hãy bắt đầu từ container: viết Dockerfile gọn, chạy được ở máy local và giữ dịch vụ không trạng thái. Sau đó nắm cho chắc sự khác nhau giữa service và job, rồi tới ingress, vì đó là chỗ đội bảo mật của khách sẽ soi kỹ nhất. Cuối cùng, tự đo cold start trên dịch vụ của chính bạn.

Trong CV, đừng chỉ ghi "Google Cloud". Hãy viết một dòng cụ thể, chẳng hạn: deploy API trích xuất tài liệu lên Cloud Run với ingress Internal, kèm một job xử lý hàng đêm, đặt min instances để giảm cold start trong giờ demo.

Khi đọc mô tả công việc thấy yêu cầu triển khai trên GCP của khách, đó chính là câu chuyện bạn nên chuẩn bị sẵn để kể.

Cloud Run không làm thay bạn phần khó nhất của nghề, tức là hiểu mạng và quy trình của khách. Nhưng nó gánh bớt phần hạ tầng, để bạn có thêm thời gian cho phần khó đó.

**Thử ngay tuần này:**

- Đẩy image của một API nhỏ lên Artifact Registry, deploy lên Cloud Run, để yên một lúc rồi đo độ trễ của request đầu tiên.
- Chuyển một script chạy định kỳ thành Cloud Run job, chạy thủ công một lần rồi đặt lịch.
- Đặt ingress Internal cho một service thử nghiệm rồi gọi URL run.app từ internet để xác nhận request bị chặn.

## Nguồn

- [What is Cloud Run | Google Cloud Documentation](https://docs.cloud.google.com/run/docs/overview/what-is-cloud-run)

- [General development tips | Cloud Run documentation](https://docs.cloud.google.com/run/docs/tips)

- [Cloud Run min instances: Minimize your serverless cold starts](https://cloud.google.com/blog/products/serverless/cloud-run-adds-min-instances-feature-for-latency-sensitive-apps)

- [How to Configure Minimum Instances on Cloud Run to Eliminate Cold Starts for Production Services](https://oneuptime.com/blog/post/2026-02-17-how-to-configure-minimum-instances-on-cloud-run-to-eliminate-cold-starts-for-production-services/markdown)

- [Restrict network endpoint ingress for Cloud Run services and instances | Google Cloud Documentation](https://docs.cloud.google.com/run/docs/securing/ingress)

- [Deploy container images to Cloud Run services | Google Cloud Documentation](https://docs.cloud.google.com/run/docs/deploying)

- [Google Kubernetes Engine vs Cloud Run: Which should you use?](https://cloud.google.com/blog/products/containers-kubernetes/when-to-use-google-kubernetes-engine-vs-cloud-run-for-containers/)

- [Select a managed container runtime environment | Cloud Architecture Center](https://docs.cloud.google.com/architecture/select-managed-container-runtime-environment)