Container Service for Kubernetes:FAQ ALB Ingress

Masalah

Dalam skenario nyata, Anda perlu mengakses ALB Ingress melalui jaringan publik maupun pribadi. Namun, Anda tidak yakin apakah ALB Ingress mendukung keduanya secara bersamaan.

Solusi

Ya. Untuk menggunakan akses jaringan publik dan pribadi sekaligus, buat instans ALB publik. Instans tersebut membuat alamat IP elastis (EIP) di setiap zona untuk komunikasi jaringan publik, serta menyediakan alamat IP virtual (VIP) pribadi yang dapat digunakan untuk mengakses ALB melalui jaringan pribadi. Jika Anda hanya memerlukan akses jaringan pribadi, buat instans ALB pribadi.

Masalah

Saat mencari pod ALB Ingress Controller di kluster Anda, Anda tidak menemukan pod terkait di namespace kube-system dan tidak dapat melihat komponen ALB Ingress Controller menggunakan metode standar.

Solusi

Anda hanya dapat melihat pod ALB Ingress Controller di namespace kube-system pada cluster khusus ACK. Pada ACK Edisi Dasar, ACK Edisi Pro, dan ACK Serverless, komponen ALB Ingress Controller dikelola sepenuhnya sehingga tidak terlihat di kluster tersebut. Untuk petunjuk peningkatan cluster khusus ACK ke kluster ACK yang dikelola Edisi Pro, lihat Migrasi panas cluster khusus ACK ke kluster ACK yang dikelola Edisi Pro.

Masalah

Anda ingin menyambungkan pod backend ke ALB berdasarkan alamat IP. Namun secara default, Service tidak secara otomatis membuat kelompok server berbasis IP, sehingga membatasi distribusi lalu lintas ke layanan backend.

Solusi

Tambahkan anotasi alb.ingress.kubernetes.io/server-group-type: Ip ke Service. Hal ini akan membuat kelompok server berbasis IP untuk Service tersebut, sehingga Anda dapat mendaftarkan pod backend ke ALB berdasarkan alamat IP.

apiVersion: v1
kind: Service
metadata:
  annotations:
    alb.ingress.kubernetes.io/server-group-type: Ip
  name: tea-svc
spec:
  ports:
    - port: 80
      targetPort: 80
      protocol: TCP
  selector:
    app: tea
  type: ClusterIP

Akar penyebab

Setelah Anda mengaktifkan perlindungan WAF secara manual untuk instans ALB di konsol WAF, ALB Ingress Controller mendeteksi selama rekonsiliasi bahwa edisi aktual instans ALB tidak sesuai dengan field edition yang dideklarasikan di AlbConfig. Jika AlbConfig tidak secara eksplisit menentukan edition: StandardWithWaf, Controller akan mengembalikan instans ke Edisi Standar default, sehingga WAF turun ke Edisi Standar.

Solusi

Untuk mempertahankan Edisi WAF Enhanced, tetapkan secara eksplisit field edition ke StandardWithWaf di AlbConfig saat membuat instans ALB baru atau melakukan peningkatan dan penurunan instans yang sudah ada.

Akar penyebab

• Kesalahan 503 (Service Temporarily Unavailable)

  • Tidak ada aturan routing yang sesuai: Path permintaan tidak sesuai dengan aturan routing yang dikonfigurasi di Ingress.

  • Tidak ada pod backend yang sehat: Semua pod yang terkait dengan layanan tidak siap atau tidak ada, sehingga menghasilkan objek endpoint kosong.

• Kesalahan 502 (Bad Gateway)

  Listener HTTP atau HTTPS menerima permintaan koneksi klien. Jika instans ALB tidak dapat meneruskan permintaan ke pod atau menerima respons dari pod, instans tersebut mengirimkan kode status HTTP 502 Bad Gateway ke klien.

• Kesalahan 404 (Not Found)

  Hal ini biasanya berarti permintaan sesuai dengan aturan routing yang ditentukan di Ingress, tetapi tidak sesuai dengan URL layanan aktual yang disediakan oleh aplikasi di dalam pod.

• Kesalahan 400 (Bad Request)

  Hal ini dapat terjadi karena berbagai alasan, seperti permintaan HTTP yang dikirim ke listener HTTPS.

Untuk kode error HTTP lainnya, lihat Kode Status ALB.

Solusi

1. Periksa status Ingress. Jalankan perintah kubectl describe ingress <ingress-name> -n <namespace> dan periksa bagian Events untuk pesan kesalahan. Misalnya, jika Anda melihat event seperti listener does not exist in alb, Anda harus membuat listener yang diperlukan untuk resource Ingress di AlbConfig.

   ...
   Events:
     Type     Reason                  Age     From     Message
     ----     ------                  ----    ----     -------
     Warning  FailedBuildModel        ****    ingress  listener is not exist in alb, port: 443, protocol: HTTPS
     Warning  FailedBuildModel        ****    ingress  listener not found for (443/HTTPS), with ingresses 1
   ...

2. Periksa endpoint backend. Jalankan perintah kubectl get endpoints <service-name> -n <namespace> untuk memastikan field ENDPOINTS berisi setidaknya satu alamat IP dan port pod yang sehat. Jika field tersebut kosong, verifikasi bahwa selector layanan sesuai dengan labels pada pod Anda, dan pastikan pod berada dalam status Running.

3. Periksa status dan log pod. Pertama, jalankan perintah kubectl get pod -l <app=your-app> -n <namespace> untuk memeriksa status pod aplikasi Anda. Kemudian, jalankan kubectl logs <pod-name> -n <namespace> untuk memeriksa log pod tertentu guna mengidentifikasi kegagalan startup atau kesalahan pemrosesan permintaan.

4. Uji konektivitas jaringan. Dari dalam pod lain atau langsung dari node, gunakan curl untuk mengakses ClusterIP layanan backend atau IP pod langsung. Hal ini memverifikasi bahwa layanan dapat dijangkau dari dalam kluster.

Akar penyebab

• Instans ALB tidak mendengarkan di port 443. Anda telah mengonfigurasi enkripsi TLS untuk Ingress, tetapi listener HTTPS:443 yang sesuai belum dibuat.

• Sertifikat dikonfigurasi salah. Tipe secret bukan kubernetes.io/tls atau IngressTLS, atau isi tls.crt dan tls.key di field data salah atau tidak cocok.

• Pembaruan sertifikat belum berlaku. Anda memperbarui sertifikat di Alibaba Cloud Certificate Management Service, tetapi tidak memperbarui ID sertifikat yang ditentukan di AlbConfig, atau rekonsiliasi penemuan sertifikat otomatis tidak dipicu. Akibatnya, instans ALB masih mereferensikan sertifikat lama.

Solusi

1. Periksa port listener. Jalankan perintah kubectl describe albconfig <alb-name> -n <namespace> untuk memeriksa apakah konfigurasi spec.listeners.port: 443 dan spec.listeners.protocol: HTTPS hilang.

2. Periksa konfigurasi Ingress. Periksa apakah konfigurasi Ingress kehilangan anotasi alb.ingress.kubernetes.io/listen-ports: [{"HTTP": 80}, {"HTTPS": 443}]. Anotasi ini mengaitkan Ingress dengan listener HTTP dan HTTPS.

3. Periksa konfigurasi secret. Periksa field secretName dari spec.tls di konfigurasi Ingress untuk memastikan secret yang benar direferensikan. Jalankan perintah kubectl get secret <secret-name> -n <namespace> -o yaml untuk memastikan tipe secret dan integritas data.

Masalah

Setelah Anda membuat aturan ALB Ingress baru, aturan tersebut tidak berlaku seperti yang diharapkan. Lalu lintas tidak diteruskan ke layanan backend yang dituju.

Akar penyebab

Instans ALB memelihara aturan routing secara berurutan. Jika beberapa resource ALB Ingress menggunakan instans ALB yang sama, kesalahan konfigurasi pada satu ALB Ingress mencegah semua perubahan ALB Ingress lainnya berlaku.

Solusi

Jika ALB Ingress Anda tidak berlaku, kemungkinan ALB Ingress sebelumnya salah dikonfigurasi. Perbaiki terlebih dahulu ALB Ingress yang salah konfigurasi tersebut. Setelah itu, ALB Ingress baru Anda akan berlaku.

Masalah

Setelah Anda mengubah konfigurasi ALB Ingress atau mengaitkannya dengan AlbConfig, tidak ada aktivitas anomali yang muncul. Namun, perubahan tersebut tidak berlaku.

Solusi

Hal ini dapat terjadi jika pengikatan antara IngressClass dan AlbConfig salah. Periksa field parameters di IngressClass Anda. Untuk petunjuk langkah demi langkah, lihat Mengaitkan AlbConfig dengan Ingress menggunakan IngressClass.

Masalah

Aturan pengalihan ALB Ingress dihapus tepat setelah dibuat. Hal ini mengembalikan kode status 503 dan menghentikan distribusi lalu lintas.

Solusi

Periksa apakah semua resource Ingress yang terkait dengan aturan pengalihan memiliki anotasi canary: true. Rilis canary memerlukan versi baseline untuk mengarahkan lalu lintas. Oleh karena itu, Anda tidak perlu menambahkan canary: true ke Ingress baseline. Untuk petunjuk penggunaan ALB Ingress dalam rilis bertahap, lihat Implementasikan rilis bertahap dengan ALB Ingress.

Rilis canary hanya mendukung dua resource Ingress dan memiliki kondisi terbatas. Kami menyarankan penggunaan aturan pengalihan kustom untuk opsi routing lalu lintas yang lebih kaya. Untuk petunjuknya, lihat Kustomisasi aturan pengalihan ALB Ingress.

Masalah

Permintaan ke port selain port 80 gagal terhubung. AlbConfig melaporkan “listener is not exist in alb, port: xxx”, yang berarti port tersebut tidak mendengarkan atau meneruskan lalu lintas.

Solusi

AlbConfig default hanya mencakup listener untuk port 80. Untuk mendengarkan port lain, tambahkan konfigurasi listener untuk port tersebut di AlbConfig. Untuk petunjuknya, lihat Buat listener.

Masalah

Saya telah mengonfigurasi listener HTTP dan HTTPS di AlbConfig. Namun, saya tidak dapat mengakses keduanya. Lalu lintas tidak didengarkan atau diteruskan.

Solusi

Pastikan Anda telah menambahkan anotasi alb.ingress.kubernetes.io/listen-ports ke resource Ingress. Anotasi ini memberi tahu ALB Ingress untuk mendengarkan baik HTTP (port 80) maupun HTTPS (port 443). Contohnya:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: https-ingress
  annotations:
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80},{"HTTPS": 443}]' # Tambahkan anotasi ini agar ALB Ingress berfungsi dengan beberapa listener.
spec:
  #...

Mengapa perubahan konfigurasi manual di konsol ALB hilang? Mengapa aturan dihapus dan log akses dinonaktifkan?

Mengapa muncul pesan kesalahan selama proses tuning: Specified parameter array contains too many items, up to 15 items, Certificates is not valid?

Setelah saya mengonfigurasi instans ALB di konsol, mengapa menjalankan kubectl apply untuk memperbarui pengaturan ACL AlbConfig menghapus beberapa listener?

Masalah

Di Kubernetes, rekonsiliasi server memakan waktu terlalu lama saat pod yang terhubung ke Service mengalami penskalaan. Hal ini memengaruhi elastisitas real-time. Investigasi menunjukkan bahwa waktu rekonsiliasi meningkat seiring jumlah resource Ingress yang terkait.

Solusi

Untuk meningkatkan efisiensi tuning server, Anda dapat menerapkan langkah-langkah optimasi berikut:

• Batasi jumlah Ingress: Hubungkan tidak lebih dari 30 resource Ingress ke satu Service.

• Gabungkan aturan Ingress: Jika Anda memiliki banyak resource Ingress, hubungkan beberapa Service ke satu Ingress. Definisikan beberapa aturan pengalihan di Ingress tersebut untuk meningkatkan performa rekonsiliasi server.

Masalah

Saat menggunakan plugin Flannel dengan Service mode Local, distribusi lalu lintas di antara node tidak merata. Beberapa node menanggung beban lebih tinggi daripada yang lain. Bagaimana cara menetapkan bobot node secara otomatis berdasarkan jumlah pod per node untuk mencapai distribusi lalu lintas yang seimbang?

Solusi

Di kluster Flannel, saat Service berada dalam mode Local, bobot node dihitung seperti yang ditunjukkan pada diagram di bawah. Dalam contoh ini, pod aplikasi (app=nginx) berjalan di tiga instans ECS. Service A mengeksposnya ke luar.