В Kubernetes мы развёртываем сервисы в подах, но как поды внутри Kubernetes общаются друг с другом и в чём тут загвоздка? Разберемся в этой статье.
Взаимодействие между подами
Kubernetes использует интерфейс CNI для взаимодействия между сетью и подами в кластере. На рабочей ноде за общение подов отвечает kube-proxy — сетевой прокси, который работает на каждой ноде в кластере и управляет сетевыми правилами. Сетевые правила регулируют взаимодействие в кластере и за его пределами.
Когда мы создаём под, или сервис, kube-proxy обновляет правила iptables, чтобы поды могли общаться:
Когда мы создаём сервис Service B, сервер API Kubernetes уведомляет kube-proxy на рабочей ноде, чтобы он добавил в iptables правила для Service B. Когда какой-то под будет вызывать Service B, запрос сначала будет направлен в iptables. iptables заменит целевой IP в Packet X на IP пода Pod B и перешлёт запрос в Pod B.
Но у kube-proxy есть ограничения:
- Запросы подам отправляются случайным образом.
- Трафик нельзя поделить на части по процентам.
- Канареечные и сине-зелёные развёртывания не поддерживаются.
- Сложно мониторить и отлаживать.
Service mesh
Service mesh — это отдельный инфраструктурный уровень, который мы добавляем к приложениям для взаимодействия между сервисами или микросервисами. На этом уровне можно прозрачно добавить наблюдаемость, управление трафиком и безопасность, чтобы не включать их в код.
В Kubernetes data plane — это sidecar-контейнер рядом с главным контейнером в поде. Когда service mesh запускается на платформе кубернетес, data plane service mesh представлен sidecar-контейнером, который выполняется рядом с основным контейнером в поде. Эти sidecar-контейнеры обеспечивают взаимодействие между сервисами в разных подах.
Таким образом теперь взаимодействие между подами происходит не через kube-proxy, а через sidecar: под обращается к sidecar-контейнеру и уже через него общается с другими подами.
Безопасность, автоматические повторы запросов, мониторинг и другие возможности обрабатывает sidecar-контейнер, а приложение содержит только бизнес-логику.
Две самых популярных реализации service mesh — Istio и Consul. Мы познакомимся только с Istio.
Istio
Istio — это service mesh с открытым кодом, который прозрачно накладывается на существующие распределённые приложения. Istio предлагает единообразный и эффективный подход к безопасности, взаимодействию и мониторингу.
Control plane в Istio реализована в контейнере Istiod, а data plane развёртывается в поде как sidecar с помощью контейнера с Envoy.
Istiod отвечает за обнаружение сервисов, конфигурацию и управление сертификатами. Он преобразует высокоуровневые правила маршрутизации трафика в конфигурации для Envoy, а затем распространяет их по sidecar-контейнерам в рантайме.
Прокси Envoy развёртываются как sidecar’ы в подах и дают несколько возможностей:
- динамическое обнаружение сервисов;
- балансировки нагрузки;
- терминация TLS;
- прокси HTTP/2 и gRPC;
- размыкатели цепи;
- проверки работоспособности;
- постепенное развёртывание с процентным разделением трафика;
- внесение ошибок;
- всевозможные метрики.
Сейчас Istio — это проект Cloud Native Computing Foundation (CNCF).
Теперь вы знаете, зачем микросервисам нужна service mesh и причём тут Istio.
