Revisi bidang kontrol Cloud Service Mesh

Halaman ini menjelaskan cara kerja revisi bidang kontrol dan manfaat menggunakannya untuk upgrade mesh layanan yang aman (dan rollback).

Dasar-dasar penginstalan mesh layanan

Pada level tinggi, penginstalan Cloud Service Mesh terdiri dari dua fase utama:

1. Pertama-tama, gunakan alat asmcli untuk menginstal bidang kontrol dalam cluster atau mengonfigurasi bidang kontrol terkelola. Bidang kontrol terdiri dari sekumpulan layanan sistem yang bertanggung jawab untuk mengelola konfigurasi mesh.

2. Selanjutnya, Anda akan men-deploy proxy file bantuan khusus di seluruh lingkungan yang mencegat komunikasi jaringan ke dan dari setiap workload. Proxy ini 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 workload Anda.

   Untuk men-deploy proxy, gunakan proses yang disebut injeksi file bantuan otomatis (injeksi otomatis) untuk menjalankan proxy sebagai container file bantuan 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 Anda dengan aman

Kemampuan untuk mengontrol traffic adalah salah satu manfaat utama penggunaan mesh layanan. Misalnya, Anda dapat mengalihkan traffic secara bertahap ke versi baru aplikasi saat pertama kali men-deploy-nya ke produksi. Jika ada masalah yang terdeteksi 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.

Catatan: Jenis upgrade alternatif adalah upgrade yang diterapkan, yang memungkinkan Anda mengupgrade dengan menginstal versi baru bidang kontrol. Versi bidang kontrol baru akan segera menggantikan versi lama. Upgrade yang diterapkan di tempat berisiko karena jika terjadi kegagalan, melakukan roll back dapat menjadi hal yang sulit. Untuk memasukkan ulang proxy dan membuatnya berkomunikasi dengan versi bidang kontrol baru, Anda harus memulai ulang semua workload di semua namespace Anda. Bergantung pada jumlah beban kerja dan namespace di mesh Anda, seluruh proses upgrade dapat memerlukan waktu satu jam atau lebih. Upgrade yang diterapkan dapat menyebabkan periode nonaktif dan harus dijadwalkan di masa pemeliharaan.

Dengan menggunakan revisi bidang kontrol dalam upgrade canary, Anda menginstal konfigurasi dan bidang kontrol baru dan terpisah bersama bidang kontrol yang ada. Penginstal menetapkan string yang disebut revisi untuk mengidentifikasi bidang kontrol baru. Pada awalnya, proxy file bantuan terus menerima konfigurasi dari bidang kontrol versi sebelumnya. Anda secara bertahap mengaitkan workload dengan bidang kontrol baru dengan memberi label namespace atau Pod-nya dengan revisi bidang kontrol baru. Setelah memberi label namespace atau Pod dengan revisi baru, Anda harus memulai ulang Pod workload sehingga Pod bantuan baru dimasukkan secara otomatis, dan menerima konfigurasinya dari bidang kontrol baru. Jika ada masalah, Anda dapat dengan mudah melakukan roll back dengan mengaitkan workload dengan bidang kontrol asli.

Bagaimana cara kerja injeksi otomatis?

Injeksi otomatis menggunakan fitur Kubernetes yang disebut kontrol penerimaan. Webhook akses yang bermutasi didaftarkan untuk mengawasi Pod yang baru dibuat. Webhook dikonfigurasi dengan pemilih namespace sehingga hanya cocok dengan Pod yang sedang di-deploy ke namespace yang memiliki label tertentu. Jika Pod cocok, webhook akan berkonsultasi dengan layanan injeksi yang disediakan oleh bidang kontrol untuk mendapatkan konfigurasi bermutasi baru untuk Pod, yang berisi container dan volume yang diperlukan untuk menjalankan file bantuan.

1. Konfigurasi webhook dibuat selama penginstalan. Webhook terdaftar dengan server Kubernetes API.
2. Server Kubernetes API memantau deployment Pod di namespace yang cocok dengan webhook namespaceSelector.
3. Namespace diberi label sehingga akan dicocokkan dengan namespaceSelector.
4. Pod yang di-deploy ke namespace akan memicu webhook.
5. Layanan inject yang disediakan oleh bidang kontrol mengubah spesifikasi Pod untuk menginjeksikan file bantuan secara otomatis.

Apa yang dimaksud dengan revisi?

Label yang digunakan untuk injeksi otomatis sama seperti label Kubernetes lain yang ditentukan pengguna. Label pada dasarnya adalah pasangan nilai kunci yang dapat digunakan untuk mendukung konsep pelabelan. 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. {i>Installer<i} 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 dengan istio.io/rev=asm-1204-0, dengan asm-1204-0 mengidentifikasi versi Cloud Service Mesh. Revisi menjadi bagian dari nama layanan, misalnya: istiod-asm-1204-0.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, tambahkan label revisi ke namespace yang cocok dengan label revisi di bidang kontrol. Misalnya, bidang kontrol dengan revisi istio.io/rev=asm-1204-0 akan memilih Pod di namespace dengan label istio.io/rev=asm-1204-0 dan memasukkan file bantuan.

Proses upgrade canary

Label revisi memungkinkan upgrade canary dan rollback yang mudah pada bidang kontrol dalam cluster. Kontrol terkelola menggunakan proses serupa, tetapi cluster Anda akan otomatis diupgrade ke versi terbaru dalam saluran tersebut.

Langkah-langkah berikut menjelaskan cara kerja proses tersebut:

1. Mulailah dengan Cloud Service Mesh atau penginstalan Istio open source yang sudah ada. Tidak masalah apakah namespace menggunakan label revisi atau label istio-injection=enabled.
2. Gunakan string revisi saat Anda menginstal bidang kontrol versi baru. Karena string revisi, bidang kontrol baru diinstal bersama versi yang ada. Penginstalan baru ini mencakup konfigurasi webhook baru dengan namespaceSelector yang dikonfigurasi untuk memantau namespace dengan label revisi spesifik tersebut.
3. Anda akan memigrasikan proxy file bantuan 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. Bidang kontrol dengan revisi tidak memilih Pod dalam namespace dengan label istio-injection, meskipun ada label revisi. Webhook untuk bidang kontrol baru memasukkan file bantuan ke dalam Pod.
4. Uji dengan cermat workload yang terkait dengan bidang kontrol yang diupgrade, dan Anda akan terus meluncurkan upgrade atau melakukan roll back ke bidang kontrol asli.

Setelah mengaitkan Pod dengan bidang kontrol baru, bidang kontrol dan webhook yang ada masih terinstal. Webhook lama tidak berpengaruh pada Pod di namespace yang telah dimigrasikan ke bidang kontrol baru. Anda dapat melakukan roll back Pod dalam namespace ke bidang kontrol asli dengan menghapus label revisi baru, menambahkan kembali label asli, dan memulai ulang Pod. Setelah yakin bahwa upgrade telah selesai, Anda dapat menghapus bidang kontrol lama.

Untuk langkah-langkah mendetail tentang cara mengupgrade menggunakan revisi, lihat Panduan upgrade.

Pelajari lebih lanjut konfigurasi webhook yang bermutasi

Guna lebih memahami webhook yang berubah untuk injeksi file bantuan otomatis, periksa sendiri konfigurasinya. 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 diinstal. Pemilih namespace untuk bidang kontrol berbasis revisi akan terlihat seperti ini:

 namespaceSelector:
    matchExpressions:
    - key: istio-injection
      operator: DoesNotExist
    - key: istio.io/rev
      operator: In
      values:
      - asm-1204-0

Pemilih ini dapat bervariasi bergantung pada versi Cloud Service Mesh atau Istio yang Anda jalankan. Pemilih ini mencocokkan namespace dengan label revisi tertentu selama tidak memiliki label istio-injection juga.

Saat Pod di-deploy ke namespace yang cocok dengan pemilih, spesifikasi Pod-nya akan dikirimkan ke layanan injektor untuk mutasi. Layanan injektor yang akan dipanggil ditentukan sebagai berikut:

     service:
        name: istiod-asm-1204-0
        namespace: istio-system
        path: /inject
        port: 443

Catatan: Untuk Mesh Layanan Cloud terkelola, layanan yang dikelola Google ditentukan oleh url:, bukan service:.

Layanan diekspos oleh bidang kontrol pada port 443 di jalur URL inject.

Bagian rules menentukan bahwa webhook harus diterapkan ke pembuatan Pod:

   rules:
    - apiGroups:
      - ""
      apiVersions:
      - v1
      operations:
      - CREATE
      resources:
      - pods
      scope: '*'

Langkah selanjutnya

• Mengupgrade Cloud Service Mesh
• Memasukkan proxy file bantuan