Rozwiązywanie problemów

Wyświetlasz dokumentację Apigee Edge.
Otwórz dokumentację 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 znaleźć przyczynę problemu.

Konflikt bramy z wieloznacznikiem

Może istnieć tylko jedna definicja bramy, która używa wartości hostów z symbolem wieloznacznym „*”. Jeśli wdrożysz cokolwiek innego, co zawiera bramę z symbolem wieloznacznym, wywołania klienta zakończą się niepowodzeniem ze statusem 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 bram płatności, które ze sobą kolidują.

Śledzenie miejsca, w którym trasa się nie powiodła

Istio jest jak cebula (albo może jak ogr) – ma warstwy. Systematyczny sposób debugowania błędu 404 polega na sprawdzaniu elementów od miejsca docelowego na zewnątrz.

zbiór zadań backendu,

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

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

Kontener pomocniczy backendu

Ustaw adres świadczenia usługi i uzyskaj adres IP poda zadania.

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

Dostęp do zadania za pomocą kontenera dodatkowego:

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

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 pomocniczy kontener frontendowy);

Uzyskiwanie dostępu do usługi z bramy:

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

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

Brak analityki

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

  • Przetwarzanie danych w Apigee może być opóźnione o kilka minut.
  • Dziennik dostępu gRPC Envoy nie jest poprawnie skonfigurowany
  • Envoy nie może połączyć się 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, rozważ te możliwe przyczyny:

Bezpośredni serwer proxy

Sprawdź konfigurację ext-authz.

Sidecar
  • Sprawdź, czy detektor jest skonfigurowany pod kątem 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). Zapoznaj się też z informacjami o właściwości failure_mode_allow. Ta właściwość umożliwia zmianę działania filtra w przypadku błędów.

Brakujący lub nieprawidłowy token JWT nie jest odrzucany

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

Prawidłowy klucz interfejsu API nie działa

Prawdopodobne przyczyny

  • Envoy nie może połączyć się ze zdalną usługą
  • Twoje dane logowania są nieprawidłowe
  • Usługa API Apigee nie jest skonfigurowana dla miejsca docelowego i środowiska

Jak rozwiązać problem

Sprawdzanie usługi API w Apigee

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

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

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

    Sprawdź sekcję Środowiska docelowe usługi zdalnej Apigee. Pamiętaj, że nazwa usługi musi być 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 helloworld usługę w default przestrzeni nazw.

  • Czy ścieżka zasobu jest zgodna z Twoją prośbą?

    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 „**”.

  • Czy masz aplikację dewelopera?

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

Sprawdź prośbę

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

    Przykład:

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

    Sprawdź, czy dane logowania z aplikacji, której używasz, są zatwierdzone w przypadku Twojego produktu API.

Sprawdzanie logów usługi zdalnej

  1. Uruchom usługę zdalną z logowaniem w debug level. Zobacz Ustawianie poziomów rejestrowania usług zdalnych.

    Użyj opcji -l debug w wierszu poleceń. Na przykład:

    apigee-remote-service-envoy -l debug
  2. Spróbuj uzyskać dostęp do miejsca docelowego i sprawdź dzienniki

    Sprawdź logi pod kątem wiersza podobnego do tego:

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

    3. Ustawianie poziomów logowania usługi zdalnej

    Za pomocą flagi wiersza poleceń możesz uruchomić usługę zdalną w jednym z tych trybów debugowania (w kolejności od najbardziej do najmniej szczegółowego, gdzie debug jest najbardziej szczegółowy, a error – najmniej):

    • debug – najbardziej szczegółowy tryb logowania.
    • info – domyślny.
    • warn
    • error – najmniej szczegółowy tryb logowania.

    Aby na przykład uruchomić usługę na poziomie debug: 

    apigee-remote-service-envoy -l debug