Cloud Service Mesh dan Traffic Director kini bergabung menjadi Cloud Service Mesh. Untuk mengetahui informasi selengkapnya, lihat ringkasan Cloud Service Mesh.

Halaman ini diterjemahkan oleh Cloud Translation API.

Revisi bidang kontrol Cloud Service Mesh

Halaman ini berlaku untuk ISTIOD dalam cluster dan terkelola implementasi bidang kontrol. Halaman ini tidak berlaku untuk penerapan bidang kontrol TRAFFIC_DIRECTOR, yang merupakan bidang kontrol global multi-tenant, tanpa revisi individual.

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

Dasar-dasar penginstalan mesh layanan

Secara umum, 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, sehingga Anda dapat mengarahkan dan mengontrol traffic (traffic bidang data) di sekitar mesh tanpa membuat perubahan apa pun pada workload.

Untuk men-deploy proxy, Anda menggunakan proses yang disebut injeksi sidecar otomatis (injeksi otomatis) untuk menjalankan proxy sebagai container sidecar tambahan di setiap Pod workload Anda. Anda tidak perlu mengubah manifes Kubernetes yang Anda gunakan 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-deploynya ke produksi. Jika mendeteksi masalah selama upgrade, Anda dapat mengalihkan traffic kembali ke versi asli, sehingga memberikan cara yang sederhana dan berisiko rendah untuk melakukan roll back. 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 bidang kontrol dan konfigurasi baru yang 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 bidang kontrol sebelumnya. Anda secara bertahap mengaitkan beban kerja dengan panel kontrol baru dengan memberi label pada namespace atau Pod-nya dengan revisi panel kontrol baru. Setelah memberi label pada namespace atau Pod dengan revisi baru, Anda memulai ulang Pod workload agar sidecar baru disuntikkan secara otomatis, dan menerima konfigurasinya dari bidang kontrol baru. Jika ada masalah, Anda dapat melakukan roll back dengan mudah dengan mengaitkan workload dengan panel kontrol asli.

Bagaimana cara kerja injeksi otomatis?

Penyisipan otomatis menggunakan fitur Kubernetes yang disebut kontrol penerimaan. Webhook penerimaan yang mengubah 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. Jika Pod cocok, webhook akan berkonsultasi dengan layanan injeksi yang disediakan oleh bidang kontrol untuk mendapatkan konfigurasi baru yang diubah untuk Pod, yang berisi container dan volume yang diperlukan untuk menjalankan sidecar.

sidecar injector

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

Apa yang dimaksud dengan revisi?

Label yang digunakan untuk injeksi otomatis sama seperti label Kubernetes yang ditentukan pengguna lainnya. Pada dasarnya, label 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 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-1253-11, dengan asm-1253-11 mengidentifikasi versi Cloud Service Mesh. Revisi menjadi bagian dari nama layanan, misalnya: istiod-asm-1253-11.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

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 penyuntikan otomatis, Anda menambahkan label revisi ke namespace yang cocok dengan label revisi pada bidang kontrol. Misalnya, bidang kontrol dengan revisi istio.io/rev=asm-1253-11 memilih Pod di namespace dengan label istio.io/rev=asm-1253-11 dan memasukkan file bantuan.

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 akan otomatis diupgrade ke versi terbaru dalam saluran tersebut.

upgrade canary

Langkah-langkah berikut menjelaskan cara kerja prosesnya:

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 bidang kontrol. Karena string revisi, bidang kontrol baru diinstal bersama versi yang ada. Penginstalan baru mencakup 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 Anda menggunakan revisi dengan Cloud Service Mesh, Anda harus berhenti menggunakan label istio-injection=enabled. Panel kontrol dengan revisi tidak memilih Pod di namespace dengan label istio-injection, meskipun ada label revisi. Webhook untuk bidang kontrol baru menyuntikkan sidecar ke dalam Pod.
Uji dengan cermat workload yang terkait dengan bidang kontrol yang diupgrade dan lanjutkan peluncuran upgrade atau kembalikan ke bidang kontrol asli.

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

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

Melihat lebih dekat konfigurasi webhook yang mengubah

Untuk lebih memahami webhook mutating untuk penyisipan sidecar 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 terlihat seperti ini:

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

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

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

     service:
        name: istiod-asm-1253-11
        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 pada pembuatan Pod:

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