Container Service for Kubernetes：FAQ ALB Ingress

Apakah ALB Ingress mendukung akses jaringan publik dan internal?

Bagaimana cara memastikan bahwa ALB Ingress menggunakan nama domain ALB tetap?

Setelah membuat instans ALB menggunakan AlbConfig, ALB Ingress mereferensikan AlbConfig melalui IngressClass untuk menggunakan nama domain instans ALB yang sesuai. Nama domain tetap tidak berubah selama IngressClass dan AlbConfig yang terkait tidak dimodifikasi.

Gejala

Saat mencari pod ALB Ingress Controller di namespace kube-system, Anda tidak menemukan pod terkait.

Solusi

Pod ALB Ingress Controller hanya tersedia di namespace kube-system pada kluster ACK khusus. Pada kluster ACK standar, ACK Pro, dan ACK Serverless, komponen ALB Ingress Controller dikelola oleh Alibaba Cloud sehingga tidak dapat ditemukan secara langsung. Untuk informasi lebih lanjut tentang migrasi kluster ACK khusus ke ACK Pro, lihat Migrasi panas kluster ACK khusus ke kluster ACK Pro.

Bagaimana cara memasang server berbasis 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

Gejala

Setelah membuat aturan ALB Ingress, aturan routing tidak berfungsi seperti yang diharapkan. Permintaan tidak diteruskan ke layanan backend yang sesuai.

Penyebab

Instans ALB memproses aturan routing secara serial. Jika satu ALB Ingress memiliki kesalahan konfigurasi, perubahan pada ALB Ingress lainnya tidak akan berlaku.

Solusi

Jika ALB Ingress baru tidak berlaku, kemungkinan besar ALB Ingress sebelumnya mengandung kesalahan. Perbaiki ALB Ingress yang rusak agar ALB Ingress baru dapat berfungsi.

Gejala

Setelah mengubah konfigurasi ALB Ingress atau mengaitkannya dengan AlbConfig, perubahan tersebut tidak berlaku meskipun tidak ada aktivitas anomali yang dilaporkan.

Solusi

Jika peristiwa rekonsiliasi terkait dengan AlbConfig tidak dieksekusi atau peristiwa perubahan tidak diproses, pengikatan antara IngressClass dan AlbConfig mungkin salah. Periksa parameter parameters yang ditentukan dalam IngressClass. Untuk informasi lebih lanjut, lihat Gunakan IngressClass untuk mengaitkan AlbConfig dengan Ingress.

Gejala

Aturan pengalihan ALB Ingress dihapus segera setelah dibuat, mengakibatkan permintaan ke layanan mengembalikan kode status 503 dan trafik tidak didistribusikan.

Solusi

Periksa apakah anotasi canary:true telah ditambahkan ke semua Ingress yang sesuai dengan aturan pengalihan. Rilis canary memerlukan versi utama untuk merutekan trafik, sehingga anotasi canary:true tidak perlu ditambahkan ke Ingress versi utama. Untuk informasi lebih lanjut tentang implementasi rilis bertahap menggunakan ALB Ingress, lihat Implementasikan rilis bertahap menggunakan ALB Ingress.

Metode rilis canary hanya mendukung dua Ingress dan memiliki keterbatasan. Gunakan aturan pengalihan kustom untuk solusi pengalihan trafik yang lebih fleksibel. Untuk informasi lebih lanjut, lihat Kustomisasi aturan pengalihan untuk ALB Ingress.

Gejala

Saat mencoba mengakses port selain port 80, permintaan gagal terhubung. Sumber daya AlbConfig melaporkan kesalahan "pendengar tidak ada di alb, port: xxx", menunjukkan bahwa port terkait tidak sedang didengarkan dan trafik tidak diteruskan.

Solusi

Secara default, AlbConfig hanya berisi pendengar untuk port 80. Untuk mendengarkan port lain, tambahkan konfigurasi pendengar untuk port tersebut ke AlbConfig. Untuk informasi lebih lanjut, lihat Buat pendengar.

Gejala

Meskipun telah mengonfigurasi port pendengar HTTP dan HTTPS di AlbConfig, baik port HTTP maupun HTTPS tidak mendengarkan atau meneruskan trafik, sehingga layanan tidak dapat diakses melalui port-port ini.

Solusi

Pastikan Anda telah menambahkan anotasi alb.ingress.kubernetes.io/listen-ports ke anotasi sumber daya Ingress. Anotasi ini menentukan bahwa ALB Ingress mendengarkan port HTTP (80) dan HTTPS (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 untuk memastikan bahwa ALB Ingress berfungsi dengan benar saat beberapa pendengar digunakan.
spec:
  #...

Mengapa perubahan konfigurasi manual yang dibuat di konsol ALB hilang, aturan tambahan dihapus, dan log akses dinonaktifkan?

Mengapa saya menerima kesalahan "Parameter array yang ditentukan berisi terlalu banyak item, maksimal 15 item, Sertifikat tidak valid" selama rekonsiliasi?

Setelah saya mengonfigurasi instans ALB di konsol, mengapa beberapa pendengar dihapus ketika saya menjalankan perintah kubectl apply untuk memperbarui konfigurasi daftar kontrol akses (ACL) AlbConfig?

Masalah

Dalam lingkungan Kubernetes, proses rekonsiliasi server dapat memakan waktu lama saat pod yang terkait dengan layanan diskalakan masuk atau keluar. Penundaan ini memengaruhi kinerja real-time dari penskalaan elastis, terutama seiring dengan bertambahnya jumlah Ingress yang terkait.

Solusi

Untuk meningkatkan efisiensi rekonsiliasi server, terapkan optimasi berikut:

• Batasi jumlah Ingress: Jangan melampirkan lebih dari 30 Ingress ke layanan tunggal.

• Gabungkan aturan Ingress: Lampirkan beberapa layanan ke satu Ingress dan tentukan beberapa aturan pengalihan dalam sumber daya Ingress tersebut untuk meningkatkan kinerja rekonsiliasi server.

Masalah

Saat menggunakan Plugin Jaringan Flannel dan mengonfigurasi layanan dalam mode Lokal, trafik tidak didistribusikan secara merata di seluruh node. Ketidakseimbangan ini menyebabkan beban tinggi pada beberapa node dan mencegah distribusi trafik yang seimbang. Tujuannya adalah untuk menetapkan bobot ke node berdasarkan jumlah pod pada setiap node untuk distribusi trafik yang lebih efektif.

Solusi

Dalam kluster yang menggunakan Plugin Flannel, bobot node dihitung berdasarkan jumlah pod pada setiap node ketika layanan disetel ke mode Lokal. Gambar berikut menunjukkan contoh di mana pod aplikasi (app=nginx) diterapkan pada tiga Instance ECS dan diekspos melalui Service A.