Улучшите свои микросервисы, работающие в Kubernetes

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

Вы тщательно исследовали свою среду разработки, но не смогли определить, в чем проблема.

Единственный способ исследовать проблему - это посмотреть на трафик, проходящий через ваши производственные службы. Кто-то из вашей операционной группы заметил тайм-ауты в цепочке, и вам нужно продолжить расследование.

Эта история является продолжением Балансировки нагрузки на основе локальности в Kubernetes с использованием Istio. Сегодня давайте обсудим внедрение неисправностей и устранение неисправностей.

Что такое инжекция неисправностей?

Внедрение ошибок в контексте Istio - это механизм, с помощью которого мы можем целенаправленно внедрять некоторые проблемы в нашу сетку, чтобы имитировать поведение нашего приложения в случае возникновения таких проблем.

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

Есть две формы ошибок, которые вы можете внедрить в свое приложение.

  • Задержки: вы можете добавить временную задержку в виртуальную службу, которая позволяет имитировать такие ситуации, как задержка обработки или перегрузка сети.
  • Прерывания: это сбои в ваших микросервисах, например внутренняя ошибка сервера HTTP 500 или сбои TCP-соединения. Это позволяет вам протестировать ваше приложение на предмет потенциальной обработки ошибок и увидеть, не приведет ли ваше приложение к сбою из-за небольшой ошибки.

Исследование проблемы

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

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

Чтобы изолировать проблему, давайте добавим синтетическую ошибку в нашу цепочку. Нам нужно целенаправленно ввести семисекундную задержку в нашу цепочку, потому что операционная группа сообщила, что время ожидания запросов составляет шесть секунд.

Это позволяет нам воссоздать проблему в окружающей среде и помогает изолировать проблему.

Но ждать. Вы изучаете продакшн. Это расследование не должно повлиять на наших конечных клиентов. Что мы можем теперь сделать? Что ж, давайте воспользуемся здесь добрым старым Джейсоном.

Предпосылки

Убедитесь, что у вас есть работающий кластер Kubernetes. Следуйте руководству Как управлять трафиком с помощью Istio в Kubernetes, чтобы настроить маршрутизацию на основе идентификации пользователя в нашем приложении.

Введение задержки

Чтобы тактически решить проблему, нам нужно откатить внесенное нами изменение. Мы должны вернуть переключатель в положение v2 и убедиться, что прямой трафик идет на reviews-v1; однако для нашего бизнес-тестера jason нам все еще нужно направить трафик на reviews-v2.

Если вы следили за последней историей, мы оставили маршрутизировать запросы на reviews-v2 для всех запросов, исходящих от нашего бизнес-тестера, jason. Для остальных пользователей трафик собирался на reviews-v1. Поэтому начнем с этого.

Поскольку мы выполняем маршрутизацию на основе личности пользователя, это не коснется никого, кроме одного. Таким образом, мы не будем беспокоить клиентов и можем провести расследование в фоновом режиме.

Давайте посмотрим на манифест, который нам нужно применить, чтобы ввести задержку.

Если вы видите манифест для пользователя jason, это означает, что в микросервис ratings добавляется семисекундная задержка для 100% трафика. По остальным сообщениям задержки нет.

Пора применить изменение.

$ kubectl apply -f samples/bookinfo/networking/virtual-service-ratings-test-delay.yaml
virtualservice.networking.istio.io/ratings configured

Тестирование конфигурации

Теперь давайте зайдем на сайт и посмотрим, что произойдет.

Мы видим обзоры, но не рейтинги. Мы ожидали этого, когда откатили наше изменение с v2 на v1. Авторизуйтесь как пользователь jason - пароль не нужен.

Вы заметили задержку загрузки страницы? Почему мы не можем видеть отзывы? Тайм-аут между reviews-v2 и ratings - это жестко запрограммированное значение в 10 секунд. Таким образом, даже после семи секундной инъекции неисправности вы должны увидеть отзывы, но это, конечно, не так.

Если вы откроете инструменты разработчика и проверите вкладку сети, вы обнаружите, что страница продукта загружается примерно за шесть секунд. Но вы добавили семисекундную задержку? Что случилось? Что ж, здесь мы обнаружили ошибку.

В этом случае тайм-аут возникает между микросервисами productpage и reviews. Таймауты между ними жестко запрограммированы на 3s+3s(retry), что составляет шесть секунд. Таким образом, если ответ микросервиса reviews занимает более шести секунд, время ожидания productpage истекает.

Поздравляю! Теперь мы выяснили, в чем проблема. Подобные проблемы распространены в больших приложениях, использующих несколько микросервисов, а также когда несколько команд разрабатывают части приложения и работают изолированно.

Устранение проблемы

Итак, как мы можем исправить эту проблему? Что ж, есть два способа сделать это:

  • Увеличьте время ожидания с productpage до reviews.
  • Уменьшите время ожидания с reviews до ratings.

Что ж, мы не хотим мешать существующему работающему productpage микросервису. Поэтому давайте исправим приложение, развернув микросервис reviews-v3. Версия v3 устраняет проблему, сокращая время ожидания до двух с половиной секунд.

Если вы перенесете весь трафик на v3, как мы это сделали в предыдущем рассказе, и добавите двухсекундную задержку, вы обнаружите, что проблема больше не существует.

Примените приведенный ниже манифест:

$ kubectl apply -f samples/bookinfo/networking/virtual-service-reviews-v3.yaml

Откройте страницу и вы увидите, что reviews-v3 выполняется успешно.

Инъекционные прерывания

Есть и другие способы исследовать и изолировать проблему. Например, вы можете внедрить ошибку HTTP в виртуальную службу, чтобы проверить, как ваше приложение ведет себя в этих обстоятельствах.

В качестве демонстрации вы можете применить приведенный ниже манифест, чтобы вставить ошибку HTTP 500 (внутренняя ошибка сервера) в микросервис ratings.

Как видно из файла YAML, для пользователя jason Istio вводит ошибку HTTP 500 для 100% трафика. Остальной трафик не пострадает.

Примените манифест:

kubectl apply -f samples/bookinfo/networking/virtual-service-ratings-test-abort.yaml

Тестирование прерванной инъекции

Зайдите на страницу, и вы увидите, что теперь вы получаете сообщение «Рейтинговая служба в настоящее время недоступна».

Это показывает, что внедрение ошибок работает правильно, и разработчик хорошо закодировал страницу - поскольку вместо сбоя мы видим изящную ошибку.

Заключение

Спасибо, что прочитали! Надеюсь, вам понравилась статья. В следующей части я расскажу Как визуализировать вашу сервисную сетку Istio на Kubernetes с практической демонстрацией, так что до встречи в следующей истории!