Pemecahan masalah

Halaman ini berlaku untuk Apigee dan Apigee Hybrid.

Lihat dokumentasi Apigee Edge.

Error 404 (Tidak Ditemukan) Istio

Men-debug error 404 (Tidak Ditemukan) di Istio bisa membuat frustrasi. Semoga ini akan memberi Anda tempat untuk mulai melacak di mana saja yang mungkin salah.

Konflik Wildcard Gateway

Hanya boleh ada satu definisi Gateway yang menggunakan nilai host karakter pengganti "*". Jika Anda telah men-deploy hal lain yang menyertakan Gateway wildcard, panggilan klien akan gagal dengan status 404.

Contoh:

$ istioctl get gateways
GATEWAY NAME         HOSTS     NAMESPACE   AGE
bookinfo-gateway     *         default     20s
httpbin-gateway      *         default     3s

Jika ya, Anda harus menghapus atau mengubah salah satu gateway yang bertentangan.

Telusuri lokasi kegagalan rute

Istio seperti bawang (atau, mungkin, Ogre), memiliki banyak lapisan. Cara sistematis untuk men-debug error 404 adalah dengan bekerja dari target.

Workload backend

Pastikan Anda dapat mengakses beban kerja dari sidecar:

kubectl exec $WORKLOAD_POD -c istio-proxy -- curl localhost:80/headers

File bantuan backend

Tetapkan alamat layanan Anda dan dapatkan alamat IP pod workload.

SERVICE=httpbin.default.svc.cluster.local:80
  POD_IP=$(kubectl get pod $WORKLOAD_POD -o jsonpath='{.status.podIP}')

Mengakses workload melalui sidecar:

kubectl exec $WORKLOAD_POD -c istio-proxy -- curl -v http://$SERVICE/headers --resolve "$SERVICE:$POD_IP"

Atau, jika Istio mTLS diaktifkan:

kubectl exec $WORKLOAD_POD -c istio-proxy -- curl -v https://$SERVICE/headers --resolve "$SERVICE:$POD_IP" --key /etc/certs/key.pem --cert /etc/certs/cert-chain.pem --cacert /etc/certs/root-cert.pem --insecure

Gateway (atau sidecar frontend)

Akses layanan dari gateway:

kubectl -n istio-system exec $GATEWAY_POD -- curl -v http://$SERVICE/header

Atau, jika Istio mTLS diaktifkan:

kubectl -n istio-system exec $GATEWAY_POD -- curl -v https://$SERVICE/headers --key /etc/certs/key.pem --cert /etc/certs/cert-chain.pem --cacert /etc/certs/root-cert.pem --insecure

Analisis tidak ada

Jika Anda tidak melihat analisis di UI Analytics, pertimbangkan kemungkinan penyebab berikut:

  • Penyerapan Apigee dapat tertunda beberapa menit
  • Log Akses gRPC Envoy tidak dikonfigurasi dengan benar
  • Envoy tidak dapat menjangkau Layanan Jarak Jauh
  • Layanan Jarak Jauh gagal mengupload

Kunci API yang tidak ada atau salah tidak ditolak

Jika validasi kunci API tidak berfungsi dengan baik, pertimbangkan kemungkinan penyebab berikut:

Proxy langsung

Periksa konfigurasi ext-authz.

Sidecar
  • Pastikan pemroses dikonfigurasi untuk mencegat.
  • Periksa konfigurasi ext-authz.

Permintaan tidak valid sedang diperiksa dan diizinkan

  • Layanan Jarak Jauh dikonfigurasi untuk fail open
  • Envoy tidak dikonfigurasi untuk pemeriksaan RBAC

Untuk mengetahui informasi tentang cara mengatasi masalah ini, lihat topik dokumentasi Envoy berikut: Otorisasi Eksternal, dan lihat informasi tentang properti failure_mode_allow. Properti ini memungkinkan Anda mengubah perilaku filter saat terjadi error.

JWT yang tidak ada atau buruk tidak ditolak

Kemungkinan penyebabnya adalah filter JWT Envoy tidak dikonfigurasi.

Kunci API yang valid gagal

Kemungkinan penyebab

  • Envoy tidak dapat menjangkau layanan jarak jauh
  • Kredensial Anda tidak valid
  • Produk API Apigee tidak dikonfigurasi untuk target dan lingkungan
  • Envoy tidak mengetahui Produk API Apigee

Langkah pemecahan masalah

Periksa Produk API Anda di Apigee

  • Apakah diaktifkan untuk lingkungan Anda (pengujian vs. produksi)?

    Produk harus terikat ke lingkungan yang sama dengan Layanan Jarak Jauh Anda.

  • Apakah terikat ke target yang Anda akses?

    Periksa bagian target layanan jarak jauh Apigee. Ingat, nama layanan harus berupa nama host yang sepenuhnya memenuhi syarat. Jika merupakan layanan Istio, namanya akan seperti helloworld.default.svc.cluster.localcode> - yang merepresentasikan layanan helloworld di namespace default.

  • Apakah Jalur Resource cocok dengan permintaan Anda?

    Ingat, jalur seperti / atau /** akan cocok dengan jalur apa pun. Anda juga dapat menggunakan karakter pengganti '*' atau '**' untuk pencocokan.

  • Apakah Anda memiliki Aplikasi Developer?

    Produk API harus terikat ke Aplikasi Developer untuk memeriksa kuncinya.

  • Apakah operationConfigType Produk API Apigee ditetapkan ke remoteservice?

    Periksa konfigurasi Produk API menggunakan Apigee Management API, dan pastikan operationConfigType disetel ke remoteservice.

Periksa permintaan Anda

  • Apakah Anda meneruskan Kunci Konsumen di x-api-key header

    Contoh:

    curl http://localhost/hello -H "x-api-key: wwTcvmHvQ7Dui2qwj43GlKJAOwmo"
  • Apakah Anda menggunakan Kunci Konsumen yang valid?

    Pastikan Kredensial dari Aplikasi yang Anda gunakan disetujui untuk Produk API Anda.

Periksa log Layanan Jarak Jauh

  1. Mulai Layanan Jarak Jauh dengan logging di debug level. Lihat Menetapkan tingkat log layanan jarak jauh.

    Gunakan opsi -l debug di command line. Contoh:

    apigee-remote-service-envoy -l debug
  2. Coba akses target Anda dan periksa log

    Periksa log untuk menemukan baris yang terlihat seperti ini:

    Resolve api: helloworld.default.svc.cluster.local, path: /hello, scopes: []
Selected: [helloworld]
Eliminated: [helloworld2 doesn't match path: /hello]

Menetapkan tingkat log layanan jarak jauh

Dengan menggunakan tanda command line, Anda dapat memulai layanan jarak jauh dalam salah satu mode debug berikut, dalam urutan kejelasan, dengan debug adalah yang paling jelas dan error adalah yang paling tidak jelas:

  • debug - Mode logging paling panjang.
  • info - Default.
  • warn
  • error - Mode logging paling tidak panjang.

Misalnya, untuk memulai layanan di tingkat debug: 

apigee-remote-service-envoy -l debug