Rozwiązywanie problemów

Wyświetlasz dokumentację Apigee Edge.
Przejdź do dokumentacji Apigee X. info

Błąd Istio 404 (nie znaleziono)

Debugowanie błędu 404 (nie znaleziono) w Istio może być frustrujące. Mamy nadzieję, że pomoże Ci to w ustaleniu, gdzie może występować problem.

Konflikt bramy z symbolem wieloznacznym

Może istnieć tylko 1 definicja bramy, która używa wartości hostów z symbolem wieloznacznym „*”. Jeśli wdrożysz coś innego, co zawiera bramę z symbolem wieloznacznym, wywołania klienta będą kończyć się niepowodzeniem ze stanem 404.

Przykład:

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

W takim przypadku musisz usunąć lub zmienić jedną z powodujących konflikt bram.

Śledzenie, gdzie występuje błąd trasy

Istio jest jak cebula (lub, być może, jak ogr) – ma warstwy. Systematyczny sposób debugowania błędu 404 polega na pracy od celu na zewnątrz.

Zbiór zadań backendu

Sprawdź, czy możesz uzyskać dostęp do zbioru zadań z sidecara:

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

Sidecar backendu

Ustaw adres świadczenia usługi i pobierz adres IP poda zbioru zadań.

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

Uzyskaj dostęp do zbioru zadań przez sidecar:

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

Lub, jeśli włączono Istio mTLS:

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

Brama (lub sidecar frontendu)

Uzyskaj dostęp do usługi z bramy:

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

Lub, jeśli włączono Istio mTLS:

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

Brakujące dane analityczne

Jeśli nie widzisz danych analitycznych w interfejsie danych analitycznych, sprawdź te możliwe przyczyny:

  • Przyjmowanie danych w Apigee może potrwać kilka minut.
  • Dziennik dostępu gRPC Envoy nie jest prawidłowo skonfigurowany.
  • Envoy nie może nawiązać połączenia z usługą zdalną.
  • Usługa zdalna nie może przesłać danych.

Brakujący lub nieprawidłowy klucz interfejsu API nie jest odrzucany

Jeśli weryfikacja klucza interfejsu API nie działa prawidłowo, sprawdź te możliwe przyczyny:

Bezpośredni serwer proxy

Sprawdź konfigurację ext-authz.

Sidecar
  • Upewnij się, że odbiornik jest skonfigurowany do przechwytywania.
  • Sprawdź konfigurację ext-authz.

Nieprawidłowe żądania są sprawdzane i dozwolone

  • Usługa zdalna skonfigurowana do otwierania w przypadku awarii
  • Envoy nie jest skonfigurowany do sprawdzania RBAC

Informacje o tym, jak rozwiązać te problemy, znajdziesz w tym artykule w dokumentacji Envoy: External Authorization (Autoryzacja zewnętrzna), oraz w informacjach o właściwości failure_mode_allow. Ta właściwość umożliwia zmianę zachowania filtra w przypadku błędów.

Brakujący lub nieprawidłowy JWT nie jest odrzucany

Prawdopodobną przyczyną jest to, że filtr JWT Envoy nie jest skonfigurowany.

Prawidłowy klucz interfejsu API nie działa

Możliwe przyczyny

  • Envoy nie może nawiązać połączenia z usługą zdalną.
  • Twoje dane logowania są nieprawidłowe.
  • Usługa API Apigee nie jest skonfigurowana na potrzeby celu i środowiska.

Jak rozwiązać problem

Sprawdź usługę API w Apigee

  • Czy jest włączona w Twoim środowisku (testowym lub produkcyjnym)?

    Usługa musi być powiązana z tym samym środowiskiem co usługa zdalna.

  • Czy jest powiązana z celem, do którego uzyskujesz dostęp?

    Sprawdź sekcję Cele usługi zdalnej Apigee. Pamiętaj, że nazwa usługi musi być a pełną i jednoznaczną nazwą hosta. Jeśli jest to usługa Istio, nazwa będzie wyglądać np. tak: helloworld.default.svc.cluster.localcode> - co oznacza usługę helloworld w przestrzeni nazw default.

  • Czy ścieżka zasobu jest zgodna z Twoim żądaniem?

    Pamiętaj, że ścieżka taka jak / lub /** będzie pasować do każdej ścieżki. Do dopasowywania możesz też używać symboli wieloznacznych „*” lub „**” do dopasowywania.

  • Czy masz aplikację dewelopera?

    Aby sprawdzić klucze, usługa API musi być powiązana z aplikacją dewelopera.

Sprawdź swoją prośbę

  • Czy przekazujesz klucz klienta w x-api-key header

    Przykład:

    curl http://localhost/hello -H "x-api-key: wwTcvmHvQ7Dui2qwj43GlKJAOwmo"
  • Czy używasz prawidłowego klucza klienta?

    Upewnij się, że dane logowania z aplikacji, której używasz, są zatwierdzone w przypadku Twojej usługi API.

Sprawdź logi usługi zdalnej

  • Uruchom usługę zdalną z logowaniem na poziomie debug level

    Użyj opcji -l debug w wierszu poleceń.

  • Spróbuj uzyskać dostęp do celu i sprawdź logi

    W logach poszukaj wiersza podobnego do tego:

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