Поиск неисправностей

Вы просматриваете документацию 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 – это отойти от цели.

Серверная нагрузка

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

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 настроен неправильно.
  • Посланник не может связаться с удаленной службой
  • Удаленная служба не может загрузить

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

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

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

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

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

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

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

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

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

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

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

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

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

Действия по устранению неполадок

Проверьте свой продукт API на Apigee

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

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

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

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

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

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

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

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

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

  • Вы передаете Consumer Key в x-api-key header

    Пример:

    curl http://localhost/hello -H "x-api-key: wwTcvmHvQ7Dui2qwj43GlKJAOwmo"
  • Используете ли вы хороший потребительский ключ?

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

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

  1. Запустите Remote Service с ведением журнала на debug level . См. Настройка уровней журнала удаленных служб .

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

    apigee-remote-service-envoy -l debug
  2. Попытайтесь получить доступ к вашей цели и проверьте журналы.

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

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

    3. Настройка уровней журнала удаленного обслуживания

    Используя флаг командной строки, вы можете запустить удаленную службу в одном из следующих режимов отладки, в порядке детализации, где debug является наиболее подробной, а error — наименьшим:

    • debug — самый подробный режим журналирования.
    • info — значение по умолчанию.
    • warn
    • error — наименее подробный режим журналирования.

    Например, чтобы запустить службу на уровне debug : 

    apigee-remote-service-envoy -l debug