Container Compute Service:ALB Ingress FAQ

Daftar isi

• Mengapa aturan ALB Ingress gagal diterapkan?

• Apa perbedaan antara ALB Ingress dan NGINX Ingress?

• ALB Ingress mendengarkan permintaan yang dikirim ke grup server kube-system-fake-svc-80 secara default. Apa tujuan dari grup server tersebut?

• Dapatkah saya mengaktifkan akses internal dan eksternal untuk ALB Ingress pada saat bersamaan?

• Mengapa saya tidak dapat melihat pod kontroler ALB Ingress di dalam kluster?

• Bagaimana cara memastikan bahwa nama domain ALB yang digunakan oleh ALB Ingress tetap tidak berubah?

• Apakah instance ALB dibuat secara otomatis jika saya menggunakan ALB Ingress ketika membuat kluster ACK yang dikelola?

• Mengapa perubahan konfigurasi ALB yang saya buat di konsol SLB hilang, aturan yang saya tambahkan terhapus, dan log akses dinonaktifkan?

• Apa yang harus saya lakukan jika kode status HTTP 503 dikembalikan ketika saya menghapus aturan pengalihan ALB Ingress segera setelah saya membuat aturan pengalihan?

• Apa yang harus saya lakukan jika tidak ada kesalahan pada ALB Ingress tetapi perubahan tidak diterapkan?

• Mengapa beberapa pendengar dihapus setelah saya membuat instance ALB di konsol dan menjalankan perintah kubectl apply untuk memperbarui konfigurasi ACL jaringan di AlbConfig?

• Bagaimana cara mengurangi waktu rekonsiliasi server ketika Layanan melakukan penskalaan pod?

• Bagaimana cara mengaktifkan sistem untuk secara otomatis menetapkan bobot ke node ketika kluster menggunakan plugin jaringan Flannel dan mode Lokal diaktifkan untuk Layanan?

Mengapa aturan ALB Ingress gagal diterapkan?

ALB Ingress mempertahankan aturan routing dalam mode inline. Jika beberapa ALB Ingress menggunakan instance ALB yang sama dan konfigurasi ALB Ingress mengandung kesalahan, ALB Ingress lainnya tidak akan diterapkan.

Jika ALB Ingress yang Anda buat tidak diterapkan, kemungkinan ALB Ingress yang Anda buat sebelum membuat ALB Ingress saat ini mengalami kesalahan. Dalam skenario ini, Anda perlu menemukan ALB Ingress tersebut dan memperbaiki kesalahannya agar ALB Ingress baru dapat diterapkan.

Apa perbedaan antara ALB Ingress dan NGINX Ingress?

Kami merekomendasikan Anda menggunakan ALB Ingress. Anda perlu memelihara NGINX Ingress secara manual. Berbeda dengan NGINX Ingress, ALB Ingress dikembangkan berdasarkan ALB, layanan cloud sepenuhnya dikelola tanpa pemeliharaan. ALB Ingress dapat berfungsi sebagai gateway berperforma tinggi dan menyediakan kemampuan manajemen trafik Ingress yang kuat.

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 Anda dapat 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 bersamaan?

Ya. Anda dapat mengaktifkan akses internal dan eksternal untuk ALB Ingress pada saat bersamaan. Jika Anda ingin mengaktifkan akses internal dan eksternal untuk ALB Ingress pada saat bersamaan, Anda perlu membuat 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 untuk ALB Ingress, Anda dapat membuat instance ALB dengan akses internal.

Mengapa saya tidak dapat melihat pod kontroler ALB Ingress di dalam kluster?

Anda dapat melihat pod kontroler ALB Ingress di namespace kube-system hanya jika kluster Anda adalah kluster Container Service for Kubernetes (ACK) khusus. Anda tidak dapat melihat pod kontroler ALB Ingress di ACK Basic, ACK Pro, dan kluster Alibaba Cloud Container Compute Service (ACS) karena kontroler ALB Ingress adalah komponen yang sepenuhnya dikelola di kluster tersebut.

Bagaimana cara memastikan bahwa nama domain ALB yang digunakan oleh ALB Ingress tidak berubah?

Setelah Anda menggunakan AlbConfig untuk membuat instance ALB, ALB Ingress menggunakan IngressClass untuk merujuk ke AlbConfig. Ini memungkinkan ALB Ingress menggunakan nama domain instance ALB. Jika Anda tidak mengubah IngressClass yang terkait dengan ALB Ingress atau AlbConfig, nama domain tetap tidak berubah.

Apakah instance ALB dibuat secara otomatis jika saya memilih untuk menggunakan ALB Ingress ketika membuat kluster ACK yang dikelola?

Tidak, tidak ada instance ALB yang dibuat. Jika Anda memilih untuk menggunakan ALB Ingress ketika membuat kluster ACK yang dikelola, 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 terhapus, dan log akses dinonaktifkan?

Untuk memodifikasi konfigurasi ALB Ingress, Anda perlu memodifikasi konfigurasi yang disimpan di ALB Ingress atau AlbConfig pada API server kluster. Jika Anda memodifikasi konfigurasi ALB di konsol ALB, perubahan tersebut tidak disinkronkan ke API server. Akibatnya, perubahan tersebut tidak diterapkan. Selain itu, panggilan internal atau operasi kluster akan memicu ACS untuk menimpa konfigurasi ALB di konsol ALB dengan konfigurasi yang disimpan di ALB Ingress atau AlbConfig. Kami merekomendasikan Anda memodifikasi konfigurasi yang disimpan di ALB Ingress atau 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 trafik 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 menerapkan rilis canary, lihat Gunakan ALB Ingress untuk Melakukan Rilis Canary.

Rilis canary hanya mendukung dua Ingress dan sejumlah kondisi pengalihan yang terbatas. Kami merekomendasikan Anda menggunakan aturan pengalihan kustom untuk mengarahkan trafik secara 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 peristiwa rekonsiliasi yang terkait dengan AlbConfig tidak dilakukan atau peristiwa perubahan konfigurasi tidak diproses, IngressClass dari ALB Ingress mungkin dikaitkan dengan AlbConfig yang salah. Periksa apakah pengaturan parameters dari IngressClass dikonfigurasikan dengan benar berdasarkan panduan pengguna. Untuk informasi lebih lanjut, lihat Gunakan AlbConfig untuk Mengonfigurasi Instance ALB.

Mengapa beberapa pendengar dihapus setelah saya membuat instance ALB di konsol dan menjalankan perintah kubectl apply untuk memperbarui konfigurasi ACL jaringan di AlbConfig?

Perintah kubectl apply memperbarui AlbConfig dengan menimpa AlbConfig. Oleh karena itu, ketika 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.

1. 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.

2. 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 AlbConfig dan nama AlbConfig.

Bagaimana cara mengurangi waktu rekonsiliasi server ketika Layanan melakukan penskalaan pod?

Saat Layanan di kluster ACK melakukan penskalaan pod, waktu rekonsiliasi server bervariasi berdasarkan jumlah Ingress yang terkait dengan Layanan. Anda dapat menggunakan metode berikut untuk mengurangi waktu rekonsiliasi server:

• Batasi jumlah Ingress: Pastikan tidak lebih dari 30 Ingress terkait dengan setiap Layanan.

• Gabungkan aturan Ingress: Jika terlalu banyak Ingress digunakan, Anda dapat mengaitkan beberapa Layanan dengan Ingress yang sama dan membuat aturan Ingress di dalam Ingress untuk meningkatkan efisiensi rekonsiliasi server.

Bagaimana cara mengaktifkan sistem untuk secara otomatis menetapkan bobot ke node ketika kluster menggunakan plugin jaringan Flannel dan mode Lokal diaktifkan untuk Layanan?

Dalam contoh ini, plugin jaringan Flannel diinstal di kluster dan mode Lokal diaktifkan untuk Layanan untuk menunjukkan cara menghitung bobot node. Gambar berikut menunjukkan bahwa pod bisnis bernama app=nginx diterapkan pada tiga Elastic Compute Service (ECS) instance dan menyediakan layanan eksternal berdasarkan Layanan A.