Kubernetes 1.36 (Haru) - Giải thích chi tiết
Kubernetes 1.36 (Haru) mang đến nhiều thay đổi đáng chú ý, đặc biệt trong cách nền tảng xử lý admission control, webhooks và độ ổn định của cụm Kubernetes. Một số cải tiến hứa hẹn giảm độ phức tạp trong vận hành, nhưng đồng thời cũng có những thay đổi có thể ảnh hưởng trực tiếp đến các môi trường production hiện tại nếu không được chuẩn bị kỹ. Trong bài viết này, chúng ta sẽ cùng tìm hiểu những điểm mới quan trọng của Kubernetes 1.36 và tác động thực tế của chúng đối với các team vận hành và phát triển.
Mutating Webhook đã lỗi thời. Hãy đến với CEL
Nếu từng vận hành admission webhooks trong môi trường production, bạn sẽ biết chúng có thể làm tăng độ trễ cho các yêu cầu API, tạo thêm thành phần cần quản lý và đôi khi trở thành điểm lỗi đơn lẻ (single point of failure) ảnh hưởng đến hoạt động của cụm Kubernetes.
Trong Kubernetes 1.36, tính năng MutatingAdmissionPolicies đã chính thức đạt trạng thái General Availability (GA). Thay vì phải triển khai các HTTP webhook bên ngoài, quản trị viên có thể định nghĩa trực tiếp các quy tắc mutation trong API server bằng Common Expression Language (CEL), giúp đơn giản hóa việc vận hành và giảm sự phụ thuộc vào các thành phần bên ngoài.
Ít thành phần hạ tầng hơn, giảm các điểm lỗi tiềm ẩn và mang lại cách tiếp cận đơn giản hơn trong việc quản lý admission policies trên Kubernetes.
# Example: Automatically inject an environment variable using CEL
apiVersion: admissionregistration.k8s.io/v1
kind: MutatingAdmissionPolicy
metadata:
name: inject-proxy-env
spec:
failurePolicy: Fail
matchConstraints:
resourceRules:
- apiGroups: [""]
apiVersions: ["v1"]
operations: ["CREATE"]
resources: ["pods"]
mutations:
- patchType: ApplyConfiguration
applyConfiguration:
expression: >
Object{
spec: Object{
containers: [
Object{
name: object.spec.containers[0].name,
env: [
Object{
name: "HTTP_PROXY",
value: "http://internal-proxy.acme.corp:8080"
}
]
}
]
}
}
MutatingAdmissionPolicies hoạt động trực tiếp bên trong API server, giúp loại bỏ nhu cầu sử dụng các webhook bên ngoài. Nhờ đó, Kubernetes không còn phải xử lý các kết nối mạng bổ sung, chứng chỉ TLS hay các pod webhook cần triển khai và giám sát.
Cách tiếp cận này giúp đơn giản hóa kiến trúc, giảm độ trễ và hạn chế các điểm lỗi tiềm ẩn. Đặc biệt, những sự cố phát sinh từ việc quá tải hoặc gián đoạn của admission webhook sẽ được giảm đáng kể, bởi toàn bộ logic xử lý được thực thi ngay trong Kubernetes thông qua CEL thay vì phụ thuộc vào một dịch vụ bên ngoài.
Ingress NGINX chính thức ngừng phát triển
Một trong những thay đổi đáng chú ý liên quan đến hệ sinh thái Kubernetes là việc Ingress NGINX đã chính thức được nhóm SIG Network và Security Response Committee ngừng hỗ trợ từ tháng 3/2026. Dự án sẽ không còn nhận các bản phát hành mới, bản sửa lỗi hay bản vá bảo mật.
Điều này đồng nghĩa với việc các cụm Kubernetes vẫn đang sử dụng Ingress NGINX sẽ phải đối mặt với rủi ro vận hành và bảo mật trong tương lai. Đồng thời, đây cũng là tín hiệu rõ ràng cho thấy Kubernetes đang thúc đẩy quá trình chuyển đổi sang Gateway API như tiêu chuẩn mới cho việc quản lý lưu lượng truy cập.
Các tổ chức chưa bắt đầu kế hoạch di chuyển sang các giải pháp hỗ trợ Gateway API như Envoy Gateway, Cilium hoặc các dịch vụ cloud-native tương đương nên cân nhắc lộ trình chuyển đổi để đảm bảo khả năng hỗ trợ và bảo mật lâu dài.
HPA hỗ trợ Scale to Zero
Một cải tiến đáng chú ý trong Kubernetes 1.36 là việc Horizontal Pod Autoscaler (HPA) bổ sung hỗ trợ Scale to Zero ở mức Alpha đối với các Object Metrics và External Metrics.
Trước đây, HPA yêu cầu tối thiểu một pod luôn phải hoạt động, khiến nhiều workload như queue workers hoặc các dịch vụ xử lý bất đồng bộ vẫn tiêu tốn tài nguyên ngay cả khi không có tác vụ cần xử lý. Với tính năng mới này, Kubernetes có thể giảm số lượng pod xuống 0 khi không có nhu cầu, giúp tối ưu việc sử dụng tài nguyên và giảm chi phí vận hành.
Đây là bước tiến quan trọng đối với các workload theo mô hình sự kiện (event-driven) hoặc xử lý theo hàng đợi, vốn trước đây thường phải sử dụng các giải pháp bổ sung như KEDA để đạt được khả năng scale-to-zero.
# The future of serverless K8s workloads
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: async-worker-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: queue-worker
minReplicas: 0 # <-- The magic number
maxReplicas: 50
metrics:
- type: External
external:
metric:
name: sqs_queue_length
target:
type: AverageValue
value: 1
Khi SQS queue đạt đến 0, hệ thống triển khai của bạn sẽ tự động thu nhỏ quy mô về 0. Khi một message được đưa vào queue, HPA sẽ khởi tạo lại các pod. Kết hợp điều này với Karpenter hoặc cluster-autoscaler, bạn sẽ đạt được kiến trúc serverless thu nhỏ quy mô về 0 thực sự, nguyên bản mà không làm mất đi khả năng kiểm soát của Kubernetes.
Không cần SSH nữa: Native Node Log Querying
Đã bao nhiêu lần bạn phải thực hiện các bước phức tạp như thiết lập VPN, tìm máy chủ trung gian, SSH vào worker node và chạy lệnh `journalctl -u kubelet` chỉ để tìm hiểu lý do tại sao một node hoạt động bất thường?
Trong phiên bản 1.36, tính năng Node Log Query được phát hành chính thức.
Giờ đây, bạn có thể pull log trực tiếp từ các node của mình bằng `kubectl` (với điều kiện các node service được ghi vào `/var/log` hoặc nhật ký hệ thống `systemd journal`).
# Get kubelet logs without leaving your local terminal
kubectl get --raw "/api/v1/nodes/kind-worker2/proxy/logs/?query=kubelet"
Bạn sẽ cần bật tính năng NodeLogQuery và enableSystemLogQuery trong cấu hình kubelet của bạn, nhưng một khi đã bật, SRE team của bạn sẽ không bao giờ cần phải SSH thủ công vào một node để gỡ lỗi thông thường nữa.
Tăng cường khả năng phòng thủ: User Namespaces đạt trạng thái ổn định
Nếu bạn đang vận hành các multi-tenant cluster, các lỗ hổng container từng là một cơn ác mộng. Trước đây, nếu một process thoát khỏi container thành công, nó có thể kế thừa quyền root trên node host, tạo ra nguy cơ nghiêm trọng đối với toàn bộ hệ thống.
Với phiên bản 1.36, hỗ trợ User Namespaces đã được nâng cấp lên trạng thái ổn định.
Bạn có thể ánh xạ người dùng root bên trong container sang một tài khoản không có đặc quyền trên máy chủ. Điều đó có nghĩa là ngay cả khi một lỗ hổng zero-day cho phép kẻ tấn công thoát khỏi container, chúng vẫn chỉ có thể truy cập vào một môi trường host bị cô lập với quyền hạn rất hạn chế. Đây được cho là cải tiến bảo mật quan trọng nhất đối với Kubernetes multi-tenant trong nhiều năm qua.
Dễ dàng kiểm tra trạng thái và cấu hình của control plane
Kubernetes 1.36 đưa ComponentStatusz và ComponentFlagz lên trạng thái Beta và bật mặc định. Tính năng này bổ sung các endpoint chuẩn /statusz và /flagz cho các thành phần cốt lõi của Kubernetes.
Nhờ đó, quản trị viên có thể nhanh chóng kiểm tra trạng thái hoạt động của một component hoặc xem các tham số dòng lệnh (command-line flags) thực tế mà component được khởi động cùng. Thay vì phải tìm kiếm trong cấu hình systemd hay các manifest của pod để xác minh thay đổi, giờ đây chỉ cần truy cập endpoint /flagz là có thể xem trực tiếp cấu hình đang được áp dụng.
Đây là một cải tiến hữu ích cho việc vận hành và khắc phục sự cố control plane, giúp quá trình kiểm tra và xác thực cấu hình trở nên nhanh chóng và minh bạch hơn.
Resource Observability thông minh hơn: PSI Metrics (GA)
Chúng ta đều đã thấy các node có mức sử dụng CPU ổn định nhưng vẫn gặp phải tình trạng latency không rõ nguyên nhân. Các số liệu truyền thống thường quá thô sơ để thể hiện mức độ tranh chấp resource.
Trong phiên bản 1.36, việc export số liệu Pressure Stall Information (PSI) dựa trên cgroup v2 đã được đưa lên trạng thái Stable. Thông qua kubelet, hệ thống có thể cung cấp các chỉ số về mức độ "áp lực" của CPU, memory và I/O thay vì chỉ hiển thị mức sử dụng tài nguyên thông thường. Thay vì chỉ trả lời câu hỏi "CPU đang được sử dụng bao nhiêu?", giờ đây người vận hành có thể biết "các pod đã phải chờ CPU hoặc bộ nhớ trong bao lâu?". Những thông tin này giúp phản ánh chính xác hơn tình trạng nghẽn tài nguyên và hiệu năng của workload. Đây là một bước đột phá trong việc điều chỉnh Vertical Pod Autoscaler (VPA) và phát hiện các trường hợp gây ảnh hưởng đến hiệu năng của các workload khác trong cùng hệ thống (noisy neighbor).
Lưu trữ nhanh hơn: SELinux Volume Labeling (Đã được phát hành chính thức)
Nếu bạn đang chạy các cluster thực thi SELinux, có lẽ bạn đã nhận thấy thời gian khởi động pod cực kỳ chậm khi gắn các ổ đĩa lớn. Đó là vì Kubernetes truyền thống phải duyệt file tree để relabel cho từng file.
Trong phiên bản 1.36, tính năng SELinux volume labeling nhanh hơn đã được phát hành chính thức, giúp giải quyết xử lý phức tạp đó bằng tùy chọn đơn giản `mount -o context=XYZ`, áp dụng label cho toàn bộ ổ đĩa tại thời điểm mount. Các pod với dataset lớn giờ đây sẽ khởi động gần như ngay lập tức, mặc dù điều này yêu cầu bạn phải đảm bảo storage driver của mình hỗ trợ tính năng này.
Tóm lại
Kubernetes 1.36 không chỉ đơn thuần là tinh chỉnh các endpoint; mà là một bước chuyển lớn trong cách nền tảng xử lý sự phức tạp.
Bằng việc đưa logic xác thực và biến đổi dữ liệu vào API server thông qua CEL, loại bỏ các thành phần định tuyến cũ như Ingress NGINX, và hỗ trợ scale-to-zero, Kubernetes đang thể hiện một định hướng rõ ràng: giảm phụ thuộc vào các giải pháp bên ngoài và tận dụng trực tiếp các thành phần cốt lõi của hệ thống.
Người dùng được khuyến nghị nâng cấp cluster, lên kế hoạch chuyển sang Gateway API và bắt đầu áp dụng CEL policies. Đây là những thay đổi quan trọng giúp hệ thống đơn giản hơn, ổn định hơn và dễ vận hành hơn trong dài hạn.
