Revisi bidang kontrol Cloud Service Mesh

Halaman ini menjelaskan cara kerja revisi bidang kontrol dan nilai 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 men-deploy proxy file bantuan khusus di seluruh lingkungan yang mencegat komunikasi jaringan ke dan dari setiap beban kerja. {i>Proxy<i} berkomunikasi dengan bidang kontrol untuk mendapatkan konfigurasi, yang memungkinkan mengarahkan dan mengontrol traffic (traffic bidang data) di sekitar mesh Anda tanpa mengubah beban kerja Anda.

   Untuk men-deploy proxy, Anda menggunakan proses yang disebut injeksi file bantuan otomatis (injeksi otomatis) untuk menjalankan {i>proxy<i} sebagai penampung file bantuan tambahan di setiap Pod workload Anda. Anda tidak perlu memodifikasi manifes Kubernetes yang digunakan untuk men-deploy workload, tetapi Anda perlu menambahkan label namespace dan memulai ulang Pod.

Menggunakan revisi untuk mengupgrade mesh Anda dengan aman

Kemampuan untuk mengontrol traffic adalah salah satu manfaat utama dari jaringan layanan. Misalnya, Anda dapat secara bertahap mengalihkan lalu lintas data ke versi baru sebuah aplikasi saat pertama kali men-deploy-nya ke produksi. Jika Anda mendeteksi masalah selama peningkatan versi, Anda dapat mengalihkan lalu lintas kembali ke versi asli, menyediakan cara melakukan roll back yang sederhana dan berisiko rendah. Prosedur ini telah diketahui sebagai rilis canary, dan ini sangat mengurangi risiko yang terkait dengan deployment.

Catatan: Jenis upgrade alternatif adalah upgrade yang diterapkan saat Anda {i>upgrade <i}dengan memasang versi baru bidang kontrol. Bidang kontrol baru {i>version<i} segera menggantikan versi lama. Upgrade yang diterapkan di tempat berisiko karena jika terjadi kegagalan, melakukan roll back akan sulit dilakukan. Untuk memasukkan kembali menggunakan {i>proxy<i} dan memintanya berkomunikasi dengan versi bidang kontrol baru, Anda harus untuk memulai ulang semua workload di semua namespace Anda. Tergantung jumlah workload dan namespace di mesh Anda, seluruh proses upgrade dapat memakan waktu jam atau lebih. Upgrade yang diterapkan dapat menyebabkan periode nonaktif dan harus dijadwalkan masa pemeliharaan.

Dengan menggunakan revisi bidang kontrol dalam {i>upgrade <i}canary, Anda menginstal bidang kontrol dan konfigurasi yang terpisah di samping bidang kontrol yang ada. Penginstal menetapkan string yang disebut revisi untuk mengidentifikasi kontrol baru pesawat terbang. Pada awalnya, proxy file bantuan terus menerima konfigurasi dari bidang kontrol versi sebelumnya. Anda secara bertahap menghubungkan workload dengan bidang kontrol baru dengan memberi label namespace atau Pod dengan kontrol baru versi baru. Setelah memberi label namespace atau Pod dengan revisi, Anda bisa memulai ulang Pod workload sehingga file bantuan baru dapat dimasukkan secara otomatis, dan mereka menerima konfigurasinya dari bidang kontrol baru. Jika ada masalah, Anda dapat dengan mudah melakukan rollback dengan mengaitkan beban kerja ke 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. Tujuan webhook dikonfigurasi dengan pemilih namespace agar hanya cocok dengan Pod yang di-deploy ke namespace yang memiliki label tertentu. Kapan Pod cocok, webhook berkonsultasi dengan layanan injeksi yang disediakan oleh kontrol untuk mendapatkan konfigurasi bermutasi baru untuk Pod, yang berisi dan volume yang diperlukan untuk menjalankan file bantuan.

1. Konfigurasi webhook dibuat selama penginstalan. Webhook-nya adalah yang terdaftar di server Kubernetes API.
2. Server Kubernetes API mengamati 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 akan mengubah Pod spesifikasi untuk memasukkan file bantuan secara otomatis.

Apa yang dimaksud dengan revisi?

Label yang digunakan untuk injeksi otomatis sama seperti label Kubernetes lain yang ditentukan pengguna label. Label pada dasarnya adalah pasangan nilai kunci yang dapat digunakan untuk mendukung konsep pelabelan. Label banyak digunakan untuk penandaan dan untuk beberapa revisi. Misalnya, tag Git, tag Docker, dan Revisi Knative.

Proses penginstalan Cloud Service Mesh saat ini memungkinkan Anda memberi label pada penginstalan bidang kontrol dengan string revisi. Penginstal memberi label pada setiap bidang kontrol dengan revisi. Kunci dalam pasangan nilai kunci adalah istio.io/rev, tetapi nilai label revisi berbeda untuk bidang kontrol yang dikelola 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-1233-2, dengan asm-1233-2 mengidentifikasi versi Cloud Service Mesh. Revisi menjadi bagian dari nama layanan, misalnya: istiod-asm-1233-2.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 Anda yang sesuai dengan label revisi di bidang kontrol. Misalnya, bidang kontrol dengan revisi istio.io/rev=asm-1233-2 memilih Pod dalam namespace dengan label istio.io/rev=asm-1233-2 dan memasukkan file bantuan.

Proses upgrade canary

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

Langkah-langkah berikut menjelaskan cara kerja proses tersebut:

1. Memulai dengan Cloud Service Mesh atau Istio open source yang sudah ada penginstalan. Tidak masalah apakah namespace menggunakan revisi label atau label istio-injection=enabled.
2. Gunakan string revisi saat Anda menginstal kontrol versi baru pesawat terbang. Karena string revisi, bidang kontrol baru diinstal bersama dengan versi yang sudah ada. Penginstalan baru menyertakan webhook baru dengan namespaceSelector yang dikonfigurasi untuk memantau namespace dengan label revisi khusus tersebut.
3. Anda memigrasikan proxy file bantuan ke bidang kontrol baru dengan menghapus proxy lama dari ruang nama, tambahkan label revisi baru, lalu memulai ulang Pod. Jika Anda menggunakan revisi dengan Cloud Service Mesh, Anda harus berhenti menggunakan label istio-injection=enabled. Sebuah bidang kontrol dengan revisi tidak memilih Pod dalam namespace dengan istio-injection label, meskipun ada label revisi. Webhook untuk kontrol baru pesawat menginjeksikan file bantuan ke dalam Pod.
4. Menguji dengan cermat workload yang terkait dengan bidang kontrol yang diupgrade dan akan terus meluncurkan upgrade atau melakukan roll back ke versi aslinya bidang kontrol.

Setelah mengaitkan Pod dengan bidang kontrol baru, bidang kontrol yang ada dan webhook masih terinstal. Webhook lama tidak berpengaruh untuk 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, menambahkan kembali label asli dan memulai ulang Pod. Jika Anda yakin bahwa upgrade telah selesai, Anda dapat menghapus kontrol lama pesawat terbang.

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

Pelajari lebih lanjut konfigurasi webhook yang bermutasi

Agar lebih memahami webhook bermutasi untuk injeksi file bantuan otomatis, memeriksa 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 Anda miliki terinstal. 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-1233-2

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

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

     service:
        name: istiod-asm-1233-2
        namespace: istio-system
        path: /inject
        port: 443

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

Layanan diekspos oleh bidang kontrol pada port 443 di 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