Revisi bidang kontrol Cloud Service Mesh
Halaman ini menjelaskan cara kerja revisi panel kontrol dan manfaat menggunakannya untuk upgrade (dan rollback) mesh layanan yang aman.
Dasar-dasar penginstalan mesh layanan
Pada tingkat tinggi, penginstalan Cloud Service Mesh terdiri dari dua fase utama:
Pertama, Anda menggunakan alat
asmcli
untuk menginstal bidang kontrol dalam cluster atau mengonfigurasi bidang kontrol terkelola. Bidang kontrol terdiri dari serangkaian layanan sistem yang bertanggung jawab untuk mengelola konfigurasi mesh.Selanjutnya, Anda men-deploy proxy sidecar khusus di seluruh lingkungan yang mencegat komunikasi jaringan ke dan dari setiap workload. Proxy berkomunikasi dengan bidang kontrol untuk mendapatkan konfigurasinya, yang memungkinkan Anda mengarahkan dan mengontrol traffic (traffic bidang data) di sekitar mesh tanpa melakukan perubahan apa pun pada beban kerja Anda.
Untuk men-deploy proxy, Anda menggunakan proses yang disebut injeksi sidecar otomatis (injeksi otomatis) untuk menjalankan proxy sebagai penampung sidecar tambahan di setiap Pod workload Anda. Anda tidak perlu mengubah manifes Kubernetes yang digunakan untuk men-deploy workload, tetapi Anda perlu menambahkan label ke namespace dan memulai ulang Pod.
Menggunakan revisi untuk mengupgrade mesh dengan aman
Kemampuan untuk mengontrol traffic adalah salah satu manfaat utama penggunaan mesh layanan. Misalnya, Anda dapat secara bertahap mengalihkan traffic ke versi baru aplikasi saat pertama kali men-deploynya ke produksi. Jika mendeteksi masalah selama upgrade, Anda dapat mengalihkan traffic kembali ke versi asli, sehingga memberikan cara melakukan roll back yang sederhana dan berisiko rendah. Prosedur ini dikenal sebagai rilis canary, dan sangat mengurangi risiko yang terkait dengan deployment baru.
Dengan menggunakan revisi bidang kontrol dalam upgrade canary, Anda menginstal konfigurasi dan bidang kontrol baru dan terpisah bersama dengan bidang kontrol yang ada. Penginstal menetapkan string yang disebut revisi untuk mengidentifikasi bidang kontrol baru. Pada awalnya, proxy sidecar terus menerima konfigurasi dari versi panel kontrol sebelumnya. Anda secara bertahap mengaitkan beban kerja dengan panel kontrol baru dengan memberi label pada namespace atau Pod dengan revisi panel kontrol baru. Setelah memberi label pada namespace atau Pod dengan revisi baru, Anda harus memulai ulang Pod workload sehingga sidecar baru dimasukkan secara otomatis, dan menerima konfigurasinya dari platform kontrol baru. Jika ada masalah, Anda dapat dengan mudah melakukan roll back dengan mengaitkan workload dengan panel kontrol asli.
Bagaimana cara kerja injeksi otomatis?
Injeksi otomatis menggunakan fitur Kubernetes yang disebut kontrol akses. Webhook izin yang diubah didaftarkan untuk memantau Pod yang baru dibuat. Webhook dikonfigurasi dengan pemilih namespace sehingga hanya cocok dengan Pod yang di-deploy ke namespace yang memiliki label tertentu. Saat Pod cocok, webhook akan berkonsultasi dengan layanan injeksi yang disediakan oleh platform kontrol untuk mendapatkan konfigurasi baru yang diubah untuk Pod, yang berisi penampung dan volume yang diperlukan untuk menjalankan sidecar.
- Konfigurasi webhook dibuat selama penginstalan. Webhook terdaftar dengan server Kubernetes API.
- Server Kubernetes API memantau deployment Pod di namespace yang cocok dengan
namespaceSelector
webhook. - Namespace diberi label agar cocok dengan
namespaceSelector
. - Pod yang di-deploy ke namespace akan memicu webhook.
- Layanan
inject
yang disediakan oleh bidang kontrol memutasi spesifikasi Pod untuk memasukkan sidecar secara otomatis.
Apa yang dimaksud dengan revisi?
Label yang digunakan untuk injeksi otomatis sama seperti label Kubernetes yang ditentukan pengguna lainnya. Label pada dasarnya adalah pasangan nilai kunci yang dapat digunakan untuk mendukung konsep pemberian label. Label banyak digunakan untuk pemberian tag dan revisi. Misalnya, tag Git, tag Docker, dan revisi Knative.
Proses penginstalan Cloud Service Mesh saat ini memungkinkan Anda memberi label pada
bidang kontrol yang diinstal dengan string revisi. Penginstal memberi label pada setiap objek
bidang kontrol dengan revisi. Kunci dalam key-value pair adalah istio.io/rev
, tetapi
nilai label revisi berbeda untuk bidang kontrol terkelola dan
bidang kontrol dalam cluster.
Untuk bidang kontrol dalam cluster, Layanan dan Deployment
istiod
biasanya memiliki label revisi yang mirip denganistio.io/rev=asm-1187-26
, denganasm-1187-26
mengidentifikasi versi Cloud Service Mesh. Revisi menjadi bagian dari nama layanan, misalnya:istiod-asm-1187-26.istio-system
Untuk bidang kontrol terkelola, label revisi sesuai dengan saluran rilis:
Label revisi Saluran istio.io/rev=asm-managed
Reguler istio.io/rev=asm-managed-rapid
Cepat istio.io/rev=asm-managed-stable
Stabil
Selain itu, Anda memiliki opsi untuk menggunakan
label injeksi default
(misalnya, istio-injection=enabled
).
Untuk mengaktifkan injeksi otomatis, Anda menambahkan label revisi ke namespace yang cocok dengan label revisi di bidang kontrol. Misalnya, platform kontrol
dengan revisi istio.io/rev=asm-1187-26
memilih Pod di namespace dengan
label istio.io/rev=asm-1187-26
dan memasukkan sidecar.
Proses upgrade canary
Label revisi memungkinkan Anda melakukan upgrade canary dan rollback yang mudah pada bidang kontrol dalam cluster. Kontrol terkelola menggunakan proses yang serupa, tetapi cluster Anda otomatis diupgrade ke versi terbaru dalam saluran tersebut.
Langkah-langkah berikut menjelaskan cara kerja proses ini:
- Mulai dengan penginstalan Cloud Service Mesh atau Istio open source yang ada. Tidak masalah apakah namespace menggunakan label revisi atau label
istio-injection=enabled
. - Gunakan string revisi saat Anda menginstal versi baru platform kontrol. Karena string revisi, panel kontrol baru diinstal bersama versi yang ada. Penginstalan baru menyertakan konfigurasi webhook baru dengan
namespaceSelector
yang dikonfigurasi untuk memantau namespace dengan label revisi tertentu tersebut. - Anda memigrasikan proxy sidecar ke bidang kontrol baru dengan menghapus label lama dari namespace, menambahkan label revisi baru, lalu memulai ulang Pod. Jika menggunakan revisi dengan Cloud Service Mesh, Anda
harus berhenti menggunakan label
istio-injection=enabled
. Panel kontrol dengan revisi tidak memilih Pod di namespace dengan labelistio-injection
, meskipun ada label revisi. Webhook untuk bidang kontrol baru memasukkan sidecar ke dalam Pod. - Uji dengan cermat beban kerja yang terkait dengan bidang kontrol yang diupgrade dan lanjutkan untuk meluncurkan upgrade atau kembali ke bidang kontrol asli.
Setelah mengaitkan Pod dengan panel kontrol baru, panel kontrol dan webhook yang ada masih diinstal. Webhook lama tidak berpengaruh untuk Pod di namespace yang telah dimigrasikan ke bidang kontrol baru. Anda dapat melakukan rollback Pod dalam namespace ke bidang kontrol asli dengan menghapus label revisi baru, menambahkan kembali label asli, dan memulai ulang Pod. Jika sudah yakin bahwa upgrade telah selesai, Anda dapat menghapus bidang kontrol lama.
Untuk mengetahui langkah-langkah mendetail tentang cara mengupgrade menggunakan revisi, lihat Panduan upgrade.
Melihat lebih dekat konfigurasi webhook yang berubah
Untuk lebih memahami webhook yang berubah untuk injeksi sidecar otomatis, periksa konfigurasinya sendiri. Gunakan perintah berikut:
kubectl -n istio-system get mutatingwebhookconfiguration -l app=sidecar-injector -o yaml
Anda akan melihat konfigurasi terpisah untuk setiap bidang kontrol yang telah Anda instal. Pemilih namespace untuk bidang kontrol berbasis revisi terlihat seperti ini:
namespaceSelector:
matchExpressions:
- key: istio-injection
operator: DoesNotExist
- key: istio.io/rev
operator: In
values:
- asm-1187-26
Pemilih dapat bervariasi bergantung pada versi Cloud Service Mesh atau Istio yang
Anda jalankan. Pemilih ini mencocokkan namespace dengan label revisi tertentu
asalkan tidak memiliki label istio-injection
.
Saat Pod di-deploy ke namespace yang cocok dengan pemilih, spesifikasi Pod-nya akan dikirim ke layanan injector untuk mutasi. Layanan penginjeksi yang akan dipanggil ditentukan sebagai berikut:
service:
name: istiod-asm-1187-26
namespace: istio-system
path: /inject
port: 443
Layanan diekspos oleh bidang kontrol di port 443 pada jalur URL inject
.
Bagian rules
menentukan bahwa webhook harus diterapkan ke pembuatan Pod:
rules:
- apiGroups:
- ""
apiVersions:
- v1
operations:
- CREATE
resources:
- pods
scope: '*'