Các autoscaler của Kubernetes xung đột do thiếu một control plane thống nhất

Khi các kỹ sư độ tin cậy trang web (SRE) yêu cầu xác định kích thước đúng cho một dịch vụ như checkout-api, họ nhận được những câu trả lời mâu thuẫn từ chính hạ tầng của mình. Horizontal Pod Autoscaler (HPA) có thể yêu cầu mười một bản sao (replica) do tải CPU, trong khi Vertical Pod Autoscaler (VPA) lại khẳng định các pod đang được cấp phát quá mức. Đồng thời, KEDA yêu cầu hai mươi bốn bản sao để xử lý backlog Kafka, và Karpenter bổ sung các node mới dựa trên các yêu cầu tài nguyên bị phóng đại. Sự hỗn loạn này xảy ra vì năm controller khác nhau hoạt động logic riêng lẻ, nhưng không cái nào sở hữu cái nhìn toàn diện về nhu cầu thực tế của hệ thống.

Chuyện gì đã xảy ra

Hoạt động vận hành Kubernetes hiện đại phụ thuộc vào bộ công cụ chuyên biệt được xây dựng theo triết lý Unix: các thành phần nhỏ, mô-đun hóa, thực hiện tốt từng tác vụ đơn lẻ. HPA quản lý tính co giãn ngang, VPA xử lý việc điều chỉnh kích thước dọc, KEDA kết nối nguồn sự kiện với số lượng bản sao, và các node autoscaler như Karpenter quản lý năng lực vật lý. Các công cụ GitOps như Argo CD áp dụng trạng thái cơ sở từ hệ thống kiểm soát phiên bản. Trong các pipeline Unix truyền thống, các công cụ xử lý dữ liệu tuần tự, truyền đầu ra bất biến từ giai đoạn này sang giai đoạn tiếp theo. Tuy nhiên, các autoscaler của Kubernetes hoạt động đồng thời, thay đổi cùng các trường API như .spec.replicas và .resources.requests mà không thấy rõ hành động của nhau.

Khoảng trống kiến trúc này tạo ra tình huống mà việc xác định năng lực làm việc trở thành một quy trình phân mảnh. Thay vì giải một phương trình toán học liên kết duy nhất để tối ưu hiệu suất và chi phí, hệ thống chia bài toán thành nhiều controller tách rời. Mỗi controller giả định quyền kiểm soát độc quyền đối với lĩnh vực cụ thể của nó, dẫn đến sự dao động (thrashing) thay vì hiệu quả. Kết quả là một cụm nơi không có thực thể đơn lẻ nào hiểu rõ sự đánh đổi giữa độ trễ, chi phí và năng lực, gây ra sự bất ổn trong vận hành.

Cơ chế hoạt động

Xung đột nảy sinh vì các vòng lặp điều khiển độc lập thao túng các biến phụ thuộc lẫn nhau, tạo ra bốn chế độ lỗi phổ biến. Thứ nhất, HPA và VPA va chạm thông qua sự sụp đổ mẫu số. HPA tính toán số bản sao mục tiêu bằng cách chia mức sử dụng thực tế cho các yêu cầu tài nguyên đã khai báo. Khi VPA giảm các yêu cầu này để cắt giảm lãng phí, mẫu số thu hẹp lại. Ngay cả những tăng nhẹ về lưu lượng cũng đẩy tỷ lệ sử dụng vượt ngưỡng của HPA, kích hoạt việc scale-out mạnh mẽ. Khi nhiều pod hơn chia sẻ tải, mức sử dụng mỗi pod giảm xuống, thúc đẩy VPA giảm yêu cầu tài nguyên hơn nữa, tạo ra một vòng xoáy tử thần của các container siêu nhỏ.

Thứ hai, HPA gốc và KEDA rơi vào điều kiện cạnh tranh đa người ghi (multi-writer race condition). Nếu hàng đợi sự kiện tăng vọt, KEDA sẽ scale-up deployment để giải phóng backlog. Tuy nhiên, nếu các pod worker nặng về I/O với mức sử dụng CPU thấp, HPA thấy mức sử dụng thấp và scale-down deployment trở lại. Máy chủ API ghi nhận các sự kiện rescale xen kẽ trong khi thông lượng xử lý thực tế bị đình trệ. Thứ ba, các engine GitOps tạo ra hiệu ứng ping-pong trôi dạt (drift). Khi HPA scale một deployment trong lúc tăng đột biến, các công cụ GitOps đánh dấu ứng dụng là không đồng bộ. Nếu auto-sync được bật, hệ thống sẽ reset deployment về trạng thái cơ sở, khiến ứng dụng thiếu hụt năng lực trong giờ cao điểm.

Cuối cùng, các node autoscaler khuếch đại những sự kém hiệu quả này. Các công cụ như Karpenter cung cấp các instance vật lý dựa chặt chẽ vào các yêu cầu container đã khai báo, chứ không phải mức tiêu thụ thực tế. Nếu một container yêu cầu một lõi CPU nhưng chỉ sử dụng 150 millicores, scheduler vẫn dành trọn vẹn một lõi đó. Điều này nhân lên các lỗi sizing từ upstream thành hóa đơn đám mây khổng lồ, khiến mức sử dụng CPU trung bình của cụm dao động quanh tám phần trăm bất chấp việc cấp phát dư thừa.

Chi tiết quan trọng

• Năm controller riêng biệt (HPA, VPA, KEDA, Karpenter, GitOps) thường đưa ra các khuyến nghị sizing mâu thuẫn cho cùng một workload.
• HPA và VPA xung đột vì VPA giảm các yêu cầu tài nguyên, điều này làm phồng lên tỷ lệ phần trăm sử dụng được HPA dùng để tính toán.
• KEDA và HPA cạnh tranh ghi vào cùng sub-resource /scale, gây ra số lượng bản sao dao động khi mức sử dụng CPU không khớp với độ sâu hàng đợi.
• Các công cụ GitOps có thể hoàn tác những thay đổi scaling động do HPA thực hiện, khôi phục cấu hình cơ sở không đủ khả năng xử lý tải lưu lượng hiện tại.
• Node autoscaler cung cấp năng lực dựa trên các yêu cầu đã khai báo thay vì mức sử dụng thực tế, dẫn đến việc cấp phát quá mức đáng kể và mức sử dụng cụm thấp.
• Các autoscaler hiện tại hoạt động như những phản xạ tự động thiếu một hệ thần kinh trung ương để phối hợp hành động của chúng.

Tại sao điều này quan trọng

Đối với các kỹ sư phần mềm và đội ngũ nền tảng, những xung đột này chuyển trực tiếp thành các dịch vụ không đáng tin cậy và chi phí bị thổi phồng. Sự dao động gây ra bởi các controller cạnh tranh dẫn đến các đỉnh nhọn độ trễ trong những đợt tăng nhu cầu, vì scaling phản ứng chờ cho đến khi ngưỡng bị vi phạm trước khi hành động. Bản chất phản ứng này có nghĩa là các tài nguyên tính toán mới chỉ được khởi tạo sau khi hiệu suất đã suy giảm, vi phạm các mục tiêu mức độ dịch vụ (SLO). Hơn nữa, việc GitOps không thể phản ánh chính xác thực tế sản xuất phá vỡ các nguyên tắc hạ tầng khai báo, khiến các lần rollout tương lai trở nên rủi ro và khó kiểm toán.

Tác động tài chính cũng nghiêm trọng không kém. Vì node autoscaler phụ thuộc vào các yêu cầu đã khai báo thường bị phóng đại để ngăn chặn xung đột HPA-VPA, các cụm chạy với lượng lớn năng lực chưa sử dụng. Các kỹ sư dành nhiều thời gian để tinh chỉnh thủ công các ngưỡng và đối chiếu các diff Git thay vì tập trung vào phát triển tính năng. Việc thiếu một control plane thống nhất có nghĩa là mọi quyết định scaling đều là một tối ưu cục bộ có thể gây hại cho trạng thái hệ thống toàn cục, ngăn cản các đội ngũ đạt được cả hiệu quả chi phí và tính sẵn sàng cao đồng thời.

Bạn có thể làm gì

• Kiểm tra cụm của bạn để tìm các controller đồng thời nhắm mục tiêu vào cùng các tài nguyên, đặc biệt là kiểm tra việc sử dụng đồng thời HPA và VPA trên cùng các deployment.
• Đánh giá xem các chính sách auto-sync của GitOps có đang hoàn tác các sự kiện scaling hợp lệ hay không, và cân nhắc cấu hình cẩn thận việc bỏ qua các khác biệt về số lượng bản sao.
• Giám sát tỷ lệ giữa các yêu cầu tài nguyên đã khai báo và mức sử dụng thực tế để xác định nơi node autoscaler đang cung cấp năng lực dư thừa.
• Hợp nhất các tín hiệu scaling bằng cách chỉ sử dụng autoscaling hướng sự kiện cho các workload dựa trên hàng đợi, vô hiệu hóa HPA dựa trên CPU cho các dịch vụ cụ thể đó.
• Triển khai các chiến lược scaling dự đoán phân tích các mẫu tiêu thụ lịch sử để làm ấm năng lực trước khi các đợt tăng lưu lượng xảy ra.
• Tìm kiếm các giải pháp cung cấp một control plane thống nhất có khả năng tiếp nhận nhiều tín hiệu và đưa ra các quyết định chung về sizing ngang và dọc.