Rencanakan upgrade

Halaman ini memberikan informasi untuk membantu Anda merencanakan upgrade Cloud Service Mesh. Rab sebaiknya Anda juga meninjau Catatan upgrade Istio.

Tentang upgrade canary

Sebaiknya upgrade Cloud Service Mesh dengan menjalankan deployment canary terlebih dahulu bidang kontrol baru. Dengan upgrade canary, asmcli akan menginstal revisi kontrol bersama pesawat kontrol lama. Bidang kontrol lama dan baru diberi label dengan label revision, yang berfungsi sebagai ID untuk bidang kontrol.

Untuk memigrasikan workload ke bidang kontrol baru:

  1. Tetapkan label revision bidang kontrol baru di salah satu namespace Anda.

  2. Lakukan mulai ulang berkelanjutan. Mulai ulang memasukkan ulang proxy file bantuan di Pod sehingga proxy menggunakan bidang kontrol baru.

  3. Memantau efek upgrade pada workload. Jika diperlukan untuk menguji aplikasi, ulangi langkah sebelumnya.

  4. Setelah menguji aplikasi, Anda dapat memigrasikan semua traffic ke bidang kontrol atau rollback ke bidang kontrol lama.

Upgrade canary jauh lebih aman daripada melakukan upgrade langsung di mana bidang kontrol menggantikan bidang kontrol lama. Untuk langkah-langkah mendetailnya, lihat Beralih ke bidang kontrol baru.

Menyesuaikan bidang kontrol

Jika Anda menyesuaikan penginstalan sebelumnya, Anda memerlukan penyesuaian yang sama saat Anda mengupgrade Cloud Service Mesh. Jika Anda menyesuaikan penginstalan dengan menambahkan flag --set values ke istioctl install, Anda harus menambahkan setelan tersebut ke file YAML IstioOperator, yang disebut sebagai file overlay. Anda menentukan overlay dengan menggunakan opsi --custom_overlay dengan nama file saat Anda jalankan asmcli.

Tujuan Direktori asmcli di GitHub berisi banyak file overlay. File ini berisi penyesuaian umum ke konfigurasi default. Anda dapat menggunakan {i>file<i} ini sebagaimana adanya, atau Anda dapat membuat perubahan tambahan pada mereka sesuai kebutuhan. Beberapa file diperlukan untuk mengaktifkan fitur Cloud Service Mesh opsional. Paket anthos-service-mesh akan didownload saat Anda menjalankan asmcli ke validasikan project dan cluster Anda.

Saat menginstal Cloud Service Mesh menggunakan asmcli install, Anda dapat menentukan satu atau beberapa file overlay dengan --option atau --custom_overlay. Jika Anda tidak perlu melakukan perubahan apa pun pada file di anthos-service-mesh repositori, Anda dapat menggunakan --option, dan skrip mengambil file dari GitHub. keamanan untuk Anda. Jika tidak, Anda dapat membuat perubahan pada file overlay, lalu menggunakan --custom_overlay untuk meneruskannya ke asmcli.

Pilih certificate authority

Jika penginstalan Cloud Service Mesh Anda saat ini menggunakan Certificate authority Cloud Service Mesh sebagai certificate authority (CA) untuk menerbitkan TLS bersama (mTLS) sertifikat, sebaiknya Anda terus menggunakan certificate authority Cloud Service Mesh karena alasan berikut:

  • Otoritas sertifikat {i>Cloud Service Mesh<i} adalah layanan yang sangat andal dan skalabel dan dioptimalkan untuk workload yang diskalakan secara dinamis.
  • Dengan certificate authority Cloud Service Mesh, Google mengelola keamanan dan ketersediaan dari backend CA.
  • Dengan certificate authority Cloud Service Mesh, Anda dapat mengandalkan satu root kepercayaan di seluruh klaster.

Jika penginstalan Cloud Service Mesh Anda saat ini menggunakan Istio CA (sebelumnya disebut "Citadel"), Anda dapat beralih ke certificate authority Cloud Service Mesh saat Anda melakukan {i>upgrade<i}, tetapi Anda perlu menjadwalkan periode nonaktif. Selama proses upgrade, traffic mTLS terganggu sampai semua beban kerja dialihkan untuk menggunakan bidang kontrol baru dengan certificate authority Cloud Service Mesh.

Sertifikat dari certificate authority Cloud Service Mesh mencakup data berikut tentang layanan aplikasi Anda:

  • ID project Google Cloud
  • Namespace GKE
  • Nama akun layanan GKE

Mengidentifikasi CA Anda

Saat menjalankan asmcli install untuk melakukan upgrade, Anda menentukan CA yang asmcli yang harus diaktifkan pada bidang kontrol baru.

Mengubah CA menyebabkan periode nonaktif saat Anda men-deploy workload ke yang baru bidang kontrol. Jika Anda tidak dapat menjadwalkan periode nonaktif, pastikan untuk menentukan CA yang sama untuk bidang kontrol baru yang digunakan bidang kontrol lama. Jika Anda tidak yakin CA mana yang diaktifkan di mesh Anda, jalankan perintah berikut:

  1. Dapatkan daftar Pod dari salah satu namespace Anda:

    kubectl get pods -n NAMESPACE

  2. Ganti POD_NAME dengan nama salah satu Pod Anda di perintah berikut:

    kubectl get pod POD_NAME -n NAMESPACE -o yaml | grep CA_ADDR -A 1

    Jika certificate authority Cloud Service Mesh diaktifkan pada namespace, Anda akan melihat output berikut:

    - name: CA_ADDR
  value: meshca.googleapis.com:443

Menyiapkan konfigurasi gateway

Cloud Service Mesh memberi Anda opsi untuk men-deploy dan mengelola gateway sebagai bagian dari jaringan layanan. Gateway menjelaskan load balancer yang beroperasi di tepi yang menerima koneksi HTTP/TCP masuk atau keluar. Gateway adalah Envoy {i>proxy<i} yang memberi Anda kontrol mendetail atas lalu lintas yang masuk dan meninggalkan {i>mesh<i}.

asmcli tidak menginstal istio-ingressgateway. Sebaiknya Anda men-deploy dan mengelola gateway dan bidang kontrol secara terpisah. Untuk selengkapnya lihat Menginstal dan mengupgrade gateway.

Upgrade platform Anda (opsional)

Sebagai praktik terbaik, Anda harus mengupgrade Cloud Service Mesh ke versi terbaru versi yang didukung yang juga mendukung platform Anda saat ini. Kemudian, upgrade lingkungan Anda agar bahwa data itu berada dalam kisaran platform dan versi Kubernetes yang didukung. Terakhir, jika diperlukan, upgrade ke versi terbaru versi yang didukung Cloud Service Mesh.

Apa langkah selanjutnya?