Upgrade OpenShift 4.18 to 4.20
Upgrade klaster OpenShift di lingkungan production bukan sekadar menjalankan perintah oc adm upgrade. Tantangan terbesarnya berada pada ketersediaan workloads, terutama aplikasi stateful, message broker, atau database yang rentan mengalami gangguan jika worker node di-reboot secara otomatis bersamaan oleh Machine Config Operator (MCO).
Dokumentasi ini merangkum strategi Controlled Upgrade dari OpenShift 4.18 ke 4.20 melalui intermediate release 4.19, dengan mengisolasi node menggunakan Dedicated MachineConfigPool (MCP).
1. Konsep & Alur Arsitektur
Secara default, saat upgrade OpenShift selesai di level Control Plane, MCO akan langsung melakukan rolling drain and reboot pada seluruh worker node. Strategi controlled upgrade memisahkan siklus update antara Control Plane dan Worker Node:
OpenShift 4.18 ──(Hop 1)──► OpenShift 4.19 ──(Hop 2)──► OpenShift 4.20
│
┌───────────────────────────────────────────────────────────┴──────────────────────────────┐
│ │
▼ ▼
Control Plane (Masters) Worker Nodes (Paused)
Di-upgrade otomatis sampai 4.20 Tahan reboot selama CP upgrade
┌──────────────┴─────────────┐
▼ ▼
Worker-Special MCP Regular Worker MCP
(Node stateful/manual) (Tuning maxUnavailable)| Komponen | Peran dalam Controlled Upgrade |
|---|---|
| etcd Backup | Recovery point wajib sebelum menyentuh versi klaster. |
| spec.paused: true | Menghentikan MCO agar tidak me-reboot worker selama control plane bergerak. |
| worker-special MCP | Memisahkan node dengan aplikasi khusus (singleton, DB) agar dipelihara manual. |
| maxUnavailable | Mengatur jumlah node yang boleh restart paralel pada worker reguler. |
2. Fase 1: Pre-Flight & Proteksi Klaster
A. Validasi Status Klaster
Pastikan klaster dalam kondisi sehat tanpa ada operator yang degraded:
oc get clusterversion
oc get co | grep -iv 'True.*False.*False'
oc get nodes
oc adm top nodesB. Backup etcd
Jalankan script backup etcd pada salah satu control-plane node dan simpan arsipnya di luar klaster:
# Jalankan backup langsung via debug pod pada master node
oc debug node/<master-node-name> -- chroot /host /usr/local/bin/cluster-backup.sh /home/core/assets/backup/$(date +%F)
# Ambil salinan hasil backup ke bastion host
scp -r core@<master-node-name>:/home/core/assets/backup/$(date +%F) ~/etcd-backup/Simpan juga snapshot diagnostik klaster dengan oc adm must-gather sebagai baseline pendukung.
3. Fase 2: Isolasi Worker Node (Dedicated MCP)
Pisahkan node yang menjalankan workload sensitif ke dalam pool terisolasi (worker-special).
A. Buat Manifest MachineConfigPool
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfigPool
metadata:
name: worker-special
spec:
machineConfigSelector:
matchExpressions:
- key: machineconfiguration.openshift.io/role
operator: In
values:
- worker
- worker-special
nodeSelector:
matchLabels:
node-role.kubernetes.io/worker-special: ""Terapkan manifest dan beri label pada node target:
oc apply -f mcp-worker-special.yaml
# Pindahkan node target ke role worker-special
oc label node <special-worker-node> node-role.kubernetes.io/worker-special="" B. Pause Seluruh Worker MCP
Kunci kedua pool worker agar MCO tidak menyentuh worker node selama upgrade control-plane berlangsung:
oc patch mcp/worker --type merge -p '{"spec":{"paused":true}}'
oc patch mcp/worker-special --type merge -p '{"spec":{"paused":true}}'
# Verifikasi status paused
oc get mcp4. Fase 3: Upgrade Control Plane (4.18 ➔ 4.19 ➔ 4.20)
OpenShift memerlukan upgrade bertahap (no skip minor version). Karena seluruh worker di-pause, fase ini hanya memperbarui Control Plane, API, dan Cluster Operators tanpa memicu reboot node worker.
A. Ubah Channel ke eus-4.20
Untuk transisi EUS-to-EUS (dari rilis genap 4.18 ke 4.20 melalui intermediate 4.19), ubah update channel pada resource clusterversion ke eus-4.20:
# Ubah channel ke eus-4.20 via patch
oc patch clusterversion version --type merge -p '{"spec":{"channel":"eus-4.20"}}'
# Atau edit manual konfigurasi clusterversion
oc edit clusterversion
# Verifikasi channel telah berpindah
oc get clusterversionB. Hop 1 — Upgrade ke 4.19
Sebelum eksekusi Hop 1, periksa apakah klaster memerlukan persetujuan API deprecation dari 4.18 menuju 4.19:
# 1. Cek apakah cluster upgradeable atau ada blocker
oc adm upgrade
# 2. Terapkan acknowledgement untuk 4.18 -> 4.19 jika diminta:
oc -n openshift-config patch cm admin-acks \
--patch '{"data":{"ack-4.18-kube-1.32-api-removals-in-4.19":"true"}}' --type=merge
oc -n openshift-config patch cm admin-acks \
--patch '{"data":{"ack-4.18-gateway-api-management-in-4.19":"true"}}' --type=merge
# 3. Eksekusi upgrade ke target intermediate 4.19
oc adm upgrade --to 4.19.34
# 4. Monitor hingga ClusterVersion dan seluruh Operator AVAILABLE
watch "oc get clusterversion && oc get co"C. Hop 2 — Upgrade ke 4.20
Setelah rilis 4.19 stabil dan sehat, lakukan acknowledgement untuk transisi 4.19 menuju 4.20:
# 1. Cek blocker acknowledgement pada rilis 4.19
oc adm upgrade
# 2. Terapkan acknowledgement untuk 4.19 -> 4.20 jika diminta:
oc -n openshift-config patch cm admin-acks \
--patch '{"data":{"ack-4.19-admissionregistration-v1beta1-api-removals-in-4.20":"true"}}' --type=merge
# 3. Eksekusi upgrade ke target final 4.20
oc adm upgrade --to 4.20.26
# 4. Monitor proses pembaruan control plane
watch "oc get clusterversion && oc get co"
# 5. Verifikasi hasil akhir control plane
oc get clusterversion
oc get nodes5. Fase 4: Controlled Worker Rolling Update
Setelah Control Plane berada di versi 4.20, lakukan update worker node secara terkontrol.
A. Eksekusi Node Stateful (worker-special)
Unpause pool khusus dan lakukan failover manual per-aplikasi jika diperlukan:
# Unpause pool worker-special
oc patch mcp/worker-special --type merge -p '{"spec":{"paused":false}}'
# Monitor proses drain, update MachineConfig, dan reboot node
watch "oc get mcp worker-special && oc get nodes"Production Best Practice: Untuk workload active-standby, lakukan manual switchover database sebelum node aktif di-drain oleh MCO, lalu validasi kesehatan instance standby.
B. Eksekusi Pool Regular Worker
Untuk worker reguler, Anda dapat mempercepat durasi maintenance window dengan menaikkan nilai maxUnavailable:
# Izinkan 2 node di-reboot bersamaan (sesuaikan dengan kapasitas resource klaster)
oc patch mcp/worker --type merge -p '{"spec":{"maxUnavailable":2}}'
# Unpause worker reguler
oc patch mcp/worker --type merge -p '{"spec":{"paused":false}}'
# Monitor proses rolling update
watch "oc get mcp worker && oc get nodes"6. Fase 5: Post-Upgrade
Setelah seluruh node selesai diperbarui ke versi 4.20 (UPDATED: True, UPDATING: False):
A. Restore Safety Configuration
# Restore maxUnavailable ke nilai konservatif
oc patch mcp/worker --type merge -p '{"spec":{"maxUnavailable":1}}'
# Restore node worker-special ke pool worker standar
oc label node <special-worker-node> node-role.kubernetes.io/worker-special- B. Verifikasi Workload
Lakukan pengujian menyeluruh pada level aplikasi:
# Pastikan tidak ada pod abnormal di seluruh namespace
oc get pods -A | grep -iv 'Running\|Completed'
# Cek status operator dan ingress routing
oc get co
oc get routes -ARingkasan
- Jadikan Upgrade Dapat Diprediksi (Predictable): Jangan biarkan worker reboot bersamaan tanpa batas kendali.
- Pisahkan Siklus Pembaruan: Biarkan Control Plane selesai dan stabil terlebih dahulu sebelum menyentuh worker node.
- Pahami Karakter Workload: Stateful workloads memerlukan koordinasi level aplikasi, bukan sekadar evakuasi pod otomatis.
- Validasi Setiap Hop: Jangan berpindah dari 4.19 ke 4.20 sebelum status cluster operator pada 4.19 sepenuhnya
AVAILABLE=TruedanDEGRADED=False.