Baca dalam bahasa Inggris

Bagikan melalui


Meningkatkan add-on mesh layanan berbasis Istio untuk Azure Kubernetes Service

Artikel ini membahas pengalaman peningkatan untuk add-on mesh layanan berbasis Istio untuk Azure Kubernetes Service (AKS).

Pengumuman tentang rilis revisi atau patch minor baru ke add-on jala layanan berbasis Istio diterbitkan dalam catatan rilis AKS. Untuk mempelajari selengkapnya tentang jadwal rilis dan dukungan untuk revisi add-on jala layanan, baca kebijakan dukungan.

Peningkatan revisi kecil

Add-on Istio memungkinkan peningkatan revisi kecil menggunakan proses peningkatan kenari. Ketika peningkatan dimulai, sarana kontrol revisi (kenari) baru disebarkan bersama sarana kontrol revisi awal (stabil). Anda kemudian dapat secara manual menggulirkan beban kerja sarana data saat menggunakan alat pemantauan untuk melacak kesehatan beban kerja selama proses ini. Jika Anda tidak mengamati masalah apa pun dengan kesehatan beban kerja, Anda dapat menyelesaikan peningkatan sehingga hanya revisi baru yang tersisa pada kluster. Jika tidak, Anda dapat kembali ke revisi Istio sebelumnya.

Jika kluster saat ini menggunakan revisi kecil Istio yang didukung, peningkatan hanya diizinkan satu revisi kecil pada satu waktu. Jika kluster menggunakan revisi Istio yang tidak didukung, Anda harus meningkatkan ke revisi minor Terendah yang didukung Istio untuk versi Kubernetes tersebut. Setelah itu, peningkatan dapat kembali dilakukan satu revisi kecil pada satu waktu.

Contoh berikut mengilustrasikan cara meningkatkan dari revisi asm-1-22 ke asm-1-23 dengan semua beban kerja di default namespace. Langkah-langkahnya sama untuk semua peningkatan kecil dan dapat digunakan untuk sejumlah namespace layanan.

  1. Gunakan perintah az aks mesh get-upgrades untuk memeriksa revisi mana yang tersedia untuk kluster sebagai target peningkatan:

    az aks mesh get-upgrades --resource-group $RESOURCE_GROUP --name $CLUSTER
    

    Jika Anda berharap untuk melihat revisi yang lebih baru yang tidak dikembalikan oleh perintah ini, Anda mungkin perlu meningkatkan kluster AKS Anda terlebih dahulu sehingga kompatibel dengan revisi terbaru.

  2. Jika Anda menyiapkan konfigurasi jala untuk revisi jala yang ada di kluster, Anda perlu membuat ConfigMap terpisah yang sesuai dengan revisi baru di aks-istio-system namespace sebelum memulai peningkatan kenari di langkah berikutnya. Konfigurasi ini berlaku saat sarana kontrol revisi baru disebarkan pada kluster. Rincian selengkapnya dapat ditemukan di sini.

  3. Mulai peningkatan kenari dari revisi asm-1-22 ke asm-1-23 menggunakan az aks mesh upgrade start:

    az aks mesh upgrade start --resource-group $RESOURCE_GROUP --name $CLUSTER --revision asm-1-23
    

    Peningkatan kenari berarti sarana kontrol 1.23 disebarkan bersama sarana kontrol 1.22. Mereka terus berdampingan sampai Anda menyelesaikan atau mengembalikan peningkatan.

  4. Secara opsional, tag revisi dapat digunakan untuk menggulirkan bidang data ke revisi baru tanpa perlu melabeli ulang setiap namespace secara manual. Melabeli namespace secara manual saat memindahkannya ke revisi baru dapat melelahkan dan rawan kesalahan. Tag revisi menyelesaikan masalah ini dengan berfungsi sebagai pengidentifikasi stabil yang menunjuk ke revisi.

    Daripada melabeli ulang setiap namespace layanan, operator kluster dapat mengubah tag untuk menunjuk ke revisi baru. Semua namespace yang diberi label dengan tag tersebut diperbarui secara bersamaan. Namun, Anda masih perlu menghidupkan ulang beban kerja untuk memastikan versi istio-proxy sidecar yang benar disuntikkan.

    Untuk menggunakan tag revisi selama peningkatan:

    1. Menginstal istioctl CLI

    2. Buat tag revisi untuk revisi awal. Dalam contoh ini, kami menamainya prod-stable:

      istioctl tag set prod-stable --revision asm-1-22 --istioNamespace aks-istio-system
      
    3. Buat tag revisi untuk revisi yang diinstal selama peningkatan. Dalam contoh ini, kami menamainya prod-canary:

      istioctl tag set prod-canary --revision asm-1-23 --istioNamespace aks-istio-system
      
    4. Beri label namespace aplikasi untuk dipetakan ke tag revisi:

      # label default namespace to map to asm-1-22
      kubectl label ns default istio.io/rev=prod-stable --overwrite
      

      Anda juga dapat memberi label namespace dengan istio.io/rev=prod-canary untuk revisi yang lebih baru. Namun, beban kerja di namespace layanan tersebut tidak diperbarui ke sidecar baru hingga dimulai ulang.

      Jika aplikasi baru dibuat di namespace setelah diberi label, sidecar akan disuntikkan sesuai dengan tag revisi pada namespace tersebut.

  5. Verifikasi pod sarana kontrol yang sesuai dengan dan asm-1-22 asm-1-23 yang ada:

    1. Verifikasi istiod pod:

      kubectl get pods -n aks-istio-system
      

      Contoh output:

      NAME                                        READY   STATUS    RESTARTS   AGE
      istiod-asm-1-22-55fccf84c8-dbzlt            1/1     Running   0          58m
      istiod-asm-1-22-55fccf84c8-fg8zh            1/1     Running   0          58m
      istiod-asm-1-23-f85f46bf5-7rwg4             1/1     Running   0          51m
      istiod-asm-1-23-f85f46bf5-8p9qx             1/1     Running   0          51m
      
    2. Jika ingress diaktifkan, verifikasi pod ingress:

      kubectl get pods -n aks-istio-ingress
      

      Contoh output:

      NAME                                                          READY   STATUS    RESTARTS   AGE
      aks-istio-ingressgateway-external-asm-1-22-58f889f99d-qkvq2   1/1     Running   0          59m
      aks-istio-ingressgateway-external-asm-1-22-58f889f99d-vhtd5   1/1     Running   0          58m
      aks-istio-ingressgateway-external-asm-1-23-7466f77bb9-ft9c8   1/1     Running   0          51m
      aks-istio-ingressgateway-external-asm-1-23-7466f77bb9-wcb6s   1/1     Running   0          51m
      aks-istio-ingressgateway-internal-asm-1-22-579c5d8d4b-4cc2l   1/1     Running   0          58m
      aks-istio-ingressgateway-internal-asm-1-22-579c5d8d4b-jjc7m   1/1     Running   0          59m
      aks-istio-ingressgateway-internal-asm-1-23-757d9b5545-g89s4   1/1     Running   0          51m
      aks-istio-ingressgateway-internal-asm-1-23-757d9b5545-krq9w   1/1     Running   0          51m
      

      Amati bahwa pod gateway ingress dari kedua revisi disebarkan secara berdampingan. Namun, layanan dan IP-nya tetap tidak dapat diubah.

  6. Labeli kembali namespace layanan sehingga setiap pod baru dipetakan ke sidecar Istio yang terkait dengan revisi baru dan sarana kontrolnya:

    1. Jika menggunakan tag revisi, timpa tag itu prod-stable sendiri untuk mengubah pemetaannya:

      istioctl tag set prod-stable --revision asm-1-23 --istioNamespace aks-istio-system --overwrite 
      

      Verifikasi pemetaan tag-ke-revisi:

      istioctl tag list
      

      Kedua tag harus menunjuk ke revisi yang baru diinstal:

      TAG           REVISION   NAMESPACES
      prod-canary   asm-1-23   default
      prod-stable   asm-1-23   ...
      

      Dalam hal ini, Anda tidak perlu melabeli ulang setiap namespace layanan satu per satu.

    2. Jika tidak menggunakan tag revisi, namespace data plane harus diberi label ulang untuk menunjuk ke revisi baru:

      kubectl label namespace default istio.io/rev=asm-1-23 --overwrite
      

    Pelabelan ulang tidak memengaruhi beban kerja Anda hingga dimulai ulang.

  7. Secara individual menggulung setiap beban kerja aplikasi Anda dengan memulai ulang beban kerja tersebut. Contohnya:

    kubectl rollout restart deployment <deployment name> -n <deployment namespace>
    
  8. Periksa alat pemantauan dan dasbor Anda untuk menentukan apakah semua beban kerja Anda berjalan dalam keadaan sehat setelah mulai ulang. Berdasarkan hasilnya, Anda memiliki dua opsi:

    1. Selesaikan peningkatan kenari: Jika Anda puas bahwa semua beban kerja berjalan dalam keadaan sehat seperti yang diharapkan, Anda dapat menyelesaikan peningkatan kenari. Penyelesaian peningkatan menghapus sarana kontrol revisi sebelumnya dan meninggalkan sarana kontrol revisi baru pada kluster. Jalankan perintah berikut untuk menyelesaikan peningkatan kenari:

      az aks mesh upgrade complete --resource-group $RESOURCE_GROUP --name $CLUSTER
      
    2. Gulung balik peningkatan kenari: Jika Anda mengamati masalah apa pun dengan kesehatan beban kerja Anda, Anda dapat kembali ke revisi Istio sebelumnya:

    • Labeli kembali namespace layanan ke revisi sebelumnya: Jika menggunakan tag revisi:

      istioctl tag set prod-stable --revision asm-1-22 --istioNamespace aks-istio-system --overwrite
      

      Atau, jika tidak menggunakan tag revisi:

      kubectl label namespace default istio.io/rev=asm-1-22 --overwrite
      
    • Gulung balik beban kerja untuk menggunakan sidecar yang sesuai dengan revisi Istio sebelumnya dengan memulai ulang beban kerja ini lagi:

      kubectl rollout restart deployment <deployment name> -n <deployment namespace>
      
    • Gulung balik sarana kontrol ke revisi sebelumnya:

      az aks mesh upgrade rollback --resource-group $RESOURCE_GROUP --name $CLUSTER
      

    Tag prod-canary revisi dapat dihapus:

    istioctl tag remove prod-canary --istioNamespace aks-istio-system 
    
  9. Jika konfigurasi jala sebelumnya disiapkan untuk revisi, Anda sekarang dapat menghapus ConfigMap untuk revisi yang dihapus dari kluster selama selesai/putar kembali.

Peningkatan revisi kecil dengan gateway ingress

Jika saat ini Anda menggunakan gateway masuk Istio dan melakukan peningkatan revisi kecil, perlu diingat bahwa pod/penyebaran gateway masuk Istio disebarkan per revisi. Namun, kami menyediakan satu layanan LoadBalancer di semua pod gateway masuk melalui beberapa revisi, sehingga alamat IP eksternal/internal gateway ingress tetap tidak berubah selama peningkatan.

Dengan demikian, selama peningkatan kenari, ketika dua revisi ada secara bersamaan pada kluster, pod gateway masuk dari kedua revisi melayani lalu lintas masuk.

Peningkatan revisi kecil dengan kustomisasi penskalaan otomatis pod horizontal

Jika Anda telah menyesuaikan pengaturan penskalaan otomatis pod horizontal (HPA) untuk Istiod atau gateway ingress, perhatikan perilaku berikut tentang bagaimana pengaturan HPA diterapkan di kedua revisi untuk mempertahankan konsistensi selama peningkatan kenari:

  • Jika Anda memperbarui spesifikasi HPA sebelum memulai peningkatan, pengaturan dari revisi (stabil) yang ada akan diterapkan ke HPAs revisi kenari saat sarana kontrol baru diinstal.
  • Jika Anda memperbarui spesifikasi HPA saat peningkatan kenari sedang berlangsung, spesifikasi HPA dari revisi stabil akan diutamakan dan diterapkan pada HPA revisi kenari.
    • Jika Anda memperbarui HPA revisi stabil selama peningkatan, spesifikasi HPA dari revisi kenari akan diperbarui untuk mencerminkan pengaturan baru yang diterapkan pada revisi stabil.
    • Jika Anda memperbarui HPA revisi kenari selama peningkatan, spesifikasi HPA dari revisi kenari akan dikembalikan ke spesifikasi HPA dari revisi stabil.

Peningkatan versi patch

  • Informasi ketersediaan versi patch add-on Istio diterbitkan dalam catatan rilis AKS.
  • Patch diluncurkan secara otomatis untuk pod istiod dan ingress sebagai bagian dari rilis AKS ini, yang menghormati default jendela pemeliharaan terencana yang disiapkan untuk kluster.
  • Pengguna perlu memulai patch ke proksi Istio dalam beban kerja mereka dengan memulai ulang pod untuk diinjeksi ulang:
    • Periksa versi proksi Istio yang ditujukan untuk pod baru atau yang dimulai ulang. Versi ini sama dengan versi pod istiod dan istio ingress setelah di-patch:

      kubectl get cm -n aks-istio-system -o yaml | grep "mcr.microsoft.com\/oss\/istio\/proxyv2"
      

      Contoh output:

      "image": "mcr.microsoft.com/oss/istio/proxyv2:1.22.0-distroless",
      "image": "mcr.microsoft.com/oss/istio/proxyv2:1.22.0-distroless"
      
    • Periksa versi gambar proksi Istio untuk semua pod di namespace:

      kubectl get pods --all-namespaces -o jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{range .spec.containers[*]}{.image}{", "}{end}{end}' |\
      sort |\
      grep "mcr.microsoft.com\/oss\/istio\/proxyv2"
      

      Contoh output:

      productpage-v1-979d4d9fc-p4764:	docker.io/istio/examples-bookinfo-productpage-v1:1.22.0, mcr.microsoft.com/oss/istio/proxyv2:1.22.0-distroless
      
    • Untuk memicu reinjeksi, mulai ulang beban kerja. Contohnya:

      kubectl rollout restart deployments/productpage-v1 -n default
      
    • Untuk memverifikasi bahwa mereka sekarang berada di versi yang lebih baru, periksa lagi versi gambar proksi Istio untuk semua pod di namespace:

      kubectl get pods --all-namespaces -o jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{range .spec.containers[*]}{.image}{", "}{end}{end}' |\
      sort |\
      grep "mcr.microsoft.com\/oss\/istio\/proxyv2"
      

      Contoh output:

      productpage-v1-979d4d9fc-p4764:	docker.io/istio/examples-bookinfo-productpage-v1:1.2.0, mcr.microsoft.com/oss/istio/proxyv2:1.22.0-distroless
      

Catatan

Jika ada masalah yang dihadapi selama peningkatan, lihat artikel tentang pemecahan masalah peningkatan revisi jala