Trong thế giới ứng dụng cloud-native, Kubernetes đã trở thành tiêu chuẩn de facto cho việc điều phối container. Tuy nhiên, một thách thức dai dẳng là việc scheduler không có khả năng hiểu được network topology bên ngoài cluster. Hạn chế này trở nên đặc biệt có vấn đề khi các ứng dụng cần giao tiếp với các dịch vụ bên ngoài như cơ sở dữ liệu, nơi độ trễ xuyên vùng có thể ảnh hưởng đáng kể đến hiệu suất và chi phí. Một giải pháp mới có tên Automatic Zone Placement đang tạo ra sự chú ý trong cộng đồng Kubernetes bằng cách giải quyết chính xác vấn đề này.
Vấn Đề Hiệu Suất Xuyên Vùng
Khi Kubernetes lập lịch trình cho các pod mà không nhận thức được vị trí của các tài nguyên bên ngoài, các ứng dụng có thể phải giao tiếp không cần thiết xuyên các availability zones. Điều này tạo ra hai vấn đề lớn: độ trễ tăng lên và chi phí chuyển dữ liệu cao hơn. Lưu lượng mạng cross-AZ trong các môi trường cloud như AWS phát sinh chi phí, và độ trễ giữa các zones, mặc dù có vẻ nhỏ, có thể tích lũy đáng kể trong các ứng dụng thực hiện nhiều lần gọi mạng.
Thảo luận trong cộng đồng tiết lộ rằng đây không chỉ là mối quan ngại lý thuyết. Một bình luận viên lưu ý rằng lưu lượng giữa các zones là chi phí lớn thứ hai trên hóa đơn AWS của chúng tôi, nhiều hơn chi phí EC2/EKS của chúng tôi, cộng dồn lên đến con số sáu chữu giữa mỗi năm. Một người tham gia khác quan sát thấy độ trễ cross-AZ thường đo được khoảng 0.7ms nhưng có thể tăng vọt lên 3-4ms trong một số trường hợp - một sự khác biệt về cấp số nhân trở nên quan trọng khi ứng dụng thực hiện hàng chục RPCs để phục vụ một yêu cầu duy nhất.
Hầu hết mọi người chấp nhận độ trễ tăng nhẹ để có tính sẵn sàng cao hơn, nhưng tôi đoán trong trường hợp này, điều đó là không thể chấp nhận được.
So sánh Tác động Hiệu suất
- Độ trễ cùng AZ: 0.119-0.187ms
- Độ trễ khác AZ: 0.548-0.658ms
- Cải thiện hiệu suất: Tăng 175-375% TPS
- Chi phí truyền dữ liệu: ~$0.01/GB giữa các AZ trong AWS
Cách Thức Hoạt Động Của Automatic Zone Placement
Giải pháp này sử dụng một kiến trúc hai thành phần thông minh hoạt động trong cơ sở hạ tầng Kubernetes hiện có. Một dịch vụ tra cứu nhẹ đóng vai trò là bộ não, lấy tên miền và ánh xạ chúng đến các availability zones cụ thể dựa trên các dải địa chỉ IP. Dịch vụ này sau đó tích hợp với Kubernetes thông qua một mutating webhook được cung cấp bởi Kyverno, nó chặn các yêu cầu tạo pod và tự động tiêm các quy tắc node affinity.
Điều làm cho cách tiếp cận này đặc biệt tinh tế là sự đơn giản và tự động hóa của nó. Thay vì yêu cầu các nhà phát triển tự cấu hình thủ công các quy tắc node affinity có thể trở nên lỗi thời khi các tài nguyên bên ngoài di chuyển trong các sự kiện bảo trì, hệ thống xác định động vị trí tối ưu tại thời điểm tạo pod. Giải pháp sử dụng các quy tắc affinity preferredDuringSchedulingIgnoredDuringExecution, có nghĩa là các pod sẽ cố gắng được lập lịch trong zone tối ưu nhưng vẫn có thể chạy ở nơi khác nếu cần thiết.
Các Thành Phần Giải Pháp
- Lookup Service: API dựa trên Python để ánh xạ IP tới các zone
- Mutating Webhook: Công cụ chính sách dựa trên Kyverno
- Affinity Type: preferredDuringSchedulingIgnoredDuringExecution
- Yêu cầu: FQDN bản ghi A đơn, ánh xạ subnet đã biết
Các Câu Hỏi và Cân Nhắc Từ Cộng Đồng
Cuộc thảo luận xung quanh công cụ này tiết lộ một số cân nhắc quan trọng cho việc sử dụng trong môi trường production. Một câu hỏi then chốt được đặt ra là về việc xử lý các kịch bản failover: Làm thế nào bạn xử lý các lần failover của RDS? Mutating Webhook chỉ được kích hoạt khi Pods được tạo, vì vậy nếu AZ zone không gặp sự cố, sẽ không có pods nào được tạo và các quy tắc affinity cần được thay đổi.
Người tạo ra công cụ này đã thừa nhận hạn chế này trong triển khai hiện tại, gợi ý rằng các chính sách quét nền có thể được thêm vào để kiểm tra định kỳ và cập nhật các deployments khi vị trí tài nguyên bên ngoài thay đổi. Điều này làm nổi bật bản chất động của các môi trường cloud, nơi vị trí tài nguyên không phải là tĩnh.
Một bình luận viên khác đã đặt câu hỏi về nhu cầu cơ bản cho một công cụ như vậy, gợi ý rằng các triển khai single-zone có thể là đủ cho nhiều tổ chức. Tuy nhiên, dữ liệu hiệu suất được trình bày kể một câu chuyện hấp dẫn - các điểm chuẩn cho thấy sự cải thiện 175% đến 375% về số lượng giao dịch mỗi giây khi các pod được đặt cùng chỗ với cơ sở dữ liệu của chúng trong cùng một availability zone.
Hàm Ý Rộng Hơn và Định Hướng Tương Lai
Khái niệm đằng sau Automatic Zone Placement có ý nghĩa vượt ra ngoài các kịch bản AWS RDS. Các bình luận viên lưu ý rằng các cách tiếp cận tương tự có thể hoạt động cho các triển khai on-premise, nơi khối lượng công việc có thể được lập lịch dựa trên sự gần gũi về mặt vật lý với các tài nguyên trong các racks, rows hoặc data centers cụ thể. Người tạo công cụ đã đề cập đến việc đang làm việc trên các phần mở rộng cho các dịch vụ multi-AZ và các tối ưu hóa định tuyến lưu lượng.
Một thành viên cộng đồng chỉ ra rằng giải pháp hiện tại yêu cầu ánh xạ tĩnh thông tin subnet, gợi ý rằng các phiên bản trong tương lai có thể tự động thu thập dữ liệu này thông qua các cloud provider APIs. Điều này sẽ làm cho công cụ dễ thích ứng hơn với các môi trường động, nơi cấu hình mạng thay đổi thường xuyên.
Chỉ số độ trễ AWS (vùng eu-central-1)
- Cùng AZ: 0.164ms (az1), 0.119ms (az2), 0.187ms (az3)
- Khác AZ: 0.556ms (az1-az2), 0.548ms (az1-az3), 0.658ms (az2-az3)
Kết Luận
Automatic Zone Placement đại diện cho một bước tiến quan trọng trong việc làm cho Kubernetes thông minh hơn về nhận thức hạ tầng. Bằng cách thu hẹp khoảng cách giữa lập lịch cluster và vị trí tài nguyên bên ngoài, nó giải quyết các mối quan tâm thực tế về hiệu suất và chi phí mà nhiều tổ chức phải đối mặt trong môi trường production. Mặc dù giải pháp có những hạn chế xung quanh việc xử lý failover và yêu cầu một số cấu hình thủ công, khái niệm này chứng minh cách Kubernetes có thể phát triển để hiểu rõ hơn và tối ưu hóa cho hệ sinh thái hạ tầng rộng lớn hơn mà nó hoạt động trong đó. Khi các công nghệ cloud-native trưởng thành, các công cụ như thế này làm nổi bật nhu cầu liên tục cho việc sắp xếp tài nguyên thông minh hơn và tối ưu hóa mạng trong các hệ thống phân tán.
Tham khảo: Automatic zone placement service