Retry и Circuit Breaker в Kubernetes с помощью Istio и Spring Boot

Каждому service mesh-фреймворку абсолютно необходимо уметь обрабатывать сбои в межсервисном взаимодействии. К ним также относятся таймауты и HTTP-коды ошибок. Я покажу, как с помощью Istio настроить механизмы retries (повторных попыток) и circuit breaker (автоматического выключения). Мы проанализируем взаимодействие между двумя простыми Spring Boot-сервисами, развёрнутыми в Kubernetes. Но вместо основ рассмотрим более сложные вопросы.

Для демонстрации использования Istio и Spring Boot я создал GitHub-репозиторий с двумя сервисами: callme-service и caller-service.

Архитектура

Архитектура системы очень похожа на ту, что рассматривалась в моей предыдущей статье "Service mesh on Kubernetes with Istio and Spring Boot", но с некоторыми отличиями. Мы добавляем ошибку или задержку не с помощью Istio-компонентов, а прямо в исходном коде сервиса. Почему? Так мы сможем обрабатывать правила для callme-service напрямую, а не на клиенте. Также мы запустим два пода callme-service v2, чтобы проверить, как circuit breaker работает с несколькими подами того же Deployment.
Вот как выглядит архитектура:

Spring Boot-сервисы

Начнём с реализации сервисов. callme-service предоставляет два эндпоинта, возвращающие информацию о версии и ID инстанса. Вызов GET /ping-with-random-error выдаёт ошибку HTTP 504 в ответ на примерно половину запросов. А GET /ping-with-random-delay отвечает со случайной задержкой в диапазоне 0…3 с. Так реализован @RestController на стороне callme-service:

@RestController @RequestMapping("/callme") public class CallmeController {      private static final Logger LOGGER = LoggerFactory.getLogger(CallmeController.class);     private static final String INSTANCE_ID = UUID.randomUUID().toString();     private Random random = new Random();      @Autowired     BuildProperties buildProperties;     @Value("${VERSION}")     private String version;      @GetMapping("/ping-with-random-error")     public ResponseEntity<String> pingWithRandomError() {         int r = random.nextInt(100);         if (r % 2 == 0) {             LOGGER.info("Ping with random error: name={}, version={}, random={}, httpCode={}",                     buildProperties.getName(), version, r, HttpStatus.GATEWAY_TIMEOUT);             return new ResponseEntity<>("Surprise " + INSTANCE_ID + " " + version, HttpStatus.GATEWAY_TIMEOUT);         } else {             LOGGER.info("Ping with random error: name={}, version={}, random={}, httpCode={}",                     buildProperties.getName(), version, r, HttpStatus.OK);             return new ResponseEntity<>("I'm callme-service" + INSTANCE_ID + " " + version, HttpStatus.OK);         }     }      @GetMapping("/ping-with-random-delay")     public String pingWithRandomDelay() throws InterruptedException {         int r = new Random().nextInt(3000);         LOGGER.info("Ping with random delay: name={}, version={}, delay={}", buildProperties.getName(), version, r);         Thread.sleep(r);         return "I'm callme-service " + version;     }  }

Сервис caller-service тоже предоставляет два эндпоинта GET. С помощью RestTemplate он вызывает соответствующий GET callme-service. Сервис также возвращает версию caller-service, у него только один Deployment, он помечен как version=v1.

@RestController @RequestMapping("/caller") public class CallerController {      private static final Logger LOGGER = LoggerFactory.getLogger(CallerController.class);      @Autowired     BuildProperties buildProperties;     @Autowired     RestTemplate restTemplate;     @Value("${VERSION}")     private String version;      @GetMapping("/ping-with-random-error")     public ResponseEntity<String> pingWithRandomError() {         LOGGER.info("Ping with random error: name={}, version={}", buildProperties.getName(), version);         ResponseEntity<String> responseEntity =                 restTemplate.getForEntity("http://callme-service:8080/callme/ping-with-random-error", String.class);         LOGGER.info("Calling: responseCode={}, response={}", responseEntity.getStatusCode(), responseEntity.getBody());         return new ResponseEntity<>("I'm caller-service " + version + ". Calling... " + responseEntity.getBody(), responseEntity.getStatusCode());     }      @GetMapping("/ping-with-random-delay")     public String pingWithRandomDelay() {         LOGGER.info("Ping with random delay: name={}, version={}", buildProperties.getName(), version);         String response = restTemplate.getForObject("http://callme-service:8080/callme/ping-with-random-delay", String.class);         LOGGER.info("Calling: response={}", response);         return "I'm caller-service " + version + ". Calling... " + response;     }  }

Обработка повторных попыток (retries) в Istio

Определение объекта DestinationRule в Istio такое же, как в моей предыдущей статье. Создано два подмножества для подов, помеченных как version=v1 и version=v2. Retries и timeouts можно настроить в VirtualService. Мы можем задать количество повторных попыток и условия их выполнения (списком enum-строк). В коде ниже также задаётся таймаут 3 с. для всего запроса. Обе эти настройки доступны внутри объекта HTTPRoute. Заодно нам нужно задать длительность таймаута на одну попытку, я задал 1 с. Как это работает на практике? Рассмотрим простой пример:

apiVersion: networking.istio.io/v1beta1 kind: DestinationRule metadata:   name: callme-service-destination spec:   host: callme-service   subsets:     - name: v1       labels:         version: v1     - name: v2       labels:         version: v2 --- apiVersion: networking.istio.io/v1beta1 kind: VirtualService metadata:   name: callme-service-route spec:   hosts:     - callme-service   http:     - route:       - destination:           host: callme-service           subset: v2         weight: 80       - destination:           host: callme-service           subset: v1         weight: 20       retries:         attempts: 3         perTryTimeout: 1s         retryOn: 5xx       timeout: 3s

Перед развёртыванием сервисов нужно поднять уровень логирования. Мы легко можем включить логи обращений в Istio. Тогда Envoy-прокси будут выводить логи для всех входящих запросов и исходящих ответов. Анализ этих записей будет особенно полезен для определения повторных попыток.

$ istioctl manifest apply --set profile=default --set meshConfig.accessLogFile="/dev/stdout"

Давайте выполним тестовый запрос GET /caller/ping-with-random-delay. Он обратится к отвечающему со случайной задержкой GET /callme/ping-with-random-delay сервиса callme-service. Вот запрос и ответ на него:

Вроде бы, всё понятно. Но давайте посмотрим, что происходит под капотом. Я выделил последовательность повторных попыток. Как видите, Istio сделал две попытки, потому что два вызова обрабатывались дольше одной секунды, заданной в perTryTimeout. Два первых вызова завершились по таймауту из-за Istio, что видно в логе обращений. Третья попытка оказалась успешной, потому что обрабатывалась примерно 400 мс.

Повторы из-за таймаута — не единственная функция этого механизма в Istio. Мы можем задавать их при любых кодах 5хх и 4хх. Использовать VirtualService для тестирования одних лишь кодов ошибок гораздо проще, ведь нам не нужно конфигурировать таймауты.

apiVersion: networking.istio.io/v1beta1 kind: VirtualService metadata:   name: callme-service-route spec:   hosts:     - callme-service   http:     - route:       - destination:           host: callme-service           subset: v2         weight: 80       - destination:           host: callme-service           subset: v1         weight: 20       retries:         attempts: 3         retryOn: gateway-error,connect-failure,refused-stream

Вызовем GET /caller/ping-with-random-error, который обратится к GET /callme/ping-with-random-error сервиса callme-service. Она возвращает HTTP 504 в ответ примерно на половину входящих запросов. Вот запрос и успешный ответ с кодом 200 OK.

А вот лог, который показывает, что происходит на стороне callme-service. Было две повторные попытки, потому что на первые два вызова мы получили код ошибки.

Автоматическое выключение (circuit breaker) в Istio

Автоматическое выключение настраивается в объекте DestinationRule. Для этого воспользуемся TrafficPolicy. Не будем задавать retries из предыдущего примера, так что потребуется удалить их из определения VirtualService. Нужно также отключить все настройки повторов в connectionPool внутри TrafficPolicy. А теперь самое важное. Для настройки circuit breaker в Istio мы воспользуемся объектом OutlierDetection. Механизм автоматического выключение реализован на основе последовательных ошибок, возвращаемых конечным сервисом. Количество ошибок можно задать с помощью свойства consecutive5xxErrors или consecutiveGatewayErrors. Они отличаются лишь тем, что могут обрабатывать разные наборы ошибок. consecutiveGatewayErrors обрабатывает только 502, 503 и 504, а consecutive5xxErrors применяется для всех 5хх кодов. Ниже в конфигурации callme-service-destination я задал consecutive5xxErrors значение 3. Это означает, что после трёх ошибок подряд под сервиса на одну минуту убирается из балансировки нагрузки (baseEjectionTime=1m). Поскольку у нас запущено два пода callme-service версии v2, нам также нужно переопределить на 100% заданное для maxEjectionPercent значение по умолчанию, которое равно 10%: это максимальная доля хостов в пуле балансировки нагрузки, которые могут быть исключены.

apiVersion: networking.istio.io/v1beta1 kind: DestinationRule metadata:   name: callme-service-destination spec:   host: callme-service   subsets:     - name: v1       labels:         version: v1     - name: v2       labels:         version: v2   trafficPolicy:     connectionPool:       http:         http1MaxPendingRequests: 1         maxRequestsPerConnection: 1         maxRetries: 0     outlierDetection:       consecutive5xxErrors: 3       interval: 30s       baseEjectionTime: 1m       maxEjectionPercent: 100 --- apiVersion: networking.istio.io/v1beta1 kind: VirtualService metadata:   name: callme-service-route spec:   hosts:     - callme-service   http:     - route:       - destination:           host: callme-service           subset: v2         weight: 80       - destination:           host: callme-service           subset: v1         weight: 20

Оба сервиса быстрее всего можно развернуть с помощью Jib и Skaffold. Сначала идём в директорию callme-service и исполняем команду skaffold dev с опциональным параметром --port-forward.

$ cd callme-service $ skaffold dev --port-forward

Затем то же самое делаем для caller-service.

$ cd caller-service $ skaffold dev --port-forward 

Прежде чем отправлять тестовые запросы, давайте запустим второй под callme-service версии v2, поскольку Deployment присваивает параметру replicas значение 1. Для этого выполним команду:

$ kubectl scale --replicas=2 deployment/callme-service-v2

Проверим статус деплоймента в Kubernetes. Три деплоймента, две запущенные поды callme-service-v2.

Теперь можно тестировать. Вызовем GET /caller/ping-with-random-error сервиса caller-service, который обращается к эндпоинту GET /callme/ping-with-random-error сервиса callme-service. Напомню, что она возвращает ошибку HTTP 504 в ответ на половину запросов. Я уже настроил для callme-service перенаправление на порт 8080, так что команда вызова сервиса выглядит так:

curl http://localhost:8080/caller/ping-with-random-error

Проанализируем ответ. Я выделил ответы с ошибкой от пода callme-service версии v2 и ID 98c068bb-8d02-4d2a-9999-23951bbed6ad. После трёх ответов с ошибкой подряд от этого пода он немедленно был убран из пула балансировки нагрузки, и в результате все последующие запросы стали отправляться на второй под callme-service v2 с ID 00653617-58e1-4d59-9e36-3f98f9d403b8. Конечно, есть ещё один под callme-service v1, на который идёт 20% всех запросов от caller-service.

Посмотрим, что произойдёт, если единственный под callme-service v1 возвратит три ошибки подряд. Я выделил такие ответы на скриншоте. Поскольку под единственный, перенаправлять входящий трафик больше некуда. Поэтому Istio возвращает HTTP 503 на следующий запрос к callme-service v1. Тот же ответ повторяется в течение следующей минуты, потому что circuit ещё открыт.