How we replaced Ingress-NGINX at Stack Overflow

Stack Overflow · 2026 · 4. Điều chỉnh · Độ khó: Trung bình — bài gốc

Bài kể giai đoạn đánh giá và chọn; migration thật chưa làm lúc viết.

Bối cảnh

• 11/2025 dự án Kubernetes thông báo khai tử Ingress-NGINX, thứ định tuyến traffic của Stack Overflow từ khi lên Kubernetes. Gateway API (thay Ingress) đã được bàn nhưng không ai đầu tư vì cái cũ vẫn chạy tốt; giờ bị buộc phải đưa vào roadmap gần.

Thay đổi chính

• Thu hẹp lựa chọn: muốn nhân dịp chuyển sang Gateway API (tính năng mới, phân vai tốt hơn), giữ Ingress khác làm dự phòng nếu vướng. Tiêu chí: nằm trong danh sách triển khai conformant đầy đủ; không phụ thuộc một cloud (họ chạy cả GCP lẫn Azure); bảng tính năng 1.4 và một benchmark bên thứ ba. Còn ba Gateway: NGINX Gateway Fabric, Traefik, Istio; hai Ingress dự phòng (F5 NGINX, Traefik) bị loại sớm vì Traefik không phủ phần lớn annotation đang dùng, F5 dựa vào resource riêng thay vì kiểu chuẩn.
• Dựng test từ cấu hình thật: dump mọi Ingress object trên cụm production ra YAML, dùng Claude phân nhóm theo use case: phần lớn đơn giản, vài ngoại lệ, ra khoảng sáu test chức năng (backend HTTPBin để kiểm request/response, ví dụ ghi đè host header động) và hai benchmark scale (backend Go đơn giản có tham số latency giả lập).
• Kết quả chức năng: cả ba làm được; Istio đủ tính năng nhất. Một số tính năng Gateway API "đẹp trên giấy" nhưng nông (sửa header trong HTTPRoute chỉ nhận giá trị tĩnh), phải dùng extension riêng của từng bản. Xác thực qua auth_request của NGINX khác hẳn external authorization của Istio, buộc sửa ứng dụng.
• Benchmark: 10.000 RPS với 0/150/350 ms latency giả lập, 4 replica trên e2-standard-4: cả ba tương đương. 5.000 HTTPRoute: NGINX và Istio hội tụ khoảng 42 giây, Traefik hơn 5 phút. Nhưng với 5.000 route, chạy lại 10.000 RPS thì hỏng nặng; hạ mục tiêu còn 1.000 route mỗi gateway (đủ dùng). Sửa một route khi đang có tải: Istio và Traefik không ảnh hưởng, NGINX có gai latency lớn ở 1.000 route.
• Chọn Istio vì ổn định và hiệu năng xuyên suốt các test.

Vì sao

• Thành phần hạ tầng mã nguồn mở bị khai tử là migration bắt buộc theo lịch của người khác; nền tảng phải có quy trình đánh giá nhanh và thực tế (Nền tảng nội bộ cho service (đường ray chung), Migration không downtime).

Bài học cho SWE

• Đánh giá theo yêu cầu của chính mình (use case lấy từ cấu hình production, mục tiêu tải có khoảng dư) thay vì benchmark tổng quát.
• Đo cả hành vi khi cấu hình thay đổi dưới tải và thời gian hội tụ route, không chỉ RPS.
• "Chuẩn" (Gateway API) vẫn để lộ khác biệt ở các tích hợp phức tạp (auth); phần đó tốn thời gian migration nhất.

Liên quan

• Stack Overflow 2023 · Stack Overflow 2016 · Kubernetes (CNCF) 2024
• Migration không downtime · Nền tảng nội bộ cho service (đường ray chung)