Istio для практиков: как упростить управление микросервисами / forpes.ru

Главная
Istio для практиков: как упростить управление микросервисами

Istio для практиков: как упростить управление микросервисами

22.01.2025 05:01

kubelet 0 11 Источник

Примечание переводчика: статья является переводом из блога Луки Каваллини (Luca Cavallin) — инженера-программиста в GitHub, который специализируется на создании инструментов разработчика и инфраструктуры. В материале он делится опытом работы с Istio и объясняет, как этот инструмент помогает упростить взаимодействие между сервисами, обеспечивая безопасность и наблюдаемость. Статья актуальна для тех, кто хочет разобраться в современных подходах к управлению микросервисной архитектурой и узнать о преимуществах использования Istio.

Недавно я добавил пару тестов для одной из команд Istio CLI (вот мой PR для тех, кому интересно). Правки были не особо большими, зато я получил много полезных знаний. Это помогло мне глубже понять, как именно работает Istio. Но останавливаться на этом не хочется — надо сделать ещё что-нибудь полезное. Поэтому в этой статье я расскажу, что такое Istio, почему он полезен и как работает.

Что такое Istio

По своей сути Istio — это платформа для создания сервис-меша (service mesh), который управляет коммуникацией между микросервисами: заботится о маршрутизации трафика, защите связи и обеспечении наблюдаемости. С ростом числа микросервисов управлять их взаимодействием становится всё сложнее. Istio автоматизирует многие из этих задач, так что можно просто сосредоточиться на приложении и забыть о взаимодействии сервисов друг с другом.

Почему стоит использовать Istio

По мере усложнения архитектуры возникают новые проблемы. Обмен данными между сервисами должен быть надёжным, безопасным и эффективным. Istio помогает в трёх ключевых областях:

Управление трафиком: Istio позволяет контролировать потоки трафика между сервисами. Можно делить его между различными версиями сервиса, перенаправлять запросы во время развёртываний или настраивать политики повторных попыток и таймаутов.
Защита коммуникаций: Istio реализует взаимный TLS (Mutual TLS, mTLS). Все коммуникации шифруются, а сервисы проходят аутентификацию. Доступ неавторизованных сервисов исключён.
Наблюдаемость: Istio автоматически собирает метрики, логи и трассировки — за сервисами можно наблюдать в реальном времени. Это помогает с мониторингом, устранением неполадок и настройкой производительности.

Эти три области — ключ к здоровой микросервисной архитектуре, и Istio с лёгкостью справляется с ними.

Управление трафиком с помощью Istio

Одна из основных функций Istio — управление трафиком между сервисами. В случае микросервисов разные версии одного и того же сервиса могут работать одновременно. Например, вы тестируете новую версию сервиса payments и хотите, чтобы основная часть трафика продолжала поступать на старую версию и лишь небольшой его процент — на новую.

Вот как с помощью Istio можно разделить трафик между двумя версиями сервиса:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: payments
spec:
  hosts:
  - payments.myapp.com
  http:
  - route:
    - destination:
        host: payments
        subset: v1
      weight: 90
    - destination:
        host: payments
        subset: v2
      weight: 10

В этом примере:

90% трафика направляется на старую версию сервиса payments, а 10% — на новую;
в поле hosts указывается домен, для которого применим виртуальный сервис, — в данном случае payments.myapp.com;
блок route определяет, как трафик делится между двумя подмножествами сервиса — v1 (для старой версии) и v2 (для новой версии). Поле weight управляет долями.

Одно из применений такого подхода — «канареечные» развёртывания, когда новые функции тестируются на небольшом проценте пользователей перед полным развёртыванием.

Прокси Envoy и sidecar-контейнеры

Управляющий слой Istio опирается на Envoy — прокси 7-го уровня, — который управляет всем трафиком между сервисами. Для каждого сервиса в сервис-меше запускается отдельный sidecar-контейнер с прокси, который управляет всем его входящим и исходящим трафиком.

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

Поскольку Envoy работает как sidecar-контейнер, он может применять эти правила и собирать данные, не вмешиваясь при этом в логику самого приложения. Так он выступает в роли этакого регулировщика всех коммуникаций в сервис-меше.

Наблюдаемость: возможность видеть, что происходит в системе

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

Инструменты наблюдаемости Istio дают чёткое представление о том, как работает система. Проблемы выявляются на ранних стадиях, поэтому сервисы работают стабильнее.

Безопасность: MTLS и контроль доступа

Безопасность — одна из основных проблем при управлении микросервисами. Istio упрощает реализацию mTLS, который шифрует все коммуникации между сервисами и гарантирует, что перед обменом данными сервисы проходят аутентификацию.

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

Вот пример политики Istio, которая позволяет только сервису выставления счетов (billing) взаимодействовать с сервисом платежей (payments):

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: payments-to-billing
spec:
  selector:
    matchLabels:
      app: payments
  rules:
  - from:
    - source:
        principals: ["billing.myapp.com"]

Здесь:

с помощью лейбла app: payments селектор указывает, что это правило применяется к сервису payments;
блок rules разрешает взаимодействовать с сервисом payments только биллинговому сервису, идентифицируемому по имени "billing.myapp.com". Ни один другой сервис не сможет отправить трафик на payments.

Такая политика ограничивает доступ к payments для всех сервисов, кроме billing, что повышает безопасность.

Что такое SPIFFE?

Istio использует SPIFFE (Secure Production Identity Framework for Everyone) для управления идентификаторами сервисов. SPIFFE позволяет присваивать сервисам безопасные, проверяемые идентификаторы. Каждый сервис в меше получает SPIFFE Verifiable Identity Document (SVID), который вместе с mTLS обеспечивает безопасность коммуникаций. Такая система идентификации лежит в основе модели безопасности Istio.

Работа с сетями в Istio

Работа с сетями в микросервисах — дело непростое, особенно когда речь идёт о контроле трафика внутри и вне сервис-меша. Istio предоставляет несколько инструментов для управления сетевым трафиком:

Gateways: управляет трафиком, поступающим в сервис-меш и выходящим из него.
ServiceEntry: позволяет внешним сервисам взаимодействовать с сервисами внутри сервис-меша и наоборот.
VirtualService: определяет, как трафик маршрутизируется внутри сервис-меша.
DestinationRule: применяет политики трафика, такие как балансировка нагрузки или mTLS, к сервисам.

Пример конфигурации: Gateway, Service Entry, Virtual Service и Destination Rule

Предположим, у вас есть API-сервер внутри сервис-меша, который получает трафик из интернета через балансировщик нагрузки. Вот как можно настроить Gateway, Service Entry, Virtual Service и Destination Rule на обработку этого трафика.

Конфигурация Gateway

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: api-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "api.myapp.com"

Разберемся, что здесь происходит. Gateway прослушивает порт 80 для HTTP-трафика, поступающего на домен api.myapp.com. Поле selector соединяет этот Gateway со шлюзом Istio ingress, который обрабатывает трафик, поступающий в сервис-меш.

Конфигурация Service Entry

Допустим, серверу API необходимо вызвать внешний сервис аутентификации. Вот как настроить Service Entry для этого случая:

apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: auth-service-entry
spec:
  hosts:
  - "auth.external-service.com"
  location: MESH_EXTERNAL
  ports:
  - number: 443
    name: https
    protocol: HTTPS
  resolution: DNS
  endpoints:
  - address: 203.0.113.1

Здесь Service Entry указывает Istio, как маршрутизировать трафик к внешнему сервису (auth.external-service.com), который работает на 443-м порту (HTTPS). location: MESH_EXTERNAL означает, что сервис находится за пределами сервис-меша Istio. В поле endpoints указывается IP-адрес внешнего сервиса, на который сервер API внутри сервис-меша будет отправлять запросы.

Конфигурация VirtualService

А вот как маршрутизировать трафик внутри сервис-меша:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: api-virtualservice
spec:
  hosts:
  - "api.myapp.com"
  gateways:
  - api-gateway
  http:
  - match:
    - uri:
        prefix: "/v1"
    route:
    - destination:
        host: api-service
        subset: stable

VirtualService определяет правила маршрутизации трафика. В нашем случае трафик, поступающий на api.myapp.com/v1 через api-gateway, направляется на api-service в сервис-меше. Параметр subset: stable указывает на конкретную версию api-service (может быть несколько версий одного и того же сервиса).

Конфигурация DestinationRule

И наконец, вот DestinationRule для балансировки нагрузки и mTLS:

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: api-destination-rule
spec:
  host: api-service
  trafficPolicy:
    loadBalancer:
      simple: ROUND_ROBIN
    tls:
      mode: ISTIO_MUTUAL

Разберёмся, что здесь происходит. DestinationRule применяет политики к трафику, направляемому на api-service. Нагрузка балансируется по принципу round-robin для равномерного распределения запросов между экземплярами. mTLS включается с помощью tls.mode: ISTIO_MUTUAL и обеспечивает шифрованную связь между сервисами.

Отказоустойчивость: обработка отказов с помощью повторных попыток, таймаутов и прерывателей

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

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

Вот пример настройки повторных попыток и таймаутов в Istio:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: my-service
spec:
  hosts:
  - my-service
  http:
  - route:
    - destination:
        host: my-service
    retries:
      attempts: 3
      perTryTimeout: 2s
    timeout: 5s

Если запрос к my-service не удался, Istio повторит его до трёх раз. Для каждой повторной попытки установлено ограничение в 2 секунды. Общее время, отведённое на выполнение запроса, составляет 5 секунд. После этого Istio перестанет ждать ответа.

Для прерывателя можно использовать следующее DestinationRule:

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: my-service
spec:
  host: my-service
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 100
      http:
        http1MaxPendingRequests: 50
    outlierDetection:
      consecutive5xxErrors: 2
      interval: 10s
      baseEjectionTime: 30s
      maxEjectionPercent: 50

Если my-service последовательно возвращает две ошибки 5xx в течение 10 секунд, Istio перестаёт отправлять на него трафик. Сервис будет исключён из пула балансировки нагрузки на 30 секунд.

Резюме

Istio — мощный инструмент, который упрощает управление трафиком, безопасностью и наблюдаемостью для микросервисов. Участие в проекте Istio позволило мне понять, как он помогает решить некоторые сложные проблемы, возникающие при работе распределённых систем.

Используете микросервисную архитектуру или планируете масштабирование? Тогда Istio поможет сделать вашу систему более устойчивой и простой в управлении. Если у вас есть вопросы или вы хотите узнать больше об Istio, не стесняйтесь, обращайтесь — буду рад поделиться тем, что узнал.

P. S.

Читайте также в нашем блоге: