Memecahkan masalah GKE Ingress

Masalah pada Ingress di Google Kubernetes Engine (GKE) dapat mencegah traffic eksternal atau internal mencapai layanan Anda.

Gunakan dokumen ini untuk menemukan solusi bagi error yang terkait dengan class Ingress, anotasi IP statis, ukuran kunci sertifikat, dan interaksi dengan tingkat jaringan.

Informasi ini ditujukan bagi admin dan operator Platform serta Developer aplikasi yang men-deploy dan mengelola aplikasi yang diekspos menggunakan Ingress di GKE. Untuk mengetahui informasi selengkapnya tentang peran umum dan contoh tugas yang kami referensikan dalam konten Google Cloud , lihat Peran dan tugas pengguna GKE umum.

Anotasi yang salah untuk class Ingress

Gejala

Saat membuat Ingress, Anda mungkin melihat error berikut:

Missing one or more resources. If resource creation takes longer than expected, you might have an invalid configuration.

Kemungkinan penyebab

Saat membuat Ingress, Anda mungkin salah mengonfigurasi class Ingress dalam manifes.

Resolusi

Untuk menentukan class Ingress, Anda harus menggunakan anotasi kubernetes.io/ingress.class. Anda tidak dapat menentukan Ingress GKE menggunakan spec.ingressClassName.

  • Untuk men-deploy Load Balancer Aplikasi internal, gunakan anotasi kubernetes.io/ingress.class: gce-internal.
  • Untuk men-deploy Load Balancer Aplikasi eksternal, gunakan anotasi kubernetes.io/ingress.class: gce.

Anotasi yang salah untuk alamat IP statis

Gejala

Saat mengonfigurasi Ingress eksternal untuk menggunakan alamat IP statis, Anda mungkin melihat error berikut:

Error syncing to GCP: error running load balancer syncing routine: loadbalancer <Name of load balancer> does not exist: the given static IP name <Static IP> doesn't translate to an existing static IP.

Kemungkinan penyebab

  • Anda tidak membuat alamat IP eksternal statis sebelum men-deploy Ingress.
  • Anda tidak menggunakan anotasi yang benar untuk jenis Load Balancer Anda.

Resolusi

Jika Anda mengonfigurasi Ingress eksternal:

Jika Anda mengonfigurasi Ingress internal:

  • Cadangkan alamat IP internal statis regional sebelum Anda men-deploy Ingress.
  • Gunakan anotasi kubernetes.io/ingress.regional-static-ip-name pada resource Ingress Anda.

Alamat IP statis sudah digunakan

Gejala

Anda mungkin melihat error berikut saat menentukan alamat IP statis untuk menyediakan resource Ingress internal atau eksternal:

Error syncing to GCP: error running load balancer syncing
routine: loadbalancer <LB name> does not exist:
googleapi: Error 409: IP_IN_USE_BY_ANOTHER_RESOURCE - IP ''<IP address>'' is already being used by another resource.

Kemungkinan penyebab

Alamat IP statis sudah digunakan oleh resource lain.

Error saat menonaktifkan HTTP dan menggunakan sertifikat yang dikelola Google

Gejala

Jika Anda mengonfigurasi sertifikat SSL yang dikelola Google dan menonaktifkan traffic HTTP di Ingress, Anda akan melihat error berikut:

Error syncing to GCP: error running load balancer syncing
routine: loadbalancer <Load Balancer name> does not exist:
googleapi: Error 404: The resource ''projects/<Project>/global/sslPolicies/<Policy name>' was not found, notFound

Kemungkinan penyebab

Anda tidak dapat menggunakan anotasi berikut secara bersamaan saat mengonfigurasi Ingress:

  • networking.gke.io/managed-certificates (untuk mengaitkan sertifikat yang dikelola Google dengan Ingress)
  • kubernetes.io/ingress.allow-http: false (untuk menonaktifkan traffic HTTP)

Resolusi

Nonaktifkan traffic HTTP hanya setelah Load Balancer Aplikasi eksternal diprogram sepenuhnya. Anda dapat memperbarui Ingress dan menambahkan anotasi kubernetes.io/ingress.allow-http: false ke manifes.

Subnet khusus proxy tidak ada untuk Ingress internal

Gejala

Saat men-deploy Ingress untuk Load Balancer Aplikasi internal, Anda mungkin melihat error berikut:

Error syncing to GCP: error running load balancer syncing routine:
loadbalancer <LB name> does not exist: googleapi: Error 400: Invalid value for field 'resource.target': 'https://www.googleapis.com/compute/v1/projects/<Project ID>/regions/<Region>/targetHttpsProxies/<Target proxy>'.
An active proxy-only subnetwork is required in the same region and VPC as
the forwarding rule.

Kemungkinan penyebab

Anda tidak membuat subnet khusus proxy sebelum membuat resource Ingress. Subnet khusus proxy diperlukan untuk Load Balancer Aplikasi internal.

Resolusi

Buat subnet khusus proxy sebelum men-deploy Ingress internal.

Kunci sertifikat SSL terlalu besar

Gejala

Jika ukuran kunci sertifikat SSL load balancer Anda terlalu besar, Anda mungkin melihat error berikut:

Error syncing to GCP: error running load balancer syncing routine: loadbalancer gky76k70-load-test-trillian-api-ingress-fliismmb does not exist: Cert creation failures - k8s2-cr-gky76k70-znz6o1pfu3tfrguy-f9be3a4abbe573f7 Error:googleapi: Error 400: The SSL key is too large., sslCertificateKeyTooLarge

Kemungkinan penyebab

Google Cloud memiliki batas 2.048 bit untuk kunci sertifikat SSL.

Resolusi

Kurangi ukuran kunci sertifikat SSL menjadi 2.048 bit atau kurang.

Error saat membuat Ingress di Tingkat Standar

Gejala

Jika Anda men-deploy Ingress dalam project dengan tingkat jaringan default project ditetapkan ke Standard, pesan error berikut akan muncul:

Error syncing to GCP: error running load balancer syncing routine: load balancer <LB Name> does not exist: googleapi: Error 400: STANDARD network tier (the project''s default network tier) is not supported: STANDARD network tier is not supported for global forwarding rule., badRequest

Resolusi

Konfigurasi tingkat jaringan default project ke Premium.

Error 'Tidak Ditemukan' yang Diharapkan untuk k8s-ingress-svc-acct-permission-check-probe

Pengontrol Ingress melakukan pemeriksaan izin akun layanan secara berkala dengan mengambil resource pengujian dari project Google Cloud Anda. Anda akan melihat ini sebagai GET dari BackendService global (yang tidak ada) dengan nama k8s-ingress-svc-acct-permission-check-probe. Karena resource ini biasanya tidak ada, permintaan GET akan menampilkan "not found". Hal ini wajar; pengontrol memeriksa bahwa panggilan API tidak ditolak karena masalah otorisasi. Jika Anda membuat BackendService dengan nama yang sama, maka GET akan berhasil, alih-alih menampilkan "not found".

Error saat menggunakan load balancing berbasis container

Gunakan teknik berikut untuk memverifikasi konfigurasi jaringan Anda. Bagian berikut menjelaskan cara menyelesaikan masalah tertentu terkait load balancing berbasis container.

  • Lihat dokumentasi load balancing untuk mengetahui cara mencantumkan grup endpoint jaringan Anda.

  • Anda dapat menemukan nama dan zona NEG yang sesuai dengan layanan dalam anotasi neg-status layanan. Dapatkan spesifikasi Layanan dengan:

    kubectl get svc SVC_NAME -o yaml

    Anotasi metadata:annotations:cloud.google.com/neg-status mencantumkan nama NEG yang terkait dengan layanan dan zona NEG.

  • Anda dapat memeriksa responsivitas layanan backend yang sesuai dengan NEG menggunakan perintah berikut:

    gcloud compute backend-services --project PROJECT_NAME \
    get-health BACKEND_SERVICE_NAME --global

    Layanan backend memiliki nama yang sama dengan NEG-nya.

  • Untuk mencetak log aktivitas layanan:

    kubectl describe svc SERVICE_NAME

    String nama layanan mencakup nama dan namespace Layanan GKE yang terkait.

Tidak dapat membuat cluster dengan IP alias

Gejala

Saat mencoba membuat cluster dengan IP alias, Anda mungkin mengalami error berikut:

ResponseError: code=400, message=IP aliases cannot be used with a legacy network.
Kemungkinan penyebab

Anda mengalami error ini jika mencoba membuat cluster dengan IP alias yang juga menggunakan jaringan lama.

Resolusi

Pastikan Anda tidak membuat cluster dengan IP alias dan jaringan lama yang diaktifkan secara bersamaan. Untuk mengetahui informasi selengkapnya tentang penggunaan IP alias, lihat Membuat cluster VPC native.

Traffic tidak mencapai endpoint

Gejala
Error 502/503 atau koneksi ditolak.
Kemungkinan penyebab

Endpoint baru umumnya dapat dijangkau setelah memasangkan endpoint tersebut ke load balancer, asalkan endpoint itu merespons health check. Anda mungkin mengalami error 502 atau koneksi ditolak jika traffic tidak dapat mencapai endpoint.

Error 502 dan koneksi yang ditolak juga dapat disebabkan oleh container yang tidak menangani SIGTERM. Jika container tidak menangani SIGTERM secara eksplisit, container tersebut akan segera menghentikan dan berhenti menangani permintaan. Load balancer terus mengirim traffic masuk ke container yang dihentikan, sehingga menyebabkan error.

Load balancer berbasis container hanya memiliki satu endpoint backend. Selama update berkelanjutan, endpoint lama di-deprogram sebelum endpoint baru diprogram.

Pod Backend akan di-deploy ke zona baru untuk pertama kalinya setelah load balancer berbasis container disediakan. Infrastruktur load balancer diprogram di zona saat setidaknya ada satu endpoint di zona tersebut. Saat endpoint baru ditambahkan ke suatu zona, infrastruktur load balancer diprogram dan menyebabkan gangguan layanan.

Resolusi

Konfigurasikan container untuk menangani SIGTERM dan terus respons permintaan selama masa tenggang penghentian (30 detik secara default). Konfigurasi Pod untuk mulai gagal dalam health check saat menerima SIGTERM. Sinyal ini akan memberi tahu load balancer untuk berhenti mengirim traffic ke Pod saat proses deprogram endpoint sedang berlangsung.

Jika aplikasi Anda tidak dinonaktifkan dengan baik dan berhenti merespons permintaan saat menerima SIGTERM, hook preStop dapat digunakan untuk menangani SIGTERM dan tetap menyalurkan traffic saat proses deprogram endpoint sedang berlangsung.

lifecycle:
  preStop:
    exec:
      # if SIGTERM triggers a quick exit; keep serving traffic instead
      command: ["sleep","60"]

Lihat dokumentasi tentang penghentian Pod.

Jika backend load balancer hanya memiliki satu instance, konfigurasi strategi peluncuran agar tidak menghilangkan satu-satunya instance sebelum instance baru diprogram sepenuhnya. Untuk pod aplikasi yang dikelola oleh workload Deployment, hal ini dapat dicapai dengan mengonfigurasi strategi peluncuran dengan parameter maxUnavailable yang setara dengan 0.

strategy:
  rollingUpdate:
    maxSurge: 1
    maxUnavailable: 0

Untuk memecahkan masalah traffic yang tidak mencapai endpoint, pastikan aturan firewall mengizinkan traffic TCP masuk ke endpoint Anda dalam rentang 130.211.0.0/22 dan 35.191.0.0/16. Untuk mempelajari lebih lanjut, lihat Menambahkan Health Check di dokumentasi Cloud Load Balancing.

Lihat layanan backend di project Anda. String nama layanan backend yang relevan mencakup nama dan namespace Layanan GKE yang sesuai:

gcloud compute backend-services list

Ambil status respons backend dari layanan backend:

gcloud compute backend-services get-health BACKEND_SERVICE_NAME

Jika semua backend tidak responsif, firewall, Ingress, atau Layanan Anda mungkin salah dikonfigurasi.

Jika beberapa backend tidak responsif dalam waktu singkat, kemungkinan penyebabnya adalah latensi pemrograman jaringan.

Jika beberapa backend tidak muncul dalam daftar layanan backend, kemungkinan penyebabnya adalah latensi pemrograman. Anda dapat memverifikasinya dengan menjalankan perintah berikut, dengan NEG_NAME adalah nama layanan backend. (NEG dan layanan backend menggunakan nama yang sama):

gcloud compute network-endpoint-groups list-network-endpoints NEG_NAME

Periksa apakah semua endpoint yang diharapkan ada di NEG.

Jika Anda memiliki sedikit backend (misalnya, 1 Pod) yang dipilih oleh load balancer berbasis container, sebaiknya tingkatkan jumlah replika dan distribusikan Pod backend di semua zona yang dicakup cluster GKE. Tindakan ini akan memastikan infrastruktur load balancer dasar sudah diprogram sepenuhnya. Jika tidak, pertimbangkan untuk membatasi Pod backend ke satu zona.

Jika Anda mengonfigurasi kebijakan jaringan untuk endpoint, pastikan ingress dari subnet Khusus proxy diizinkan.

Peluncuran terhenti

Gejala
Peluncuran Deployment yang diupdate terhenti, dan jumlah replika terbaru tidak sesuai dengan jumlah replika yang dipilih.
Kemungkinan penyebab

Health check deployment gagal. Image container mungkin buruk atau health check mungkin salah dikonfigurasi. Penggantian peluncuran Pod menunggu hingga Pod yang baru dimulai lulus gate kesiapan Pod-nya. Ini hanya terjadi jika Pod merespons health check load balancer. Jika Pod tidak merespons, atau jika health check salah dikonfigurasi, kondisi gate kesiapan tidak dapat dipenuhi dan peluncuran tidak dapat dilanjutkan.

Jika menggunakan kubectl 1.13 atau yang lebih tinggi, Anda dapat memeriksa status gateway kesiapan Pod dengan perintah berikut:

kubectl get pod POD_NAME -o wide

Periksa kolom READINESS GATES.

Kolom ini tidak ada di kubectl 1.12 dan versi sebelumnya. Pod yang ditandai sebagai berada dalam status READY mungkin memiliki gate kesiapan yang gagal. Untuk memastikannya, gunakan perintah berikut:

kubectl get pod POD_NAME -o yaml

Gate kesiapan dan statusnya tercantum di output.

Resolusi

Verifikasi bahwa image container di spesifikasi Pod Deployment Anda berfungsi dengan benar dan dapat merespons health check. Pastikan health check dikonfigurasi dengan benar.

Error mode yang mengalami penurunan kualitas

Gejala

Mulai dari GKE versi 1.29.2-gke.1643000, Anda mungkin mendapatkan peringatan berikut pada layanan Anda di Logs Explorer saat NEG diperbarui:

Entering degraded mode for NEG <service-namespace>/<service-name>-<neg-name>... due to sync err: endpoint has missing nodeName field
Kemungkinan penyebab

Peringatan ini menunjukkan bahwa GKE telah mendeteksi kesalahan konfigurasi endpoint selama update NEG berdasarkan objek EndpointSlice, yang memicu proses penghitungan yang lebih mendalam yang disebut mode berperforma buruk. GKE terus memperbarui NEG atas dasar upaya terbaik, dengan memperbaiki kesalahan konfigurasi atau mengecualikan endpoint yang tidak valid dari update NEG.

Beberapa kesalahan umum adalah:

  • endpoint has missing pod/nodeName field
  • endpoint corresponds to an non-existing pod/node
  • endpoint information for attach/detach operation is incorrect
Resolusi

Biasanya, status sementara menyebabkan peristiwa ini dan diperbaiki dengan sendirinya. Namun, peristiwa yang disebabkan oleh kesalahan konfigurasi pada objek EndpointSlice kustom tetap belum terselesaikan. Untuk memahami kesalahan konfigurasi, periksa objek EndpointSlice yang sesuai dengan layanan:

kubectl get endpointslice -l kubernetes.io/service-name=<service-name>

Validasi setiap endpoint berdasarkan error dalam peristiwa.

Untuk mengatasi masalah ini, Anda harus mengubah objek EndpointSlice secara manual. Pembaruan ini memicu NEG untuk diperbarui lagi. Setelah kesalahan konfigurasi tidak ada lagi, outputnya akan mirip dengan berikut ini:

NEG <service-namespace>/<service-name>-<neg-name>... is no longer in degraded mode

Error saat menggunakan sertifikat SSL yang dikelola Google

Bagian ini memberikan informasi tentang cara menyelesaikan masalah terkait sertifikat yang dikelola Google.

Memeriksa peristiwa pada resource ManagedCertificate dan Ingress

Jika Anda melampaui jumlah sertifikat yang diizinkan, peristiwa dengan alasan TooManyCertificates akan ditambahkan ke ManagedCertificate. Anda dapat memeriksa peristiwa pada objek ManagedCertificate menggunakan perintah berikut:

kubectl describe managedcertificate CERTIFICATE_NAME

Ganti CERTIFICATE_NAME dengan nama ManagedCertificate Anda.

Jika Anda memasang ManagedCertificate yang tidak ada ke Ingress, peristiwa dengan alasan MissingCertificate akan ditambahkan ke Ingress. Anda dapat memeriksa peristiwa di Ingress menggunakan perintah berikut:

kubectl describe ingress INGRESS_NAME

Ganti INGRESS_NAME dengan nama Ingress Anda.

Sertifikat terkelola tidak disediakan saat domain me-resolve ke alamat IP dari beberapa load balancer

Saat domain Anda me-resolve ke alamat IP dari beberapa load balancer (beberapa objek Ingress), Anda harus membuat satu objek ManagedCertificate dan memasangnya ke semua objek Ingress. Jika Anda membuat banyak objek ManagedCertificate dan melampirkan masing-masing objek tersebut ke Ingress yang terpisah, Certificate Authority mungkin tidak dapat memverifikasi kepemilikan domain Anda dan beberapa sertifikat mungkin tidak akan disediakan. Agar verifikasi berhasil, sertifikat harus terlihat pada semua alamat IP yang menjadi tujuan resolve domain Anda.

Khususnya, saat domain Anda me-resolve ke alamat IPv4 dan IPv6 yang dikonfigurasi dengan objek Ingress yang berbeda, Anda harus membuat satu objek ManagedCertificate dan memasangnya ke kedua Ingress tersebut.

Komunikasi antara sertifikat yang dikelola Google dan Ingress terganggu

Sertifikat terkelola berkomunikasi dengan Ingress menggunakan anotasi ingress.gcp.kubernetes.io/pre-shared-cert. Anda dapat mengganggu komunikasi ini jika Anda, misalnya:

  • Menjalankan proses otomatis yang menghapus anotasi ingress.gcp.kubernetes.io/pre-shared-cert.
  • Menyimpan snapshot Ingress, lalu menghapus dan memulihkan Ingress tersebut dari snapshot. Sementara itu, resource SslCertificate yang tercantum dalam anotasi ingress.gcp.kubernetes.io/pre-shared-cert mungkin telah dihapus. Ingress tidak akan berfungsi jika sertifikat yang dipasang ke Ingress tidak ada.

Jika komunikasi antara sertifikat yang dikelola Google dan Ingress terganggu, hapus konten anotasi ingress.gcp.kubernetes.io/pre-shared-cert dan tunggu hingga sistem direkonsiliasi. Untuk mencegah terulangnya masalah ini, pastikan anotasi tidak dimodifikasi atau dihapus secara tidak sengaja.

Error validasi saat membuat sertifikat yang dikelola Google

Definisi ManagedCertificate divalidasi sebelum objek ManagedCertificate dibuat. Jika validasi gagal, objek ManagedCertificate tidak dibuat dan pesan error akan dicetak. Berbagai pesan error dan alasannya dijelaskan sebagai berikut:

spec.domains in body should have at most 100 items

Manifes ManagedCertificate Anda mencantumkan lebih dari 100 domain di kolom spec.domains. Sertifikat yang dikelola Google hanya mendukung maksimal 100 domain.

spec.domains in body should match '^(([a-zA-Z0-9]+|[a-zA-Z0-9][-a-zA-Z0-9]*[a-zA-Z0-9])\.)+[a-zA-Z][-a-zA-Z0-9]*[a-zA-Z0-9]\.?$'

Anda menentukan nama domain yang tidak valid atau nama domain dengan karakter pengganti di kolom spec.domains. Objek ManagedCertificate tidak mendukung domain dengan karakter pengganti (misalnya, *.example.com).

spec.domains in body should be at most 63 chars long

Nama domain yang Anda tentukan terlalu panjang. Sertifikat yang dikelola Google mendukung nama domain yang memiliki maksimal 63 karakter.

Memperbarui sertifikat yang dikelola Google secara manual

Untuk memperbarui sertifikat secara manual agar sertifikat untuk domain lama terus berfungsi hingga sertifikat untuk domain baru disediakan, ikuti langkah-langkah berikut:

  1. Buat ManagedCertificate untuk domain baru.
  2. Tambahkan nama ManagedCertificate ke anotasi networking.gke.io/managed-certificates di Ingress menggunakan daftar yang dipisahkan koma. Jangan menghapus nama sertifikat lama.
  3. Tunggu hingga ManagedCertificate menjadi Aktif.
  4. Lepaskan sertifikat lama dari Ingress dan hapus sertifikat tersebut.

Saat Anda membuat ManagedCertificate, Google Cloud akan membuat sertifikat SSL yang dikelola Google. Anda tidak dapat memperbarui sertifikat ini. Jika Anda memperbarui ManagedCertificate, Google Cloud akan menghapus dan membuat ulang sertifikat SSL yang dikelola Google.

Guna menyediakan Ingress terenkripsi HTTPS yang aman untuk cluster GKE, silakan melihat contoh Ingress yang Aman.

Langkah berikutnya