Fehlerbehebung

<ph type="x-smartling-placeholder"></ph> Sie sehen die Dokumentation zu Apigee Edge.
Gehen Sie zur Apigee X-Dokumentation. Weitere Informationen

Istio-Fehler 404 (Nicht gefunden)

Die Behebung eines 404-Fehlers (Nicht gefunden) in Istio kann frustrierend sein. Ich hoffe, dass du hier einen Ort erkennst, an dem du Probleme hast.

Platzhalter-Gateway-Konflikt

Es darf nur eine Gateway-Definition vorhanden sein, bei der als Platzhalter "*" verwendet wird. Wenn Sie etwas anderes angegeben haben, das ein Platzhalter-Gateway enthält, schlagen Clientaufrufe mit dem Fehler 404 fehl.

Beispiel:

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

Sollte dies der Fall sein, müssen Sie eines der in Konflikt stehenden Gateways löschen oder ändern.

Nachsehen, wo die Route ausfällt

Istio ist wie eine Zwiebel (oder ein Ogre) und hat Schichten. Eine systematische Möglichkeit zur Fehlerbehebung eines 404-Fehlers besteht darin, direkt vom Ziel aus zu arbeiten.

Die Back-End-Arbeitslast

Prüfen Sie, ob Sie über die Sidecar-Datei auf die Arbeitslast zugreifen können:

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

Back-End-Sidecar-Datei

Legen Sie Ihre Dienstadresse fest und rufen Sie die IP-Adresse des Arbeitslast-Pods ab.

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

Greifen Sie über die Sidecar auf die Arbeitslast zu:

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

Wenn Istio mTLS aktiviert ist, gehen Sie so vor:

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

Das Gateway (oder ein Frontend-Sidecar)

Greifen Sie über das Gateway auf den Dienst zu:

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

Wenn Istio mTLS aktiviert ist, gehen Sie so vor:

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

Fehlende Analysen

Wenn die Analyseoberfläche in Analytics nicht angezeigt wird, kann das folgende Ursachen haben:

  • Die Aufnahme von Apigee kann sich um einige Minuten verzögern
  • Envoy gRPC-Zugriffslog ist nicht richtig konfiguriert
  • Envoy kann den Remotedienst nicht erreichen
  • Fehler beim Hochladen des Remotediensts

Fehlender oder ungültiger API-Schlüssel wird nicht abgelehnt

Wenn die API-Schlüsselvalidierung nicht ordnungsgemäß funktioniert, kann dies folgende Ursachen haben:

Direkter Proxy

Prüfen Sie die ext-authz-Konfiguration.

Sidecar
  • Der Listener muss für das Abfangen konfiguriert sein.
  • Prüfen Sie die ext-authz-Konfiguration.

Ungültige Anfragen werden geprüft und zugelassen

  • Remote-Dienst wurde für fehlgeschlagenes Ausfall konfiguriert
  • Envoy nicht für RBAC-Prüfungen konfiguriert

Informationen zum Beheben dieser Probleme finden Sie im folgenden Envoy-Dokumentationsthema: External Authorization und in den Informationen zum Attribut failure_mode_allow. Mit diesem Attribut können Sie das Verhalten des Filters bei Fehlern ändern.

Fehlendes oder ungültiges JWT wird nicht abgelehnt

Der Grund dafür könnte sein, dass der JWT-Filter für Envoy nicht konfiguriert ist.

Gültiger API-Schlüssel schlägt fehl

Mögliche Ursachen

  • Envoy kann den Remotedienst nicht erreichen.
  • Ihre Anmeldedaten sind ungültig
  • Apigee API-Produkt nicht für Ziel und Umgebung konfiguriert

Schritte zur Fehlerbehebung

API-Produkt auf Apigee prüfen

  • Ist es für Ihre Umgebung aktiviert (Test vs. prod)?

    Das Produkt muss an dieselbe Umgebung wie der Remotedienst gebunden sein.

  • Ist es an das Ziel gebunden, auf das Sie zugreifen?

    Prüfen Sie den Abschnitt Apigee-Remote-Serviceziele. Denken Sie daran, dass der Dienstname ein vollständig qualifizierter Hostname sein muss. Wenn es sich um einen Istio-Dienst handelt, lautet der Name beispielsweise helloworld.default.svc.cluster.localcode>, der den helloworld-Dienst im Namespace default darstellt.

  • Stimmt der Ressourcenpfad mit Ihrer Anfrage überein?

    Denken Sie daran, dass ein Pfad wie / oder /** mit einem beliebigen Pfad übereinstimmt. Sie können auch Platzhalter (*) oder Sternchen verwenden, um einen Abgleich zu ermöglichen.

  • Haben Sie eine Entwickler-App?

    Das API-Produkt muss an eine Entwickler-App gebunden sein, um die Schlüssel zu prüfen.

Anfrage prüfen

  • Übergeben Sie den Consumer-Key in den x-api-key header

    Beispiel:

    curl http://localhost/hello -H "x-api-key: wwTcvmHvQ7Dui2qwj43GlKJAOwmo"
  • Verwenden Sie einen guten Consumer-Key?

    Prüfen Sie, ob die Anmeldedaten der von Ihnen verwendeten App für Ihr API-Produkt genehmigt sind.

Logs für Remotedienst prüfen

  1. Remotedienst mit Logging unter debug level starten Siehe Logebenen für Remotedienst festlegen.

    Verwenden Sie die Option -l debug in der Befehlszeile. Beispiel:

    apigee-remote-service-envoy -l debug
  2. Versuchen Sie, auf Ihr Ziel zuzugreifen, und prüfen Sie die Protokolle.

    Prüfen Sie die Logs auf eine Zeile, die in etwa so aussieht:

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

    3. Logebenen für Remotedienst festlegen

    Mit einem Befehlszeilen-Flag können Sie den Remotedienst in einem der folgenden Debug-Modi in der Reihenfolge der Ausführlichkeit starten, wobei debug am ausführlichsten und error am wenigsten ausführlich ist:

    • debug: Der ausführlichste Logging-Modus.
    • info: Der Standardwert.
    • warn
    • error: Logging-Modus mit der geringsten Ausführlichkeit.

    So starten Sie den Dienst beispielsweise auf der Ebene debug: 

    apigee-remote-service-envoy -l debug