Устранение неполадок

Вы просматриваете документацию Apigee Edge .
Перейдите в документацию Apigee X.info

Ошибка Istio 404 (Не найдено).

Отладка ошибки 404 (Not Found) в Istio может быть довольно сложной задачей. Надеюсь, это поможет вам начать поиск причин возможных проблем.

конфликт шлюза Wildcard

Может существовать только одно определение шлюза, использующее значение hosts с подстановочным знаком "*". Если вы развернули что-либо еще, включающее шлюз с подстановочным знаком, вызовы клиентов будут завершаться ошибкой 404.

Пример:

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

В этом случае вам потребуется удалить или изменить один из конфликтующих шлюзов.

Выясните, где именно маршрут дает сбой.

Istio похож на луковицу (или, возможно, на огра), он состоит из слоев. Систематический способ отладки ошибки 404 — это начинать с целевого объекта.

Нагрузка на бэкэнд

Убедитесь, что вы можете получить доступ к рабочей нагрузке из вспомогательного контейнера:

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

бэкэнд-сайдкар

Укажите адрес службы и получите IP-адрес пода рабочей нагрузки.

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

Доступ к рабочей нагрузке осуществляется через вспомогательный модуль (sidecar):

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

Или, если включена поддержка 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

Шлюз (или вспомогательный интерфейс)

Доступ к сервису осуществляется через шлюз:

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

Или, если включена поддержка 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

Отсутствует аналитика.

Если вы не видите аналитику в пользовательском интерфейсе Analytics, рассмотрите следующие возможные причины:

  • Приём препарата Apigee можно отложить на несколько минут.
  • Журнал доступа Envoy gRPC настроен неправильно.
  • Envoy не может связаться с удаленной службой.
  • Загрузка через удаленный сервис завершается с ошибкой.

Отсутствующий или некорректный ключ API не отклоняется.

Если проверка ключа API работает некорректно, рассмотрите следующие возможные причины:

Прямой прокси

Проверьте конфигурацию ext-authz .

Боковая коляска
  • Убедитесь, что обработчик настроен на перехват.
  • Проверьте конфигурацию ext-authz .

Недействительные запросы проверяются и разрешаются.

  • Удалённая служба настроена на отказоустойчивое открытие.
  • Envoy не настроен для проверок RBAC.

Для получения информации о том, как решить эти проблемы, обратитесь к следующему разделу документации Envoy: Внешняя авторизация , а также к информации о свойстве failure_mode_allow . Это свойство позволяет изменять поведение фильтра при возникновении ошибок.

Отсутствующий или некорректный JWT не отклоняется

Вероятная причина заключается в том, что фильтр Envoy JWT не настроен.

Недействительный ключ API не работает.

Вероятные причины

  • Envoy не может связаться с удалённым сервисом.
  • Ваши учетные данные недействительны.
  • Продукт Apigee API не настроен для целевого объекта и среды.

Этапы устранения неполадок

Проверьте свой API-продукт в Apigee.

  • Включена ли эта функция в вашей среде (тестовой или производственной)?

    Продукт должен быть привязан к той же среде, что и ваша служба удаленного доступа.

  • Привязано ли оно к целевому объекту, к которому вы обращаетесь?

    Проверьте раздел « Цели удаленных служб Apigee» . Помните, что имя службы должно быть полным именем хоста. Если это служба Istio, имя будет выглядеть примерно так: helloworld.default.svc.cluster.local <имя_службы> — что представляет службу helloworld в пространстве имен default .

  • Соответствует ли путь к ресурсу вашему запросу?

    Помните, что путь типа / или /** будет соответствовать любому пути. Вы также можете использовать символы подстановки '*' или '**' для сопоставления.

  • У вас есть приложение для разработчиков?

    Для проверки ключей API-продукт должен быть привязан к приложению разработчика.

Проверьте свой запрос

  • Вы передаете ключ потребителя в x-api-key header

    Пример:

    curl http://localhost/hello -H "x-api-key: wwTcvmHvQ7Dui2qwj43GlKJAOwmo"
  • Вы используете надежный ключ доступа?

    Убедитесь, что учетные данные из используемого вами приложения одобрены для вашего API-продукта.

Проверьте журналы удаленной службы.

  • Запустите удаленную службу с ведением логов на debug level

    Используйте параметр -l debug в командной строке.

  • Попробуйте получить доступ к целевому объекту и проверьте журналы.

    Проверьте журналы на наличие строки, которая выглядит примерно так:

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