Revisi bidang kontrol Cloud Service Mesh

Catatan: Panduan ini hanya mendukung Cloud Service Mesh dengan Istio API dan tidak mendukung Google Cloud API. Untuk informasi selengkapnya, lihat ringkasan Cloud Service Mesh.

Halaman ini berlaku untuk implementasi panel kontrol ISTIOD dalam cluster dan yang dikelola. 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

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

1. 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.

2. 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.

Catatan: Jenis upgrade alternatif adalah upgrade langsung yang Anda lakukan dengan menginstal versi baru panel kontrol. Versi platform kontrol baru akan segera menggantikan versi lama. Upgrade di tempat berisiko karena jika terjadi kegagalan, proses rollback dapat menjadi sulit. Untuk memasukkan ulang proxy dan membuatnya berkomunikasi dengan versi platform kontrol baru, Anda harus memulai ulang semua workload di semua namespace. Bergantung pada jumlah workload dan namespace di mesh Anda, seluruh proses upgrade dapat memerlukan waktu satu jam atau lebih. Upgrade di tempat dapat menyebabkan periode nonaktif dan harus dijadwalkan dalam masa pemeliharaan.

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.

1. Konfigurasi webhook dibuat selama penginstalan. Webhook terdaftar dengan server Kubernetes API.
2. Server Kubernetes API memantau deployment Pod di namespace yang cocok dengan namespaceSelector webhook.
3. Namespace diberi label agar cocok dengan namespaceSelector.
4. Pod yang di-deploy ke namespace akan memicu webhook.
5. 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 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, Anda menambahkan label revisi ke namespace yang cocok dengan label revisi di bidang kontrol. Misalnya, platform kontrol dengan revisi istio.io/rev=asm-1233-2 memilih Pod di namespace dengan label istio.io/rev=asm-1233-2 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:

1. Mulai dengan penginstalan Cloud Service Mesh atau Istio open source yang ada. Tidak masalah apakah namespace menggunakan label revisi atau label istio-injection=enabled.
2. 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.
3. 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 label istio-injection, meskipun ada label revisi. Webhook untuk bidang kontrol baru memasukkan sidecar ke dalam Pod.
4. 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-1233-2

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-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 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: '*'

Langkah selanjutnya

• Mengupgrade Cloud Service Mesh
• Memasukkan proxy sidecar