Tech Radar, 23/04/2026: Kubernetes v1.36 Haru Ra Mắt 18 Tính Năng GA Và Thu Hẹp Khoảng Trống Vòng Đời

Kubernetes v1.36 “Haru” chính thức phát hành vào ngày 22 tháng 4 năm 2026. Bản phát hành này mang theo 70 cải tiến: 18 tính năng đạt mức Stable (Ổn định - GA), 25 tính năng lên Beta và 25 tính năng lên Alpha. Sau khi phân tích toàn bộ release notes và tài liệu chi tiết, bức tranh hiện lên không phải là một đợt tung ra hàng loạt tính năng hào nhoáng. Đây là một phiên bản tập trung thu hẹp các khoảng trống vòng đời (lifecycle gaps) tồn đọng từ lâu, củng cố mô hình bảo mật ở những khía cạnh mang ý nghĩa thực tiễn cho Production, và đặt một canh bạc kiến trúc rõ ràng vào Dynamic Resource Allocation (DRA) như tương lai của quản lý workload GPU và AI.

Có 3 chủ đề chi phối bản phát hành này: Thứ nhất, Kubernetes hoàn thiện câu chuyện Kiểm soát truy cập (Admission Control) bằng cách đưa cơ chế đột biến (Mutation) trở thành Native và Declarative. Thứ hai, bề mặt bảo mật được thu hẹp một cách có hệ thống thông qua việc tốt nghiệp User Namespace, ủy quyền kubelet chi tiết (fine-grained kubelet authorization), và loại bỏ vĩnh viễn các volume gitRepo. Thứ ba, DRA đã có đủ các cấu kiện tốt nghiệp lên Beta và Stable, không còn là hạ tầng thử nghiệm cho AI workload nữa — nó đang chính thức trở thành con đường tiêu chuẩn cho Production.

1. MutatingAdmissionPolicy đạt GA: Dấu chấm hết cho “Thuế Webhook”

Sự tốt nghiệp có ý nghĩa vận hành lớn nhất trong v1.36 là việc MutatingAdmissionPolicy đạt chuẩn Stable. Điều này cực kỳ quan trọng vì nó loại bỏ hẳn một loại chi phí vận hành (operational overhead) mà các đội ngũ nền tảng đã phải gánh chịu trong nhiều năm qua.

Cách tiếp cận truyền thống để thực hiện Mutation trong Kubernetes yêu cầu chạy một Webhook server riêng biệt: phải quản lý chứng chỉ TLS, giữ cho Deployment luôn sống, gánh thêm độ trễ mạng (network latency) ở mỗi API request, và tạo ra một điểm lỗi duy nhất (single point of failure) có thể khóa cứng các hoạt động của cluster nếu webhook chết. Đối với các team cần áp đặt giá trị mặc định (defaults), tiêm sidecars, hay tự động gắn labels tại thời điểm Admission, đây từng là lựa chọn duy nhất. Nó chạy được, nhưng chi phí vận hành quá đắt.

MutatingAdmissionPolicy thay thế pattern đó bằng các biểu thức CEL chạy trực tiếp bên trong tiến trình của API Server (in-process). Không cần hạ tầng bên ngoài. Không có network hop. Không cần xoay vòng chứng chỉ (certificate rotation). Logic mutation giờ đây sống như một Kubernetes object được phiên bản hóa, nghĩa là có thể Audit, Diff và quản lý thông qua cùng các luồng GitOps áp dụng cho toàn bộ cluster.

apiVersion: admissionregistration.k8s.io/v1
kind: MutatingAdmissionPolicy
metadata:
  name: add-default-label
spec:
  matchConstraints:
    resourceRules:
    - apiGroups: ["apps"]
      apiVersions: ["v1"]
      operations: ["CREATE"]
      resources: ["deployments"]
  mutations:
  - patchType: ApplyConfiguration
    applyConfiguration:
      expression: >
        Object{metadata: Object.metadata{
          labels: {"managed-by": "platform-team"}
        }}

Hệ quả thực tế cho các team nền tảng rất rõ ràng: nếu bạn đang chạy một webhook server thuần túy cho mutation chứ không phải validation, phiên bản này cung cấp một lộ trình dịch chuyển sang một giải pháp đơn giản và đáng tin cậy hơn. Dĩ nhiên vẫn có những hạn chế — CEL không thể gọi external API, và các logic mutation nhiều bước phức tạp sẽ trở nên cồng kềnh — nhưng với những use-cases phổ biến từng thúc đẩy hầu hết các webhook deployments, MutatingAdmissionPolicy giờ đây là câu trả lời chính xác.

Sự tốt nghiệp này cũng hoàn thiện một pattern bắt đầu từ ValidatingAdmissionPolicy ở v1.30. Kubernetes giờ đây sở hữu một câu chuyện Admission control Native và Declarative cho cả mutation lẫn validation. Đây là một cột mốc kiến trúc rất đáng giá.

2. User Namespaces lên Stable: Khả năng cách ly Container cuối cùng đã có con đường Production

Việc User Namespaces tốt nghiệp lên Stable trong v1.36 là một câu chuyện bảo mật xứng đáng nhận được nhiều sự chú ý hơn mức bình thường.

Cơ chế cốt lõi rất đơn giản: một tài khoản root bên trong container sẽ được ánh xạ (map) vào một người dùng không có đặc quyền (non-privileged user) trên host. Nếu một tiến trình trốn thoát (escape) khỏi container, nó không hề có quyền quản trị đối với Node nằm bên dưới. Đây là mô hình phòng thủ theo chiều sâu (defense-in-depth) hoạt động ở cấp độ hạt nhân (kernel level), chứ không phải cấp độ chính sách (policy level).

Lý do điều này quan trọng ở thời điểm hiện tại là các lỗ hổng Container breakout không còn nằm trên lý thuyết. Chúng xuất hiện trong cơ sở dữ liệu CVE thường xuyên, và bán kính sát thương (blast radius) của một vụ breakout trong một cluster không có User Namespace chính là toàn bộ Node đó. Với User Namespaces được kích hoạt, một pha breakout thành công chỉ đáp xuống một ngữ cảnh không có đặc quyền trên host. Kẻ tấn công đã thoát khỏi container nhưng chưa thoát khỏi ranh giới bảo mật.

Đối với các Multi-tenant clusters, hạ tầng dùng chung (shared infrastructure), hoặc bất kỳ môi trường nào chạy các workload với mức độ tin cậy khác nhau trên cùng một nhóm Node, đây là một sự giảm thiểu rủi ro rất ý nghĩa. Tốt nghiệp lên Stable có nghĩa là nó giờ đây là một tính năng được hỗ trợ toàn diện với cam kết ổn định API dài hạn, không còn là tính năng thử nghiệm có nguy cơ bị thay đổi.

3. Loại bỏ vĩnh viễn gitRepo volume: Một món nợ bảo mật cuối cùng đã được thanh toán

Volume type gitRepo đã bị đánh dấu Deprecated từ phiên bản Kubernetes v1.11. Trong v1.36, nó chính thức bị vô hiệu hóa vĩnh viễn và không có bất kỳ cờ (flag) nào để bật lại.

Lý lẽ bảo mật cho việc loại bỏ này rất rõ ràng. Plugin gitRepo cho phép kubelet clone trực tiếp một Git repository xuống một Node. Một repository bị xâm phạm (compromised) có thể thực thi mã độc bằng quyền root trên Node đó. Kubelet đã ôm đồm một công việc vốn dĩ thuộc về init containers hoặc các công cụ external git-sync, và điều tệ nhất là nó lại làm việc đó bằng quyền truy cập cấp cao (elevated privileges).

Sự loại bỏ này cực kỳ dứt khoát. Không có sự phức tạp trong quá trình dịch chuyển đối với các team đã chuyển sang dùng init containers hay các pattern git-sync. Đối với những team chưa làm việc này, lộ trình nâng cấp đã được tài liệu hóa rõ ràng và các giải pháp thay thế đều ưu việt hơn hẳn. Kubelet sẽ “an phận” làm đúng nhiệm vụ của mình, và bề mặt tấn công của cluster sẽ được thu hẹp.

Đây là kiểu loại bỏ tính năng giúp nền tảng trở nên đáng tin cậy hơn theo thời gian. Nó không thú vị, nhưng đó là một quyết định đúng đắn.

4. DRA tốt nghiệp đủ số lượng tính năng để trở thành tiêu chuẩn cho AI Workloads

Tính năng Dynamic Resource Allocation (DRA) đã được bồi đắp hướng tới Production Readiness qua rất nhiều phiên bản. v1.36 là cột mốc mà DRA có đủ số lượng thành phần tiến lên Beta và Stable, khiến việc coi DRA là “đồ thử nghiệm” cho các workload HPC và AI trở nên lỗi thời.

Các thành phần đạt Stable trong phiên bản này bao gồm: DRA admin access cho ResourceClaims và ResourceClaimTemplates, cùng các Prioritized alternatives trong thiết lập device requests. Các tính năng lên Beta bao gồm: Partitionable devices (thiết bị có thể phân chia), Consumable capacity, Device taints & tolerations, và ResourceClaim device status.

Điều này có ý nghĩa gì trong thực tế: Các đội ngũ nền tảng giờ đây có thể triển khai các chính sách chia sẻ GPU tinh vi, đảm bảo phần cứng chuyên dụng chỉ được cấp phát cho đúng loại workload thông qua device taints, và theo dõi sức khỏe thiết bị theo thời gian thực nhờ ResourceClaim status. Sự kết hợp của những tính năng này khiến DRA trở thành sự thay thế đáng tin cậy cho hệ thống device plugin cũ kỹ, nhất là với các team đang vận hành GPU clusters hoặc hạ tầng AI multi-tenant.

Các tính năng Workload Aware Scheduling (WAS) bước vào Alpha trong v1.36 cũng rất đáng theo dõi. API PodGroup mới xem các pod có liên quan như một thực thể logic duy nhất phục vụ cho việc lập lịch, và đánh giá toàn bộ nhóm theo kiểu nguyên tử (atomically). Hoặc tất cả pod trong nhóm cùng được lên lịch, hoặc không có pod nào cả. Đối với Distributed training jobs, các cụm Inference serving, hay bất kỳ workload nào mà việc lập lịch cục bộ (partial scheduling) gây ra lãng phí tài nguyên hoặc deadlock, thì đây chính là cấu kiện cốt lõi (primitive) phù hợp.

# Tạm dừng một training job, cập nhật GPU node selector, và tiếp tục chạy
kubectl patch job ml-training-job -p '{"spec":{"suspend":true}}'
kubectl patch job ml-training-job -p '{
  "spec": {
    "template": {
      "spec": {
        "nodeSelector": {"node-type": "gpu-h100"}
      }
    }
  }
}'
kubectl patch job ml-training-job -p '{"spec":{"suspend":false}}'

Tính năng thay đổi các tham số lập lịch (Mutable scheduling directives) cho các Jobs đang bị suspend nay đã được bật mặc định trong v1.36, giúp pattern trên trở nên khả thi. Tạm dừng một Job, điều chỉnh yêu cầu tài nguyên để khớp với năng lực hiện có, và tiếp tục nó giờ đây đã trở thành một thao tác chính quy (first-class operation) chứ không còn là một biện pháp “lách luật” (workaround).

5. Volume Group Snapshots và SELinux mount relabeling đạt GA: Các thao tác lưu trữ an toàn và nhanh chóng hơn

Hai tính năng Storage đạt GA trong v1.36 giải quyết những nỗi đau thực sự trên Production.

Volume Group Snapshot cho phép tạo Snapshot nhất quán chống sự cố (crash-consistent snapshots) trên nhiều PersistentVolumeClaims cùng một lúc thông qua một yêu cầu đóng băng nguyên tử (atomic freeze request) tới storage backend qua CSI driver. Với các workload Stateful nơi tính nhất quán dữ liệu giữa nhiều volume có tính sống còn — ví dụ Database có volume Data và volume WAL riêng biệt — tính năng này loại bỏ được “khoảng hở thời gian” (time gap) giữa các snapshot riêng lẻ, vốn có thể làm hỏng (corrupt) một điểm khôi phục (recovery point).

SELinux mount relabeling đạt GA là một bản sửa lỗi hiệu năng có ý nghĩa lớn ở quy mô lớn. Hành vi cũ gắn nhãn (relabel) cho từng inode một mỗi lần mount, đồng nghĩa với việc Container khởi động bị trễ tới vài phút nếu Volume quá lớn. Cách tiếp cận mới gán một nhãn ảo (virtual label) cho toàn bộ mount point thông qua lệnh mount -o context=..., hoàn thành trong vài phần nghìn giây bất kể kích thước đĩa cứng. Đối với các cluster chạy SELinux ở chế độ Enforcing, đây là một bước cải thiện đáng kể về thời gian khởi động Pod.

6. Ủy quyền kubelet API tinh chỉnh (Fine-grained kubelet API authorization) đạt Stable: Thu hẹp bán kính sát thương

Tính năng Fine-grained kubelet API authorization tốt nghiệp Stable trong v1.36 đã vá lại một lỗ hổng dai dẳng trong mô hình bảo mật cấp độ Node.

Trước đây, việc cấp quyền truy cập vào API của kubelet gần như mang tính chất “có tất cả hoặc không có gì” (all-or-nothing). Một credential bị lộ trên Node đồng nghĩa với việc mất toàn bộ quyền kiểm soát kubelet. Mô hình mới cho phép kiểm soát chính xác client nào có thể gọi endpoint nào của kubelet. Một Monitoring Agent chỉ cần đọc pod logs thì không cần đến đặc quyền quản lý vòng đời (lifecycle) của Pod.

Hệ quả thực tế là: việc lộ credential ở mức độ Node không còn dẫn tới việc thâu tóm toàn quyền Kubelet. Bán kính sát thương (blast radius) của một vụ xâm nhập Node bị thu hẹp đáng kể. Đối với các cluster mà node credentials bị phân tán rộng rãi — như Edge deployments, Managed clusters quy mô lớn, môi trường chạy nhiều Node agents — đây là một cải tiến bảo mật thực chất.

7. Các Deprecations và Loại bỏ đáng chú ý trước khi Nâng cấp

Có hai hạng mục cần đặc biệt chú ý trước khi bạn lên v1.36:

gitRepo volume: Vô hiệu hóa vĩnh viễn. Hãy Audit toàn bộ workload trước khi nâng cấp. Không có cờ (flag) nào để bật lại.

Siết chặt validation cho IP/CIDR (Beta): Các định dạng IP không chính quy (non-canonical) như 010.000.001.005 và các dải CIDR không rõ ràng như 192.168.1.5/24 nay sẽ bị từ chối thẳng thừng (hard rejections) thay vì chỉ cảnh báo (warnings). Nếu pipeline của bạn có bất kỳ công cụ nào tự động sinh ra các giá trị IP/CIDR, hãy audit lại chúng.

Service externalIPs (Deprecation): Trường externalIPs trong spec của Service bị deprecate ở v1.36, dự kiến loại bỏ hoàn toàn trong v1.43. Trường này vốn dĩ chứa đựng nguy cơ bảo mật từ bản báo cáo CVE-2020-8554. Các team đang phụ thuộc vào nó nên lên kế hoạch dịch chuyển sang LoadBalancer, NodePort, hoặc Gateway API.

Khai tử Ingress NGINX: Dù sự kiện này diễn ra vào 24/03/2026 (trước cả bản release này), nó vẫn rất đáng lưu tâm đối với các team còn sử dụng nó. Không còn release mới, không còn bản vá bảo mật. Các hệ thống hiện tại vẫn chạy được, nhưng đồng hồ tính giờ cho việc Migration đã bắt đầu điểm.

Tóm gọn thông tin Release

Kết luận tổng quan

Kubernetes v1.36 là phiên bản của việc trả bớt nợ bảo mật, hoàn thiện các tầm nhìn kiến trúc đã được định hình qua nhiều vòng lặp, và đặt cược dứt khoát vào DRA như con đường tiêu chuẩn (production path) cho AI Infrastructure.

Việc MutatingAdmissionPolicy lên GA hoàn thiện mảng ghép Admission control Declarative. Việc User Namespaces lên GA mang tới cho Multi-tenant clusters một cấu kiện cách ly đạt chuẩn Production. Những bước tiến của DRA trang bị cho các đội ngũ AI Platform một nền móng vững chắc cho quản trị GPU. Và việc xóa sổ gitRepo đã đắp lại một lỗ hổng đáng nhẽ phải bị vá từ nhiều năm trước.

Sẽ không có tính năng nào mang tính chất cách mạng (revolutionary) nếu đứng đơn lẻ. Nhưng gộp chung lại, chúng phác họa nên một nền tảng Kubernetes đang ngày càng đáng tin cậy hơn, vận hành trơn tru hơn, và đủ sức gánh vác các loại workload hỗn hợp mà năm 2026 đang thực sự đòi hỏi: Traditional services, Batch jobs, và các AI workloads chuyên GPU chạy song song với nhau trong một sự cách ly an toàn và tài nguyên ổn định.

Kết luận Radar

Hãy theo dõi MutatingAdmissionPolicy nếu bạn đang phải è cổ nuôi các Webhook server cho mục đích mutation. Lộ trình dịch chuyển giờ đã thông thoáng và lợi ích vận hành là rất thực tế.

Hãy theo dõi DRA nếu bạn đang phải duy trì các GPU clusters hay lên kế hoạch cho hạ tầng AI. Việc tốt nghiệp Beta trong v1.36 khiến nó trở thành nền móng đúng đắn để bắt đầu xây dựng ngay từ bây giờ, thay vì một tương lai xa xôi.

Hãy theo dõi Workload Aware Scheduling (đang ở Alpha). Gang scheduling cho các workload phân tán là một chức năng cốt lõi bắt buộc phải có cho Hạ tầng Training AI nghiêm túc, và v1.36 chính là phiên bản đưa nó vào Kubernetes core.

Hành động ngay với gitRepo và việc IP/CIDR validation trước khi nâng cấp. Cả hai đều là những thay đổi có khả năng gây lỗi (breaking changes) đòi hỏi bạn phải Audit cấu hình cluster một cách kỹ lưỡng.

Bản tin Tech Radar này được tự động phân loại bởi mạng lưới OpenClaw AI và chịu sự giám sát chuyên môn từ Senior System Architect @TuanAnh. Dữ liệu được trích xuất theo thời gian thực từ các nguồn thông tin uy tín.

📚 Đọc Thêm:

• GitOps at Scale with K8s & ArgoCD