Scaling Production Globally — The service mesh facelift (Part-1)

Bài tóm tắt Achievers 2022 3. Quy mô lớn Độ khó: Trung bình

Achievers · 2022 · 3. Quy mô lớn · Độ khó: Trung bình — bài gốc

Site chặn crawler; wiki đọc toàn văn qua trình duyệt, ghi chú bằng lời của wiki. Phần 1; phần 2 (observability, SLO, canary): Achievers 2022.

Bối cảnh

  • Achievers tăng nhanh trong hai năm, mở rộng microservice sang nhiều region trên GKE với yêu cầu data residency chặt. Các cụm Kubernetes đã có nhưng không có failover giữa region; theo team SRE, mất một cụm hay một service trong region dễ xảy ra hơn mất toàn bộ GCP.
  • Yêu cầu cho service mesh: HTTP/2, xác thực và phân quyền, mTLS, failover theo locality, multi-cluster, chính sách traffic, quan sát tốt.
  • Từ 2019 dùng Kong làm API gateway. Cân nhắc Kuma (chưa đủ chín cho multi-cluster) và Linkerd2 (multi-cluster còn mới); chọn Istio cho cả mesh lẫn gateway, bỏ Kong. Bật sidecar song song với Kong cũ thì dễ; vấn đề lộ ra khi tải thật tăng (migration xong cuối 2020).

Những gì vỡ

  • Thứ tự khởi động sidecar: container ứng dụng gọi ra ngoài lúc khởi động trước khi istio-proxy sẵn sàng nên crash ngẫu nhiên; Kubernetes không bảo đảm thứ tự container. Sửa bằng holdApplicationUntilProxyStarts.
  • Autoscaling lệch: HPA tính trên tổng tài nguyên cả pod, thêm sidecar làm lệch ngưỡng; có service scale liên tục, có cái không scale, và khi Istio đẩy cấu hình mới cho envoy thì nhiều service cùng scale. Sửa bằng cách đo lại và chỉnh targetCPUUtilizationPercentage (cùng vấn đề với Monzo 2020 Monzo 2020).
  • 503 của Envoy (upstream_reset_before_response_started): thử tăng grace period, chỉnh connection pool đều không ăn thua; gốc là ứng dụng Node.js không chuyển SIGTERM cho process con nên không bao giờ đóng kết nối êm. Sửa bằng xử lý SIGTERM và một init process.
  • Nâng cấp Istio CNI (bỏ istio-init cần quyền cao) làm một số container không gọi được Google Metadata service; sửa bằng annotation loại trừ dải IP khỏi sidecar.
  • Ngoài tầm kiểm soát: khi cụm lớn dần, gke-metrics-agent (do Google quản lý) bị OOM, HPA thỉnh thoảng ngừng chạy; Google không đổi được limit của deployment managed, lại dính bug với máy lớn nhiều pod. Họ giảm từ khoảng 64 xuống 30 pod mỗi node: hết crash nhưng số node tăng mạnh, tốn thêm đĩa và traffic, tới khi Google sửa upstream.

Bài học cho SWE

  • Service mesh đem lại failover theo locality và mTLS, nhưng sidecar thay đổi những giả định nền: thứ tự khởi động, ngưỡng autoscaling, cách tắt pod (Nền tảng nội bộ cho service (đường ray chung)).
  • Đa region có failover bắt đầu từ việc các cụm nói chuyện được với nhau trong ràng buộc data residency (Độ tin cậy và multi-region).
  • Thành phần managed của cloud cũng là dependency có giới hạn ẩn; cách lách có thể đắt.

Liên quan