Release Channels, Versioning & Version Skew Policy

Tại sao release channel là quyết định kiến trúc, không phải cấu hình

Nhiều team chọn release channel theo bản năng — "Stable nghe có vẻ an toàn hơn, dùng Stable đi." Đây là sai lầm phổ biến vì bỏ qua một thực tế quan trọng: Stable không có nghĩa là không bị upgrade. Mọi channel đều tự động upgrade; sự khác biệt nằm ở khi nào và version nào.

Chọn sai channel dẫn đến hai vấn đề đối nghịch nhau:

• Chọn Rapid cho production: Upgrade quá thường xuyên, API deprecation xảy ra sớm hơn team có thể xử lý, workload bị impact trước khi đội kịp test.
• Chọn Stable cho team cần feature mới: Bị kẹt ở version cũ 6–8 tháng, không có access đến beta API cần thiết cho workload mới.

Quyết định channel phải xuất phát từ phân tích: tần suất upgrade team có thể chấp nhận, mức độ phụ thuộc vào beta APIs, và chiến lược test upgrade của tổ chức.

Bốn release channel của GKE

Theo tài liệu chính thức GKE về release channels, GKE cung cấp bốn channel với đặc điểm khác nhau.

Rapid Channel

Rapid là channel nhận Kubernetes version sớm nhất — thường 1–2 tuần sau khi upstream Kubernetes GA. Đây là channel duy nhất cung cấp access sớm đến tính năng mới nhất.

Auto-upgrade timing: Nodes bắt đầu được upgrade 1–2 tháng sau khi version release lên Rapid.

Ai nên dùng Rapid:

• Internal development clusters, staging environments
• Team cần test compatibility với Kubernetes version mới trước khi lên production
• Platform teams cần validate workload trên version mới nhất

Anti-pattern: Dùng Rapid cho production workload quan trọng mà không có staging cluster cùng channel để validate trước. Khi Rapid nhận version mới, production sẽ upgrade trước khi team có thể phát hiện breaking changes.

Critical security patches: Mọi channel đều nhận critical security patches, không phân biệt channel. Security patches không đợi cadence thông thường.

Regular Channel (Default)

Regular là channel được Google khuyến nghị cho đa số production workloads. Minor version mới available khoảng 2 tháng sau Rapid.

Auto-upgrade timing: Nodes upgrade khoảng 3 tháng sau khi version available trên Regular. Tổng thời gian từ upstream GA đến khi node tự động upgrade trên Regular là khoảng 5 tháng.

Tại sao Regular là default tốt:

• 2 tháng để Rapid "bake" version trước khi Regular nhận
• Thêm 3 tháng nữa để Regular validate trước khi auto-upgrade nodes
• Đây là khoảng thời gian đủ dài để phần lớn breaking change được phát hiện và documented

Ai nên dùng Regular:

• Production clusters với workload không có yêu cầu stability đặc biệt nghiêm ngặt
• SaaS platforms với development velocity cao
• Teams muốn cân bằng giữa feature access và stability

Stable Channel

Stable channel nhận minor version 3–4 tháng sau khi version đó available trên Regular. Tổng thời gian từ upstream GA đến Stable là khoảng 9–12 tháng.

Auto-upgrade timing: Khoảng 2 tháng sau khi version available trên Stable.

Điều quan trọng cần hiểu: Stable channel upgrade ít thường xuyên hơn Regular, nhưng vẫn upgrade. Nếu production cluster không thể chịu được bất kỳ minor version upgrade nào trong vòng 6–12 tháng, Stable vẫn không đủ — cần xem xét Extended channel.

Ai nên dùng Stable:

• Regulated industries (fintech, healthcare) với compliance requirements
• Workloads phụ thuộc vào API behavior cụ thể, cần thời gian test dài hơn
• Enterprise environments với change management process nghiêm ngặt

Trade-off của Stable: Nhận critical bug fixes và security patches chậm hơn. Đây là trade-off thực sự — stability đổi lấy chậm nhận bản vá.

Extended Channel

Extended channel được thiết kế cho các tổ chức cần hỗ trợ minor version lên đến 24 tháng (so với ~14 tháng của các channel thông thường). Version availability aligned với Regular channel.

Mô hình hỗ trợ: Extended cung cấp thêm khoảng 10 tháng sau khi Regular/Stable ngừng support một minor version. Điều này có nghĩa là cluster có thể chạy cùng minor version lâu hơn trước khi bị force upgrade.

Khi nào Extended là lựa chọn đúng:

• Cluster chạy workload có chu kỳ test/validation rất dài (3–6 tháng)
• Enterprise với nhiều dependencies phức tạp cần upgrade theo lịch cố định
• Khi cost của việc upgrade (testing, validation, coordination) cao hơn cost của việc maintain cùng version lâu hơn

Giới hạn của Extended: Không thể enroll các loại cluster sau:

• Autopilot clusters
• Alpha clusters
• Clusters sử dụng beta Kubernetes APIs
• Windows node pools
• Một số multi-cluster features

Patch version advance notice

Trước khi một patch version trở thành auto-upgrade target, GKE đảm bảo:

• Patch version phải available ít nhất 1 tuần trước khi trở thành target auto-upgrade
• Khoảng cách tối thiểu 2 tuần giữa các lần promotion patch version giữa các channel
• Minor version cần ít nhất 4 tuần (Rapid) hoặc 8 tuần (Regular/Stable) advance notice trước khi trở thành auto-upgrade target

Điều này cho phép team có cơ hội manual upgrade trước khi auto-upgrade xảy ra, hoặc sử dụng maintenance exclusion để hoãn.

Kubernetes version skew policy

Version skew policy là constraint kỹ thuật của Kubernetes, không phải của GKE. Nhưng GKE enforce nó và nó có implication trực tiếp lên upgrade strategy.

Control plane ↔ kubelet compatibility

Theo Kubernetes version skew policy, quy tắc cốt lõi:

kubelet KHÔNG ĐƯỢC cũ hơn control plane quá 2 minor version

Ví dụ: Control plane 1.30 → kubelet phải là 1.28, 1.29, hoặc 1.30
Kubelet 1.27 với control plane 1.30 → KHÔNG hợp lệ

Tại sao điều này quan trọng trong practice:

Khi upgrade control plane từ 1.28 → 1.29, nodes vẫn chạy kubelet 1.28. Đây là trạng thái hợp lệ theo skew policy (skew = 1). Upgrade diễn ra theo thứ tự:

Bước 1: Control plane 1.28 → 1.29  (nodes vẫn 1.28, skew=1, hợp lệ)
Bước 2: Nodes 1.28 → 1.29          (align với control plane)

Không được upgrade control plane từ 1.28 → 1.30 nếu nodes đang ở 1.28, vì sau đó control plane sẽ cách nodes 2 minor versions, và khi muốn upgrade nodes từ 1.28 → 1.29 → 1.30, đây là sequence được phép.

Thực tế với GKE: GKE tự động enforce điều này. Không thể manually upgrade control plane vượt quá 1 minor version. Nếu nodes bị tụt hậu quá 2 minor versions so với control plane, GKE sẽ schedule urgent node upgrade để restore compliance.

kube-apiserver ↔ kube-controller-manager

Các control plane components phải cùng version. Trong GKE Standard cluster:

• Google quản lý toàn bộ control plane components → không cần lo về internal skew
• Chỉ cần quan tâm skew giữa control plane (API server version) và nodes (kubelet version)

API server ↔ kubectl

kubectl client có thể lag control plane 1 minor version trong hầu hết operations. Tuy nhiên một số API operations yêu cầu kubectl cùng version với server. Trong CI/CD pipelines, đây là gotcha phổ biến: update cluster nhưng quên update kubectl version trong build container.

GKE versioning model: minor, patch, n-2 support

Cấu trúc version string

1.30.5-gke.1234567
│  │  │    └── GKE patch build number (internal GKE metadata)
│  │  └────── Kubernetes patch version
│  └────────── Kubernetes minor version
└──────────── Kubernetes major version (luôn là 1)

GKE patch version (-gke.X) khác với Kubernetes upstream patch. Cùng Kubernetes 1.30.5 có thể có nhiều GKE patch versions với fixes khác nhau, OS image updates, hoặc GKE-specific component updates.

n-2 support policy

GKE duy trì support cho 3 minor versions đồng thời tại mỗi thời điểm: phiên bản mới nhất (n), phiên bản trước (n-1), và phiên bản trước nữa (n-2).

Ví dụ tại một thời điểm:
├── 1.30.x (n)   — fully supported, active development
├── 1.29.x (n-1) — supported, critical fixes only
└── 1.28.x (n-2) — supported, critical security fixes only
    (1.27.x và cũ hơn → end of support, forced upgrade)

Khi GKE release Kubernetes 1.31, version 1.28 sẽ bị drop khỏi support window. Clusters đang chạy 1.28 sẽ được scheduled forced upgrade bất kể maintenance exclusion (ngoại trừ Extended channel với window dài hơn).

Force upgrade khi end-of-support: Khi maintenance exclusion ngăn upgrade và cluster tiếp cận end-of-support, GKE sẽ schedule khoảng 1 minor version upgrade mỗi tháng để đảm bảo cluster chạy version được support. Đây là hành vi không thể bị override vĩnh viễn.

Capping behavior

"Capping" là khả năng pin cluster vào một version cụ thể hoặc không cho auto-upgrade vượt quá một version nhất định. Trong GKE:

• Có thể pin vào một patch version bằng cách sử dụng maintenance exclusion hoặc manual upgrade management
• Không thể pin mãi mãi — end-of-support override mọi maintenance exclusion
• Release channel không có khái niệm "cap version" — channel xác định cadence, không phải version floor

Nếu cần pin version lâu dài, Extended channel là lựa chọn, không phải maintenance exclusion (vì exclusion có giới hạn 90 ngày).

So sánh channel cho các use case thực tế

Tiêu chí	Rapid	Regular	Stable	Extended
Time to latest minor version	1-2 tuần	~2 tháng	~6 tháng	~2 tháng (nhưng support dài hơn)
Auto-upgrade lag	1-2 tháng	~3 tháng	~2 tháng	Configured
Thời gian support mỗi minor version	~14 tháng	~14 tháng	~14 tháng	~24 tháng
Phù hợp cho	Dev/staging	Hầu hết production	Regulated industries	Long-cycle enterprises
Beta API access	Có	Có	Có	Có
Autopilot support	Có	Có	Có	Không

Anti-patterns và production pitfalls

1. Không có staging cluster cùng channel

Vấn đề: Production chạy Regular channel nhưng không có staging environment nào chạy cùng channel để validate trước. Khi auto-upgrade diễn ra, team phát hiện breaking change lần đầu trên production.

Giải pháp: Staging cluster chạy Rapid channel, production chạy Regular. Staging nhận version sớm hơn và là early warning system. Có đủ thời gian (2 tháng) để validate trên Rapid trước khi Regular nhận cùng version.

Rapid (staging) → nhận 1.31 → team validate → 2 tháng sau
Regular (production) → nhận 1.31 → đã được validate

2. Nhầm lẫn giữa maintenance exclusion và channel change

Vấn đề: Team muốn "không bị upgrade trong 3 tháng tới" và nghĩ rằng chuyển sang Stable channel sẽ đạt được điều đó. Nhưng Stable cluster vẫn sẽ được upgrade — chỉ là theo cadence khác.

Giải pháp: Dùng maintenance exclusion để block upgrade trong window cụ thể. Maintenance exclusion và release channel là hai control plane độc lập.

3. Tight PDB kết hợp với Rapid channel

Vấn đề: Workload với minAvailable: 100% PDB chạy trên Rapid channel cluster. Rapid upgrade nodes thường xuyên. Mỗi lần node drain, PDB ngăn Pod eviction, upgrade bị stuck 1 giờ rồi force evict.

Giải pháp: Tight PDB là đúng cho workload quan trọng, nhưng kết hợp nó với Stable/Regular channel và blue-green upgrade strategy để có soak period đủ dài.

4. Bỏ qua GKE patch version khi pin version

Vấn đề: Team pin cluster vào 1.29.5-gke.1000000 để "giữ ổn định". Nhưng bỏ qua critical security fix trong 1.29.5-gke.2000000 (cùng minor.patch, khác GKE build).

Giải pháp: Không nên pin vào GKE patch build cụ thể trong production. Cho phép patch version auto-upgrade (chỉ block minor version) để nhận security fixes.

References

• GKE Release Channels — Official cadence, version availability timing, channel characteristics
• GKE Versioning and Upgrades — Version skew policy, n-2 support model
• Kubernetes Version Skew Policy — Upstream skew rules
• Extended Support for GKE — 24-month support window details