Tulisan ini di tulis sebelumnya di Medium Alevz's Medium on Day2 Operation GKE + PDB

Beberapa saat ini saya ada diskusi kecil dengan teman seperjuangan mengenai bagaimana memperbaharui versi klaster GKE tetapi dengan cara dimana kita memiliki kontrol lebih dalam melakukan upgrade ini. Beberapa hal yang menjadikan hal ini menarik adalah dengan release 1.19 yang bisa di baca di Kubernetes.io Blog kubernetes release 1.19 menandakan adanya versi baru dan kita butuh aware mengenai perubahan yang ada (terutama mengenai patches dan features baru jika ingin di adopsi). Hal yang baik adalah mereka menambah support menjadi 1 tahun dari 9 bulan, sehingga tambahan waktu untuk kita sebagai ops sebelum memutuskan apakah dibutuhkan untuk upgrade ke versi yang baru.

GKE sebagai "managed kubernetes" memiliki cara tersendiri untuk melakukan pembaharuan secara otomatis, dimana user bisa memberikan tanggung jawab pengaturan ke GKE. Tetapi ada beberapa kondisi ataupun kebutuhan internal untuk mendapatkan kontrol lebih dalam melakukan pembaharuan ini, terutama dari sisi uptime dari beban kerja (read: workload) kita. Tujuan dari tulisan ini adalah sebagai share experience untuk teman-teman yang baru mengadopsi Kubernetes (terutama GKE) sehingga bisa mempersiapkan konfigurasi yang lebih cocok untuk kondisi teman-teman dan juga persiapan sebelum pembaharuan dibutuhkan. Notes: share ini bersifat oversimplified dari konfigurasi yang ada (terutama semua beban kerja adalah stateless, untuk statefulset ataupun persistance volume tidak tersedia di tulisan ini), untuk hal yang lebih dalam boleh melakukan referensi ke dokumentasi resmi kubernetes.io ataupun ada beberapa referensi yang menurut saya cukup menarik dari Google Cloud

Kubernetes.io - pdb
Google Cloud Blog - highly available GKE cluster
Google Cloud Blog - day 2 operation for Business Continuity

Pod Disruption Budget

Pod Disruption Budget atau pdb adalah konfigurasi yang dapat membantu kita untuk melakukan deklarasi mengenai budget disrupsi kita, yang artinya adalah kita menyatakan seberapa banyak disrupsi yang kita perbolehkan terjadi dalam deployment kita. Secara konfigurasi ada dua hal yang bisa kita deklarasikan:

• Min Available : sebagai pernyataan kuantitas dari replika minimum yang harus ada
• Max Unavailable : atau kita bisa menggunakan kuantitas terbanyak yang kita perbolehkan untuk terdisrupsi

contoh berdasarkan kubernetes.io

Sehingga dengan adanya PDB kita bisa mendapatkan "tali pengaman" untuk menjaga kuantitas minimum dari beban kerja kita.

Manual Upgrade
Secara singkat untuk melakukan pembaharuan versi dengan tambahan kontrol yang kita bisa lakukan adalah:

1. Melakukan pembaharuan pada Control Plane. Ketika melakukan pembaharuan ini, dan teman-teman menggunakan zonal (dibandingkan dengan menggunakan regional) sehingga tidak ada HA dari control plane, tidak perlu khawatir karena beban kerja kita tidak akan di hentikan atau terganggu. Hanya perlu perhatian bahwa kita tidak dapat melakukan API Call karena control plane sedang tidak tersedia.
2. Menambah Node-Pool baru. Dengan kita menambah node pool baru, kita bisa seketika mempersiapkan worker nodes dengan versi yang kita inginkan (biasanya disamakan dengan versi control plane yang baru). Hal ini adalah kelebihan dari menggunakan Cloud provider karena kita bisa seketika menambah atau merubah node-pool dengan cost yang bisa di perhitungkan.
3. Cordon-Drain. Hal terakhir adalah kita melakukan secara manual cordon dan drain beban kerja kita dari masing-masing worker node yang ada.

Disinilah PDB (dan beberapa konfigurasi lainnya seperti affinity) sangat berguna. PDB menjamin ketika kita melakukan pod eviction kita tidak akan melakukan terminasi dibawah dari kuantitas minumum yang di berikan. Hal terburuk adalah ketika kita mendapatkan karena suatu hal semua Pod kita berada di 1 worker node yang sama, sehingga ketika kita melakukan drain pasti Pod kita akan di terminasi. PDB menjamin kuantitas minimum, sehingga ketika hal tersebut terjadi eviction akan di tahan sampai workload yang baru sudah berjalan dengan baik di tempat yang lain.

Beberapa sample steps:

[Satu] Kita initiate untuk Klaster GKE baru. Ada banyak cara yang teman-teman bisa gunakan, tetapi jika ingin cepat (trick) bisa coba create menggunakan UI, tetapi pada akhir step teman-teman klik command line untuk mendapatkan gcloud call yang bisa digukana dengan gcloud sdk.

Pada step ini saya menggunakan setup:

• Zonal klaster GKE versi 1.15.12-gke.20
• Node-pool "default" dengan 3 nodes versi 1.15.12-gke.20
• Beban kerja: 3 replica hello-node
• pdb: minAvailable 2 (-1 dari replica yang saya buat)

[Dua] Melakukan pembaharuan Control Plane menjadi versi 1.16.13-gke.1 (satu versi di atas dari versi 1.15.12-gke.20)

Notes: API server tidak tersedia saat ini karena saya menggunakan klaster zonal tetapi workload tetap berjalan dengan baik.

Pembaharuan berhasil dengan baik

[Tiga] Menambahkan node-pool baru dengan versi yang sama dengan control plane (node-pool-new-1)

[Empat] Ketika node pool sudah tersedia, hal yang perlu kita lakukan adalah cordon node yang ingin kita pindahkan, dan lakukan drain.

Yang menarik di proses ini adalah PDB melakukan pekerjaannya dimana setup dari minimum qty akan menentukan banyaknya disrupsi yang boleh terjadi. Pada set diatas, terlihat bahwa Allowed Disruption: 0 karena adanya eviction dari 1 replica (3-1=2;minimum 2;boleh disrupsi menjadi 0). Jika ada tambahan replica pada node ini, maka proses eviction akan di tahan hingga mencapai qty pdb yang dibutuhkan.

Lalu kita bisa ulang proses tersebut hingga seluruh beban kerja kita sudah pindah ke node-pool yang baru dengan versi yang sama dengan Control-Plane kita

Bisa terlihat semua beban kerja sekarang berada di node-pool yang baru sehingga sejauh ini proses kita bisa dianggap sebagai berhasil. Sebagai catatan kembali tulisan ini menggunakan overly simplified setting, sehingga untuk beberapa konfigurasi yang lebih kompleks akan dibutuhkan persiapan tambahan. Jika teman-teman ada pendekatan ataupun pengalaman lainnya, jangan ragu untuk drop some comment sehingga kita bisa saling belajar :) Love to hear more from you.