Topik ini menjelaskan cara menggunakan alat migrasi berbasis UI yang disediakan oleh Microservices Engine (MSE) untuk memigrasikan trafik dari gateway NGINX Ingress yang dikelola sendiri ke gateway MSE Ingress.
Prasyarat
Sebuah klaster Container Service for Kubernetes (ACK), klaster ACK Serverless, atau klaster ACS telah dibuat, dan NGINX Ingress Controller telah diterapkan di dalam klaster.
Sebuah gateway cloud-native telah dibuat. Jika Anda tidak memiliki gateway cloud-native, buat gateway cloud-native.
Catatan penggunaan
Dalam topik ini, sebuah gateway MSE Ingress menggunakan kembali konfigurasi Ingress selama proses migrasi. Konfigurasi Ingress tidak disalin. Gateway tersebut mendengarkan perubahan konfigurasi Ingress yang ada secara real-time dan menguraikan konfigurasi yang didengar.
Selama proses migrasi, baik NGINX Ingress Controller maupun gateway MSE Ingress dapat merasakan perubahan pada konfigurasi Ingress.
Setelah migrasi selesai, jangan hapus konfigurasi NGINX Ingress online yang sedang digunakan. Tujuan dari migrasi adalah untuk memungkinkan gateway MSE Ingress mendengarkan dan menguraikan konfigurasi Ingress yang ada dan baru.
Setelah migrasi selesai, konfigurasi Ingress yang ada dan baru tetap harus dikaitkan dengan kelas Ingress dari gateway NGINX Ingress. Sebagai contoh, jika nilai ingressClassName dalam spec untuk gateway NGINX Ingress adalah nginx, pengaturan ini tetap tidak berubah untuk konfigurasi Ingress yang ada dan baru setelah migrasi.
Metode dan prinsip migrasi
Tampilkan Detail
Apa itu gateway MSE Ingress?
Gateway MSE Ingress menyediakan metode yang kuat untuk mengelola trafik masuk berdasarkan gateway cloud-native MSE. Gateway trafik, gateway mikroservices, dan gerbang keamanan terintegrasi ke dalam gateway MSE Ingress. Gateway MSE Ingress kompatibel dengan standar API Kubernetes Ingress. Gateway MSE Ingress menyelesaikan masalah yang disebabkan oleh desain independen dan operasi & pemeliharaan arsitektur gateway tiga lapis. Masalah-masalah tersebut meliputi penggunaan sumber daya tinggi, kerugian performa besar, stabilitas rendah, dan perlindungan keamanan yang kompleks.
Manfaat gateway MSE Ingress
Dibandingkan dengan gateway tradisional, gateway MSE Ingress memberikan manfaat berikut dalam hal biaya sumber daya, performa, perlindungan keamanan, dan kemudahan penggunaan:
Kepatuhan terhadap Standar: Gateway MSE Ingress sepenuhnya mengikuti standar API Kubernetes Ingress. Versi
networking.k8s.io/v1beta1dannetworking.k8s.io/v1didukung.Kompatibilitas Tinggi: Gateway MSE Ingress cocok untuk lebih dari 90% skenario di mana anotasi NGINX Ingress digunakan. Konfigurasi NGINX Ingress dapat langsung berlaku pada gateway MSE Ingress tanpa modifikasi. Untuk informasi lebih lanjut tentang anotasi yang didukung oleh gateway MSE Ingress, lihat Anotasi yang Didukung oleh Gateway MSE Ingress.
Ekstensi Anotasi: Selain anotasi yang didefinisikan di gateway NGINX Ingress, gateway MSE Ingress menyediakan anotasi eksklusif yang terkait dengan fitur seperti otentikasi, kontrol header, throttling, dan perlindungan keamanan. Untuk informasi lebih lanjut tentang anotasi eksklusif yang didukung oleh gateway MSE Ingress, lihat Penggunaan Lanjutan MSE Ingress.
Arsitektur Aman: Bidang data dipisahkan dari bidang kontrol untuk mengisolasi sumber daya dan meningkatkan keamanan desain arsitektur.
Performa Tinggi: Dukungan akselerasi perangkat keras HTTPS dan peningkatan performa permintaan per detik (QPS).
Informasi latar belakang
Masalah-masalah berikut mungkin terjadi saat Anda menggunakan gateway NGINX Ingress:
Kerentanan Keamanan Utama: CVE-2021-25745, CVE-2021-25746, dan CVE-2021-25748.
Gateway MSE Ingress erat terkait dengan versi API Ingress dan versi klaster Kubernetes. Hal ini mempengaruhi proses peningkatan klaster Kubernetes. Di klaster ACK terkelola yang menjalankan Kubernetes V1.24, klaster ACK Serverless yang menjalankan Kubernetes V1.24, dan klaster ACS yang menjalankan Kubernetes V1.26, sumber daya Ingress dengan versi API networking.k8s.io/v1beta1 tidak lagi digunakan. Sumber daya Ingress dengan versi API networking.k8s.io/v1 didukung di NGINX Ingress Controller V1.0.0 dan yang lebih baru. Untuk meningkatkan klaster-klaster tersebut, Anda harus meningkatkan NGINX Ingress Controller.
Proses peningkatan NGINX Ingress Controller rumit dan kehilangan trafik mungkin terjadi selama proses peningkatan.
Sekumpulan tambahan NGINX Ingress Controller versi baru harus diterapkan.
Parameter template harus dimodifikasi secara manual untuk meningkatkan versi aplikasi.
Hanya resolusi DNS yang didukung saat Anda memigrasikan trafik dari gateway lama ke gateway baru. Ketepatan waktu buruk dan rollback tidak diizinkan ketika masalah terjadi.
Setelah Anda memigrasikan trafik dari gateway NGINX Ingress ke gateway MSE Ingress, Anda dapat melepaskan ketergantungan gateway Ingress dari versi API Ingress dan versi klaster Kubernetes. Dengan cara ini, tidak ada persyaratan versi yang diberlakukan pada NGINX Ingress Controller selama peningkatan klaster ACK. Gateway MSE Ingress menyediakan alat untuk skenario migrasi. Anda dapat menggunakan kembali instance Server Load Balancer (SLB) untuk melakukan switching trafik tingkat halus. Ini meningkatkan ketepatan waktu dan stabilitas migrasi.
Metode migrasi
Gateway MSE Ingress menyediakan metode migrasi berikut:
Gunakan Kembali Instance SLB
Prinsip: Gateway MSE Ingress menggunakan kembali instance SLB yang terkait dengan layanan NGINX Ingress Controller di klaster ACK terkelola, klaster ACK Serverless, atau klaster ACS. Node gateway MSE Ingress secara otomatis ditambahkan ke grup vServer yang memiliki listener dan instance SLB asli. Trafik dimigrasikan berdasarkan bobot trafik yang dikonfigurasi.
Gateway MSE Ingress menggunakan kembali instance SLB yang ada berdasarkan proses penanganan trafik asli dan secara otomatis menyinkronkan aturan asli gateway NGINX Ingress. Jika verifikasi berhasil, trafik secara bertahap dialihkan ke gateway MSE Ingress. Instance SLB asli untuk trafik masuk tetap tidak berubah selama seluruh proses migrasi. Anda tidak perlu mengubah server DNS untuk switching trafik.
Gunakan Resolusi DNS
Prinsip: Hasil resolusi instance SLB yang terkait dengan gateway MSE Ingress ditambahkan untuk nama domain layanan yang terkait dengan semua gateway NGINX Ingress di server DNS. Beberapa penyedia layanan DNS menyediakan nilai bobot untuk mengontrol persentase trafik instance SLB yang terkait dengan gateway NGINX Ingress dan instance SLB yang terkait dengan gateway MSE Ingress.
Perbandingan metode
Metode migrasi | Ketepatan waktu | Tingkat switching trafik | Switching berbasis bobot | Kompleksitas operasi |
Gunakan kembali instance SLB | Cepat | Tingkat SLB | Didukung | Mudah |
Gunakan resolusi DNS | Lambat | Tingkat nama domain | Bergantung pada penyedia layanan DNS | Proporsional dengan jumlah nama domain |
Ikhtisar solusi migrasi
MSE menyediakan alat migrasi bagi Anda untuk memigrasikan konfigurasi rute dan trafik sesuai petunjuk.
Langkah 1: Migrasikan aturan routing
Masuk ke Konsol MSE. Di bilah navigasi atas, pilih wilayah.
Di panel navigasi kiri, pilih Cloud-native Gateway > Migration to Cloud.
Di halaman Migration to Cloud, klik Add Task.
Di panel Create Migration Configuration, konfigurasikan parameter-parameter.
Gateway cloud-native MSE secara otomatis mendengarkan perubahan semua sumber daya Ingress yang terkait dengan kelas Ingress sumber di klaster, dan membuat konfigurasi nama domain dan rute sumber daya Ingress berlaku.
PentingJika gateway cloud-native tujuan terkait dengan klaster dan kelas Ingress yang ada di klaster tidak sama dengan kelas Ingress yang dikonfigurasikan di langkah ini, migrasi tidak diizinkan. Anda harus memastikan bahwa kelas Ingress yang dikonfigurasikan di langkah ini sama dengan kelas Ingress yang dikonfigurasikan untuk klaster terkait.
Parameter
Deskripsi
Cloud-native Gateway
Gateway cloud-native MSE ke mana Anda ingin memigrasikan aturan routing. Versi gateway cloud-native MSE harus V1.2.22 atau yang lebih baru.
ACK/ASK/ACS Cluster
Klaster tempat gateway NGINX Ingress berada. Anda harus memastikan bahwa gateway cloud-native MSE dan klaster berada di virtual private cloud (VPC) yang sama.
Source Ingress Class
Kelas Ingress yang terkait dengan sumber daya Ingress yang akan dimigrasikan.
CatatanHanya satu kelas Ingress yang didukung.
Jika Anda tidak menentukan parameter ini, gateway cloud-native MSE mendengarkan semua sumber daya Ingress di klaster.
Klik Next.
Gateway cloud-native MSE secara otomatis mendengarkan perubahan semua sumber daya Ingress yang terkait dengan kelas Ingress sumber di klaster, dan membuat konfigurasi nama domain dan rute sumber daya Ingress berlaku.
Terapkan Ingress bernama httpbin di klaster.
Di konsol MSE, periksa bahwa Ingress klaster disinkronkan secara otomatis ke gateway cloud-native MSE, dan nama domain serta rute Ingress dihasilkan.
Langkah 2: Periksa rute
Periksa kompatibilitas sumber daya Ingress yang didengarkan oleh gateway cloud-native.
Jika semua anotasi Ingress kompatibel dengan gateway cloud-native, lanjutkan ke langkah berikutnya.
Jika ada anotasi Ingress yang tidak kompatibel dengan gateway cloud-native, klik tautan untuk mengirim tiket.
PentingAnotasi
nginx.ingress.kubernetes.io/service-weightdengan nilai tanda kutip ganda ("") dapat diabaikan. Anotasi ini ditambahkan secara default di konsol ACK lama dan tidak memiliki arti.Selama migrasi, jangan hapus anotasi yang tidak kompatibel yang sedang digunakan. Anotasi yang tidak kompatibel ini masih diuraikan oleh NGINX Ingress Controller dan berlaku untuk trafik bisnis Anda. Anda dapat menambahkan anotasi ekstensi MSE ke konfigurasi sumber daya Ingress untuk mengimplementasikan fitur yang sama di gateway MSE Ingress. Setelah semua trafik dimigrasikan ke gateway MSE Ingress, Anda dapat menghapus anotasi yang tidak kompatibel berdasarkan kebutuhan bisnis Anda.
Langkah 3: Pilih metode switching trafik
Uji distribusi trafik sebelum switching trafik
Kami merekomendasikan agar Anda melakukan uji lokal dengan melakukan operasi berikut sebelum Anda beralih trafik: Modifikasi file hosts lokal, tambahkan pemetaan alamat IP instance Server Load Balancer (SLB) yang terkait dengan gateway cloud-native untuk layanan DNS, dan gunakan alat seperti curl atau Postman untuk memeriksa apakah distribusi trafik sesuai harapan.
Pilih metode switching trafik
Gunakan Kembali SLB Klaster Asli
Dalam metode ini, Anda perlu menambahkan gateway cloud-native MSE ke grup backend vServer instance SLB yang terkait dengan gateway NGINX Ingress. Selama migrasi, instance SLB mendistribusikan trafik bisnis ke gateway cloud-native MSE berdasarkan bobot yang dikonfigurasi. Setelah migrasi selesai, semua trafik bisnis di instance SLB dialihkan ke gateway cloud-native MSE.
Tabel berikut menjelaskan parameter saat metode ini dipilih.
Parameter | Deskripsi |
ACK Cluster Namespace | Namespace layanan Kubernetes yang sesuai dengan instance SLB yang terkait dengan gateway NGINX Ingress. |
ACK Cluster SLB Service | Nama layanan Kubernetes yang sesuai dengan instance SLB yang terkait dengan gateway NGINX Ingress. |
SLB ID | ID instance SLB tempat trafik yang ingin Anda alihkan. |
Ports and Backend Servers | Port listener instance SLB di klaster dan protokol gateway (HTTP atau HTTPS). Setelah Anda memilih port dan protokol, grup vServer secara otomatis ditampilkan. Catatan Pastikan bahwa port dan protokol yang Anda pilih valid. Jika tidak, kehilangan trafik mungkin terjadi. |
Resolusi DNS ke SLB
Untuk layanan DNS yang disediakan oleh vendor DNS, tambahkan pemetaan antara semua nama domain yang terlibat dalam migrasi rute dan alamat IP instance SLB yang terkait dengan gateway cloud-native. Kami merekomendasikan agar Anda menggunakan catatan DNS untuk secara bertahap beralih trafik berdasarkan nilai bobot yang dikonfigurasi.
Langkah 4: Alihkan trafik
Gunakan Kembali SLB Klaster Asli
Langkah 1: Klik Ubah SLB
Setelah Anda mengklik Ubah SLB, instance SLB tidak lagi dikelola oleh klaster dan algoritma penjadwalan listener berubah menjadi round-robin berbobot.
Setelah perubahan, instance SLB tidak dapat mendeteksi perubahan alamat IP pod NGINX Ingress Controller. Lengkapi langkah berikutnya secepat mungkin untuk mengasosiasikan ulang layanan Kubernetes dengan instance SLB.
Langkah 2: Timpa anotasi layanan
Setelah Langkah 1 selesai, masuk ke Konsol ACK untuk secara manual menghapus semua anotasi layanan Kubernetes yang Anda tentukan saat memilih Gunakan Kembali SLB Klaster Asli, dan salin anotasi yang dihasilkan secara otomatis di tab Switch Traffic ke anotasi layanan Kubernetes. Langkah ini memungkinkan layanan Kubernetes menggunakan kembali instance SLB. Setelah operasi selesai, klik Pre-check. Setelah pemeriksaan berhasil, lanjutkan ke langkah berikutnya.
Jika pod aplikasi di klaster yang sama mengakses gateway NGINX Ingress, tambahkan anotasi service.beta.kubernetes.io/alibaba-cloud-loadbalancer-hostname: mse-ingress-migration ke layanan Kubernetes. Sebelum menambahkan anotasi, pastikan bahwa kontrol akses berbasis alamat IP tidak diaktifkan untuk instance SLB yang sesuai dengan layanan Kubernetes. Anotasi ini secara paksa mengaktifkan pod aplikasi untuk mengakses gateway NGINX Ingress melalui instance SLB. Setelah anotasi ditambahkan, bypass SLB berbasis kube-proxy tidak digunakan.
Langkah 3: Alihkan trafik berdasarkan bobot yang dikonfigurasi
Tentukan bobot berdasarkan mana trafik dialihkan ke gateway cloud-native MSE. Anda dapat mengatur bobot ke nilai mulai dari 1 hingga 100 berdasarkan kebutuhan bisnis Anda. Kami merekomendasikan agar Anda mengatur bobot ke nilai mulai dari 1 hingga 10 untuk pertama kali.
Nilai tersebut adalah jumlah total bobot semua node di gateway cloud-native MSE. Instance SLB mendistribusikan trafik berdasarkan bobot setiap node di gateway cloud-native MSE dan bobot setiap node di gateway NGINX Ingress di grup vServer. Total bobot default semua node di gateway NGINX Ingress adalah 100. Jika Anda mengatur bobot gateway cloud-native menjadi 100, setengah dari trafik diarahkan ke gateway cloud-native. Dengan cara yang sama, jika Anda mengatur bobot gateway cloud-native menjadi 50, 1/3 dari trafik diarahkan ke gateway cloud-native.
Selama migrasi, Anda dapat melihat metrik gateway cloud-native di dasbor di konsol MSE. Anda dapat memantau status kesehatan gateway cloud-native dan memeriksa apakah metrik bisnis sesuai harapan.
Jika metrik bisnis sesuai harapan, Anda dapat secara bertahap meningkatkan bobot gateway cloud-native. Konfigurasi bobot berlaku secara asinkron di latar belakang. Oleh karena itu, ubah bobot dengan interval lebih dari 3 menit.
Jika metrik bisnis tidak sesuai harapan, atur bobot menjadi 0 untuk menghentikan migrasi.
Untuk meningkatkan bobot gateway cloud-native, Anda juga dapat menurunkan nilai anotasi
service.beta.kubernetes.io/alibaba-cloud-loadbalancer-weightuntuk layanan Kubernetes yang Anda tentukan saat memilih Gunakan Kembali SLB Klaster Asli. Jika Anda mengatur anotasi menjadi 0, semua trafik di instance SLB diarahkan ke gateway cloud-native.SLB berfungsi sebagai load balancer Layer-4 yang menggunakan throttling tingkat koneksi. Bobot tidak dapat secara akurat mengontrol proporsi distribusi permintaan.
Jika tingkat keberhasilan menurun setelah switching trafik, Anda dapat mengatur bobot menjadi 0 untuk melakukan rollback trafik cepat.
Jika Anda ingin mempertahankan status migrasi dan dapat menyesuaikan bobot gateway NGINX Ingress dan gateway MSE Ingress kapan saja, kami merekomendasikan agar Anda tetap berada di langkah ini untuk jangka waktu panjang. Setelah Anda memverifikasi bahwa trafik sesuai harapan dan rollback trafik tidak diperlukan, klik Complete Traffic Verification untuk melanjutkan ke langkah berikutnya.
Setelah Anda mengklik Selesaikan Verifikasi Trafik, Anda tidak dapat memodifikasi bobot.
Langkah 4: Alihkan semua trafik ke gateway cloud-native
Di konsol ACK, atur nilai anotasi service.beta.kubernetes.io/alibaba-cloud-loadbalancer-weight untuk layanan Kubernetes yang Anda tentukan di Langkah 3: Pilih Metode Switching Trafik menjadi 0. Anda juga dapat langsung menghapus sumber daya layanan Kubernetes. NGINX Ingress Controller secara otomatis dihapus dari instance SLB. Semua trafik di instance SLB dialihkan ke gateway cloud-native. Klik Complete Migration untuk menyelesaikan tugas migrasi.
Resolusi DNS ke SLB
Untuk layanan DNS yang disediakan oleh vendor DNS, tambahkan pemetaan antara semua nama domain yang terlibat dalam migrasi rute dan alamat IP instance SLB yang terkait dengan gateway cloud-native. Kami merekomendasikan agar Anda menggunakan catatan DNS untuk secara bertahap beralih trafik berdasarkan nilai bobot yang dikonfigurasi.
Lakukan rollback
Jika distribusi trafik tidak sesuai harapan, Anda dapat menggunakan salah satu metode berikut untuk segera mengembalikan trafik ke NGINX Ingress Controller.
Gunakan Kembali SLB Klaster Asli: Atur bobot menjadi 0 untuk menghentikan migrasi.
Resolusi DNS ke SLB: Untuk layanan DNS yang disediakan oleh vendor DNS, hapus pemetaan antara nama domain bisnis dan alamat IP instance SLB yang terkait dengan gateway cloud-native MSE.
Langkah 5: Selesaikan migrasi
Gunakan Kembali SLB Klaster Asli
Jika Anda memilih metode ini, pastikan bahwa semua trafik di instance SLB didistribusikan ke gateway cloud-native MSE. Kemudian, Anda dapat menghapus layanan Kubernetes dan NGINX Ingress Controller berdasarkan kebutuhan bisnis Anda.
Resolusi DNS ke SLB
Jika Anda memilih metode ini, pastikan bahwa semua nama domain diuraikan sebagai alamat IP instance SLB yang terkait dengan gateway cloud-native MSE. Kemudian, Anda dapat menghapus layanan Kubernetes dan NGINX Ingress Controller berdasarkan kebutuhan bisnis Anda.
FAQ
Apa yang harus saya lakukan jika pesan kesalahan mse.backend.gw.MIGRATE_INGRESS_CLASS_CONFLICT dilaporkan?
Gateway cloud-native MSE terkait dengan klaster, dan pemantauan Ingress diaktifkan. Namun, kelas Ingress gateway cloud-native MSE berbeda dari kelas Ingress sumber. Akibatnya, pesan kesalahan ini dikembalikan.
Untuk memodifikasi kelas Ingress, lakukan operasi berikut:
Jika Anda menggunakan sumber daya MseIngressConfig untuk mengelola Ingress MSE, ikuti petunjuk di Gunakan Gateway MSE Ingress untuk Mengakses Layanan di Klaster ACK dan Klaster ACS.
Jika Anda tidak menggunakan sumber daya MseIngressConfig untuk mengelola Ingress MSE, modifikasi pengaturan pemantauan Ingress klaster di konsol MSE.
Apa yang harus saya lakukan jika pesan kesalahan mse.backend.gw.MIGRATE_SERVICE_ANNOTATION_NOT_MATCH [annotation is not expected] dilaporkan?
Masalah ini terjadi karena anotasi layanan Kubernetes tidak sesuai harapan.
Apa yang harus saya lakukan jika pesan kesalahan mse.backend.gw.MIGRATE_SERVICE_NOT_MATCH [weight hasn't be 0 or service hasn't been deleted] dilaporkan?
Masalah ini terjadi karena anotasi service.beta.kubernetes.io/alibaba-cloud-loadbalancer-weight untuk layanan Kubernetes belum diatur ke 0, atau layanan Kubernetes belum dihapus. Dalam hal ini, ubah nilai anotasi service.beta.kubernetes.io/alibaba-cloud-loadbalancer-weight untuk layanan Kubernetes menjadi 0 di konsol ACK, atau hapus layanan Kubernetes.