Topik ini menjawab beberapa pertanyaan umum tentang Application Load Balancer (ALB) Ingress.
Daftar isi
Mengapa aturan ALB Ingress gagal diterapkan?
ALB Ingress mempertahankan aturan routing dalam mode inline. Jika beberapa ALB Ingress menggunakan instance ALB yang sama dan salah satu konfigurasinya mengandung kesalahan, aturan ALB Ingress lainnya tidak akan diterapkan.
Jika ALB Ingress yang Anda buat tidak diterapkan, kemungkinan besar ALB Ingress sebelumnya mengalami kesalahan. Dalam hal ini, Anda perlu menemukan dan memperbaiki kesalahan tersebut agar ALB Ingress baru dapat diterapkan.
Apa perbedaan antara ALB Ingress dan NGINX Ingress?
Kami merekomendasikan Anda menggunakan ALB Ingress karena NGINX Ingress memerlukan pemeliharaan manual. Berbeda dengan NGINX Ingress, ALB Ingress dikembangkan berdasarkan ALB, layanan cloud yang sepenuhnya dikelola tanpa pemeliharaan. ALB Ingress berfungsi sebagai gateway berperforma tinggi dan menyediakan kemampuan manajemen lalu lintas Ingress yang kuat. Untuk informasi lebih lanjut tentang perbandingan antara NGINX Ingress dan ALB Ingress, lihat Perbandingan antara NGINX Ingress, ALB Ingress, dan MSE Ingress.
ALB Ingress mendengarkan permintaan yang dikirim ke grup server kube-system-fake-svc-80 secara default. Apa tujuan dari grup server tersebut?
Anda harus membuat aturan pengalihan default sebelum membuat pendengar. Setiap aturan pengalihan hanya dapat dikaitkan dengan satu grup server. Grup server kube-system-fake-svc-80 adalah palsu dan digunakan oleh aturan pengalihan default. Grup server palsu ini tidak memproses permintaan dan tidak dapat dihapus.
Dapatkah saya mengaktifkan akses internal dan eksternal untuk ALB Ingress pada saat yang sama?
Ya, Anda dapat mengaktifkan akses internal dan eksternal untuk ALB Ingress secara bersamaan. Untuk mengaktifkan akses internal dan eksternal, buat instance ALB yang menghadap Internet. Instance ALB secara otomatis membuat alamat IP elastis (EIP) di setiap zona dan menggunakan EIP tersebut untuk berkomunikasi dengan Internet. Instance ALB juga diberi alamat IP virtual pribadi (VIP). Anda dapat menggunakan VIP untuk mengakses instance ALB melalui jaringan internal. Jika Anda hanya ingin mengaktifkan akses internal, buat instance ALB yang menghadap internal.
Mengapa saya tidak dapat melihat pod kontroler ALB Ingress di dalam klaster?
Pod kontroler ALB Ingress hanya dapat dilihat di namespace kube-system jika klaster Anda adalah klaster Container Service for Kubernetes (ACK) khusus. Pod kontroler ALB Ingress tidak dapat dilihat di klaster ACK Basic, ACK Pro, dan ACK Serverless karena kontroler ALB Ingress adalah komponen yang sepenuhnya dikelola di klaster tersebut. Untuk informasi lebih lanjut tentang cara memperbarui klaster ACK khusus menjadi klaster ACK Pro, lihat Migrasi panas dari klaster ACK khusus ke klaster ACK Pro.
Bagaimana cara memastikan nama domain ALB yang digunakan oleh ALB Ingress tidak berubah?
Setelah Anda menggunakan objek AlbConfig untuk membuat instance ALB, ALB Ingress menggunakan IngressClass untuk merujuk ke objek AlbConfig. Ini memungkinkan ALB Ingress menggunakan nama domain instance ALB. Jika Anda tidak memodifikasi IngressClass yang terkait dengan ALB Ingress atau objek AlbConfig, nama domain tetap tidak berubah.
Apakah instance ALB dibuat secara otomatis jika saya memilih menggunakan ALB Ingress saat membuat klaster ACK terkelola?
Tidak, tidak ada instance ALB yang dibuat. Jika Anda memilih menggunakan ALB Ingress saat membuat klaster ACK terkelola, sistem secara otomatis menginstal kontroler ALB Ingress tetapi tidak membuat instance ALB.
Mengapa perubahan konfigurasi ALB yang saya buat di konsol ALB hilang, aturan yang saya tambahkan dihapus, dan log akses dinonaktifkan?
Untuk memodifikasi konfigurasi ALB Ingress, Anda perlu memodifikasi konfigurasi yang disimpan di ALB Ingress atau objek AlbConfig pada server API klaster. Jika Anda memodifikasi konfigurasi ALB di konsol ALB, perubahan tersebut tidak disinkronkan ke server API. Akibatnya, perubahan tersebut tidak diterapkan. Selain itu, panggilan internal atau operasi klaster akan memicu ACK untuk menimpa konfigurasi ALB di konsol ALB dengan konfigurasi yang disimpan di ALB Ingress atau objek AlbConfig. Oleh karena itu, kami merekomendasikan Anda memodifikasi konfigurasi yang disimpan di ALB Ingress atau objek AlbConfig.
Apa yang harus saya lakukan jika kode status HTTP 503 dikembalikan ketika saya menghapus aturan pengalihan ALB Ingress segera setelah saya membuat aturan pengalihan?
Periksa apakah ALB Ingress yang sesuai dengan aturan pengalihan tersebut mengandung anotasi canary:true. Untuk melakukan rilis canary, Anda perlu mengarahkan ulang lalu lintas dari versi Service lama ke versi canary. Oleh karena itu, Anda tidak perlu menambahkan anotasi canary:true ke ALB Ingress versi Service lama. Untuk informasi lebih lanjut tentang cara menggunakan ALB Ingress untuk melaksanakan rilis canary, lihat Gunakan ALB Ingress untuk melaksanakan rilis canary.
Rilis canary hanya mendukung dua Ingress dan sejumlah kondisi pengalihan yang terbatas. Kami merekomendasikan Anda menggunakan aturan pengalihan kustom untuk mengarahkan lalu lintas dengan cara yang lebih fleksibel. Untuk informasi lebih lanjut, lihat Konfigurasikan aturan pengalihan kustom untuk ALB Ingress.
Apa yang harus saya lakukan jika ALB Ingress tidak mengalami kesalahan tetapi perubahan tidak diterapkan?
Jika rekonsiliasi terkait objek AlbConfig tidak dilakukan atau acara perubahan konfigurasi tidak diproses, IngressClass dari ALB Ingress mungkin dikaitkan dengan objek AlbConfig yang salah. Ikuti panduan pengguna untuk memeriksa apakah pengaturan parameters dari IngressClass dikonfigurasi dengan benar. Untuk informasi lebih lanjut, lihat Gunakan IngressClass untuk mengaitkan objek AlbConfig dengan Ingress.
Mengapa beberapa pendengar dihapus setelah saya membuat instance ALB di konsol dan menjalankan perintah kubectl apply untuk memperbarui konfigurasi ACL jaringan di AlbConfig?
Kami merekomendasikan Anda menjalankan perintah kubectl edit untuk memperbarui sumber daya. Untuk menggunakan perintah kubectl apply untuk memperbarui sumber daya, jalankan perintah kubectl diff untuk melihat pratinjau perubahan dan pastikan bahwa perubahan tersebut memenuhi persyaratan Anda sebelum menjalankan perintah kubectl apply. Kemudian, Anda dapat menjalankan perintah kubectl apply untuk menerapkan perubahan ke sumber daya di klaster Anda.
Perintah kubectl apply memperbarui AlbConfig dengan menimpanya. Oleh karena itu, saat Anda menjalankan perintah kubectl apply untuk memperbarui konfigurasi ACL jaringan di AlbConfig, pastikan bahwa file YAML berisi konfigurasi semua pendengar yang ditentukan di AlbConfig. Jika tidak, beberapa pendengar akan dihapus.
Jika pendengar dihapus setelah Anda menjalankan perintah kubectl apply, kami merekomendasikan Anda menggunakan metode berikut untuk memulihkan pendengar.
Periksa apakah file YAML berisi konfigurasi semua pendengar.
Jika beberapa pendengar hilang, lanjutkan ke langkah berikutnya. Jika semua pendengar termasuk, tidak ada tindakan yang diperlukan.
Jalankan perintah berikut untuk menambahkan konfigurasi pendengar yang hilang ke AlbConfig:
kubectl -n <namespace> edit AlbConfig <albconfig-name> # Ganti <namespace> dan <albconfig-name> dengan namespace objek AlbConfig dan nama objek AlbConfig.
Bagaimana cara mengurangi waktu rekonsiliasi server ketika satu atau lebih Layanan melakukan penskalaan pod?
Saat Layanan di klaster ACK melakukan penskalaan pod, waktu rekonsiliasi server bervariasi berdasarkan jumlah Ingress yang dikaitkan dengan Layanan tersebut. Anda dapat menggunakan metode berikut untuk mengurangi waktu rekonsiliasi server:
Batasi jumlah Ingress: Pastikan tidak lebih dari 30 Ingress dikaitkan dengan setiap Layanan.
Gabungkan aturan Ingress: Jika terlalu banyak Ingress digunakan, Anda dapat mengaitkan beberapa Layanan dengan Ingress yang sama dan kemudian membuat aturan Ingress di dalam Ingress untuk meningkatkan efisiensi rekonsiliasi server.