Panduan Migrasi Services ke Kubernetes (Bagian 3)

Panduan ini berasal dari dokumentasi internal untuk tim engineering di Vidio, yang kami rasa mungkin berguna untuk dibagikan kepada komunitas yang lebih luas. Kami sadari ada background / context yang kurang lengkap yang kami masih belum sempat menambahkannya.

Bagian 3 ini merupakan bagian akhir dari artikel tentang panduan migrasi services ke kubernetes. Diawali dengan penjelasan dan pengenalan tentang komponen serta skill yang diperlukan di Bagian 1, lalu dilanjutkan dengan penjelasan tentang proses migrasi services ke kubernetes di Bagian 2. Bagian ini menjelaskan tentang kesiapan service ke production environment melalui tahapan Production Readiness dan perencanaan skema rollout yang akan digunakan.

Production Readiness

[Kubernetes] Production Readiness Checklist [TEMPLATE]

Production Readiness di atas sebagian besar diadopsi dari artikel berikut: Kubernetes production best practices (learnk8s.io)

Salin template tersebut menjadi nama service Anda, lalu lakukan tinjauan terhadap checklist yang ada.

Rollout Plan

Tujuan memiliki rollout plan dokumen adalah untuk menuliskan rencana rollout secara aman. Semua orang dari berbagai tim dapat me-review dan memberikan feedback.

Rollout plan yang baik mengandung:

Background / konteks
Kondisi saat ini
Kondisi baru setelah rollout
Langkah-langkah rollout di environment staging
Langkah-langkah rollout di environment production
Revert / rollback plan
Proses rollout
Apa yang terjadi selama proses rollout
Isu yang ditemukan
Catatan-catatan
Post rollout

Contoh dari services yang sudah berjalan:

Skema Rollout yang direkomendasikan (diurutkan berdasarkan preferensi)

Yang paling direkomendasikan:
- Menggunakan envoy / Gloo API Gateway, yang sudah berjalan di GKE cluster.
  - Ini memungkinkan kita untuk melakukan switch di level TCP daripada DNS.
  - Proses pembaruannya instan, tidak melibatkan TTL dan client cache.
    - Risiko lebih rendah
    - Proses rollback lebih cepat
  - Memungkinkan kita untuk melakukan peralihan (switching) secara bertahap berdasarkan path
    - Risiko lebih rendah
- Dengan menggunakan opsi ini, akan ada 2 fase:
  - Switch DNS ke GKE Ingress → envoy → kembali ke VM
  - Secara berkala memperbarui envoy untuk mengalirkan lebih banyak traffic ke pods
- Lihat contoh: [Rollout Plan] Plenty Migration to GKE
Jika langkah di atas tidak berhasil karena alasan tertentu, opsi berikutnya adalah menggunakan Route53 DNS Weighted Routing.
- TODO: Jelaskan
Dalam kasus DNS → Akamai → GLB, peralihan (switching) ke GKE LB yang disarankan adalah menggunakan property yang sama dan menambahkan rules Akamai untuk mengalihkan (switch) origin berdasarkan kondisi tertentu.
- TODO: jelaskan
- NS: Di Akamai property bisa ditambah rules, path tertentu bisa beda origin
  - Bisa path, bisa user agent, bisa header / cookie
- JGM: Ada percentage client