Catatan perev.: Materi ulasan dari Weaveworks ini memperkenalkan strategi peluncuran aplikasi paling populer dan berbicara tentang kemungkinan penerapan yang paling canggih di antaranya menggunakan operator Kubernetes Flagger. Itu ditulis dalam bahasa yang sederhana dan berisi diagram visual yang memungkinkan bahkan insinyur pemula untuk memahami masalah ini.
Diagram diambil dari ulasan lain tentang strategi peluncuran yang dibuat di Container Solutions.Salah satu masalah terbesar dalam mengembangkan aplikasi cloud asli saat ini adalah penyebaran penyebaran. Dengan pendekatan microservice, pengembang sudah bekerja dengan aplikasi yang sepenuhnya modular dan mendesainnya, memungkinkan tim yang berbeda untuk menulis kode dan membuat perubahan pada aplikasi pada saat yang sama.
Penempatan yang lebih pendek dan lebih sering memiliki keuntungan sebagai berikut:
- Waktu ke pasar berkurang.
- Fitur-fitur baru menjangkau pengguna dengan lebih cepat.
- Umpan balik pengguna mencapai tim pengembangan lebih cepat. Ini berarti bahwa tim dapat melengkapi fungsi dan memperbaiki masalah dengan lebih cepat.
- Moral pengembang meningkat: lebih menarik untuk bekerja dengan sejumlah besar fungsi dalam pengembangan.
Tetapi dengan meningkatnya frekuensi rilis, peluang yang berdampak buruk terhadap keandalan aplikasi atau pengalaman pengguna juga meningkat. Itulah sebabnya penting bagi tim operasi dan DevOps untuk membangun proses dan mengelola strategi penempatan dengan cara yang meminimalkan risiko pada produk dan pengguna. (Pelajari lebih lanjut tentang otomatisasi pipa CI / CD di
sini .)
Dalam posting ini, kita akan membahas berbagai strategi penyebaran di Kubernetes, termasuk penyebaran bergulir dan metode yang lebih maju seperti peluncuran kenari dan variasinya.
Strategi Penempatan
Ada beberapa jenis strategi penerapan yang dapat Anda gunakan berdasarkan tujuan Anda. Misalnya, Anda mungkin perlu membuat perubahan pada lingkungan tertentu untuk pengujian lebih lanjut, atau ke subset pengguna / klien, atau Anda mungkin perlu melakukan pengujian terbatas pada pengguna sebelum membuat beberapa fungsi
tersedia untuk umum .
Rolling (penyebaran bertahap, “bergulir”)
Ini adalah strategi penyebaran standar di Kubernetes. Secara bertahap, satu per satu, menggantikan pods dengan versi lama aplikasi dengan pods dengan versi baru - tanpa downtime cluster.
Kubernet menunggu hingga pod baru siap untuk bekerja (memeriksanya dengan
tes kesiapan ) sebelum mulai menutup yang lama. Jika masalah terjadi, pembaruan bergulir tersebut dapat terganggu tanpa menghentikan seluruh cluster. Di jenis penyebaran jenis file YAML, 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 untuk pembaruan bergulir dapat ditentukan dalam file manifes:
spec: replicas: 3 strategy: type: RollingUpdate rollingUpdate: maxSurge: 25% maxUnavailable: 25% template: ...
Buat kembali (penciptaan ulang)
Dalam jenis penyebaran yang paling sederhana ini, pod lama terbunuh sekaligus dan diganti dengan yang baru:
Manifes yang sesuai terlihat seperti ini:
spec: replicas: 3 strategy: type: Recreate template: ...
Biru / Hijau (penyebaran biru-hijau)
Strategi penyebaran biru-hijau (kadang-kadang juga disebut merah / hitam, yaitu merah-hitam) melibatkan penerapan simultan dari versi aplikasi lama (hijau) dan baru (biru). Setelah menempatkan kedua versi, pengguna biasa mendapatkan akses ke yang hijau, sementara yang biru tersedia untuk tim QA untuk mengotomatisasi 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) telah diuji dan rilisnya telah disetujui, layanan beralih ke itu, dan hijau (lama) diminimalkan:
apiVersion: v1 kind: Service metadata: name: awesomeapp spec: selector: app: awesomeapp version: "02" ...
Canary (penyebaran kenari)
Gulungan kenari terlihat seperti biru-hijau, tetapi dikelola lebih baik dan menggunakan pendekatan bertahap
progresif . Jenis ini mencakup beberapa strategi yang berbeda, termasuk peluncuran "tersembunyi" dan pengujian A / B.
Strategi ini digunakan ketika diperlukan untuk mengalami beberapa fungsi baru, sebagai aturan, di backend aplikasi. Inti dari pendekatan ini adalah membuat dua server yang hampir identik: satu melayani hampir semua pengguna, dan yang lainnya, dengan fitur-fitur baru, hanya melayani sebagian kecil pengguna, setelah itu hasilnya dibandingkan. Jika semuanya berjalan lancar, versi baru secara bertahap diluncurkan ke seluruh infrastruktur.
Meskipun strategi ini hanya dapat diimplementasikan menggunakan alat Kubernetes, menggantikan pod lama dengan yang baru, itu jauh lebih nyaman dan lebih mudah untuk menggunakan layanan seperti Istio.
Misalnya, Anda dapat memiliki dua manifes berbeda di Git: yang biasa dengan tag 0,1.0 dan yang "canary" dengan tag 0,2.0. Dengan mengubah bobot dalam manifes gerbang virtual Istio, Anda dapat mengontrol distribusi lalu lintas antara dua penyebaran ini:
Untuk panduan tentang penerapan penyebaran kenari dengan Istio, lihat
Alur Kerja GitOps dengan Istio .
( Catatan terjemahan : Kami juga menerjemahkan materi tentang gulungan kenari di Istio di sini .)Penerapan Canary dengan Flagger Weaveworks
Weaveworks Flagger membuatnya mudah dan efisien untuk mengelola peluncuran kenari.
Flagger mengotomatiskan pekerjaan dengan mereka. Ini menggunakan Istio atau AWS App Mesh untuk merutekan dan mengalihkan lalu lintas, serta metrik Prometheus untuk menganalisis hasilnya. Selain itu, analisis penyebaran kenari dapat dilengkapi dengan kait web untuk tes penerimaan, tes stres dan segala jenis pemeriksaan lainnya.
Berdasarkan penyebaran Kubernetes dan, jika perlu, penskalaan horizontal pod (HPA), Flagger menciptakan set objek (penyebaran Kubernetes, layanan ClusterIP, dan layanan virtual Istio atau App Mesh) untuk analisis dan implementasi penyebaran kenari:
Menerapkan
loop kontrol , Flagger secara bertahap mengalihkan lalu lintas ke server kenari, sementara secara bersamaan mengukur indikator kinerja utama, seperti persentase permintaan HTTP yang berhasil, durasi permintaan rata-rata, dan kesehatan pod. Berdasarkan analisis KPI (indikator kinerja utama), bagian kenari tumbuh atau runtuh, dan hasil analisis diterbitkan dalam Slack. Deskripsi dan demonstrasi proses ini dapat ditemukan di
Pengiriman Progresif untuk App Mesh .
Gelap (tersembunyi) atau penyebaran A / B
Penyebaran rahasia adalah variasi lain dari strategi kenari (Flagger juga dapat bekerja dengannya, omong-omong). Perbedaan antara penyebaran terselubung dan kenari adalah bahwa penyebaran terselubung berurusan dengan frontend dan bukan backend, seperti penyebaran kenari.
Nama lain untuk penyebaran ini adalah pengujian A / B. Alih-alih membuka akses ke fungsi baru untuk semua pengguna, itu ditawarkan hanya untuk sebagian dari mereka. Biasanya, pengguna ini tidak tahu bahwa mereka adalah penguji perintis (oleh karena itu istilah "penyebaran terselubung").
Dengan menggunakan
sakelar fungsi dan alat lain, Anda dapat memantau bagaimana pengguna berinteraksi dengan fungsi baru, apakah itu memikat mereka, atau apakah mereka menemukan antarmuka pengguna baru membingungkan, dan jenis metrik lainnya.
Penanam Flagger dan A / B
Selain perutean tertimbang, Flagger juga dapat mengarahkan lalu lintas ke server kenari, tergantung pada pengaturan HTTP. Untuk pengujian A / B, Anda dapat menggunakan tajuk HTTP atau cookie untuk mengarahkan ulang segmen pengguna tertentu. Ini sangat efektif untuk aplikasi frontend yang memerlukan
afinitas sesi untuk server. Untuk informasi lebih lanjut, lihat dokumentasi Flagger.
Penulis berterima kasih kepada Stefan Prodan , insinyur Weaveworks (dan pencipta Flagger), untuk semua penyebaran yang mengagumkan ini.PS dari penerjemah
Baca juga di blog kami: