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

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

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

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

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

Конфликт шлюза с подстановочным знаком

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

Пример:

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

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

Как отследить, где происходит сбой маршрута

Istio похож на луковицу (или, возможно, на огра), у него много слоев. Чтобы устранить ошибку 404, нужно двигаться от целевой страницы.

рабочая нагрузка бэкенда;

Проверьте, есть ли у вас доступ к рабочей нагрузке из контейнера sidecar:

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

Контейнер backend sidecar

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

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

Чтобы получить доступ к рабочей нагрузке через дополнительный контейнер:

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

Если включен протокол 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

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

Как получить доступ к сервису через шлюз:

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

Если включен протокол 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

Отсутствие статистики

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

Загрузка данных Apigee может задерживаться на несколько минут
Журнал доступа gRPC Envoy настроен неправильно
Envoy не может подключиться к удаленному сервису
Не удается загрузить данные в удаленный сервис

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

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

Прямой прокси-сервер

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

Sidecar

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

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

Удаленный сервис настроен на открытие при сбое
Envoy не настроен для проверок RBAC

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

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

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

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

Возможные причины

Envoy не может подключиться к удаленному сервису
Неверные учетные данные
Продукт API Apigee не настроен для целевого объекта и среды

Как устранить проблему

Как проверить продукт API в Apigee

Включена ли она в вашей среде (тестовой или рабочей)?
Продукт должен быть связан с той же средой, что и ваш сервис удаленного доступа.
Связан ли он с целевым ресурсом, к которому вы обращаетесь?
Проверьте раздел Цели удаленного сервиса Apigee. Помните, что имя сервиса должно быть полным именем хоста. Если это сервис Istio, название будет выглядеть примерно так:helloworld.default.svc.cluster.localcode> – это сервис helloworld в пространстве имен default.
Соответствует ли путь к ресурсу вашему запросу?
Помните, что путь, например / или /**, будет соответствовать любому пути. Для поиска соответствий можно также использовать подстановочные знаки "*" или "**".
У вас есть приложение для разработчиков?
Чтобы проверить ключи, продукт API должен быть связан с приложением разработчика.

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

Передается ли ключ потребителя в x-api-key header
Пример:
```
curl http://localhost/hello -H "x-api-key: wwTcvmHvQ7Dui2qwj43GlKJAOwmo"
```
Используете ли вы подходящий ключ потребителя?
Убедитесь, что учетные данные приложения, которое вы используете, одобрены для вашего продукта API.

Как проверить журналы удаленного сервиса

Запустите удаленный сервис с ведением журнала в debug level. Подробнее о том, как задать уровни журналов удаленных сервисов…
Используйте параметр -l debug в командной строке. Пример:
```
apigee-remote-service-envoy -l debug
```
Попытайтесь получить доступ к целевому ресурсу и проверьте журналы
Найдите в журналах строку, похожую на следующую:
```
Resolve api: helloworld.default.svc.cluster.local, path: /hello, scopes: []
Selected: [helloworld]
Eliminated: [helloworld2 doesn't match path: /hello]
```

Как задать уровни ведения журнала удаленного сервиса

С помощью параметра командной строки можно запустить удаленный сервис в одном из следующих режимов отладки (в порядке уменьшения детализации): debug, error.

debug – режим ведения подробных журналов.
info – значение по умолчанию.
warn
error – режим ведения журналов с наименьшим количеством записей.

Например, чтобы запустить сервис на уровне debug, выполните следующие действия:

apigee-remote-service-envoy -l debug