Реализация устойчивости инфраструктуры с помощью Kubernetes
Чтобы обеспечить отказоустойчивость с использованием инфраструктуры, можно использоватьсетки служб. Помимо обеспечения устойчивости без изменения кода, сетка служб обеспечивает управление трафиком, политику, безопасность, надежную идентификацию и наблюдаемость. Эти операции отделяются от приложения и переносятся на уровень инфраструктуры. С точки зрения архитектуры сетка служб состоит из двух компонентов: плоскости управления и плоскости данных.
Компонент плоскости управления имеет множество компонентов, поддерживающих управление сеткой служб. Обычно в список компонентов входят:
- Интерфейс управления — это может быть программный интерфейс или API.
- Правила и определения политик, определяющие, как должны реализовываться определенные возможности в сетке служб.
- Управление безопасностью для таких объектов, как надежные удостоверения и сертификаты для mTLS.
- Метрики или возможность наблюдения для сбора и агрегирования метрик и телеметрии из приложений.
Компонент плоскости данных состоит из прокси-серверов, которые прозрачно внедряются вместе с каждой службой; это называется шаблоном боковицы. Каждый прокси-сервер настроен для управления сетевым трафиком в pod и из него, содержащего службу. Такая конфигурация позволяет настроить каждый прокси-сервер для выполнения следующих действий:
- Безопасный трафик через mTLS.
- Динамическая маршрутизация трафика.
- Применение политик к трафику.
- Сбор метрик и данных трассировки.
Некоторые популярные сетки служб для кластеров Kubernetes включают Linkerd, Istio и Consul. В этом модуле рассматривается Linkerd. На следующей схеме показано взаимодействие между компонентами в плоскости данных и плоскости управления:
Сравнение с методами обеспечения устойчивости с использованием кода
Стратегия обработки ошибок в компоновщике состоит из повторных попыток и времени ожидания. Поскольку Компоновщик имеет системное представление всего кластера, он может использовать стратегии устойчивости в новых способах. Пример выполняется повторно таким образом, что увеличивает нагрузку на целевую службу не больше, чем на 20 %. Представление Linkerd на основе метрик обеспечивает ему динамическую адаптацию к условиям кластера в режиме реального времени. Этот подход привносит еще один аспект в управление кластером, но не добавляет код.
При выборе подхода с использованием кода, например с помощью Polly, необходимо:
- Определить подходящие параметры повторных попыток и времени ожидания.
- Сосредоточиться на определенном HTTP-запросе.
В коде приложения нет адекватного варианта реакции на сбой инфраструктуры. Представьте, что одновременно обрабатываются сотни или даже тысячи запросов. Службу может перегрузить даже повтор с экспоненциальной задержкой (увеличением времени между запросами).
В отличие от этого, подходы на основе инфраструктуры, такие как Компоновщик, не знают внутренних приложений. Например, для Linkerd сложные транзакции баз данных невидимы. Такие транзакции можно защитить от ошибок с помощью Polly.
В предстоящих уроках вы реализуете устойчивость для службы купон с помощью Polly и Linkerd.