The Great K8S Migration

Bài tóm tắt Reddit 2020 3. Quy mô lớn Độ khó: Dễ

Reddit · 2020 · 3. Quy mô lớn · Độ khó: Dễ — bài gốc

Bối cảnh

  • Reddit 15 tuổi (2020): nhiều kỹ sư hơn thì nhiều deploy hơn và codebase phức tạp hơn. Họ gom hạ tầng về một chuẩn trên Kubernetes để service owner chỉ lo service của mình.
  • Mô hình trước Kubernetes:
    • service chạy trên VM trong EC2 Auto Scaling Group; mỗi VM chạy nhiều bản ứng dụng, quản lý bằng Einhorn để tận dụng CPU;
    • các sidecar process lo telemetry, cấu hình động (thí nghiệm, secret), service discovery;
    • hạ tầng khai báo bằng Terraform, bootstrap máy bằng Puppet từ một AMI chung.

Thay đổi chính

  • Giữ nguyên các trừu tượng dev đã quen:

    • mỗi service một namespace (dễ phân quyền theo team);
    • Deployment/ReplicaSet tương ứng Auto Scaling Group;
    • mỗi pod chạy một bản ứng dụng cộng các sidecar cần chia sẻ tài nguyên.

    Bỏ được Terraform và Puppet cho từng service, nên dễ deploy thêm thành phần theo service (ví dụ bộ gom metric riêng).

  • Case study: Campaign Management (CM) của mảng Ads. Ads vốn tách biệt khỏi phần consumer nên tụt lại khi reddit.com chuyển sang Kubernetes.

    • Chuẩn bị: Docker image lên ECR; CI bằng Drone; pipeline deploy viết bằng Starlark cho Spinnaker; tài nguyên Kubernetes sinh từ manifest Starlark thay cho helm chart dài dòng.
    • Chuyển kết nối lần lượt từng service phụ thuộc (Ads API → Billing → Ads Serving, Reporting) sang CM mới, trong khi CM vẫn đang chạy production.
    • Sự cố nhỏ: service discovery sai vì Ads API ở cluster khác, revert và sửa trong vài phút. Bài học: trước khi chuyển, gọi thử một endpoint của CM từ phía service nhận để chắc là nó tìm thấy được.
    • Với job của team khác (ngôn ngữ khác), họ lưu cấu hình trước và sau thay đổi để quay lại được.
  • Theo Reddit: "phải có cả một ngôi làng": cần nhiều team hạ tầng và team nghiệp vụ cùng tham gia.

Bài học cho SWE

  • Chuyển nền tảng thành công khi giữ các trừu tượng dev đã quen (sidecar, nhóm autoscale) và chỉ đổi phần bên dưới (Nền tảng nội bộ cho service (đường ray chung)).
  • Chuyển một service đang chạy: dời từng phụ thuộc một, kiểm tra khả năng tìm thấy trước khi chuyển, và luôn giữ cấu hình cũ để revert (Migration không downtime).
  • Phần tách biệt về tổ chức (Ads) thường tụt lại trong cuộc chuyển hạ tầng chung.

Liên quan