All Products
Search
Document Center

API Gateway:Migrasi NGINX Ingress yang Dikelola Sendiri ke API Gateway Cloud-native

Last Updated:May 07, 2026

Seiring pensiunnya NGINX Ingress, pengguna perlu bermigrasi ke solusi gerbang baru. Cloud-native API Gateway adalah produk gerbang terpadu yang mengintegrasikan fitur manajemen traffic, layanan mikro, dan keamanan, serta menyediakan jalur migrasi lancar dan peningkatan kemampuan bagi pengguna NGINX Ingress. Topik ini menjelaskan cara menggunakan tool migrasi berbasis UI untuk bermigrasi dari NGINX Ingress yang dikelola sendiri ke Cloud-native API Gateway.

Prasyarat

  • Anda telah men-deploy NGINX Ingress Controller di kluster Container Service for Kubernetes (ACK).

  • Anda telah membuat instans Cloud-native API Gateway. Jika belum, lihat Create a gateway instance.

Catatan penggunaan

  • Proses migrasi ini tidak menyalin konfigurasi Ingress Anda. Sebaliknya, Cloud-native API Gateway menggunakan kembali resource Ingress yang ada dengan mengurai perubahannya secara real time.

  • Selama migrasi, setiap perubahan pada konfigurasi Ingress akan tercermin baik di NGINX Ingress Controller maupun di Cloud-native API Gateway.

  • Setelah migrasi selesai, jangan menghapus konfigurasi Ingress produksi Anda. Migrasi hanya mengaktifkan Cloud-native API Gateway untuk mengurai konfigurasi Ingress yang ada maupun yang akan datang.

  • Setelah migrasi, konfigurasi Ingress yang ada dan yang akan datang harus tetap dikaitkan dengan IngressClass yang dikonfigurasi oleh Cloud-native API Gateway untuk dipantau. Misalnya, jika nilai ingressClassName dalam spesifikasi Ingress adalah nginx/higress/apig, nilai tersebut harus tetap nginx/higress/apig untuk semua konfigurasi Ingress—baik yang sudah ada maupun yang baru—setelah migrasi.

Prosedur migrasi

Tool Migrate to Cloud di Cloud-native API Gateway memandu Anda melalui proses migrasi konfigurasi rute dan melakukan alih trafik akhir.

Catatan

Untuk membantu developer mempercepat proses migrasi, kami menyediakan AI Skill resmi untuk migrasi dari NGINX Ingress ke Cloud-native API Gateway: alibabacloud-nginx-ingress-to-api-gateway. Anda dapat menggunakan Skill ini untuk melakukan pre-check batch terhadap kompatibilitas Ingress. Untuk anotasi NGINX Ingress yang tidak kompatibel, Skill ini secara otomatis menghasilkan plugin Wasm pengganti dan konfigurasi rute Ingress baru guna mencapai efek routing yang setara, serta membuat runbook lengkap.

Langkah 1: Migrasi aturan routing

  1. Login ke API Gateway console.

  2. Di panel navigasi kiri, pilih Cloud Migration.

  3. Pada halaman Cloud Migration, klik Create a task.

  4. Pada panel Create Migration Configuration, konfigurasikan parameter-parameter berikut.

    Cloud-native API Gateway secara otomatis memantau semua resource Ingress di kluster kontainer yang dipilih yang dikaitkan dengan source IngressClass. Selanjutnya, produk ini menerapkan konfigurasi nama domain dan rute dari resource Ingress tersebut.

    Penting

    Jika Cloud-native API Gateway tujuan sudah dikaitkan dengan kluster kontainer ini, tetapi IngressClass yang dikonfigurasikannya berbeda dari yang Anda tentukan di sini, migrasi akan gagal. Pastikan IngressClass yang Anda konfigurasikan di sini sesuai dengan yang telah dikonfigurasi untuk kluster terkait.

    Parameter

    Deskripsi

    Instance

    Tentukan instans gerbang tujuan untuk migrasi.

    Source Cluster

    Pilih kluster kontainer yang menjalankan NGINX Ingress yang ingin Anda migrasikan. Pastikan Cloud-native API Gateway dan kluster kontainer berada dalam Virtual Private Cloud (VPC) yang sama.

    API Name

    Nama HTTP API di Cloud-native API Gateway yang akan menerima rute NGINX Ingress yang diimpor.

    resource

    Pilih kelompok resource tujuan untuk migrasi.

    Namespace

    Tentukan namespace dari resource Ingress yang ingin Anda migrasikan.

    IngressClass

    Tentukan IngressClass yang dikaitkan dengan resource Ingress yang sedang Anda migrasikan.

    Catatan
    • Hanya satu IngressClass yang dapat ditentukan.

    • Jika Anda mengosongkan parameter ini, gerbang akan mengabaikan IngressClass dan memantau semua resource Ingress di kluster.

  5. Klik Next.

    Pada tahap ini, Cloud-native API Gateway mulai secara otomatis memantau semua resource Ingress di kluster kontainer yang dipilih yang dikaitkan dengan source IngressClass. Konfigurasi nama domain dan rute dari resource Ingress tersebut diterapkan ke API yang baru dibuat.

    1. Misalnya, asumsikan Anda memiliki resource Ingress bernama nginx-route di kluster kontainer sumber Anda.

    2. Di Konsol Cloud-native API Gateway, Anda dapat melihat bahwa gerbang telah secara otomatis menyinkronkan Ingress dari kluster sumber dan membuat konfigurasi nama domain serta rute yang sesuai.

Langkah 2: Validasi rute

Validasi kompatibilitas resource Ingress yang ditemukan:

  • Jika tidak ditemukan anotasi Ingress yang tidak kompatibel, lanjutkan ke langkah berikutnya.

  • Jika terdapat anotasi Ingress yang tidak kompatibel, Anda dapat terlebih dahulu menggunakan tool AI seperti HiClaw, CoPaw, atau QoderWork dengan Skill migrasi resmi alibabacloud-nginx-ingress-to-api-gateway. Skill ini menganalisis konfigurasi Ingress Anda, secara otomatis menghasilkan plugin Wasm untuk menggantikan anotasi yang tidak kompatibel, dan membuat runbook lengkap. Jika Anda masih memiliki pertanyaan, Anda dapat submit a ticket untuk mendapatkan solusi.

    Penting
    • Anda dapat mengabaikan anotasi nginx.ingress.kubernetes.io/service-weight jika nilainya berupa string kosong (""). Anotasi ini ditambahkan secara default di versi lama Konsol ACK dan tidak memiliki efek fungsional.

    • Selama migrasi, jangan menghapus anotasi yang tidak kompatibel dari konfigurasi Ingress aktif Anda. Anotasi ini masih diurai oleh NGINX Ingress Controller dan memengaruhi traffic produksi Anda.

Langkah 3: Pilih metode alih trafik

Uji sebelum mengalihkan trafik

Sebelum mengalihkan trafik langsung, kami menyarankan untuk melakukan pengujian lokal. Modifikasi file hosts lokal Anda agar nama domain layanan Anda di-resolve ke alamat IP Server Load Balancer (SLB) Cloud-native API Gateway. Gunakan tool seperti curl atau Postman untuk memverifikasi bahwa semua rute trafik berfungsi dengan benar.

Pilih metode alih trafik

Reuse the original SLB

Metode ini bekerja dengan menambahkan node Cloud-native API Gateway ke kelompok vServer backend dari instans Server Load Balancer (SLB) asli. Selama migrasi, SLB mendistribusikan trafik ke Cloud-native API Gateway berdasarkan bobot yang dikonfigurasi. Setelah migrasi selesai, SLB akan meneruskan seluruh trafik ke Cloud-native API Gateway.

Tabel berikut menjelaskan parameter-parameternya.

Parameter

Deskripsi

ACK Cluster Namespace

Pilih namespace tempat Kubernetes Service yang dikaitkan dengan SLB NGINX Ingress berada.

ACK Cluster SLB Service

Pilih nama Kubernetes Service yang dikaitkan dengan SLB NGINX Ingress.

SLB ID

Klik SLB yang ditemukan untuk memastikan bahwa SLB tersebut merupakan SLB target untuk migrasi.

Ports and Backend Servers

Pilih port listener dan protokol gerbang (HTTP/HTTPS) dari instans SLB kluster asli. Kelompok vServer target akan ditampilkan secara otomatis.

Catatan

Pastikan Anda memilih port dan protokol yang benar untuk menghindari kehilangan trafik.

Switch traffic via DNS

Buka konsol penyedia DNS Anda dan tambahkan pemetaan ke alamat SLB Cloud-native API Gateway untuk semua nama domain yang sedang dimigrasikan. Kami menyarankan menggunakan Rekaman DNS berbobot untuk mengalihkan trafik secara bertahap.

Langkah 4: Alihkan trafik

Reuse the original SLB

Langkah 1: Klik Change SLB

Setelah Anda mengklik Change SLB, sistem secara otomatis melepaskan SLB dari manajemen layanan kontainer dan mengubah algoritma penjadwalan listener menjadi Weighted Round Robin.

Penting

Langkah ini melepaskan SLB dari manajemen layanan kontainer. Setelah dilepas, SLB tidak lagi dapat mendeteksi perubahan IP Pod di NGINX Ingress Controller. Anda harus segera melanjutkan ke langkah berikutnya untuk memodifikasi anotasi dan mengaitkan ulang Kubernetes Service dengan SLB.

Langkah 2: Timpa anotasi layanan

Setelah menyelesaikan Langkah 1, buka ACK console. Hapus secara manual semua anotasi saat ini dari Kubernetes Service yang Anda pilih pada langkah Traffic Switching. Kemudian, salin anotasi yang dihasilkan secara otomatis pada halaman Traffic Switching dan tambahkan ke Kubernetes Service target. Langkah ini mengonfigurasi ulang Kubernetes Service asli agar menggunakan kembali SLB. Setelah modifikasi, klik Pre-check. Jika pemeriksaan berhasil, Anda dapat melanjutkan ke langkah berikutnya.

Langkah 3: Alihkan trafik berdasarkan bobot

Tentukan bobot trafik untuk instans Cloud-native API Gateway. Tetapkan nilai antara 1 hingga 100 sesuai kebutuhan bisnis Anda. Kami menyarankan bobot awal antara 1 hingga 10.

  • Nilai ini merepresentasikan total bobot semua node Cloud-native API Gateway. SLB mendistribusikan trafik berdasarkan rasio bobot antara node Cloud-native API Gateway dan node NGINX Ingress di kelompok vServer. Total bobot default node NGINX Ingress adalah 100. Oleh karena itu, jika Anda menetapkan bobot Cloud-native API Gateway menjadi 100, maka ia menerima separuh (1/2) trafik. Demikian pula, jika Anda menetapkan bobot menjadi 50, ia menerima sepertiga (1/3) trafik.

  • Selama migrasi, Anda dapat menggunakan dasbor pemantauan yang disediakan oleh Cloud-native API Gateway untuk memantau berbagai metrik gerbang. Terus pantau kondisi gerbang dan pastikan metrik bisnis sesuai ekspektasi.

    • Jika metrik sesuai ekspektasi, Anda dapat secara bertahap meningkatkan bobot. Tunggu minimal 3 menit antar perubahan bobot karena konfigurasi diterapkan secara asinkron.

    • Jika metrik tidak sesuai ekspektasi, tetapkan bobot menjadi 0 untuk menghentikan migrasi.

  • Di Konsol ACK, Anda juga dapat secara tidak langsung meningkatkan bobot Cloud-native API Gateway dengan menurunkan nilai anotasi service.beta.kubernetes.io/alibaba-cloud-loadbalancer-weight untuk Kubernetes Service yang Anda pilih pada langkah Reuse the original SLB. Secara khusus, menetapkan nilai anotasi ini menjadi 0 akan mengarahkan seluruh trafik ke Cloud-native API Gateway.

  • SLB adalah load balancer Lapisan 4 yang mengontrol trafik pada tingkat koneksi. Nilai bobot tidak dapat mengontrol secara tepat rasio distribusi pada tingkat permintaan (request).

  • Jika laju keberhasilan turun setelah alih trafik, Anda dapat menetapkan bobot menjadi 0 untuk melakukan quick rollback.

Catatan

Jika Anda ingin tetap berada dalam status migrasi dan dapat menyesuaikan bobot trafik antara NGINX Ingress dan Cloud-native API Gateway kapan saja, kami menyarankan untuk tetap berada di langkah ini. Setelah Anda memverifikasi bahwa trafik mengalir sesuai ekspektasi dan tidak lagi memerlukan kemampuan untuk mengembalikan seluruh trafik ke NGINX Ingress, klik Complete Traffic Verification untuk melanjutkan.

Penting

Setelah Anda mengklik Complete Traffic Verification, Anda tidak dapat lagi memodifikasi bobot.

Langkah 4: Alihkan seluruh trafik

Di Konsol ACK, tetapkan anotasi service.beta.kubernetes.io/alibaba-cloud-loadbalancer-weight menjadi 0 untuk Kubernetes Service yang Anda pilih di Langkah 3: Pilih metode alih trafik, atau cukup hapus resource Service tersebut. Sistem secara otomatis menghapus node NGINX Ingress Controller dari SLB, sehingga seluruh trafik SLB dialihkan ke Cloud-native API Gateway. Klik Complete Migration untuk menyelesaikan tugas migrasi.

Switch traffic via DNS

Buka konsol penyedia DNS Anda dan tambahkan pemetaan ke alamat SLB Cloud-native API Gateway untuk semua nama domain yang terlibat dalam migrasi. Kami menyarankan menggunakan Rekaman DNS berbobot untuk mengalihkan trafik secara bertahap.

Quick rollback

Jika Anda mengalami masalah routing selama migrasi, Anda dapat menggunakan salah satu metode berikut untuk segera mengembalikan trafik ke NGINX Ingress Controller.

  • Jika Anda menggunakan metode 'Reuse the original SLB', tetapkan bobot menjadi 0. Ini akan menghentikan migrasi.

  • Jika Anda mengalihkan trafik menggunakan resolusi DNS, hapus Rekaman DNS yang mengarahkan nama domain bisnis Anda ke alamat SLB Cloud-native API Gateway di konsol penyedia DNS Anda.

Langkah 5: Selesaikan migrasi

Reuse the original SLB

Untuk metode alih trafik SLB, jika Anda memiliki SLB lain yang belum sepenuhnya dialihkan, pastikan Anda menyelesaikan alih trafiknya. Setelah Anda selesai mengalihkan trafik untuk semua SLB, Anda dapat menghapus Kubernetes Service dan NGINX Ingress Controller jika tidak lagi diperlukan.

Switch traffic via DNS

Untuk metode alih trafik DNS, setelah Anda memastikan bahwa semua nama domain bisnis Anda di-resolve ke alamat IP SLB Cloud-native API Gateway, Anda dapat menghapus Kubernetes Service dan NGINX Ingress Controller jika tidak lagi diperlukan.