Container Service for Kubernetes:FAQ ALB Ingress

Mengapa aturan ALB Ingress gagal berlaku?

ALB Ingress mempertahankan aturan routing dalam mode inline. Jika beberapa Ingress berbagi instans ALB yang sama, kesalahan konfigurasi pada salah satu Ingress tersebut akan mencegah semua Ingress lain pada instans tersebut diterapkan.

Untuk memperbaikinya, temukan Ingress yang mengandung error — biasanya yang dibuat sebelum Ingress yang terdampak — lalu perbaiki konfigurasinya. Ingress lain akan kembali berfungsi setelah error tersebut diselesaikan.

Apa perbedaan antara ALB Ingress dan NGINX Ingress?

ALB Ingress dibangun di atas ALB, layanan cloud yang sepenuhnya dikelola dan tidak memerlukan pemeliharaan manual. NGINX Ingress mengharuskan Anda mengelola controller sendiri.

Untuk perbandingan mendetail, lihat Perbandingan antara NGINX Ingress, ALB Ingress, dan MSE Ingress.

Apa itu grup server kube-system-fake-svc-80?

ALB memerlukan aturan pengalihan default sebelum listener dapat dibuat, dan setiap aturan pengalihan harus dikaitkan dengan tepat satu grup server. Grup server kube-system-fake-svc-80 memenuhi persyaratan ini — grup ini merupakan placeholder yang digunakan oleh aturan pengalihan default. Grup ini tidak memproses permintaan apa pun dan tidak dapat dihapus.

Bisakah saya mengaktifkan akses internal dan eksternal sekaligus untuk ALB Ingress?

Ya. Buat instans ALB yang menghadap Internet. Instans tersebut secara otomatis menyediakan alamat IP elastis (EIP) di setiap zona untuk traffic internet, serta diberi alamat IP virtual privat (VIP) untuk akses jaringan internal — sehingga kedua mode akses berfungsi secara bersamaan.

Jika Anda hanya memerlukan akses internal, buatlah instans ALB internal-facing sebagai gantinya.

Mengapa saya tidak melihat pod controller ALB Ingress di kluster saya?

Pod controller ALB Ingress hanya terlihat di namespace kube-system pada kluster ACK dedicated. Pada kluster ACK Basic, ACK Pro, dan ACK Serverless, controller ALB Ingress berjalan sebagai komponen yang sepenuhnya dikelola dan tidak ditampilkan sebagai pod di kluster Anda.

Jika Anda ingin melakukan migrasi dari kluster ACK dedicated, lihat Migrasi panas dari kluster ACK dedicated ke kluster ACK Pro.

Bagaimana cara menjaga agar nama domain ALB tidak berubah?

Nama domain tetap stabil selama Anda tidak mengubah IngressClass atau objek AlbConfig yang direferensikannya. Saat Anda menggunakan objek AlbConfig untuk membuat instans ALB, Ingress mereferensikan instans tersebut melalui IngressClass — nama domain terikat pada instans ALB, bukan pada Ingress itu sendiri.

Apakah instans ALB dibuat secara otomatis saat saya mengaktifkan ALB Ingress selama pembuatan kluster?

Tidak. Memilih ALB Ingress selama pembuatan kluster ACK yang dikelola hanya menginstal controller ALB Ingress. Instans ALB itu sendiri harus dibuat secara terpisah.

Apakah ALB Ingress mendukung pemilihan Service lintas namespace?

Tidak. ALB Ingress tidak mendukung pemilihan Service lintas namespace. Resource Ingress hanya dapat mereferensikan Service dalam namespace yang sama. Jika Service yang direferensikan berada di namespace berbeda, Ingress tidak dapat mengaitkan layanan backend dengan benar.

Apakah pembatasan laju QPS pada ALB Ingress dikenai biaya terpisah? Apa cakupannya? Bagaimana cara mengonfigurasi batas laju berbeda untuk path berbeda?

Penagihan: Pembatasan laju QPS tidak dikenai biaya terpisah. Namun, instans ALB ditagih berdasarkan penggunaan, lihat penagihan ALB.

Cakupan penerapan: Anotasi alb.ingress.kubernetes.io/traffic-limit-qps berlaku pada tingkat Ingress. Saat anotasi ini dikonfigurasi, controller menerapkan konfigurasi pembatasan laju yang sama ke setiap aturan pengalihan ALB yang dihasilkan untuk Ingress tersebut. Konfigurasi ini tidak dapat diatur secara independen untuk satu path tertentu, dan kuota QPS tidak dibagi di antara beberapa path.

Konfigurasi pembatasan laju berbeda: Jika path berbeda memerlukan nilai pembatasan laju berbeda, pisahkan konfigurasi menjadi beberapa Ingress dan atur anotasi pembatasan laju spesifik untuk masing-masing. Anda tidak perlu membuat beberapa instans ALB karena satu instans ALB dapat dikaitkan dengan beberapa Ingress. Untuk skenario lanjutan, konfigurasikan TrafficLimit menggunakan aksi aturan pengalihan kustom. Namun, metode ini tidak dapat digunakan bersamaan dengan anotasi global traffic-limit-qps.

Apakah ALB Ingress mendukung beberapa nama domain?

Ya. Satu listener ALB dapat mengikat beberapa nama domain dengan mengonfigurasi beberapa aturan pengalihan.

Untuk mengonfigurasi beberapa nama domain, definisikan beberapa entri host di bawah spec.rules dalam resource Ingress. Setiap entri host menentukan satu nama domain, dan Anda dapat mengaitkan Service backend berbeda dengan nama domain berbeda dalam satu Ingress yang sama.

Mengapa perubahan saya di konsol ALB ditimpa?

Konfigurasi ALB Ingress dikelola melalui objek ALB Ingress atau AlbConfig di API server kluster. Perubahan yang dilakukan langsung di konsol ALB tidak disinkronkan kembali ke API server, sehingga panggilan internal atau operasi kluster apa pun akan menimpa perubahan di konsol dengan konfigurasi yang tersimpan di kluster.

Apa yang harus saya lakukan jika mendapatkan HTTP 503 setelah menghapus aturan pengalihan yang baru saja saya buat?

Periksa apakah ALB Ingress untuk aturan pengalihan tersebut memiliki anotasi canary:true. Untuk rilis canary, traffic dialihkan dari versi Service lama ke versi canary — tambahkan canary:true hanya pada Ingress canary, bukan pada Ingress Service lama.

Rilis canary hanya mendukung dua Ingress dan jumlah kondisi pengalihan terbatas. Untuk routing traffic yang lebih fleksibel, gunakan aturan pengalihan kustom sebagai gantinya. Lihat Gunakan ALB Ingress untuk melakukan rilis canary dan Konfigurasi aturan pengalihan kustom untuk ALB Ingress.

Mengapa perubahan ALB Ingress saya tidak berlaku meskipun tidak ada error?

IngressClass mungkin mengarah ke objek AlbConfig yang salah. Periksa apakah bidang parameters di IngressClass Anda dikonfigurasi dengan benar. Lihat Gunakan IngressClass untuk mengaitkan objek AlbConfig dengan Ingress.

Mengapa beberapa listener dihapus setelah saya menjalankan kubectl apply untuk memperbarui AlbConfig?

kubectl apply menimpa seluruh resource AlbConfig. Jika file YAML Anda menghilangkan listener yang sebelumnya dikonfigurasi, listener tersebut akan dihapus.

Gunakan kubectl edit jika memungkinkan — perintah ini membuka resource lengkap saat ini untuk diedit dan menghindari kelalaian tidak sengaja:

kubectl -n <namespace> edit AlbConfig <albconfig-name>

Jika listener sudah terhapus, tambahkan kembali menggunakan perintah kubectl edit di atas.

Mengapa titik akhir eksternal (Endpoint) ALB Ingress kosong atau alamat tidak dapat diperoleh, dan bagaimana cara mengatasinya?

Jika titik akhir eksternal ALB Ingress kosong atau alamat tidak dapat diperoleh, periksa penyebab umum berikut dan lakukan tindakan yang sesuai:

1. IngressClass tidak ditentukan: Pastikan resource Ingress menentukan ingressClassName yang benar (misalnya, alb). Jika ingressClassName tidak diatur atau nilainya tidak sesuai dengan IngressClass yang dikelola oleh ALB Ingress Controller, controller tidak akan memproses Ingress tersebut dan titik akhir akan tetap kosong.

2. Asosiasi AlbConfig salah: Periksa apakah IngressClass dikaitkan dengan nama AlbConfig yang benar, dan verifikasi bahwa status AlbConfig normal. Asosiasi yang salah atau AlbConfig dalam status abnormal mencegah provisioning ALB. Untuk informasi lebih lanjut, lihat Gunakan IngressClass untuk mengaitkan AlbConfig dengan ingress.

3. IP vSwitch tidak mencukupi: Periksa jumlah alamat IP yang tersedia di vSwitch yang dikaitkan dengan AlbConfig. Untuk memastikan fitur elastis ALB didukung sepenuhnya, sediakan minimal 8 alamat IP di setiap vSwitch tempat instans ALB ditempatkan. Jika IP yang tersedia tidak mencukupi, ganti vSwitch atau perluas rentang CIDR vSwitch.

4. Zona ketersediaan tidak mencukupi: ALB memerlukan ketersediaan tinggi dan membutuhkan vSwitch di minimal dua zona ketersediaan berbeda. Jika hanya satu zona ketersediaan yang dikonfigurasi, tambahkan vSwitch di minimal satu zona ketersediaan lainnya.

5. Opsi instalasi komponen: Jika None dipilih selama instalasi komponen, tidak ada instans ALB atau AlbConfig yang dibuat secara otomatis. Anda harus membuat AlbConfig dan IngressClass secara manual dan mengaitkan AlbConfig dengan Ingress menggunakan IngressClass.

Bagaimana cara mengurangi waktu rekonsiliasi saat scaling pod?

Waktu rekonsiliasi meningkat seiring bertambahnya jumlah Ingress yang dikaitkan dengan suatu Service. Gunakan salah satu pendekatan berikut:

• Batasi jumlah Ingress per Service: Pastikan tidak lebih dari 30 Ingress dikaitkan dengan satu Service.

• Gabungkan aturan Ingress: Kaitkan beberapa Service dengan satu Ingress yang sama dan definisikan aturan routing terpisah di dalamnya, daripada membuat satu Ingress untuk setiap Service.