Apache APISIX 3.19.0: xác thực chứng chỉ upstream bắt đầu có hiệu lực, cần rà soát gì trước khi nâng cấp
Bản phát hành Apache APISIX 3.19.0 thêm TLS passthrough cho stream, xử lý frame WebSocket, slow start cho upstream và plugin openapi-to-mcp, nhưng kèm nhiều thay đổi phá vỡ tương thích về xác thực chứng chỉ, OIDC và metric Prometheus.
Vibe DevOps biên soạn ngày · khoảng 570 từ
Điểm chính từ bài gốc
- Khóa upstream.tls.verify nay áp dụng cho upstream https và grpcs, không chỉ loại kafka như trước; chứng chỉ không được tin cậy hoặc sai hostname sẽ làm kết nối TLS thất bại, thường trả về 502.
- Plugin openid-connect khi dùng token introspection kèm danh sách issuer hợp lệ sẽ yêu cầu trường iss nằm trong danh sách đó, nếu không sẽ trả 401.
- Phiên WebSocket đi qua đường proxy cũ được gắn nhãn request_type là websocket trong các metric Prometheus, nên dashboard và alert đang lọc theo traditional_http cần xem lại.
- Plugin batch-requests mặc định giới hạn mỗi phản hồi con 1 MiB và tổng 10 MiB; basic-auth không còn chấp nhận mật khẩu rỗng.
- Tính năng mới gồm TLS passthrough và nhiều SNI cho stream route, xử lý frame WebSocket qua upstream ws hoặc wss, slow start cho upstream roundrobin, plugin openapi-to-mcp và giới hạn tốc độ theo chi phí truy vấn GraphQL.
Theo bài gốc
Các tính năng phục vụ vận hành
Cấu hình warm_up_conf cho phép node mới của upstream roundrobin bắt đầu với trọng số thấp rồi tăng dần, tránh dồn toàn bộ traffic vào instance chưa kịp làm nóng cache và connection pool. Mỗi instance APISIX tự theo dõi quá trình tăng trọng số một cách cục bộ. Ở chế độ standalone điều khiển qua API, tham số wait trên endpoint cấu hình giúp controller biết cấu hình đã được mọi worker áp dụng hay mới chỉ được chấp nhận.
Ghi chú phát hành cũng liệt kê nhiều bản sửa lỗi cho AI gateway, xác thực, etcd và health check. Một ví dụ dễ bị bỏ sót: Control API nay trả mảng rỗng thay vì object rỗng khi không có health checker, có thể làm hỏng client đang phân tích theo kiểu cũ.
Bình luận của Vibe DevOps — không phải nội dung bài gốc
Góc nhìn Vibe DevOps: nâng cấp gateway như một thay đổi rủi ro cao
Góc nhìn Vibe DevOps: API gateway nằm trên đường đi của mọi request, nên một bản phát hành có nhiều thay đổi phá vỡ tương thích như thế này cần được đối xử như thay đổi hạ tầng lớn chứ không phải cập nhật thường lệ. Điểm dễ gây sự cố nhất là việc bật xác thực chứng chỉ upstream: môi trường nội bộ dùng CA riêng hoặc gọi backend bằng địa chỉ IP thường chỉ lộ lỗi sau khi nâng cấp.
Cách an toàn là dựng staging dùng cấu hình thật, chạy kiểm thử cho từng route quan trọng và so sánh dashboard trước, sau khi nâng cấp, vì nhãn metric thay đổi có thể khiến alert im lặng mà không ai để ý. Hãy ghi rõ phương án rollback và chỉ tắt xác thực TLS như biện pháp tạm thời có hạn chót.
- Liệt kê upstream https, grpcs và kiểm tra SAN của chứng chỉ.
- Tìm các truy vấn PromQL đang lọc theo traditional_http.
- Rà soát consumer basic-auth và cấu hình batch-requests.
Lệnh và khoá cấu hình xuất hiện trong bài gốc
Trích nguyên văn từ nguồn để tra cứu; hãy đọc ngữ cảnh tại bài gốc trước khi áp dụng.
upstream.tls.verifyKhóa bật xác thực chứng chỉ cho upstream; từ bản này áp dụng cả https và grpcs.
warm_up_confKhối cấu hình slow start cho upstream roundrobin.
Lưu ý và giới hạn
- Theo ghi chú phát hành, slow start chỉ hỗ trợ upstream HTTP roundrobin một mức ưu tiên và bị từ chối trong traffic-split.
- Nhiều thay đổi không có tùy chọn tương thích để khôi phục hành vi cũ, nên cần sửa cấu hình trước khi nâng cấp.