# Upgrading OpenShift 4.18.28 (EUS) → 4.19.19 (Stable)

Upgrade ini membawa cluster dari jalur **EUS (Extended Update Support) 4.18.28** ke versi **Stable 4.19.19**. Walaupun hanya satu lompatan minor, proses upgrade tetap harus dilakukan dengan hati‑hati karena perubahan antara OpenShift 4.18 → 4.19 mencakup:

* Upgrade Kubernetes **1.31 → 1.32**
* Peningkatan API & deprecation
* Update CO (Cluster Operators) termasuk MCO
* Perbaikan keamanan & bug fixes

Artikel ini merangkum:

* Pre‑check sebelum upgrade
* Prerequisite teknis
* Step‑by‑step upgrade
* Monitoring cluster operator
* Post‑upgrade health check
* Rollback plan

---

## 1. Pendahuluan

Cluster OpenShift 4.18 berada pada jalur **EUS**, sehingga update minor hanya diperbolehkan ke versi kompatibel, yaitu **4.19.x**. Dengan update ini meningkatkan stabilitas platform, keamanan, dan reliability komponen.

**Target Upgrade:**
➡️ `4.18.28 (EUS)` → `4.19.19 (Stable)`


Upgrade ini relatif aman sepanjang pre‑check dilakukan dengan benar dan proses monitoring berjalan ketat.

---

## 2. Pre‑Upgrade Activities

Tahap ini memastikan seluruh komponen cluster siap untuk di‑upgrade.

### 2.1 Login ke Console

* Masuk ke **Administrator Perspective**
* Buka **Cluster Overview**

Pastikan:

* Tidak ada **critical alerts**
* **Cluster Operators** mayoritas hijau
* **MachineConfigPools** tidak ada status *Updating*

### 2.2 Validasi Node

Jalankan:

oc get nodes -o wide

Pastikan:

* Semua node **Ready**
* Role terdeteksi dengan benar: master, worker, infra, router, dsb.

### 2.3 Validasi Pods Kritis

oc get pods -n openshift-ingress
oc get pods -n openshift-ingress-operator
oc get pods -n openshift-etcd

Pastikan **semua Running**.

### 2.4 Validasi MCP (MachineConfigPool)

oc get mcp

Semua harus **Updated**, **Not Updating**, **Not Degraded**.

---

## 3. Prerequisite Upgrade

### 3.1 Cek Operator Compatibility (OLM)

Pastikan semua Operator sudah pada channel/versi yang kompatibel dengan 4.19.

### 3.2 Telnet Whitelist Endpoint Red Hat

Sebelum upgrade OpenShift, pastikan semua node—terutama control plane—bisa mengakses endpoint eksternal yang dibutuhkan untuk menarik image, mengambil release payload, validasi sertifikat, hingga akses layanan Red Hat Cloud:

<div style="background:#1e293b;padding:8px;border-radius:6px;border-left:2px solid #38bdf8;">
<span style="color:#38bdf8;font-weight:">Hal ini hanya dilakukan jika cluster anda menggunakan firewall untuk komunikasi ke eksternal.</span>
</div>

https://quay.io
https://cdn.quay.io
https://cdn01.quay.io
https://cdn02.quay.io
https://cdn03.quay.io
https://cdn04.quay.io
https://cdn05.quay.io
https://cdn06.quay.io
https://quay-registry.s3.amazonaws.com
https://registry.redhat.io
https://registry.access.redhat.com
https://mirror.openshift.com
https://storage.googleapis.com/openshift-release
https://openshift.org
https://cloud.redhat.com/openshift
https://cloud.redhat.com/api/ingress
https://api.openshift.com
https://api.access.redhat.com
https://cert-api.access.redhat.com
https://infogw.api.openshift.com
https://art-rhcos-ci.s3.amazonaws.com

### 3.3 Cek No Proxy Cluster

oc get proxy cluster -o yaml

<div style="background:#1e293b;padding:8px;border-radius:6px;border-left:2px solid #38bdf8;">
<span style="color:#38bdf8;font-weight:">Hal ini hanya dilakukan jika cluster anda menggunakan proxy.</span>
</div>
Pastikan internal cluster dan IP vCenter di jalur no‑proxy.

### 3.4 Snapshot + Backup

> **WAJIB dilakukan sebelum upgrade**

* Snapshot **SEMUA master node VM** (jika menggunakan vSphere)
* Backup **etcd** manual ke bastion:

[root@master01 ~]# bash /usr/local/bin/cluster-backup.sh /home/core/backup-etcd
[root@master01 ~]# tar -cvzf backup-etcd.tar /home/core/backup-etcd
[root@bastion ~]# scp [e-mail]:/home/core/backup-etcd.tar backup-etcd

### 3.5 Edit MCP Worker – Set maxUnavailable = 1

oc edit mcp worker

Atur:

spec:
  maxUnavailable: 1

<div style="background:#1e293b;padding:8px;border-radius:6px;border-left:2px solid #38bdf8;">
<span style="color:#38bdf8;font-weight:">Jika worker berjumlah lebih dari 10 jangan set 1 agar cepat ketika proses reboot node.</span>
</div>

### 3.6 Scale Down Pods Aplikasi (Opsional Produksi)

Jika aplikasi sensitif:

oc scale deploy <app> -n <ns> --replicas=0

### 3.7 Unpause MCP

> Resume semua MCP kecuali master

Dilakukan via Console → Compute → MachineConfigPools.

### 3.8 Acknowledge API Removal
OpenShift 4.19 mengikuti Kubernetes 1.32, [di mana beberapa API sudah dihapus permanen (Removed) dan tidak bisa lagi di-force enable.](https://access.redhat.com/articles/7112216)
Sebelum upgrade dilakukan, wajib memastikan tidak ada workload yang masih menggunakan API yang sudah dihapus.

Gunakan perintah berikut untuk menampilkan seluruh API yang memiliki status **removedInRelease** beserta jumlah request yang masih ada:

# oc get apirequestcounts -o jsonpath='{range .items[?(@.status.removedInRelease!="")]}{.status.removedInRelease}{"\t"}{.status.requestCount}{"\t"}{.metadata.name}{"\n"}{end}'

Cek jumlah request API removed dalam 24 jam terakhir

oc get apirequestcounts <nama_api> -o json | jq '.status.last24h.requestCount'

> Jika angka request masih > 0, workload harus migrasi ke API versi terbaru. API yang sudah Removed tidak dapat di-enable kembali, sehingga upgrade tetap dilakukan akan bikin aplikasi gagal jalan.

Jika workload sudah tidak ada yang request ke API removed maka lakukan acknowledge:

# oc -n openshift-config patch cm admin-acks --patch '{"data":{"ack-4.18-kube-1.32-api-removals-in-4.19":"true"}}' --type=merge

---

## 4. Proses Upgrade

### 4.1 Upgrade 4.18.28 → 4.19.19

Langkah:

1. Login console sebagai **cluster-admin**
2. Buka menu **Administration** → **Cluster Settings** → **Details**
3. Pada bagian **Channel**, pastikan channel sudah sesuai (misal: stable-4.19 jika upgrade ke 4.19.x)
4. Klik **Select a Version**
5. Pilih **versi target** dari drop-down (contoh: **4.19.19**)
6. Pilih **Control plane only update** / **Partial cluster update**
7. Pada langkah **Select nodes to pause**, centang custom pool node **selain master** yang ingin dipause (misalnya worker yang lagi running workload berat).
8. Klik **Update**.

Klik **Save**.

<img src="https://hackmd.io/_uploads/HyeFimclWZx.png" width="400">

### 4.2 Monitoring Proses Upgrade

Monitoring komponen OCP selama upgrade:

# watch oc get clusterversion; echo "---"; oc get mcp; echo "---"; oc get co; echo "---"; oc get po -A | grep -vE "Running|Completed";echo "---"; oc get nodes 


atau melalui console tab **Cluster Operators**.

Setelah seluruh **Cluster Operators** mencapai versi **4.19.19**(kecuali machine-config), node **master** akan otomatis melakukan proses reboot terlebih dahulu. Hal ini terjadi karena **MachineConfig untuk master diproses lebih dulu** dibandingkan worker/infra.

---
Pada saat rolling node master. Pantau log Machine Config Controller untuk memastikan tidak ada Pod yang stuck:

oc logs -n openshift-machine-config-operator deploy/machine-config-controller -f

Jika terdapat Pod aplikasi atau sistem yang **gagal / terminating** dan menghambat proses draining, lakukan force delete:

oc delete pod <nama_pod> -n <namespace> --force --grace-period=0

---
Setelah **semua master selesai reboot**, lanjutkan dengan resume semua MCP selain master:

- infra
- router
- worker

Agar MachineConfig dapat diproses dan seluruh node ikut update ke **4.19.19**.

# oc patch mcp <nama_pool> --type=merge -p '{"spec":{"paused":false}}'


## 5. Post‑Upgrade Activities

### 5.1 Health Check Cluster Global

# oc get no,co,mcp


Pastikan:

* Tidak ada Degraded
* MCP Updated
* Semua node Ready

### 5.2 Validate Ingress

oc get pods -n openshift-ingress


Cek apakah router container recreate dengan versi baru.

### 5.3 Validate Etcd

oc -n openshift-etcd get po


### 5.4 Pause MCP

Pause kembali MCP master, worker, infra, router MCP.

oc patch mcp <nama_pool> --type=merge -p '{"spec":{"paused":true}}'


---

## 6. Rollback Plan

> Rollback minor upgrade hanya dimungkinkan dengan snapshot VM + backup etcd.

Rollback Plan:

1. Power off seluruh master
2. Restore snapshot sebelum upgrade
3. Power on master node
4. Validasi etcd, API server, dan CO status

Jika tanpa snapshot, rollback **tidak direkomendasikan** dan bisa menyebabkan cluster corrupt.

---

## 7. Penutup

Upgrade 4.18 → 4.19 termasuk kategori **safe minor upgrade**, namun tetap harus dilakukan secara terstruktur.

Dengan mengikuti panduan ini, upgrade dapat dilakukan dengan aman, terdokumentasi, dan sesuai best practice Red Hat.

Referensi: [Performing a Control Plane Only update OCP 4.19](https://docs.redhat.com/en/documentation/openshift_container_platform/4.19/html-single/updating_clusters/index#control-plane-only-update)