Maintenance Windows, Exclusions & Cluster Disruption Budget

Tại sao timing control quan trọng hơn việc chọn strategy

Chọn đúng upgrade strategy (surge vs blue-green) là điều kiện cần nhưng chưa đủ. Một cluster có thể được cấu hình blue-green perfect nhưng vẫn gây outage nếu upgrade kích hoạt vào lúc 3PM thứ Sáu — giữa peak traffic của tuần.

Timing control trong GKE hoạt động theo hệ thống hai lớp bổ sung nhau:

Lớp 1: Maintenance Windows — Định nghĩa "KHI NÀO được phép upgrade"
        └── Repeating, recurring windows
        └── GKE chỉ upgrade trong window này

Lớp 2: Maintenance Exclusions — Định nghĩa "KHI NÀO KHÔNG ĐƯỢC upgrade"
        └── Non-repeating, one-off blackout periods
        └── Exclusions override windows khi overlap

Ưu tiên: Exclusion > Window

Một cluster có thể có cả hai cùng lúc: "Upgrade chỉ trong Sunday 2AM–6AM UTC" (window) nhưng "Không upgrade từ Dec 20 đến Jan 5" (exclusion). GKE sẽ không upgrade trong Dec 20 – Jan 5 dù Sunday 2AM–6AM có trong window.

Maintenance Windows

Cấu trúc và semantics

Maintenance window là repeating time window trong đó GKE được phép thực hiện automatic maintenance (upgrade cluster, node pool, v.v.).

Đặc điểm quan trọng:

Mỗi cluster chỉ được cấu hình một maintenance window (không phải nhiều)
Window lặp lại theo RRULE (iCalendar recurrence rule)
Thời gian luôn được lưu và tính toán theo UTC
Window phải có ít nhất 48 giờ trong mỗi chu kỳ 32 ngày — GKE cần đủ thời gian để thực hiện maintenance

UTC timezone và gotcha thực tế

Đây là nguồn gốc của nhiều misconfiguration. Timezone handling trong GKE:

gcloud CLI: Nhận và hiển thị thời gian theo UTC
Google Cloud Console: Hiển thị theo local timezone của browser nhưng lưu theo UTC
RRULE trong API: Luôn theo UTC

Scenario dễ nhầm: Team ở Việt Nam (UTC+7) muốn maintenance window từ 1AM–5AM giờ Việt Nam. Họ cấu hình 01:00–05:00 nhưng không specify timezone → window thực tế là 1AM–5AM UTC = 8AM–12PM giờ Việt Nam. Upgrade xảy ra đúng vào giờ cao điểm.

Cấu hình đúng:

bash

# Maintenance window: Sunday 1AM-5AM Vietnam time = Sunday 18:00-22:00 UTC (prev day)
gcloud container clusters update CLUSTER_NAME \
    --maintenance-window-start=2024-01-14T18:00:00Z \
    --maintenance-window-end=2024-01-14T22:00:00Z \
    --maintenance-window-recurrence="FREQ=WEEKLY;BYDAY=SU" \
    --zone=ZONE

Kết quả: Window là Sunday 18:00 UTC – Sunday 22:00 UTC mỗi tuần = Thứ Hai 1AM–5AM giờ Việt Nam.

RRULE recurrence patterns thực tế

bash

# Mỗi ngày, 2AM-4AM UTC
--maintenance-window-recurrence="FREQ=DAILY"

# Thứ Bảy và Chủ Nhật, 1AM-5AM UTC
--maintenance-window-recurrence="FREQ=WEEKLY;BYDAY=SA,SU"

# Ngày đầu tiên của mỗi tháng
--maintenance-window-recurrence="FREQ=MONTHLY;BYMONTHDAY=1"

# Thứ Tư thứ 3 của mỗi tháng (thường dùng cho enterprise maintenance schedule)
--maintenance-window-recurrence="FREQ=MONTHLY;BYDAY=3WE"

Requirement 48 giờ mỗi 32 ngày:

Nếu chọn chỉ 2 giờ mỗi Sunday, tổng là 2h × ~4 Sundays = 8h trong 32 ngày — không đủ 48h. GKE sẽ reject cấu hình này. Phải đảm bảo tổng window time đủ lớn.

Ví dụ an toàn: 4 giờ mỗi ngày = 4h × 32 ngày = 128h >> 48h.

Xem và update maintenance window

bash

# Xem maintenance window hiện tại
gcloud container clusters describe CLUSTER_NAME \
    --zone=ZONE \
    --format="yaml(maintenancePolicy)"

# Xóa maintenance window (cho phép upgrade bất cứ lúc nào)
gcloud container clusters update CLUSTER_NAME \
    --clear-maintenance-window \
    --zone=ZONE

Những gì maintenance window KHÔNG kiểm soát

Maintenance window chỉ kiểm soát automatic maintenance. Các sự kiện sau bỏ qua maintenance window:

Compute Engine host maintenance — VM migration, host hardware maintenance (Google control)
Control plane repairs — Khi GKE phát hiện control plane unhealthy và cần repair
Critical security patches — Patches với severity cao đặc biệt có thể override window
Manual upgrades — gcloud container clusters upgrade bằng tay luôn bypass window
End-of-support forced upgrades — Khi cluster vượt quá end-of-support, GKE force upgrade

Điều này có nghĩa là maintenance window không phải là guarantee không bị upgrade trong giờ business. Nó là best-effort scheduling, không phải hard lock.

Maintenance Exclusions

Cấu trúc và ba loại exclusion

Maintenance exclusion là non-repeating blackout period — khoảng thời gian một lần trong đó GKE không được thực hiện một số loại maintenance cụ thể.

GKE hỗ trợ ba loại exclusion scope:

Loại exclusion	`exclusion-type` flag	Control plane	Node (minor)	Node (patch)	Max length
No upgrades (default)	`no-upgrades`	Block	Block	Block	90 ngày
No minor upgrades	`no-minor-upgrades`	Block minor	Block minor	Cho phép	Không giới hạn
No minor/node upgrades	`no-minor-or-node-upgrades`	Block minor	Block minor + patch	Block	Không giới hạn

Chú giải:

No upgrades: Block mọi thứ, kể cả patch upgrades. Dùng cho blackout periods nghiêm ngặt (year-end, major events)
No minor upgrades: Cho phép patch upgrades (security fixes) nhưng block minor version bumps
No minor/node upgrades: Block minor trên control plane và mọi upgrade trên nodes (kể cả patch), nhưng vẫn cho phép control plane patch upgrades

Cấu hình maintenance exclusion

bash

# Blackout hoàn toàn cho Black Friday / Cyber Monday (30 ngày)
gcloud container clusters update CLUSTER_NAME \
    --add-maintenance-exclusion-name=black-friday-2024 \
    --add-maintenance-exclusion-start=2024-11-20T00:00:00Z \
    --add-maintenance-exclusion-end=2024-12-20T00:00:00Z \
    --add-maintenance-exclusion-scope=NO_UPGRADES \
    --zone=ZONE

# Cho phép patch nhưng block minor (holiday period)
gcloud container clusters update CLUSTER_NAME \
    --add-maintenance-exclusion-name=holiday-minor-block \
    --add-maintenance-exclusion-start=2024-12-20T00:00:00Z \
    --add-maintenance-exclusion-end=2025-01-05T00:00:00Z \
    --add-maintenance-exclusion-scope=NO_MINOR_UPGRADES \
    --zone=ZONE

Tracking end-of-support date

GKE có tính năng đặc biệt: exclusion có thể tự động expire khi cluster's minor version tiếp cận end-of-support:

bash

gcloud container clusters update CLUSTER_NAME \
    --add-maintenance-exclusion-name=version-support-tracking \
    --add-maintenance-exclusion-start=2024-01-01T00:00:00Z \
    --add-maintenance-exclusion-end=2025-01-01T00:00:00Z \
    --add-maintenance-exclusion-scope=NO_MINOR_UPGRADES \
    --zone=ZONE

Khi bật tính năng end-of-support tracking, end date của exclusion tự động điều chỉnh theo end-of-support date của minor version đang chạy. Điều này giúp team tránh tình huống: "đặt exclusion 1 năm nhưng version hết support trong 6 tháng → cluster forced upgrade bất kể exclusion".

Giới hạn và ràng buộc của exclusion

Tối đa 3 maintenance exclusions cho mỗi cluster tại một thời điểm. Đây là giới hạn cứng từ API.

Scope NO_UPGRADES có max 90 ngày. Nếu cần block lâu hơn 90 ngày, phải dùng NO_MINOR_UPGRADES (không có max length). Lý do: Google muốn đảm bảo security patches vẫn có thể được apply trong trường hợp vulnerability nghiêm trọng.

End-of-support override mọi exclusion:

Kịch bản thực tế:
- Cluster chạy 1.27 với NO_UPGRADES exclusion kéo dài 90 ngày
- 1.27 hết support trong exclusion window
- GKE bắt đầu schedule ~1 minor upgrade/tháng để đưa cluster về supported version
- Không thể block bằng exclusion

Đây là điểm nhiều team không biết đến. Nếu cluster ở end-of-support, không có gì ngăn được GKE upgrade. Đây là thiết kế có chủ ý để đảm bảo security compliance.

Xem và quản lý exclusions

bash

# Liệt kê tất cả exclusions
gcloud container clusters describe CLUSTER_NAME \
    --zone=ZONE \
    --format="yaml(maintenancePolicy.window.maintenanceExclusions)"

# Xóa một exclusion cụ thể
gcloud container clusters update CLUSTER_NAME \
    --remove-maintenance-exclusion=black-friday-2024 \
    --zone=ZONE

Precedence: exclusion vs window

Khi maintenance window và exclusion overlap:

Window: [Mon-Fri 2AM-4AM UTC]
Exclusion: [Tháng 12 toàn bộ - NO_UPGRADES]

Result trong tháng 12:
- Mon 3AM UTC → Trong window, trong exclusion → BLOCKED (exclusion thắng)
- Sau tháng 12, Mon 3AM UTC → Trong window, ngoài exclusion → ALLOWED

Exclusion luôn thắng window khi overlap.

Cluster Disruption Budget

Vấn đề khi không có disruption control ở fleet level

Trong một GKE Fleet quản lý 50 clusters, nếu không có disruption budget:

GKE có thể quyết định upgrade 20 clusters cùng lúc trong maintenance window
Với mỗi cluster gây ~5% disruption risk, 20 clusters đồng thời = risk tích lũy cao
Nếu version mới có regression, 40% fleet bị impact trước khi phát hiện

Cluster disruption budget giải quyết vấn đề này ở tầng fleet.

Cơ chế hoạt động

Cluster disruption budget (CDB) định nghĩa số lượng hoặc tỷ lệ clusters tối đa trong fleet được phép upgrade đồng thời. GKE Fleet management layer enforce constraint này khi scheduling auto-upgrades.

Cấu hình thông qua Fleet API:

yaml

# fleet_config.yaml
maintenancePolicy:
  window:
    recurringWindow:
      window:
        startTime: "2024-01-01T02:00:00Z"
        endTime: "2024-01-01T06:00:00Z"
      recurrence: "FREQ=WEEKLY;BYDAY=SA,SU"
  resourceVersion: "1"

Disruption budget được cấu hình per cluster hoặc fleet level:

bash

# Giới hạn số lượng cluster auto-upgrading đồng thời trong fleet
gcloud container fleet update \
    --cluster-disruption-budget=max-unavailable-percentage=25 \
    --project=PROJECT_ID

Interaction với maintenance windows

CDB và maintenance windows hoạt động cùng nhau:

Maintenance window: [Sunday 2AM-6AM UTC] → 4 tiếng
Fleet có 20 clusters, CDB: max 25% = 5 clusters đồng thời

Behavior:
T=2:00: GKE bắt đầu upgrade 5 clusters đầu tiên
T=2:30: 5 clusters xong → bắt đầu 5 clusters tiếp theo
T=3:00: Batch 3...
T=3:30: Batch 4 = tất cả 20 clusters xong

Nếu một batch mất quá lâu và vượt qua end time của window, GKE dừng batch mới và đợi window tiếp theo.

Rollout sequencing với phân nhóm clusters

Pattern nâng cao: phân nhóm clusters theo risk tier và configure CDB theo từng tier:

Tier 1 (canary): 2 clusters — upgrade trước, 24h soak
Tier 2 (regional): 10 clusters — upgrade sau khi Tier 1 healthy 24h
Tier 3 (global): 38 clusters — upgrade sau khi Tier 2 healthy 24h

Không có native "tier" concept trong GKE Fleet, nhưng có thể implement bằng:

Maintenance windows với start time khác nhau giữa các tiers
Automation script monitor Tier 1 health, trigger manual upgrade Tier 2

Production patterns kết hợp window + exclusion + budget

Pattern 1: SaaS platform với peak traffic cuối tuần

Maintenance window: Thứ Hai – Thứ Tư, 2AM–6AM UTC
Exclusion: Không upgrade minor version trong Q4 (Oct–Dec)
Lý do: Peak business period cuối năm

Kết quả:
- Patch upgrades OK mọi Thứ Hai – Thứ Tư
- Minor version upgrades bị blocked Oct–Dec
- Jan: minor version upgrades tự động reactivate

Pattern 2: Fintech với compliance requirement

Maintenance window: Mỗi ngày 11PM–3AM UTC
Exclusion (NO_MINOR_UPGRADES): Không có thời hạn cố định
                                 Track end-of-support date
Lý do: Minor upgrades cần 6 tuần regression testing

Quy trình:
1. GKE thông báo version mới available (Pub/Sub notification)
2. Team bắt đầu 6-week regression testing cycle
3. Kết thúc test → xóa exclusion → minor upgrade xảy ra trong next maintenance window
4. Thêm exclusion mới cho version tiếp theo

Pattern 3: Multi-cluster fleet với canary strategy

Cluster tier:
- canary-cluster: Regular channel, NO maintenance window (upgrade ngay lập tức)
- prod-cluster-1..5: Regular channel, maintenance window: Thứ Sáu 11PM UTC, CDB: max 2 clusters/window
- prod-cluster-6..50: Regular channel, maintenance window: Thứ Bảy 11PM UTC, CDB: max 10 clusters/window

Luồng upgrade:
canary upgrade Thứ Sáu → team validate Thứ Sáu → prod-cluster-1..5 upgrade Thứ Sáu đêm
→ validate Thứ Bảy → prod-cluster-6..50 upgrade Thứ Bảy đêm

Những gì không thể kiểm soát bằng windows và exclusions

Điều quan trọng nhất để hiểu: maintenance windows và exclusions có giới hạn cứng về những gì chúng có thể kiểm soát.

Không kiểm soát được:

Compute Engine host maintenance — Google có quyền migrate VM sang host khác bất cứ lúc nào
Control plane repairs — Nếu GKE detect control plane unhealthy, sẽ repair ngay
Kubernetes node repairs — auto-repair khi node condition xấu
Critical vulnerability patches — Với severity đặc biệt cao, có thể override mọi window
End-of-support forced upgrades

Implication cho SLA design: Nếu SLA của bạn không cho phép bất kỳ disruption nào (99.999%), maintenance windows và exclusions không đủ. Cần thiết kế workload với multi-zone redundancy và chaos engineering để tolerate unexpected node recreation.

Ưu tiên của các control plane theo thứ tự

1. End-of-support deadline → force upgrade (không thể block)
2. Critical security patch → có thể override window (hiếm)
3. Maintenance exclusion → block upgrade trong window
4. Maintenance window → chỉ upgrade trong window
5. Cluster disruption budget → giới hạn số clusters upgrade đồng thời
6. Node upgrade strategy → kiểm soát cách upgrade từng node
7. PodDisruptionBudget → kiểm soát cách evict pods trong mỗi node drain

Hiểu thứ tự này giúp diagnose tại sao upgrade xảy ra "đúng thời điểm không mong muốn" — thường là một trong các control plane cấp cao hơn override.

References

Maintenance windows and exclusions — Official documentation
Configuring maintenance windows — Configuration guide
Cluster disruption budgets — Fleet-level disruption control
GKE Fleet management — Fleet concepts

Maintenance Windows, Exclusions & Cluster Disruption Budget ​

Tại sao timing control quan trọng hơn việc chọn strategy ​

Maintenance Windows ​

Cấu trúc và semantics ​

UTC timezone và gotcha thực tế ​

RRULE recurrence patterns thực tế ​

Xem và update maintenance window ​

Những gì maintenance window KHÔNG kiểm soát ​

Maintenance Exclusions ​

Cấu trúc và ba loại exclusion ​

Cấu hình maintenance exclusion ​

Tracking end-of-support date ​

Giới hạn và ràng buộc của exclusion ​

Xem và quản lý exclusions ​

Precedence: exclusion vs window ​

Cluster Disruption Budget ​

Vấn đề khi không có disruption control ở fleet level ​

Cơ chế hoạt động ​

Interaction với maintenance windows ​

Rollout sequencing với phân nhóm clusters ​

Production patterns kết hợp window + exclusion + budget ​

Pattern 1: SaaS platform với peak traffic cuối tuần ​

Pattern 2: Fintech với compliance requirement ​

Pattern 3: Multi-cluster fleet với canary strategy ​

Những gì không thể kiểm soát bằng windows và exclusions ​

Ưu tiên của các control plane theo thứ tự ​

References ​

Maintenance Windows, Exclusions & Cluster Disruption Budget

Tại sao timing control quan trọng hơn việc chọn strategy

Maintenance Windows

Cấu trúc và semantics

UTC timezone và gotcha thực tế

RRULE recurrence patterns thực tế

Xem và update maintenance window

Những gì maintenance window KHÔNG kiểm soát

Maintenance Exclusions

Cấu trúc và ba loại exclusion

Cấu hình maintenance exclusion

Tracking end-of-support date

Giới hạn và ràng buộc của exclusion

Xem và quản lý exclusions

Precedence: exclusion vs window

Cluster Disruption Budget

Vấn đề khi không có disruption control ở fleet level

Cơ chế hoạt động

Interaction với maintenance windows

Rollout sequencing với phân nhóm clusters

Production patterns kết hợp window + exclusion + budget

Pattern 1: SaaS platform với peak traffic cuối tuần

Pattern 2: Fintech với compliance requirement

Pattern 3: Multi-cluster fleet với canary strategy

Những gì không thể kiểm soát bằng windows và exclusions

Ưu tiên của các control plane theo thứ tự

References