Mixed Version Proxy K8s 1.36: Nâng Cấp Cluster An Toàn Hơn, Không Còn 404 Giả

Karify98 & Amy 🌸·
Cover Image for Mixed Version Proxy K8s 1.36: Nâng Cấp Cluster An Toàn Hơn, Không Còn 404 Giả
#kubernetes#devops#cluster#upgrade

Nâng cấp Kubernetes cluster luôn là bài toán đau đầu với team DevOps. Trong một control plane nhiều node, khi tiến hành rolling upgrade, các API server sẽ chạy phiên bản khác nhau trong một khoảng thời gian ngắn. Phiên bản mới hơn có thể phục vụ các API resource mà phiên bản cũ chưa biết đến.

Không có Mixed Version Proxy (MVP), request gửi đến API server cũ sẽ nhận về HTTP 404. Đây là lỗi sai về mặt logic — resource vẫn tồn tại trong cluster, chỉ là API server đó không phục vụ được. Hậu quả có thể nghiêm trọng: garbage collection nhầm, namespace deletion bị chặn, hoặc controller loop hoạt động sai.

MVP hoạt động thế nào

MVP giải quyết vấn đề bằng cách proxy request sang peer API server có khả năng xử lý. Quy trình gồm bốn bước:

  1. Client gửi request đến API Server A (phiên bản cũ hơn).
  2. API Server A kiểm tra discovery cache, phát hiện mình không phục vụ được resource này.
  3. Request được proxy sang API Server B (phiên bản mới hơn) kèm header x-kubernetes-peer-proxied.
  4. API Server B xử lý và trả kết quả về cho client thông qua API Server A.

Cải tiến từ Alpha lên Beta

Từ phiên bản Alpha trong K8s 1.28 đến Beta trong 1.36, MVP đã được hiện đại hóa đáng kể:

Aggregated Discovery thay thế StorageVersion API. Phiên bản Alpha dùng StorageVersion API để xác định peer nào phục vụ resource nào. Cách này có hạn chế: không hỗ trợ CRD và aggregated API. Beta chuyển sang Aggregated Discovery — mỗi API server tự động hiểu được khả năng của peer thông qua discovery data.

Peer-Aggregated Discovery. Khi client thực hiện discovery request, API server sẽ merge dữ liệu local với discovery data từ tất cả peer đang hoạt động. Client nhận được một danh sách API thống nhất, đầy đủ trên toàn cluster, bất kể kết nối vào API server nào.

Nếu cần kiểm tra resource của một API server cụ thể, thêm profile=nopeer vào Accept header.

Cấu hình cần thiết

Feature gate UnknownVersionInteroperabilityProxy sẽ bật mặc định trong 1.36. Tuy nhiên, cần cấu hình các flag sau để MVP hoạt động:

  • --peer-ca-file: Bắt buộc. CA bundle dùng để xác thực chứng chỉ của peer API server. Không có flag này, proxy sẽ thất bại do lỗi TLS.
  • --peer-advertise-ip và --peer-advertise-port: Địa chỉ mạng mà peer dùng để kết nối đến API server này. Với topology mạng phức tạp, nên thiết lập tường minh.

Với kubeadm, cấu hình trong ClusterConfiguration:

apiVersion: kubeadm.k8s.io/v1beta4
kind: ClusterConfiguration
apiServer:
  extraArgs:
    peer-ca-file: "/etc/kubernetes/pki/ca.crt"

Tại sao developer cần quan tâm

MVP không chỉ là tính năng dành cho admin cluster. Developer triển khai ứng dụng lên Kubernetes cần hiểu tại sao nâng cấp cluster đôi khi gây ra lỗi 404 khó giải thích — đặc biệt khi dùng CRD từ operator như cert-manager, Istio, hoặc Prometheus. MVP giúp loại bỏ hoàn toàn class lỗi này.

Với việc MVP bật mặc định trong K8s 1.36, team DevOps có thêm một lớp bảo vệ tự động trong quá trình nâng cấp. Chỉ cần đảm bảo --peer-ca-file được cấu hình đúng — phần còn lại Kubernetes tự xử lý.