Rozwiązywanie problemów

Przeglądasz dokumentację Apigee Edge.
Otwórz dokumentację Apigee X. Informacje

Błąd 404 (nie znaleziono) Istio

Debugowanie błędu 404 (Nie znaleziono) w Istio może być frustrujące. Mam nadzieję, że pozwoli Ci to zacząć określać, gdzie coś jest nie tak.

Konflikt bramy Wildcard

Może być tylko jedna definicja bramy używająca symbolu wieloznacznego „*” wartości hostów. Jeśli wdrożysz cokolwiek, co zawiera bramę z symbolami wieloznacznymi, wywołania klienta będą kończyć się niepowodzeniem i zgłoszeniem stanu 404.

Przykład:

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

Jeśli tak się stanie, musisz usunąć lub zmienić jedną z bram powodujących konflikty.

Wyznacz miejsca, w których na trasie występuje błąd

Istio jest jak cebula (lub ogr) – ma warstwy. Systematyczny sposób debugowania błędu 404 to wychodzenie poza cel.

Zbiór zadań backendu

Sprawdź, czy masz dostęp do zadania z pomocniczej:

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

Moduł pomocniczy backendu

Ustaw adres usługi i pobierz 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ą pliku pomocniczego:

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

Jeśli jest włączone mTLS Istio:

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 plik pomocniczy frontendu)

Uzyskaj dostęp do usługi z bramy:

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

Jeśli jest włączone mTLS Istio:

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 statystyki

Jeśli nie widzisz statystyk w interfejsie Analytics, przyczyny mogą być następujące:

  • Spożycie Apigee może być opóźnione o kilka minut
  • Log dostępu Envoy gRPC nie jest prawidłowo skonfigurowany
  • Envoy nie może połączyć się z usługą zdalną
  • Nie udało się przesłać do usługi zdalnej

Brakujący lub nieprawidłowy klucz interfejsu API nie został odrzucony

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
  • Upewnij się, że detektor jest skonfigurowany pod kątem przechwytywania.
  • Sprawdź konfigurację ext-authz.

Nieprawidłowe żądania są sprawdzane i dozwolone

  • Usługa zdalna skonfigurowana pod kątem nieudanego otwarcia
  • Serwer Envoy nie jest skonfigurowany do sprawdzania RBAC

Informacje o tym, jak rozwiązać te problemy, znajdziesz w tym temacie w dokumentacji Envoy: Autoryzacja zewnętrzna oraz informacje 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 został odrzucony

Prawdopodobną przyczyną jest nieskonfigurowanie filtra JWT Envoy.

Nieprawidłowy klucz interfejsu API kończy się niepowodzeniem

Prawdopodobne przyczyny

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

Jak rozwiązać problem

Sprawdź swój interfejs API w Apigee

  • Czy jest ona włączona w Twoim środowisku (testowa lub produkcyjna)?

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

  • Czy jest ona powiązana z celem, do którego chcesz uzyskać dostęp?

    Zapoznaj się z sekcją Zdalne cele usługi Apigee. Pamiętaj, że nazwa usługi musi być w pełni kwalifikowaną nazwą hosta. Jeśli jest to usługa Istio, jej nazwa będzie wyglądać mniej więcej tak: helloworld.default.svc.cluster.localcode>, która reprezentuje usługę helloworld w przestrzeni nazw default.

  • Czy ścieżka zasobu pasuje do żądania?

    Pamiętaj, że ścieżka / lub /** będzie pasować do dowolnej ścieżki. Aby dopasować, możesz też używać symboli wieloznacznych „*” lub „**”.

  • Czy masz aplikację dewelopera?

    Aby można było sprawdzić klucze, Usługa API musi być powiązana z aplikacją dewelopera.

Sprawdzanie prośby

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

    Przykład:

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

    Upewnij się, że dane uwierzytelniające aplikacji, której używasz, są zatwierdzone w przypadku Twojego interfejsu API.

Sprawdzanie dzienników usługi zdalnej

  1. Uruchom usługę zdalną z logowaniem na debug level. Zobacz Ustawianie poziomów dzienników usługi zdalnej.

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

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

    W dziennikach poszukaj 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 logów usługi zdalnej

    Za pomocą flagi wiersza poleceń możesz uruchomić usługę zdalną w jednym z tych trybów debugowania (według szczegółowości) (debug oznacza największą szczegółowość, a error – najmniejszą):

    • debug – najbardziej szczegółowy tryb logowania.
    • info – wartość domyślna.
    • warn
    • error – tryb najmniej szczegółowego zapisywania.

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

    apigee-remote-service-envoy -l debug