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.
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.
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.
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.Mulai peningkatan kenari dari revisi
asm-1-22
keasm-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.
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:
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
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
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.
Verifikasi pod sarana kontrol yang sesuai dengan dan
asm-1-22
asm-1-23
yang ada: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
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.
Labeli kembali namespace layanan sehingga setiap pod baru dipetakan ke sidecar Istio yang terkait dengan revisi baru dan sarana kontrolnya:
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.
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.
Secara individual menggulung setiap beban kerja aplikasi Anda dengan memulai ulang beban kerja tersebut. Contohnya:
kubectl rollout restart deployment <deployment name> -n <deployment namespace>
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:
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
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
Jika konfigurasi jala sebelumnya disiapkan untuk revisi, Anda sekarang dapat menghapus ConfigMap untuk revisi yang dihapus dari kluster selama selesai/putar kembali.
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.
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.
- 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
Umpan balik Azure Kubernetes Service
Azure Kubernetes Service adalah proyek sumber terbuka. Pilih tautan untuk memberikan umpan balik: