Sorun giderme

Apigee Edge belgelerini görüntülüyorsunuz.
Apigee X belgelerine gidin. bilgi

Istio 404 (Bulunamadı) hatası

Istio'da 404 (Bulunamadı) hatasını ayıklamak sinir bozucu olabilir. Bu bilgiler, işlerin nerede yanlış gidebileceğini takip etmeye başlamanız için bir başlangıç noktası sunar.

Joker ağ geçidi çakışması

Joker karakter "*" ana makine değerini kullanan yalnızca bir ağ geçidi tanımı olabilir. Joker karakterli bir ağ geçidi içeren başka bir şey dağıttıysanız istemci çağrıları 404 durumuyla başarısız olur.

Örnek:

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

Bu durumda, çakışan ağ geçitelerinden birini silmeniz veya değiştirmeniz gerekir.

Rotanın başarısız olduğu yeri izleme

Istio, katmanları olan bir soğan (veya belki de bir dev) gibidir. 404 hatasında hata ayıklamanın sistematik bir yolu, hedeften dışarıya doğru çalışmaktır.

Arka uç iş yükü

İş yüküne sidecar'dan erişebildiğinizi doğrulayın:

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

Arka uç sidecar'ı

Hizmet adresinizi ayarlayın ve iş yükü pod'unun IP adresini alın.

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

Sidecar üzerinden iş yüküne erişme:

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

Alternatif olarak, Istio mTLS etkinse:

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

Ağ geçidi (veya bir ön uç yardımcı kapsayıcısı)

Hizmete ağ geçidinden erişme:

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

Alternatif olarak, Istio mTLS etkinse:

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

Eksik analizler

Analytics kullanıcı arayüzünde analizleri görmüyorsanız bunun olası nedenleri şunlar olabilir:

  • Apigee alımı birkaç dakika gecikebilir.
  • Envoy gRPC erişim günlüğü doğru şekilde yapılandırılmamış
  • Envoy, Uzak Hizmete erişemiyor
  • Uzaktan Servis yükleme işlemi başarısız oluyor

Eksik veya hatalı API anahtarı reddedilmiyor

API anahtarı doğrulama işlemi düzgün çalışmıyorsa olası nedenler şunlar olabilir:

Doğrudan proxy

ext-authz yapılandırmasını kontrol edin.

Sidecar
  • Dinleyicinin yakalama için yapılandırıldığından emin olun.
  • ext-authz yapılandırmasını kontrol edin.

Geçersiz istekler kontrol ediliyor ve izin veriliyor

  • Hata durumunda açılacak şekilde yapılandırılmış uzak hizmet
  • Envoy, RBAC kontrolleri için yapılandırılmamış

Bu sorunları nasıl gidereceğiniz hakkında bilgi edinmek için aşağıdaki Envoy dokümanı konusuna bakın: External Authorization (Harici Yetkilendirme) ve failure_mode_allow özelliğiyle ilgili bilgilere bakın. Bu özellik, hatalarda filtrenin davranışını değiştirmenize olanak tanır.

Eksik veya hatalı JWT'nin reddedilmemesi

Bunun olası nedeni, Envoy JWT filtresinin yapılandırılmamış olmasıdır.

Geçerli API anahtarı başarısız oluyor

Olası nedenler

  • Envoy, uzak hizmete erişemiyor
  • Kimlik bilgileriniz geçerli değil
  • Apigee API ürünü, hedef ve ortam için yapılandırılmamış

Sorun giderme adımları

Apigee'de API ürününüzü kontrol etme

  • Ortamınızda (test ve üretim) etkin mi?

    Ürün, Uzak Servisinizle aynı ortama bağlı olmalıdır.

  • Erişmek istediğiniz hedefe bağlı mı?

    Apigee uzak hizmet hedefleri bölümünü kontrol edin. Hizmet adının tam nitelikli bir ana makine adı olması gerektiğini unutmayın. Bu bir Istio hizmetiyse ad, helloworld.default.svc.cluster.localcode> gibi bir şey olur. Bu, default ad alanındaki helloworld hizmetini temsil eder.

  • Kaynak yolu, isteğinizle eşleşiyor mu?

    / veya /** gibi bir yolun tüm yollarla eşleşeceğini unutmayın. Eşleştirme için "*" veya "**" joker karakterlerini de kullanabilirsiniz.

  • Geliştirici uygulamanız var mı?

    API ürününün anahtarlarını kontrol etmek için bir geliştirici uygulamasına bağlı olması gerekir.

İsteğinizi kontrol edin

  • x-api-key header parametresinde tüketici anahtarını iletiyor musunuz?

    Örnek:

    curl http://localhost/hello -H "x-api-key: wwTcvmHvQ7Dui2qwj43GlKJAOwmo"
  • İyi bir tüketici anahtarı mı kullanıyorsunuz?

    Kullandığınız uygulamadaki kimlik bilgilerinin API ürününüz için onaylandığından emin olun.

Uzaktan hizmet günlüklerini kontrol etme

  1. Uzak hizmeti debug level konumunda günlüğe kaydetme ile başlatın. Uzak hizmet günlük kaydı düzeylerini ayarlama başlıklı makaleyi inceleyin.

    Komut satırında -l debug seçeneğini kullanın. Örneğin:

    apigee-remote-service-envoy -l debug
  2. Hedefinize erişmeyi deneyin ve günlükleri kontrol edin

    Günlüklerde aşağıdaki gibi bir satır olup olmadığını kontrol edin:

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

    3. Uzaktan hizmet günlük kaydı düzeylerini ayarlama

    Komut satırı işaretini kullanarak, ayrıntı düzeyine göre aşağıdaki hata ayıklama modlarından birinde uzak hizmeti başlatabilirsiniz. Burada debug en ayrıntılı, error ise en az ayrıntılı olan moddur:

    • debug: En ayrıntılı günlük kaydı modu.
    • info: Varsayılan ayardır.
    • warn
    • error: En az ayrıntılı günlük kaydı modu.

    Örneğin, hizmeti debug düzeyinde başlatmak için: 

    apigee-remote-service-envoy -l debug