🥇Strategi penerapan di Kubernetes: rolling, recreate, blue/green, canary, dark (pengujian A/B)

Catatan terjemahan: Ikhtisar dari Weaveworks ini memperkenalkan strategi peluncuran aplikasi paling populer dan menunjukkan bagaimana strategi paling canggih dapat diimplementasikan menggunakan operator Kubernetes Flagger. Itu ditulis dalam bahasa sederhana dan berisi diagram visual yang memungkinkan bahkan insinyur pemula untuk memahami masalahnya.

Diagram diambil dari review lain strategi peluncuran yang dibuat di Container Solutions

Salah satu tantangan terbesar dalam mengembangkan aplikasi cloud native saat ini adalah mempercepat penerapan. Dalam pendekatan layanan mikro, pengembang telah bekerja dengan dan merancang aplikasi yang sepenuhnya modular, memungkinkan tim yang berbeda untuk menulis kode secara bersamaan dan membuat perubahan pada aplikasi.

Penerapan yang lebih singkat dan lebih sering memiliki manfaat sebagai berikut:

Waktu ke pasar berkurang.
Fitur-fitur baru menjangkau pengguna lebih cepat.
Umpan balik pengguna mencapai tim pengembangan lebih cepat. Artinya, tim dapat menambahkan fitur dan memperbaiki masalah dengan lebih cepat.
Semangat pengembang meningkat: semakin banyak fitur dalam pengembangan, semakin menyenangkan untuk digunakan.

Namun seiring dengan meningkatnya frekuensi rilis, kemungkinan dampak negatif terhadap keandalan aplikasi atau pengalaman pengguna juga meningkat. Itulah mengapa penting bagi tim operasi dan DevOps untuk membangun proses dan mengelola strategi penerapan dengan cara yang meminimalkan risiko terhadap produk dan pengguna. (Anda dapat mempelajari lebih lanjut tentang otomatisasi saluran CI/CD di sini.)

Dalam postingan kali ini, kita akan membahas berbagai strategi penerapan di Kubernetes, termasuk penerapan bergulir dan metode yang lebih canggih seperti peluncuran canary dan variasinya.

Strategi penerapan

Ada beberapa jenis strategi penerapan yang dapat Anda gunakan bergantung pada tujuan Anda. Misalnya, Anda mungkin perlu melakukan perubahan pada lingkungan tertentu untuk pengujian lebih lanjut, atau pada sebagian pengguna/klien, atau Anda mungkin perlu melakukan pengujian pengguna terbatas sebelum membuat fitur publik.

Bergulir (penyebaran bertahap, “bergulir”)

Ini adalah strategi penerapan standar di Kubernetes. Secara bertahap, satu per satu, menggantikan pod dengan aplikasi versi lama dengan pod dengan versi baru - tanpa downtime cluster.

Kubernetes menunggu hingga pod baru siap bekerja (memeriksanya menggunakan tes kesiapan), sebelum Anda mulai menggulung yang lama. Jika terjadi masalah, pembaruan berkelanjutan ini dapat dibatalkan tanpa menghentikan seluruh klaster. Dalam file YAML yang menjelaskan jenis penerapan, gambar baru menggantikan gambar lama:

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: awesomeapp
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: awesomeapp
    spec:
      containers:
        - name: awesomeapp
          image: imagerepo-user/awesomeapp:new
          ports:
            - containerPort: 8080

Parameter pembaruan roll-up dapat ditentukan dalam file manifes:

spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
       maxSurge: 25%
       maxUnavailable: 25%  
  template:
  ...

Buat ulang

Dalam jenis penerapan yang paling sederhana ini, pod lama akan dimatikan sekaligus dan diganti dengan yang baru:

Manifes terkait terlihat seperti ini:

spec:
  replicas: 3
  strategy:
    type: Recreate
  template:
  ...

Biru/Hijau (penerapan biru-hijau)

Strategi penerapan biru-hijau (terkadang juga disebut merah/hitam) melibatkan penerapan versi aplikasi lama (hijau) dan baru (biru) secara bersamaan. Setelah memposting kedua versi, pengguna biasa memiliki akses ke versi hijau, sedangkan versi biru tersedia bagi tim QA untuk mengotomatiskan pengujian melalui layanan terpisah atau penerusan port langsung:

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: awesomeapp-02
spec:
  template:
    metadata:
      labels:
        app: awesomeapp
        version: "02"

Setelah versi biru (baru) diuji dan peluncurannya disetujui, layanan beralih ke versi tersebut, dan versi hijau (lama) ditutup:

apiVersion: v1
kind: Service
metadata:
  name: awesomeapp
spec:
  selector:
    app: awesomeapp
    version: "02"
...

Canary (penyebaran kenari)

Peluncuran Canary mirip dengan peluncuran biru-hijau, namun memiliki kontrol dan penggunaan yang lebih baik progresif pendekatan langkah demi langkah. Jenis ini mencakup beberapa strategi berbeda, termasuk peluncuran “diam-diam” dan pengujian A/B.

Strategi ini digunakan ketika ada kebutuhan untuk mencoba beberapa fungsi baru, biasanya di backend aplikasi. Inti dari pendekatan ini adalah membuat dua server yang hampir identik: satu melayani hampir semua pengguna, dan yang lainnya, dengan fungsi baru, hanya melayani subkelompok kecil pengguna, setelah itu hasil pekerjaan mereka dibandingkan. Jika semuanya berjalan tanpa kesalahan, versi baru akan diluncurkan secara bertahap ke seluruh infrastruktur.

Meskipun strategi ini dapat diimplementasikan secara eksklusif menggunakan Kubernetes, menggantikan pod lama dengan yang baru, akan jauh lebih nyaman dan sederhana menggunakan service mesh seperti Istio.

Misalnya, Anda mungkin memiliki dua manifes berbeda di Git: manifes reguler dengan tag 0.1.0 dan manifes canary dengan tag 0.2.0. Dengan mengubah bobot dalam manifes gateway virtual Istio, Anda dapat mengontrol distribusi lalu lintas antara dua penerapan berikut:

Untuk panduan langkah demi langkah dalam mengimplementasikan penerapan canary menggunakan Istio, lihat Alur Kerja GitOps dengan Istio. (Catatan. terjemahan: Kami juga menerjemahkan materi tentang peluncuran kenari ke Istio di sini.)

Penerapan Canary dengan Weaveworks Flagger

Penanda Tenun memungkinkan Anda mengelola peluncuran canary dengan mudah dan efektif.

Flagger mengotomatiskan pekerjaan dengan mereka. Ia menggunakan Istio atau AWS App Mesh untuk merutekan dan mengalihkan lalu lintas, dan metrik Prometheus untuk menganalisis hasilnya. Selain itu, analisis penerapan canary dapat dilengkapi dengan webhook untuk melakukan uji penerimaan, uji beban, dan jenis pemeriksaan lainnya.

Berdasarkan penerapan Kubernetes dan, jika perlu, penskalaan pod horizontal (HPA), Flagger membuat kumpulan objek (penerapan Kubernetes, layanan ClusterIP, dan layanan virtual Istio atau App Mesh) untuk menganalisis dan mengimplementasikan penerapan canary:

Menerapkan loop kontrol (lingkaran kontrol),Flagger secara bertahap mengalihkan lalu lintas ke server canary sambil mengukur indikator kinerja utama seperti rasio permintaan HTTP yang berhasil, durasi permintaan rata-rata, dan kesehatan pod. Berdasarkan analisis KPI (Key Performance Indicators), kenari tumbuh atau runtuh dan hasil analisisnya dipublikasikan di Slack. Deskripsi dan demonstrasi proses ini dapat ditemukan dalam materi Pengiriman Progresif untuk App Mesh.

Penerapan gelap (tersembunyi) atau A/B

Penerapan siluman adalah variasi lain dari strategi canary (yang juga dapat digunakan oleh Flagger). Perbedaan antara penerapan stealth dan canary adalah penerapan stealth berhubungan dengan frontend, bukan backend seperti penerapan canary.

Nama lain untuk penerapan ini adalah pengujian A/B. Alih-alih membuat fitur baru tersedia untuk semua pengguna, fitur ini hanya ditawarkan kepada sebagian pengguna saja. Biasanya, para pengguna ini tidak menyadari bahwa mereka adalah penguji perintis (karena itulah istilah "penyebaran siluman").

Menggunakan sakelar fungsionalitas (fitur beralih) dan alat lainnya, Anda dapat memantau cara pengguna berinteraksi dengan fitur baru, apakah mereka terlibat dengan fitur tersebut, atau apakah mereka menganggap antarmuka pengguna baru membingungkan, dan jenis metrik lainnya.

Penerapan penanda dan A/B

Selain perutean berbasis bobot, Flagger juga dapat merutekan lalu lintas ke server canary berdasarkan parameter HTTP. Dalam pengujian A/B, Anda dapat menggunakan header atau cookie HTTP untuk menargetkan segmen pengguna tertentu. Hal ini sangat efektif terutama dalam kasus aplikasi frontend yang memerlukan pengikatan sesi ke server (afinitas sesi). Informasi lebih lanjut dapat ditemukan di dokumentasi Penanda.

Penulis berterima kasih Stefan Prodan, insinyur Weaveworks (dan pencipta Flagger), atas semua pola penerapan yang menakjubkan ini.

Strategi penerapan di Kubernetes: rolling, recreate, blue/green, canary, dark (pengujian A/B)