Memecahkan masalah load balancing di GKE

Autopilot Standard

---

Halaman ini menunjukkan cara menyelesaikan masalah terkait load balancing di cluster Google Kubernetes Engine (GKE) menggunakan resource Service, Ingress, atau Gateway.

Jika Anda memerlukan bantuan tambahan, hubungi Cloud Customer Care.

BackendConfig tidak ditemukan

Error ini terjadi saat BackendConfig untuk port Layanan ditetapkan dalam anotasi Layanan, tetapi resource BackendConfig yang sebenarnya tidak dapat ditemukan.

Untuk mengevaluasi peristiwa Kubernetes, jalankan perintah berikut:

kubectl get event

Contoh output berikut menunjukkan BackendConfig tidak ditemukan:

KIND    ... SOURCE
Ingress ... loadbalancer-controller

MESSAGE
Error during sync: error getting BackendConfig for port 80 on service "default/my-service":
no BackendConfig for service port exists

Untuk mengatasi masalah ini, pastikan Anda tidak membuat resource BackendConfig di namespace yang salah atau salah mengeja referensinya di anotasi Service.

Kebijakan keamanan Ingress tidak ditemukan

Setelah objek Ingress dibuat, jika kebijakan keamanan tidak dikaitkan dengan benar dengan Layanan LoadBalancer, evaluasi peristiwa Kubernetes untuk melihat apakah ada kesalahan konfigurasi. Jika BackendConfig menentukan kebijakan keamanan yang tidak ada, peristiwa peringatan akan dikeluarkan secara berkala.

Untuk mengevaluasi peristiwa Kubernetes, jalankan perintah berikut:

kubectl get event

Contoh output berikut menunjukkan bahwa kebijakan keamanan Anda tidak ditemukan:

KIND    ... SOURCE
Ingress ... loadbalancer-controller

MESSAGE
Error during sync: The given security policy "my-policy" does not exist.

Untuk mengatasi masalah ini, tentukan nama kebijakan keamanan yang benar di BackendConfig.

Mengatasi error seri 500 dengan NEG selama penskalaan beban kerja di GKE

Gejala:

Saat menggunakan NEG yang disediakan GKE untuk load balancing, Anda mungkin mengalami error 502 atau 503 untuk layanan selama penskalaan turun beban kerja. Error 502 terjadi saat Pod dihentikan sebelum koneksi yang ada ditutup, sedangkan error 503 terjadi saat traffic diarahkan ke Pod yang dihapus.

Masalah ini dapat memengaruhi cluster jika Anda menggunakan produk load balancing terkelola GKE yang menggunakan NEG, termasuk Gateway, Ingress, dan NEG mandiri. Jika Anda sering menskalakan beban kerja, cluster Anda berisiko lebih tinggi untuk terpengaruh.

Diagnosis:

Menghapus Pod di Kubernetes tanpa menghabiskan endpoint-nya dan menghapusnya dari NEG terlebih dahulu akan menyebabkan error seri 500. Untuk menghindari masalah selama penghentian Pod, Anda harus mempertimbangkan urutan operasi. Gambar berikut menampilkan skenario saat BackendService Drain Timeout tidak ditetapkan dan BackendService Drain Timeout ditetapkan dengan BackendConfig.

Catatan: Penyelesaian berikut tidak efektif dalam menyelesaikan error seri 500 lainnya yang dihasilkan dari preemption node atau Pod di GKE, terutama dalam kasus GKE dengan Spot VM dan preemptible VM.

Skenario 1: BackendService Drain Timeout tidak ditetapkan.

Gambar berikut menampilkan skenario saat BackendService Drain Timeout tidak ditetapkan.

Skenario 2: BackendService Drain Timeout ditetapkan.

Gambar berikut menampilkan skenario saat BackendService Drain Timeout ditetapkan.

Waktu terjadinya error seri 500 bergantung pada faktor-faktor berikut:

• Latensi pemisahan NEG API: Latensi pemisahan NEG API mewakili waktu saat ini yang diperlukan untuk menyelesaikan operasi pemisahan di Google Cloud. Hal ini dipengaruhi oleh berbagai faktor di luar Kubernetes, termasuk jenis load balancer dan zona tertentu.

• Latensi drain: Latensi drain adalah waktu yang diperlukan load balancer untuk mulai mengalihkan traffic dari bagian tertentu pada sistem Anda. Setelah drain dimulai, load balancer berhenti mengirim permintaan baru ke endpoint, tetapi masih ada latensi dalam memicu drain (latensi drain) yang dapat menyebabkan error 503 sementara jika Pod tidak ada lagi.

• Konfigurasi health check: Batas health check yang lebih sensitif mengurangi durasi error 503 karena dapat memberi sinyal kepada load balancer untuk berhenti mengirim permintaan ke endpoint meskipun operasi pemisahan belum selesai.

• Masa tenggang penghentian: Masa tenggang penghentian menentukan jumlah waktu maksimum yang diberikan Pod untuk keluar. Namun, Pod dapat keluar sebelum masa tenggang penghentian selesai. Jika Pod memerlukan waktu lebih lama dari periode ini, Pod akan dipaksa keluar pada akhir periode ini. Ini adalah setelan di Pod dan harus dikonfigurasi dalam definisi beban kerja.

Kemungkinan penyelesaian:

Untuk mencegah error 5XX tersebut, terapkan setelan berikut. Nilai waktu tunggu adalah sugestif dan Anda mungkin perlu menyesuaikannya untuk aplikasi tertentu. Bagian berikut akan memandu Anda dalam proses penyesuaian.

Gambar berikut menampilkan cara menjaga Pod tetap aktif dengan hook preStop:

Untuk menghindari error seri 500, lakukan langkah-langkah berikut:

1. Tetapkan BackendService Drain Timeout untuk layanan Anda ke 1 menit.

   Catatan: Jika waktu permintaan rata-rata Anda lebih dari 30 detik, lihat Menyesuaikan waktu tunggu untuk menyesuaikan BackendService Drain Timeout.

   • Untuk Pengguna Ingress, lihat menetapkan waktu tunggu di BackendConfig.

   • Untuk Pengguna Gateway, lihat mengonfigurasi waktu tunggu di GCPBackendPolicy.

   • Untuk pengguna yang mengelola BackendServices secara langsung saat menggunakan NEG mandiri, lihat menetapkan waktu tunggu langsung di Layanan Backend.

2. Perluas terminationGracePeriod di Pod.

   Tetapkan terminationGracePeriodSeconds di Pod ke 3,5 menit. Jika digabungkan dengan setelan yang direkomendasikan, hal ini akan memberi Pod Anda periode waktu 30 hingga 45 detik untuk penonaktifan yang mulus setelah endpoint Pod dihapus dari NEG. Jika memerlukan lebih banyak waktu untuk penonaktifan yang wajar, Anda dapat memperluas masa tenggang atau mengikuti petunjuk yang disebutkan di bagian Menyesuaikan waktu tunggu.

   Manifes Pod berikut menentukan waktu tunggu pengosongan koneksi selama 210 detik (3,5 menit):

   spec:
     terminationGracePeriodSeconds: 210
     containers:
     - name: my-app
       ...
     ...
   

3. Terapkan hook preStop ke semua penampung.

   Terapkan hook preStop yang akan memastikan Pod aktif selama 120 detik lebih lama saat endpoint Pod dikosongkan di load balancer dan endpoint dihapus dari NEG.

   Catatan: Terapkan hook preStop ke setiap penampung di Pod Anda. Penampung tanpa hook akan keluar segera setelah Pod dihapus. Jika Anda menggunakan alat yang memasukkan penampung, pastikan penampung yang dimasukkan akan memiliki hook preStop yang diperlukan.

   spec:
     containers:
     - name: my-app
       ...
       lifecycle:
         preStop:
           exec:
             command: ["/bin/sh", "-c", "sleep 120s"]
     ...
   

Menyesuaikan waktu tunggu

Untuk memastikan kontinuitas Pod dan mencegah error seri 500, Pod harus aktif hingga endpoint dihapus dari NEG. Secara khusus untuk mencegah error 502 dan 503, pertimbangkan untuk menerapkan kombinasi waktu tunggu dan hook preStop.

Catatan: Jika konfigurasi health check disetel untuk mendeteksi kegagalan dengan segera, hal ini dapat menyebabkan load balancer berhenti mengirim permintaan lebih cepat, sehingga berpotensi mengurangi terjadinya error 503. Namun, perhatikan bahwa error 503 mungkin masih terjadi selama durasi nilai minimum yang tidak sehat. Anda harus memahami bahwa mengonfigurasi health check tidak akan mencegah error 502, yang terjadi saat koneksi yang ada dihentikan sebelum waktunya.

Agar Pod tetap aktif lebih lama selama proses penonaktifan, tambahkan hook preStop ke Pod. Jalankan hook preStop sebelum Pod diberi sinyal untuk keluar, sehingga hook preStop dapat digunakan untuk menjaga Pod tetap aktif hingga endpoint yang sesuai dihapus dari NEG.

Untuk memperpanjang durasi Pod tetap aktif selama proses penonaktifan, masukkan hook preStop ke dalam konfigurasi Pod sebagai berikut:

spec:
  containers:
  - name: my-app
    ...
    lifecycle:
      preStop:
        exec:
          command: ["/bin/sh", "-c", "sleep <latency time>"]

Catatan: Di Pod multi-penampung, pastikan Anda menambahkan hook preStop ke setiap penampung agar semua penampung tetap aktif. Hanya penampung dengan hook yang berjalan, dan perhentian lainnya. Jika Anda menggunakan alat yang menambahkan penampung, pastikan penampung yang ditambahkan tersebut juga memiliki hook preStop yang diperlukan.

Anda dapat mengonfigurasi waktu tunggu dan setelan terkait untuk mengelola penonaktifan Pod secara halus selama penskalaan turun beban kerja. Anda dapat menyesuaikan waktu tunggu berdasarkan kasus penggunaan tertentu. Sebaiknya mulai dengan waktu tunggu yang lebih lama dan kurangi durasi jika diperlukan. Anda dapat menyesuaikan waktu tunggu dengan mengonfigurasi parameter terkait waktu tunggu dan hook preStop dengan cara berikut:

Waktu Tunggu Pengosongan Layanan Backend

Parameter Backend Service Drain Timeout tidak ditetapkan secara default dan tidak berpengaruh. Jika Anda menetapkan parameter Backend Service Drain Timeout dan mengaktifkannya, load balancer akan berhenti merutekan permintaan baru ke endpoint dan menunggu waktu tunggu habis sebelum menghentikan koneksi yang ada.

Anda dapat menetapkan parameter Backend Service Drain Timeout menggunakan BackendConfig dengan Ingress, GCPBackendPolicy dengan Gateway, atau secara manual di BackendService dengan NEG mandiri. Waktu tunggu harus 1,5 hingga 2 kali lebih lama dari waktu yang diperlukan untuk memproses permintaan. Hal ini memastikan bahwa jika permintaan datang tepat sebelum pemborosan dimulai, permintaan tersebut akan selesai sebelum waktu tunggu selesai. Menetapkan parameter Backend Service Drain Timeout ke nilai yang lebih besar dari 0 membantu mengurangi error 503 karena tidak ada permintaan baru yang dikirim ke endpoint yang dijadwalkan untuk dihapus. Agar waktu tunggu ini efektif, Anda harus menggunakannya dengan hook preStop untuk memastikan Pod tetap aktif saat pemborosan terjadi. Tanpa kombinasi ini, permintaan yang ada yang tidak selesai akan menerima error 502.

preStop waktu hook

Hook preStop harus menunda penonaktifan Pod secara memadai agar latensi drain dan waktu tunggu drain layanan backend selesai, sehingga memastikan drain koneksi dan penghapusan endpoint yang tepat dari NEG sebelum Pod dinonaktifkan.

Untuk hasil yang optimal, pastikan waktu eksekusi hook preStop lebih besar dari atau sama dengan jumlah Backend Service Drain Timeout dan latensi drain.

Hitung waktu eksekusi hook preStop ideal Anda dengan rumus berikut:

preStop hook execution time >= BACKEND_SERVICE_DRAIN_TIMEOUT + DRAIN_LATENCY

Ganti kode berikut:

• BACKEND_SERVICE_DRAIN_TIMEOUT: waktu yang Anda konfigurasikan untuk Backend Service Drain Timeout.
• DRAIN_LATENCY: estimasi waktu untuk latensi pengosongan. Sebaiknya gunakan satu menit sebagai perkiraan Anda.

Jika error 500 terus berlanjut, estimasi total durasi kemunculan dan tambahkan dua kali waktu tersebut ke estimasi latensi drain. Hal ini memastikan bahwa Pod Anda memiliki waktu yang cukup untuk dikosongkan dengan baik sebelum dihapus dari layanan. Anda dapat menyesuaikan nilai ini jika terlalu lama untuk kasus penggunaan tertentu.

Atau, Anda dapat memperkirakan waktunya dengan memeriksa stempel waktu penghapusan dari Pod dan stempel waktu saat endpoint dihapus dari NEG di Cloud Audit Logs.

Parameter Masa Tenggang Penghentian

Anda harus mengonfigurasi parameter terminationGracePeriod untuk memberikan waktu yang memadai agar hook preStop selesai dan Pod menyelesaikan penghentian yang halus.

Secara default, jika tidak ditetapkan secara eksplisit, terminationGracePeriod adalah 30 detik. Anda dapat menghitung terminationGracePeriod yang optimal menggunakan formula:

terminationGracePeriod >= preStop hook time + Pod shutdown time

Untuk menentukan terminationGracePeriod dalam konfigurasi Pod sebagai berikut:

  spec:
    terminationGracePeriodSeconds: <terminationGracePeriod>
    containers:
    - name: my-app
      ...
    ...

NEG tidak ditemukan saat membuat resource Ingress Internal

Error berikut mungkin terjadi saat Anda membuat Ingress internal di GKE:

Error syncing: error running backend syncing routine: googleapi: Error 404: The resource 'projects/PROJECT_ID/zones/ZONE/networkEndpointGroups/NEG' was not found, notFound

Error ini terjadi karena Ingress untuk Load Balancer Aplikasi internal memerlukan Grup Endpoint Jaringan (NEG) sebagai backend.

Di lingkungan atau cluster VPC Bersama yang mengaktifkan Kebijakan Jaringan, tambahkan anotasi cloud.google.com/neg: '{"ingress": true}' ke manifes Layanan.

Waktu Tunggu Gateway 504: waktu tunggu permintaan upstream

Error berikut mungkin terjadi saat Anda mengakses Layanan dari Ingress internal di GKE:

HTTP/1.1 504 Gateway Timeout
content-length: 24
content-type: text/plain

upsteam request timeout

Error ini terjadi karena traffic yang dikirim ke Load Balancer Aplikasi internal di-proxy-kan oleh proxy envoy dalam rentang subnet khusus proxy.

Untuk mengizinkan traffic dari rentang subnet khusus proxy, buat aturan firewall di targetPort Layanan.

Error 400: Nilai tidak valid untuk kolom 'resource.target'

Error berikut mungkin terjadi saat Anda mengakses Layanan dari Ingress internal di GKE:

Error syncing:LB_NAME does not exist: googleapi: Error 400: Invalid value for field 'resource.target': 'https://www.googleapis.com/compute/v1/projects/PROJECT_NAME/regions/REGION_NAME/targetHttpProxies/LB_NAME. A reserved and active subnetwork is required in the same region and VPC as the forwarding rule.

Untuk mengatasi masalah ini, buat subnet khusus proxy.

Kesalahan selama sinkronisasi: kesalahan menjalankan rutinitas sinkronisasi load balancer: loadbalancer tidak tersedia

Salah satu error berikut mungkin terjadi ketika upgrade bidang kontrol GKE atau saat Anda memodifikasi objek Ingress:

"Error during sync: error running load balancer syncing routine: loadbalancer
INGRESS_NAME does not exist: invalid ingress frontend configuration, please
check your usage of the 'kubernetes.io/ingress.allow-http' annotation."

Atau:

Error during sync: error running load balancer syncing routine: loadbalancer LOAD_BALANCER_NAME does not exist:
googleapi: Error 400: Invalid value for field 'resource.IPAddress':'INGRESS_VIP'. Specified IP address is in-use and would result in a conflict., invalid

Untuk mengatasi masalah ini, coba langkah-langkah berikut:

• Tambahkan kolom hosts di bagian tls dari manifes Ingress, lalu hapus Ingress. Tunggu selama lima menit hingga GKE menghapus resource Ingress yang tidak digunakan. Kemudian, buat ulang Ingress. Untuk informasi selengkapnya, lihat Kolom host objek Ingress.
• Kembalikan perubahan yang Anda buat ke Ingress. Kemudian, tambahkan sertifikat menggunakan anotasi atau Secret Kubernetes.

Ingress Eksternal menghasilkan error HTTP 502

Gunakan panduan berikut untuk memecahkan masalah error HTTP 502 dengan resource Ingress eksternal:

1. Aktifkan log untuk setiap layanan backend yang terkait dengan setiap Layanan GKE yang direferensikan oleh Ingress.
2. Gunakan detail status untuk mengidentifikasi penyebab respons HTTP 502. Detail status yang menunjukkan bahwa respons HTTP 502 yang berasal dari backend memerlukan pemecahan masalah dalam Pod penyaluran, bukan load balancer.

Grup instance tidak terkelola

Anda mungkin mengalami error HTTP 502 dengan resource Ingress eksternal jika Ingress eksternal Anda menggunakan backend grup instance yang tidak dikelola. Masalah ini terjadi saat semua persyaratan berikut terpenuhi:

• Cluster memiliki jumlah total node yang besar di antara semua kumpulan node.
• Pod yang aktif untuk satu atau beberapa Layanan yang direferensikan oleh Ingress hanya terletak di beberapa node.
• Layanan yang dirujuk oleh Ingress menggunakan externalTrafficPolicy: Local.

Untuk menentukan apakah Ingress eksternal Anda menggunakan backend grup instance yang tidak dikelola, lakukan hal berikut:

1. Buka halaman Ingress di Konsol Google Cloud.

   Buka Ingress

2. Klik nama Ingress eksternal Anda.

3. Klik nama Load balancer. Halaman Detail load balancing ditampilkan.

4. Periksa tabel di bagian Layanan backend untuk menentukan apakah Ingress eksternal Anda menggunakan NEG atau grup instance.

Untuk mengatasi masalah ini, gunakan salah satu solusi berikut:

• Gunakan cluster native VPC.
• Gunakan externalTrafficPolicy: Cluster untuk setiap Layanan yang dirujuk oleh Ingress eksternal. Solusi ini menyebabkan Anda kehilangan alamat IP klien asli di sumber paket.
• Gunakan anotasi node.kubernetes.io/exclude-from-external-load-balancers=true. Tambahkan anotasi ke node atau kumpulan node yang tidak menjalankan Pod penayangan untuk Layanan apa pun yang direferensikan oleh Ingress eksternal atau Layanan LoadBalancer di cluster Anda.

Menggunakan log load balancer untuk memecahkan masalah

Anda dapat menggunakan log Load Balancer Jaringan passthrough internal dan log Load Balancer Jaringan passthrough eksternal untuk memecahkan masalah dengan load balancer dan menghubungkan dari load balancing hingga resource GKE.

Log digabungkan per koneksi dan diekspor hampir secara real time. Log dibuat untuk setiap node GKE yang terlibat di jalur data Layanan LoadBalancer, untuk traffic ingress dan egress. Entri log mencakup kolom tambahan untuk resource GKE, seperti:

• Nama cluster
• Lokasi cluster
• Nama layanan
• Namespace layanan
• Nama pod
• Namespace pod

Harga

Tidak ada biaya tambahan untuk menggunakan log. Berdasarkan cara Anda menyerap log, harga standar untuk Cloud Logging, BigQuery, atau Pub/Sub berlaku. Mengaktifkan log tidak berpengaruh pada performa load balancer.

Menggunakan alat diagnostik untuk memecahkan masalah

Alat diagnostik check-gke-ingress memeriksa resource Ingress untuk menemukan kesalahan konfigurasi umum. Anda dapat menggunakan alat check-gke-ingress dengan cara berikut:

• Jalankan alat command line gcpdiag di cluster Anda. Hasil traffic ingress muncul di bagian gke/ERR/2023_004 aturan pemeriksaan.
• Gunakan alat check-gke-ingress saja atau sebagai plugin kubectl dengan mengikuti petunjuk di check-gke-ingress.

Langkah selanjutnya

Jika Anda memerlukan bantuan tambahan, hubungi Cloud Customer Care.