Kubernetes v1.35 (Timbernetes) có gì mới?
Kubernetes v1.35 (Timbernetes): Có gì mới và những thay đổi nào đang diễn ra?
Dự án Kubernetes vừa phát hành phiên bản 1.35 vào ngày 17 tháng 12 năm 2025, mang đến những cải tiến đáng kể, những tính năng bị loại bỏ quan trọng và tiếp tục tập trung vào tính ổn định và khả năng sẵn sàng cho doanh nghiệp. Sau 58 cải tiến trong suốt chu kỳ phát hành v1.34, cộng đồng tiếp tục đẩy mạnh giới hạn của việc điều phối container trong khi vẫn duy trì độ tin cậy và chất lượng cấp độ sản xuất của nền tảng.
Bản phát hành này đánh dấu một cột mốc quan trọng khác trong quá trình phát triển của Kubernetes, với các tính năng quan trọng được đưa vào sử dụng rộng rãi và các thành phần cũ được loại bỏ dần để giảm thiểu nợ kỹ thuật. Hãy cùng tìm hiểu sâu hơn về những gì v1.35 mang lại, với các ví dụ thực tế về cách những thay đổi này sẽ tác động đến hoạt động hàng ngày của bạn.
Những tính năng mang tính bước ngoặt
1. In-Place Pod Resource Updates: Cuối cùng đã GA!
Sau nhiều năm phát triển và thử nghiệm (alpha từ v1.27, beta ở v1.33), khả năng cập nhật tài nguyên của Pod mà không cần restart container cuối cùng đã đạt trạng thái General Availability (GA) trong Kubernetes v1.35.
Đây được xem là một trong những tính năng được yêu cầu nhiều nhất trong lịch sử Kubernetes.
Vấn đề mà tính năng này giải quyết
Trước đây, nếu bạn cần điều chỉnh CPU hoặc memory cho một Pod đang chạy, cách duy nhất là xóa Pod và tạo lại Pod mới.
Điều này gây gián đoạn cho nhiều loại workload, đặc biệt là:
Ứng dụng stateful duy trì các kết nối dài hạn
Job huấn luyện machine learning không thể checkpoint trạng thái giữa chừng
Database replica cần đồng bộ lại dữ liệu
Bất kỳ hệ thống nào mà downtime đồng nghĩa với mất doanh thu
Với In-Place Pod Resource Updates, bạn có thể thay đổi resource allocation trực tiếp trên Pod đang chạy, giúp giảm downtime và tăng tính linh hoạt khi vận hành hệ thống.
Cách thức hoạt động
Tính năng này cho phép bạn sửa đổi resources.requests và resources.limits cho các container trong một Pod đang chạy. Sau đây là một ví dụ thực tế:
# Original Pod specification
apiVersion: v1
kind: Pod
metadata:
name: my-app
spec:
containers:
- name: app
image: my-app:1.0
resources:
requests:
memory: "512Mi"
cpu: "500m"
limits:
memory: "1Gi"
cpu: "1000m"
Now, you can update it in place:
kubectl patch pod my-app --type='json' -p='[
{
"op": "replace",
"path": "/spec/containers/0/resources/requests/memory",
"value": "1Gi"
},
{
"op": "replace",
"path": "/spec/containers/0/resources/limits/memory",
"value": "2Gi"
}
]'
Container tiếp tục hoạt động với mức phân bổ tài nguyên mới. Không cần khởi động lại, không mất dữ liệu, không gián đoạn dịch vụ.
Use Case thực tế: Flash Sale trong E-commerce
Hãy tưởng tượng bạn đang vận hành một nền tảng e-commerce. Trong điều kiện bình thường, service checkout của bạn chạy với 2GB memory. Nhưng bạn sắp tổ chức một flash sale, và dự đoán lưu lượng truy cập sẽ tăng gấp 10 lần.
Trước Kubernetes v1.35, bạn thường chỉ có hai lựa chọn không mấy lý tưởng:
1. Over-provision tài nguyên mọi lúc
Cấp phát nhiều tài nguyên hơn mức cần thiết để phòng trường hợp traffic tăng. Điều này rất tốn chi phí vì phần lớn thời gian tài nguyên bị lãng phí.
2. Scale thêm replica và chấp nhận gián đoạn
Tăng số lượng Pod để xử lý tải, nhưng việc thay thế Pod (Pod replacement) có thể gây gián đoạn ngắn, đặc biệt với các service đang xử lý request liên tục.
Với các bản cập nhật tại chỗ:
# Before the flash sale
kubectl patch deployment checkout --type='json' -p='[
{
"op": "replace",
"path": "/spec/template/spec/containers/0/resources/limits/memory",
"value": "8Gi"
}
]'
# After the flash sale
kubectl patch deployment checkout --type='json' -p='[
{
"op": "replace",
"path": "/spec/template/spec/containers/0/resources/limits/memory",
"value": "2Gi"
}
]'
Các Pod của bạn tự động mở rộng theo chiều dọc mà không cần khởi động lại, duy trì tất cả giỏ hàng và phiên hoạt động.
Tích hợp với VPA
Kết hợp với Vertical Pod Autoscaler, điều này cho phép tối ưu hóa tài nguyên thực sự linh hoạt:
apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
name: my-app-vpa
spec:
targetRef:
apiVersion: "apps/v1"
kind: Deployment
name: my-app
updatePolicy:
updateMode: "Auto" # Now uses in-place updates!
resourcePolicy:
containerPolicies:
- containerName: app
minAllowed:
cpu: 100m
memory: 256Mi
maxAllowed:
cpu: 2
memory: 4Gi
Giờ đây, VPA có thể điều chỉnh tài nguyên mà không làm gián đoạn hoạt động của pod, học hỏi từ các mô hình sử dụng thực tế và tự động tối ưu hóa chi phí.
2. Node Declared Features: Giải quyết vấn đề Version Skew
Một trong những thách thức lớn khi quản lý cluster Kubernetes ở quy mô lớn là version skew trong quá trình nâng cấp.
Ví dụ: bạn đã nâng cấp control plane lên v1.35, nhưng một số worker node vẫn đang chạy v1.34 hoặc thậm chí v1.33.
Vậy điều gì xảy ra nếu bạn schedule một Pod sử dụng tính năng của v1.35 lên một node v1.34?
Thông thường, kết quả sẽ là: Pod bị lỗi hoặc không thể chạy.
Phương pháp truyền thống (Gán nhãn thủ công)
Cho đến nay, giải pháp là gán nhãn nút thủ công:
# Manually label nodes that support new features
kubectl label node worker-1 feature.kubernetes.io/in-place-resize=true
kubectl label node worker-2 feature.kubernetes.io/pod-certificates=true
# Then use node selectors
apiVersion: v1
kind: Pod
metadata:
name: my-app
spec:
nodeSelector:
feature.kubernetes.io/in-place-resize: "true"
containers:
- name: app
image: my-app:1.0
Cách này dễ xảy ra lỗi, không mở rộng được và tạo ra gánh nặng vận hành.
Giải pháp v1.35: Khai báo tính năng tự động
Với Tính năng được khai báo trên nút (phiên bản alpha), các nút sẽ tự động báo cáo khả năng của chúng:
kubectl get node worker-1 -o jsonpath='{.status.declaredFeatures}'
Output:
{
"InPlacePodVerticalScaling": {
"supported": true,
"kubernetesVersion": "1.35.0"
},
"PodCertificates": {
"supported": true,
"kubernetesVersion": "1.35.0"
},
"SidecarContainers": {
"supported": false,
"reason": "Kubelet version 1.34"
}
Hệ thống lập lịch sử dụng thông tin này một cách tự động:
apiVersion: v1
kind: Pod
metadata:
name: my-app
annotations:
scheduling.kubernetes.io/required-features: "InPlacePodVerticalScaling,PodCertificates"
spec:
containers:
- name: app
image: my-app:1.0
Bộ lập lịch đảm bảo Pod này được đặt trên một node hỗ trợ cả hai tính năng. Không cần gắn nhãn thủ công.
Tình huống thực tế: Rolling Upgrade cho Cluster
Giả sử bạn đang nâng cấp một cluster 100 node của Kubernetes từ v1.34 lên v1.35.
Với cách tiếp cận truyền thống, bạn thường có vài lựa chọn không thật sự lý tưởng:
1. Nâng cấp toàn bộ node cùng lúc
Upgrade tất cả node trong cluster một lần và chấp nhận khả năng gián đoạn hệ thống trong quá trình này.
2. Tạo hai node pool riêng biệt
Thiết lập hai node pool chạy hai phiên bản khác nhau, sau đó di chuyển workload dần dần giữa các pool.
3. Hy vọng mọi thứ không gặp lỗi
Tiến hành rollout nâng cấp từ từ và hy vọng không có workload nào sử dụng tính năng không tương thích với node cũ.
Những phương án này đều tăng độ phức tạp trong vận hành và có thể gây rủi ro cho hệ thống production nếu không được quản lý cẩn thận.
Với các tính năng được khai báo trong Node:
apiVersion: apps/v1
kind: Deployment
metadata:
name: critical-app
spec:
replicas: 10
template:
metadata:
annotations:
scheduling.kubernetes.io/required-features: "InPlacePodVerticalScaling"
spec:
containers:
- name: app
image: critical-app:2.0
Quá trình triển khai này tự động lên lịch chỉ trên các node đã được nâng cấp, trong khi các khối lượng công việc khác của bạn vẫn tiếp tục chạy trên các node phiên bản 1.34. Việc nâng cấp trở nên an toàn và dễ quản lý hơn.
