From One Horizontal Scaling Controller to Many: Evolving Uber's Compute Platform

Uber · 2026 · 4. Điều chỉnh · Độ khó: Khó — bài gốc

Bối cảnh

• Container Platform của Uber (2026): hơn 100 cụm compute ở data center và cloud (Oracle, Google), khoảng 4.000 service trên 3 triệu core, 1,5 triệu lần khởi động pod mỗi ngày. Up là lớp federation: service owner deploy, khai báo miền lỗi và kỳ vọng scale. CRD UberDeployment mang theo yêu cầu nghiệp vụ, kỳ vọng rollout, ràng buộc chịu lỗi; controller UDC hoà giải chúng thành đối tượng Kubernetes và báo status về Up. Up dùng status đó để chuyển bước trong workflow (kể cả continuous deployment). Nhiều năm, chỉ một bên quyết số replica (Up) và một bên áp và báo (UDC).
• Từ 2023, failover đổi cách: Uber chạy active-active giữa các region; khi failover, region còn lại phải có đủ compute rảnh. Cách cũ là giữ sẵn capacity rảnh ở mọi DC, an toàn nhưng tốn. Cách mới: scale xuống workload tier thấp để lấy chỗ scale lên workload tier cao. Vậy là có thêm một nguồn ý định scale (orchestrator failover), và dự kiến còn thêm (HPA, autoscale lai).

Thay đổi chính

• Không nhét vào UDC: UDC nằm trên đường nóng của vòng đời service (deploy, scale hằng ngày); failover thì hiếm theo thiết kế. Thêm logic failover vào UDC làm phức tạp controller quan trọng nhất, và một hồi quy ở phần failover có thể phá deploy thường của cả fleet; mỗi orchestrator mới lại thêm vào đó thì bán kính ảnh hưởng tăng mãi.
• CRD ServiceScale + Service Scale Controller (SSC): mỗi orchestrator ghi ý định scale của riêng nó (một bên ghi scale bình thường, bên kia ghi điều chỉnh khi failover), SSC hoà giải ý định đã gộp thành đối tượng Kubernetes. Cố ý không thêm DB ngoài hay dịch vụ điều phối: ý định nằm ngay trong Kubernetes, nên nhìn ServiceScale là biết orchestrator nào muốn gì, và failback chỉ là hội tụ về trạng thái ổn định đã lưu trong spec, không phải dựng lại từ log.
• Bài học 1: trường status "kết thúc" không hợp Kubernetes. Controller đọc qua informer cache, có thể trễ vài giây; bình thường không sao vì hoà giải liên tục, nhưng Up coi status.workflow_status thành công là cổng để làm bước không đảo ngược được, nên đọc cache cũ trở nên đắt. Giải: read-your-own-write cục bộ: controller gắn generation hiện tại làm annotation khi cập nhật đối tượng hạ nguồn, và trước khi báo status kiểm cache đã thấy ít nhất generation đó.
• Bài học 2: nhiều bên ghi cùng một đối tượng. UDC và SSC cùng cập nhật một tài nguyên dù đã có optimistic concurrency và server-side apply; ghi gần như đồng thời cộng đọc cache cũ làm ReplicaSet lệch giữa annotation và spec, về sau xác định là bug trong logic proportional scaling của controller Deployment upstream. Hệ quả: hỏng proportional scaling cần cho rolling update không downtime, có workload kẹt tới khi sửa tay. Phản ứng nhiều lớp: observability toàn fleet để phát hiện lệch; một healer định kỳ trong UDC quét và vá ReplicaSet lệch; song song sửa gốc trên đường scale.
• Bài học 3: rollout kéo dài khoảng một năm, không để service owner nhận ra: integration test bằng kind (Kubernetes trong Docker) mô phỏng tương tác thật giữa controller để bắt race sớm; hỗ trợ cả Deployment gốc lẫn CloneSet của OpenKruise; staging và canary; không có sự cố ảnh hưởng khách.

Vì sao

• Theo Uber, tách quyền sở hữu ý định scale khỏi việc thực thi để nhiều orchestrator cùng tồn tại mà không đè lên đường deploy chính, đổi lại có thể dùng capacity của tier thấp cho failover thay vì giữ capacity rảnh.

Bài học cho SWE

• Logic cho sự kiện hiếm không nên nằm trong controller của đường nóng; thêm một lớp ý định riêng.
• Lưu ý định của từng bên trong chính trạng thái khai báo thì vừa kiểm tra được vừa quay về được.
• Trạng thái đọc từ cache có thể cũ; nếu một bên ngoài coi status là cổng không đảo ngược, cần đảm bảo đọc-sau-ghi.
• Nhiều bên ghi cùng một đối tượng sẽ lộ race mà thiết kế không lường; phát hiện, khoanh, tự vá trước, rồi sửa gốc.

Liên quan

• Tự động hoá vận hành và auto-remediation · Độ tin cậy và multi-region · Nền tảng nội bộ cho service (đường ray chung)
• Cùng công ty: Uber 2025 · Uber 2026
• Cùng bài toán: Kubernetes 2026 · PlanetScale 2026