Kubernetes 1.37 có gì mới cho DevOps và Platform?

Vừa mới đây, những ngày cuối của 08/2026, Kubernetes 1.37 chính thức được phát hành với tên gọi Garhwal. Nếu chỉ nhìn vào con số, đây là một bản cập nhật khá lớn với tổng cộng 67 enhancement, trong đó 16 tính năng đạt trạng thái Stable, 23 tính năng lên Beta và 27 tính năng mới bước vào giai đoạn Alpha.

Kubernetes 1.37 cho thấy dự án đang tiếp tục dịch chuyển từ một nền tảng điều phối container thành một lớp hạ tầng ngày càng phù hợp hơn với những workload phức tạp, đặc biệt là AI, machine learning, hệ thống xử lý theo hàng đợi và các cluster quy mô lớn.

Trong bài viết này, DevOps VietNam sẽ tập trung vào những điểm mới của Kubernetes 1.37 có khả năng tác động rõ nhất tới DevOps Engineer, SRE và Platform Engineer.

Kubernetes 1.37 không chỉ là một bản cập nhật thông thường

Trong nhiều năm, Kubernetes đã giải quyết rất tốt câu chuyện chạy ứng dụng phân tán.

Bạn khai báo workload cần bao nhiêu replica, scheduler tìm node phù hợp, controller giữ trạng thái thực tế gần với trạng thái mong muốn và Kubernetes xử lý phần lớn công việc còn lại.

Nhưng workload hiện tại đã khác rất nhiều so với vài năm trước.

Một cluster có thể phải phục vụ API thông thường vào ban ngày, chạy batch processing vào ban đêm, xử lý queue theo thời gian thực và đồng thời cung cấp GPU cho những job huấn luyện machine learning.

Với những workload như vậy, việc scheduler chỉ nhìn từng Pod riêng lẻ hay autoscaler luôn phải duy trì ít nhất một Pod bắt đầu trở thành giới hạn.

Kubernetes 1.37 giải quyết khá nhiều vấn đề thuộc nhóm này.

1. Horizontal Pod Autoscaler cuối cùng có thể scale workload về 0

Một trong những thay đổi dễ thấy giá trị nhất trong Kubernetes 1.37 là khả năng scale về 0 của Horizontal Pod Autoscaler đã lên Beta và được bật mặc định.

Trước đây, khi sử dụng Horizontal Pod Autoscaler, workload thường phải duy trì ít nhất một Pod đang chạy.

Điều này không phải vấn đề lớn với các API luôn có traffic. Nhưng với queue consumer, batch worker hoặc workload sử dụng GPU, việc giữ một Pod hoạt động trong khi không có công việc có thể đồng nghĩa với tài nguyên bị lãng phí liên tục.

Kubernetes 1.37 cho phép cấu hình:

spec:
  minReplicas: 0

Khi không còn công việc, Horizontal Pod Autoscaler có thể đưa workload xuống 0 Pod. Khi nhu cầu quay trở lại, hệ thống có thể tăng số replica trở lại dựa trên metric phù hợp.

Điểm cần lưu ý là cơ chế này được thiết kế cho object metric hoặc external metric.

Bạn không thể scale từ 0 dựa đơn thuần vào CPU hoặc memory vì khi không còn Pod chạy thì cũng không còn Pod để tạo ra những metric đó.

Một ví dụ phù hợp hơn là số lượng message đang chờ trong queue.

Khi queue bằng 0, workload có thể về 0 replica.

Khi queue xuất hiện 500 message, metric bên ngoài thay đổi và Horizontal Pod Autoscaler có cơ sở để kích hoạt workload trở lại.

Đối với những tổ chức đang vận hành worker theo sự kiện hoặc workload GPU có chi phí cao, thay đổi này có thể mang lại giá trị thực tế đáng kể.

Kubernetes đang tiến gần hơn tới mô hình chỉ sử dụng tài nguyên khi thực sự có công việc cần xử lý.

2. Gang Scheduling tiến lên Beta và đây là tin đáng chú ý cho AI workload

Scheduler truyền thống của Kubernetes xử lý Pod theo từng đơn vị riêng lẻ.

Điều đó rất hợp lý đối với web application thông thường.

Nhưng hãy tưởng tượng một job machine learning cần 8 Pod và mỗi Pod cần một GPU.

Cluster hiện chỉ còn tài nguyên cho 5 Pod.

Scheduler có thể đưa 5 Pod vào chạy trong khi 3 Pod còn lại tiếp tục ở trạng thái Pending. Nếu job yêu cầu toàn bộ worker cùng xuất hiện trước khi thực sự bắt đầu tính toán, 5 GPU vừa được cấp phát gần như không tạo ra giá trị.

Đây chính là kiểu vấn đề mà Gang Scheduling muốn giải quyết.

Trong Kubernetes 1.37, Gang Scheduling đã lên Beta thông qua Workload API và khái niệm PodGroup. Scheduler có thể xem một nhóm Pod như một workload thống nhất và chỉ tiến hành scheduling khi cluster có đủ tài nguyên cần thiết để workload có thể thực sự chạy.

Thay vì tư duy:

Có tài nguyên cho Pod nào thì chạy Pod đó.

Scheduler có thể tiến gần hơn tới tư duy:

Chỉ cấp tài nguyên khi workload có đủ điều kiện để tiến lên.

Sự khác biệt này đặc biệt quan trọng với distributed training, HPC và các workload yêu cầu nhiều accelerator.

Kubernetes từ lâu đã có thể chạy AI workload. Kubernetes 1.37 cho thấy cộng đồng đang đầu tư sâu hơn vào việc làm cho scheduler thực sự hiểu đặc điểm của loại workload này.

3. Scheduler bắt đầu hiểu workload thay vì chỉ hiểu Pod

Kubernetes 1.37 cũng đưa Workload Aware Preemption lên Beta.

Trong cơ chế scheduling truyền thống, preemption chủ yếu được xem xét ở mức Pod.

Giả sử một workload ưu tiên cao cần 8 Pod để chạy. Scheduler có thể loại bỏ một số Pod ưu tiên thấp nhằm tạo thêm tài nguyên.

Nhưng nếu lượng tài nguyên vừa giải phóng vẫn không đủ cho toàn bộ workload cần thiết, việc preemption đó gần như vô nghĩa. Cluster vừa làm gián đoạn workload khác nhưng workload quan trọng hơn vẫn chưa thể chạy.

Workload Aware Preemption cho phép scheduler hiểu PodGroup khi đưa ra quyết định này.

Đây là một thay đổi quan trọng về cách Kubernetes nhìn nhận scheduling.

Pod vẫn là đơn vị thực thi cơ bản.

Nhưng scheduler ngày càng cần hiểu rằng nhiều Pod thực tế thuộc về cùng một công việc và việc tối ưu từng Pod độc lập chưa chắc tạo ra trạng thái tốt nhất cho toàn hệ thống.

Với những cluster chạy nhiều batch job, AI workload hoặc workload có priority khác nhau, đây là một hướng phát triển rất đáng theo dõi.

4. KYAML chính thức đạt trạng thái Stable

YAML gần như đã trở thành một phần không thể tách rời khỏi Kubernetes.

Deployment, Service, ConfigMap, Ingress hay hầu hết tài nguyên khác đều thường được khai báo bằng YAML.

Nhưng YAML cũng nổi tiếng vì có nhiều cách biểu diễn dữ liệu và đôi khi tạo ra những trường hợp khó đọc hoặc dễ gây hiểu nhầm.

Kubernetes 1.37 đưa KYAML lên Stable.

KYAML là một tập con chặt chẽ hơn của YAML được thiết kế cho Kubernetes. Điều quan trọng là KYAML không thay thế YAML và cũng không yêu cầu các tổ chức phải chuyển toàn bộ manifest hiện tại sang định dạng mới.

Mọi tài liệu KYAML hợp lệ vẫn là YAML hợp lệ. Các manifest hiện tại và pipeline hiện tại không bắt buộc phải thay đổi.

Điểm hữu ích nằm ở khả năng biểu diễn cấu hình theo cách nhất quán và ít mơ hồ hơn.

Trong Kubernetes 1.37, bạn có thể sử dụng output KYAML ổn định từ kubectl để quan sát tài nguyên theo định dạng này.

Với một developer chạy vài manifest nhỏ, đây có thể chưa phải thay đổi gây ấn tượng ngay lập tức.

Nhưng với tổ chức sở hữu hàng nghìn manifest, nhiều repository GitOps và hàng chục platform team cùng quản lý cấu hình, việc giảm sự mơ hồ của YAML có giá trị lớn hơn rất nhiều.

5. Control plane chịu tải tốt hơn khi watch cache khởi tạo

Một trong những thay đổi ít nổi bật hơn nhưng rất đáng chú ý với SRE là Resilient Watch Cache Initialization.

Trong cluster Kubernetes lớn, API server và etcd liên tục phải xử lý một lượng lớn thao tác list và watch.

Khi watch cache đang khởi tạo hoặc khởi tạo lại, một lượng request lớn có thể đồng thời đổ xuống etcd. Nếu không kiểm soát tốt, đây có thể trở thành một đợt tăng tải đột biến ngay tại thành phần quan trọng nhất của control plane.

Kubernetes 1.37 hoàn thiện cơ chế giúp quá trình này diễn ra an toàn hơn.

Thay vì để lượng request đắt đỏ tiếp tục tích tụ và tạo áp lực lên etcd, API server có thể giới hạn request và trả HTTP 429 Too Many Requests khi cần thiết.

Điều này đặc biệt có ý nghĩa với cluster lớn hoặc hệ thống có rất nhiều custom controller và operator.

Với những đội tự phát triển controller, thay đổi này cũng đặt ra một yêu cầu đáng chú ý.

Client phải xử lý HTTP 429 đúng cách.

Controller nên tôn trọng thông tin Retry After và áp dụng exponential backoff thay vì lập tức gửi request liên tục trở lại API server.

Đây không phải feature mà developer nhìn thấy trên giao diện ứng dụng, nhưng lại là kiểu thay đổi có thể giúp một cluster lớn ổn định hơn trong những thời điểm control plane chịu áp lực.

6. Kubernetes đang chuẩn bị tốt hơn cho cluster chạy nhiều phiên bản node

Nâng cấp Kubernetes hiếm khi diễn ra bằng cách thay toàn bộ cluster trong một thời điểm.

Trong thực tế, control plane và worker node thường trải qua quá trình rolling upgrade. Điều đó đồng nghĩa trong một khoảng thời gian, cluster có thể tồn tại nhiều phiên bản Kubernetes khác nhau.

Kubernetes 1.37 đưa Node Declared Features lên Stable.

Node giờ có thể công bố những feature nhất định mà nó hỗ trợ thông qua trạng thái của Node. Control plane có thể sử dụng thông tin đó để đưa ra hành vi phù hợp khi cluster đang tồn tại version skew.

Nghe có vẻ giống một chi tiết nội bộ, nhưng đây là một mảnh ghép quan trọng để Kubernetes xử lý upgrade an toàn hơn khi hệ thống ngày càng có nhiều feature gate và khả năng khác nhau giữa các node.

Thay vì control plane phải suy đoán khả năng của node dựa chủ yếu vào phiên bản, Kubernetes đang tiến tới cơ chế node tự khai báo khả năng của chính nó.

Đối với các cluster lớn cần rolling upgrade trong thời gian dài, hướng tiếp cận này đặc biệt có ý nghĩa.

7. Kubernetes tiếp tục đầu tư mạnh vào Dynamic Resource Allocation

Nếu phải chọn một khu vực đáng theo dõi trong vài phiên bản Kubernetes gần đây, Dynamic Resource Allocation chắc chắn nằm trong danh sách.

CPU và memory tương đối đơn giản.

GPU, FPGA, network device và nhiều loại accelerator khác thì không như vậy.

Những tài nguyên này có topology, thuộc tính phần cứng, khả năng chia sẻ và yêu cầu scheduling phức tạp hơn rất nhiều.

Kubernetes 1.37 tiếp tục mở rộng Dynamic Resource Allocation với nhiều thay đổi ở cả Stable, Beta và Alpha.

Một điểm đáng chú ý là ResourceClaim dành cho workload đã lên Beta. Workload và PodGroup có thể liên kết với ResourceClaim hoặc ResourceClaimTemplate thay vì mỗi Pod phải quản lý tài nguyên chuyên dụng hoàn toàn độc lập.

Điều này kết hợp khá tự nhiên với hướng phát triển của Gang Scheduling.

Một training job không chỉ cần 8 Pod.

Nó có thể cần 8 GPU với những đặc điểm nhất định, topology phù hợp và cách cấp phát tài nguyên thống nhất cho toàn workload.

Khi nhìn Gang Scheduling, Workload Aware Scheduling và Dynamic Resource Allocation cùng nhau, hướng phát triển của Kubernetes trở nên khá rõ ràng.

Kubernetes đang xây dựng nền tảng scheduling phù hợp hơn cho thế hệ workload sử dụng tài nguyên phần cứng chuyên dụng.

8. Metric của container và Pod dần bớt phụ thuộc vào cAdvisor

Trong lịch sử, kubelet sử dụng cAdvisor để thu thập nhiều thông tin thống kê liên quan tới container và Pod.

Trong khi đó, Container Runtime Interface cũng có khả năng cung cấp metric.

Việc tồn tại hai nguồn dữ liệu cho cùng một nhóm thông tin khiến kiến trúc trở nên phức tạp hơn và đôi khi gây khó khăn khi cần xác định metric thực sự xuất phát từ đâu.

Trong Kubernetes 1.37, cơ chế lấy đầy đủ thống kê Pod và container trực tiếp từ Container Runtime Interface đã lên Beta.

Mục tiêu là đưa hệ thống tiến gần hơn tới một nguồn dữ liệu thống nhất và giảm phần thu thập metric bị trùng lặp.

Tính năng này ở Kubernetes 1.37 vẫn chưa được bật mặc định, vì vậy đây chưa phải thứ các cluster hiện tại sẽ lập tức cảm nhận được sau khi nâng cấp.

Tuy nhiên, về mặt kiến trúc, nó cho thấy kubelet đang tiếp tục giảm sự phụ thuộc vào những thành phần lịch sử khi runtime interface ngày càng trưởng thành.

9. StatefulSet có thêm chiến lược Recreate

StatefulSet trước đây chủ yếu có hai chiến lược cập nhật là RollingUpdate và OnDelete.

Kubernetes 1.37 bổ sung một lựa chọn mới ở trạng thái Alpha mang tên Recreate.

Với chiến lược này, các Pod hiện tại của StatefulSet có thể được xóa trước khi những Pod mới dựa trên template cập nhật được tạo ra.

Đây không phải chiến lược phù hợp với mọi workload.

Stateful application thường yêu cầu rất nhiều sự cẩn trọng đối với thứ tự khởi động, dữ liệu và availability.

Nhưng có những hệ thống mà việc giữ hai phiên bản workload tồn tại đồng thời trong quá trình rollout là điều không mong muốn hoặc thậm chí không thể chấp nhận.

Recreate cung cấp thêm một lựa chọn cho những trường hợp như vậy.

Do tính năng vẫn ở Alpha, đây phù hợp hơn để thử nghiệm và đánh giá hơn là lập tức đưa vào hệ thống production quan trọng.

10. Node có ngôn ngữ rõ ràng hơn cho maintenance và shutdown

Một vấn đề rất thực tế khi vận hành Kubernetes là trạng thái của node đôi khi nằm rải rác giữa Kubernetes và hệ thống quản lý hạ tầng bên ngoài.

Một node đang chuẩn bị maintenance.

Một node đang được drain.

Một node chuẩn bị shutdown có kiểm soát.

Các công cụ khác nhau có thể biết những thông tin này nhưng Kubernetes chưa chắc có một biểu diễn thống nhất để toàn bộ controller và automation cùng hiểu.

Kubernetes 1.37 giới thiệu ở trạng thái Alpha một nhóm Node Condition mới dành cho lifecycle, bao gồm trạng thái đang drain, đã drain, chuẩn bị maintenance, đang maintenance và đang thực hiện graceful shutdown.

Đây có thể trở thành nền tảng rất hữu ích cho automation.

Ví dụ, hệ thống quản lý máy chủ có thể thông báo cho Kubernetes rằng một node chuẩn bị maintenance. Những controller khác có thể đọc cùng trạng thái đó và phản ứng phù hợp thay vì mỗi hệ thống phải tự tạo một cơ chế riêng.

Đối với Platform Engineering, loại khả năng này thường đáng giá hơn vẻ ngoài của nó vì nó tạo ra một ngôn ngữ chung giữa orchestration và infrastructure automation.

11. Networking tiếp tục được tối ưu với nftables

Kubernetes đã dần đưa nftables trở thành một hướng quan trọng cho networking trên Linux.

Trong Kubernetes 1.37, quá trình quản lý rule của nftables được tối ưu thêm khi Kubernetes giao tiếp trực tiếp với netlink của kernel thay vì phải đi qua công cụ dòng lệnh nft cho mỗi thao tác.

Lợi ích chính là giảm overhead khi kiểm tra và cập nhật rule.

Ở cluster nhỏ, khác biệt có thể không dễ nhận ra.

Nhưng khi số lượng Service và rule mạng tăng lên, chi phí quản lý networking cũng tăng theo. Việc loại bỏ một tầng trung gian có thể giúp quá trình đồng bộ rule hiệu quả hơn.

Đây tiếp tục là dấu hiệu cho thấy networking stack của Kubernetes đang được hiện đại hóa thay vì chỉ duy trì các cơ chế cũ.

12. cgroup v1 đang ngày càng gần ngày rời khỏi Kubernetes

Kubernetes 1.37 cũng gửi một tín hiệu khá rõ cho những cluster Linux cũ.

cgroup v2 là hướng đi chính.

Từ Kubernetes 1.35, cấu hình failCgroupV1 đã mặc định là true. Điều đó có nghĩa kubelet có thể từ chối khởi động trên node vẫn sử dụng cgroup v1 nếu administrator không chủ động thay đổi cấu hình. Kubernetes 1.37 vẫn cho phép override hành vi này, nhưng tài liệu chính thức xem đây là giải pháp tạm thời.

Nhiều khả năng quản lý tài nguyên hiện đại của Kubernetes cũng phụ thuộc vào cgroup v2.

Nếu tổ chức vẫn đang vận hành worker node dựa trên cgroup v1, Kubernetes 1.37 là một lời nhắc khá rõ rằng kế hoạch migration không nên tiếp tục bị trì hoãn.

13. kube dns chính thức bước sâu hơn vào quá trình bị loại bỏ

CoreDNS đã trở thành DNS mặc định của Kubernetes từ phiên bản 1.13.

Tuy nhiên vẫn tồn tại những môi trường cũ sử dụng kube dns.

Trong Kubernetes 1.37, kube dns tiếp tục nằm trong lộ trình deprecation. Một trong những lý do quan trọng là thành phần này không còn theo kịp các khả năng mới của Kubernetes như EndpointSlice và Service hỗ trợ dual stack.

Với cluster hiện đại, điều này gần như không tạo ra ảnh hưởng vì CoreDNS đã là lựa chọn tiêu chuẩn trong nhiều năm.

Nhưng với những tổ chức sở hữu cluster tồn tại lâu hoặc có quá trình nâng cấp qua nhiều thế hệ Kubernetes, đây là thứ nên được đưa vào checklist trước khi tiếp tục nâng cấp.

Kubernetes 1.37 nói gì về tương lai của Kubernetes?

Nếu chỉ xem release note, Kubernetes 1.37 có thể trông giống một tập hợp lớn những enhancement không liên quan tới nhau.

Nhưng khi đặt chúng cạnh nhau, một số xu hướng bắt đầu xuất hiện.

• Kubernetes muốn hiểu workload tốt hơn.
• Gang Scheduling, PodGroup, Workload Aware Preemption và ResourceClaim đều cho thấy scheduler đang tiến xa hơn khỏi mô hình chỉ xem từng Pod như một đơn vị độc lập.
• Kubernetes muốn sử dụng tài nguyên hiệu quả hơn.
• Horizontal Pod Autoscaler có thể scale về 0 giúp những workload không hoạt động không còn bắt buộc phải duy trì replica chỉ để chờ công việc.
• Kubernetes muốn trở thành nền tảng tốt hơn cho AI và accelerator.
• Dynamic Resource Allocation, Gang Scheduling và những cải tiến liên quan tới topology đều trực tiếp giải quyết các bài toán xuất hiện khi GPU và phần cứng chuyên dụng trở thành tài nguyên quan trọng trong cluster.

Cuối cùng, Kubernetes vẫn tiếp tục đầu tư vào độ ổn định ở tầng nền.

Watch cache an toàn hơn, cải thiện quản lý nftables, Node Declared Features và việc đơn giản hóa nguồn metric đều không phải những tính năng thường xuất hiện trên slide demo, nhưng lại là các thay đổi cần thiết để cluster hoạt động tốt khi quy mô tiếp tục tăng.

Có nên nâng cấp lên Kubernetes 1.37 ngay không?

Kubernetes 1.37 là bản phát hành Stable chính thức, không phải Beta hay Release Candidate. Tuy nhiên, điều đó không đồng nghĩa mọi tính năng bên trong phiên bản này đều Stable.

Một số feature đáng chú ý nhất như Gang Scheduling và Horizontal Pod Autoscaler scale về 0 đang ở Beta. Những khả năng như StatefulSet Recreate hay một số cải tiến mới của Dynamic Resource Allocation vẫn ở Alpha.

Với môi trường production, quyết định nâng cấp vì thế không nên chỉ dựa trên việc có một phiên bản mới.

Platform team nên kiểm tra compatibility của Container Runtime Interface, Container Network Interface, Container Storage Interface, ingress controller, operator, observability stack và các thành phần mở rộng đang chạy trong cluster.

Nếu cluster đang sử dụng cgroup v1, đây cũng là thời điểm rất phù hợp để xử lý technical debt đó trước khi nó trở thành blocker cho các phiên bản Kubernetes tiếp theo.

Kết luận

Kubernetes 1.37 không phải một bản phát hành tạo ra một thay đổi duy nhất làm thay đổi cách chúng ta vận hành container.

Giá trị của phiên bản này nằm ở một điều đặc biệt là:

• Các mảnh ghép đang bắt đầu nối với nhau.
• Autoscaling có thể đưa workload về 0.
• Scheduler bắt đầu hiểu một nhóm Pod thuộc về cùng một workload.
• Resource allocation ngày càng phù hợp hơn với GPU và accelerator.
• Control plane được gia cố để hoạt động tốt hơn ở quy mô lớn.
• Node có thể diễn đạt rõ hơn khả năng và trạng thái lifecycle của mình.

Kubernetes vì thế đang dần vượt khỏi câu chuyện đơn thuần là nơi chạy container.

Với Kubernetes 1.37, hướng đi ngày càng rõ hơn: trở thành một nền tảng điều phối tài nguyên có khả năng hiểu workload, phần cứng và trạng thái hạ tầng ở mức sâu hơn.

Và nếu AI workload tiếp tục tăng nhanh như hiện nay, những thay đổi về scheduling và resource allocation trong Kubernetes 1.37 có thể mới chỉ là phần mở đầu cho những gì Kubernetes sẽ tập trung trong các phiên bản tiếp theo.