Designing a Better Kubernetes Experience for Developers

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

Bài ngắn, nửa giới thiệu plugin mã nguồn mở của Backstage. Không có số liệu quy mô; ý chính là sự tách vai giữa team hạ tầng và người sở hữu service.

Bối cảnh

Theo Spotify, lúc đầu người dựng cluster Kubernetes cũng là người sở hữu service chạy trên nó. Khi Kubernetes phổ biến, tổ chức tách ra team hạ tầng dựng và giữ cluster (thường nhiều region để giảm latency), còn team tính năng chỉ deploy lên.
Hệ quả cho người sở hữu service: muốn biết service của mình có khoẻ không phải đổi nhiều context kubectl, nhiều UI, tìm xem nó được deploy ở cluster nào. Công cụ có sẵn hướng về quản trị cluster: khó với nhiều cluster, đòi quyền toàn cluster, hiện mọi thứ trên cluster kể cả thứ không phải của mình.

Viết plugin Kubernetes cho Backstage (developer portal nội bộ, nay mã nguồn mở): một góc nhìn theo service thay vì theo cluster, gom trạng thái từ mọi cluster/region vào một trang.
Hiện lỗi do Kubernetes báo, mức gần giới hạn autoscaler, số lần container restart, trạng thái từng pod; không cần ra CLI.
Gắn vào service catalog của Backstage, nơi đã có API, tài liệu, chủ sở hữu của mỗi service. Plugin gọi thẳng Kubernetes API nên không phụ thuộc cloud (Spotify dùng GKE).

Khi team hạ tầng và team sản phẩm tách nhau, công cụ phải đổi theo: người sở hữu service cần góc nhìn service của tôi, không phải góc nhìn cluster (Nền tảng nội bộ cho service (đường ray chung)).
Chi phí nhỏ lặp lại (tìm service ở cluster nào) nhân với số service và số region thành chi phí lớn của cả tổ chức.
Danh mục service là chỗ hợp lý để gắn thêm thông tin vận hành, vì nó đã biết ai sở hữu cái gì.