Rozwiązywanie problemów

Przeglądasz dokumentację Apigee Edge.
Przejdź do Dokumentacja Apigee X. informacje.

Błąd Istio 404 (nie znaleziono)

Debugowanie błędu 404 (nie znaleziono) w Istio może być frustrujące. Mam nadzieję, że dzięki temu aby zacząć monitorować miejsca, w których coś poszło nie tak.

Konflikt bramy z symbolami wieloznacznymi

Może być tylko jedna definicja bramy używająca symbolu wieloznacznego „*” . Jeśli wdrożysz wszystko, co obejmuje bramę z symbolem wieloznacznym, wywołania klienta zakończą się niepowodzeniem ze stanem 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 będących w konflikcie.

Śledzenie błędów trasy

Istio jest jak cebula (albo ogr), ma warstwy. Systematyczny sposób debugowania a 404 to wyjście poza cel.

Zbiór zadań backendu

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

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

Dodatek pomocniczy backendu

Ustaw adres 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 zadania za pomocą aplikacji pomocniczej:

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

Jeśli włączone jest 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 poziomu bramy:

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

Jeśli włączone jest 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

Brak statystyk

Jeśli w interfejsie Analytics nie widzisz statystyk, weź pod uwagę te możliwe przyczyny:

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

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

Jeśli weryfikacja klucza interfejsu API nie działa prawidłowo, weź pod uwagę 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 akceptowane

  • Usługa zdalna skonfigurowana pod kątem awarii
  • Envoy nie skonfigurowano na potrzeby kontroli RBAC

Informacje o tym, jak rozwiązać te problemy, znajdziesz w poniższej dokumentacji Envoy. topic: Zewnętrzna autoryzacja, i zapoznaj się z informacjami na temat właściwości failure_mode_allow. Ta usługa umożliwia zmianę działania filtra w przypadku błędów.

Brakujący lub nieprawidłowy token JWT nie został odrzucony

Prawdopodobną przyczyną jest to, że nie skonfigurowano filtra JWT Envoy.

Awaria prawidłowego klucza interfejsu API

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

Etapy rozwiązywania problemów

Sprawdź usługę API w Apigee

  • Czy rozwiązanie jest włączone w Twoim środowisku (testowe lub produkcyjne)?

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

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

    Sprawdź sekcję Cele usługi zdalnej Apigee. Pamiętaj, że nazwa usługi musi być ciągiem w pełni kwalifikowana nazwa hosta. Jeśli jest to usługa Istio, nazwa będzie podobna do tej: helloworld.default.svc.cluster.localcode> – reprezentuje usługę helloworld w przestrzeni nazw default.

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

    Pamiętaj, że ścieżka, np. / lub /**, pasuje do każdej ścieżki. Możesz również użyć znaku „*” lub „**” symbole wieloznaczne dopasowania.

  • Czy masz aplikację dewelopera?

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

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 dobrego klucza klienta?

    Upewnij się, że dane uwierzytelniające z aplikacji, której używasz, są zatwierdzone dla Twojej usługi API.

Sprawdź dzienniki usługi zdalnej

  1. Uruchom usługę zdalną za pomocą logowania na debug level. Zobacz Ustawianie poziomów logó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

    Poszukaj w dziennikach wiersza, który wygląda mniej więcej tak:

    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

    Przy użyciu flagi wiersza poleceń możesz uruchomić usługę zdalną w jednym z tych debugowania tryby w kolejności według szczegółowości, gdzie debug jest najbardziej szczegółowy, a error to najmniej:

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

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

    apigee-remote-service-envoy -l debug