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:

• [Rollout Plan] Plenty Migration to GKE
• [Rollout Plan] Vidio Chat Migration to Kubernetes
  

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