Autopilot Cluster Upgrades

Tại sao upgrade trong Autopilot khác Standard

Trong Standard clusters, bạn kiểm soát khi nào và cách upgrade xảy ra: bật auto-upgrade hay không, set maintenance windows, chọn surge vs blue-green strategy cho node pools.

Trong Autopilot, upgrade là mandatory và managed by Google. Bạn không thể disable auto-upgrade. Lý do: Google chịu trách nhiệm về security patches và reliability của node infrastructure — không thể để user tùy chọn bỏ qua security patches quan trọng.

Điều bạn có thể kiểm soát:

• Maintenance windows: Upgrade chỉ xảy ra trong khung giờ bạn chỉ định
• Maintenance exclusions: Blackout periods — không upgrade trong khoảng thời gian này
• Extended Duration Pods: Delay eviction khi node cần upgrade

Control plane upgrades: Zero downtime

Autopilot cam kết zero control plane downtime trong quá trình upgrade. Điều này được thực hiện thông qua:

1. Redundant control plane replicas: Control plane chạy nhiều replicas (API server, scheduler, controller-manager), được phân bố qua nhiều zones
2. Rolling upgrade: Upgrade từng replica một, không cùng lúc
3. Health checks trước khi cutover: Replica mới phải healthy trước khi replica cũ bị terminate
4. Load balancer abstraction: API endpoint không đổi dù replicas thay đổi

Từ góc nhìn của bạn, control plane upgrade là transparent — kubectl tiếp tục hoạt động, workloads tiếp tục run, không có "maintenance window" cho control plane.

Trong Standard clusters, control plane upgrade cũng được manage bởi Google và có SLA 99.95% (regional) hay 99.5% (zonal). Autopilot cùng SLA nhưng tuyên bố zero downtime bởi vì control plane được sized và replicated tốt hơn.

Node upgrades: Surge strategy

Sau control plane, đến lượt nodes. Autopilot dùng surge upgrade cho nodes:

Phase 1: Surge — tạo node mới với version mới
    [Node A v1.28] [Node B v1.28] + [New Node C v1.29]
                                      ↑ surge node
Phase 2: Cordon — mark node cũ là unschedulable
    [Node A v1.28 ⛔] [Node B v1.28] [Node C v1.29]

Phase 3: Drain — evict Pods từ node cũ
    Pods từ Node A → reschedule sang B và C

Phase 4: Delete — xóa node cũ
    [Node B v1.28] [Node C v1.29]

Phase 5: Tiếp tục cho các nodes còn lại...

Đặc điểm surge upgrade trong Autopilot

Parallel upgrade: GKE upgrade tối đa 20 nodes trong một đợt (một node group), không phải từng node một. Số lượng chính xác phụ thuộc vào cluster size và availability requirements.

Không có blue-green option: Standard clusters cho phép bạn chọn giữa surge và blue-green. Autopilot chỉ dùng surge — đây là design decision bởi vì Autopilot không expose node pool concept.

Tự động reschedule: Khi Pod bị evict từ node đang upgrade, Autopilot tự động provision node mới (nếu cần) để host Pod đó. Bạn không cần lo lắng về capacity.

Interaction với workload disruption

PodDisruptionBudgets được tôn trọng trong quá trình node upgrade:

# GKE sẽ không evict quá nhiều Pods cùng lúc nếu vi phạm PDB
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: my-app-pdb
spec:
  minAvailable: "80%"  # Giữ ít nhất 80% Pods available
  selector:
    matchLabels:
      app: my-app

Tuy nhiên: PDB chỉ slow down, không ngăn chặn upgrade. Nếu upgrade bị block quá lâu do PDB, GKE sẽ cố gắng tiến hành bất kể PDB.

Extended Duration Pods (annotation safe-to-evict: "false") sẽ delay eviction lên đến 7 ngày — node chứa Extended Duration Pod được upgrade sau cùng, sau khi tất cả nodes khác đã upgrade.

Điều gì xảy ra với Pods khi node upgrade

Pod type	Hành vi khi node upgrade
Pod thông thường	Evict, reschedule trên node khác/mới
Pod với PDB	Evict nhưng GKE throttle tốc độ
Spot Pod	Evict với grace period tối đa 25 giây
Extended Duration Pod	Delay eviction lên đến 7 ngày
DaemonSet Pod	Restart trên node mới tự động
Static Pod	Không evict, chỉ restart khi node restart

Maintenance windows

Maintenance windows cho phép bạn chỉ định khoảng thời gian Autopilot được phép tiến hành upgrades:

gcloud container clusters update CLUSTER_NAME \
  --region REGION \
  --maintenance-window-start "2024-01-01T02:00:00Z" \
  --maintenance-window-end "2024-01-01T06:00:00Z" \
  --maintenance-window-recurrence "FREQ=WEEKLY;BYDAY=SA,SU"

Cấu hình trên cho phép maintenance mỗi cuối tuần từ 2-6 giờ sáng UTC.

Lưu ý quan trọng: Maintenance window không đảm bảo upgrade bắt đầu trong window — nó đảm bảo upgrade chỉ xảy ra trong window. Nếu có security patch khẩn cấp, Google có thể override window.

Recurrence format

Dùng RFC 5545 RRULE format:

# Hàng ngày từ 2-6 sáng UTC
FREQ=DAILY

# Thứ 2 và thứ 5 hàng tuần
FREQ=WEEKLY;BYDAY=MO,TH

# Ngày đầu mỗi tháng
FREQ=MONTHLY;BYMONTHDAY=1

Minimum maintenance window

Autopilot yêu cầu maintenance window tối thiểu 48 giờ mỗi tuần. Nếu bạn cấu hình window quá nhỏ, GKE sẽ báo lỗi.

Lý do: Google cần đủ thời gian để hoàn thành upgrade cho toàn bộ cluster, đặc biệt với large clusters có nhiều node groups.

Maintenance exclusions

Maintenance exclusions là blackout periods — khoảng thời gian Autopilot không được phép upgrade:

gcloud container clusters update CLUSTER_NAME \
  --region REGION \
  --add-maintenance-exclusion-name "holiday-freeze-2024" \
  --add-maintenance-exclusion-start "2024-12-20T00:00:00Z" \
  --add-maintenance-exclusion-end "2025-01-03T00:00:00Z" \
  --add-maintenance-exclusion-scope "NO_UPGRADES"

Exclusion scopes

Scope	Ý nghĩa
NO_UPGRADES	Block cả control plane và node upgrades
NO_MINOR_UPGRADES	Chỉ block minor version upgrades (1.28 → 1.29), patch upgrades vẫn xảy ra
NO_MINOR_OR_NODE_UPGRADES	Block minor upgrades và node upgrades, chỉ allow control plane patch

Maximum 3 exclusions active cùng lúc, mỗi exclusion tối đa 180 ngày.

Anti-pattern: Exclusion kéo dài quá lâu

Nếu blackout quá dài, cluster của bạn có thể bị out of support window — version đang chạy quá cũ và Google không còn support. Khi đó, GKE có thể force-upgrade bất kể exclusion.

Recommendation: Luôn có kế hoạch test và upgrade trước khi set exclusion dài.

Release channels và version management

Autopilot bắt buộc đăng ký release channel. Lựa chọn channel ảnh hưởng đến tần suất upgrade:

Channel	Kubernetes version	Upgrade frequency	Phù hợp
Rapid	Latest available	Hàng tuần	Staging, testing
Regular	Stable release	Mỗi 2-4 tuần	Đa số production
Stable	Tested thoroughly	Mỗi 1-2 tháng	Risk-averse production
Extended	Long-term support	Ít thường xuyên	Enterprise compliance

# Tạo Autopilot cluster với Regular channel
gcloud container clusters create-auto CLUSTER_NAME \
  --release-channel regular \
  --region REGION

Version skew policy

Autopilot đảm bảo version skew policy giữa control plane và nodes:

• Node không thể chạy Kubernetes version mới hơn control plane
• Node có thể đứng sau control plane tối đa 2 minor versions

Autopilot quản lý điều này tự động — control plane luôn được upgrade trước nodes.

Monitoring upgrade progress

# Xem cluster operations (bao gồm upgrade)
gcloud container operations list \
  --filter="operationType=UPGRADE_CLUSTER OR operationType=UPGRADE_NODES" \
  --sort-by=startTime

# Xem status của operation cụ thể
gcloud container operations describe OPERATION_ID --region REGION

# Theo dõi nodes đang được upgrade
kubectl get nodes -w

# Xem events liên quan đến upgrade
kubectl get events --field-selector reason=Upgrade -n kube-system

Cloud Monitoring để alert về upgrades

# Log-based metric cho upgrade events
gcloud logging metrics create autopilot-upgrade-started \
  --description="Autopilot cluster upgrade started" \
  --log-filter='resource.type="gke_cluster" AND jsonPayload.operationType="UPGRADE_NODES"'

Zero-downtime deployment khi cluster đang upgrade

Ngay cả khi Autopilot đang upgrade nodes, workloads có thể tiếp tục serve traffic nếu bạn thiết kế đúng:

# Deployment với rolling update để handle node eviction gracefully
apiVersion: apps/v1
kind: Deployment
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0  # Không cho phép Pod nào down
  template:
    spec:
      containers:
      - name: app
        readinessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 10
          periodSeconds: 5
        lifecycle:
          preStop:
            exec:
              command: ["/bin/sleep", "10"]  # Drain connections
      topologySpreadConstraints:
      - maxSkew: 1
        topologyKey: kubernetes.io/hostname
        whenUnsatisfiable: DoNotSchedule
        labelSelector:
          matchLabels:
            app: my-app

Với cấu hình này:

• maxUnavailable: 0 đảm bảo không bao giờ có zero Pods trong quá trình eviction
• topologySpreadConstraints spread Pods qua nhiều nodes để khi một node upgrade, không phải tất cả Pods bị ảnh hưởng
• preStop: sleep 10 cho phép load balancer drain connections trước khi Pod terminate

References

• Autopilot cluster upgrades
• Maintenance windows and exclusions
• GKE release channels
• Node upgrade strategies