Как стать автором
Обновить
70.25
Слёрм
Учебный центр для тех, кто работает в IT

Service Mesh Wars, прощаемся с Istio

Время на прочтение 5 мин
Количество просмотров 7.5K
Автор оригинала: Eric Fossas

image
Фото Brian McGowan, Unsplash.com


Мы использовали Istio в продакшене почти два года, но больше не хотим. Я расскажу, чем мы недовольны и как выбрали другую service mesh.


Начнем с начала.


Зачем вообще нужна service mesh?


  • Она мониторит трафик между микросервисами, включая схему взаимодействия и коды статусов HTTP между ними.
  • Она позволяет добавлять mTLS, то есть шифрованный HTTP-трафик между сервисами.

Получается, всего две функции. Зато какие полезные.


Многие service mesh предлагают дополнительные фичи, например, разделение трафика, повторные попытки и т. д. Как по мне, не самые нужные функции. Во всяком случае для sidecar-proxy. Их часто используют не по назначению, чтобы закрыть проблемы, которые требуют другого решения.


Сложно ли использовать service mesh?


Да. Вы набьете немало шишек, пока не поймете, что:


Service mesh пока стабильно работает только для HTTP-трафика

Я работал с Istio и Linkerd, и обе вроде как должны поддерживать много разных протоколов, но на деле не все так радужно. Поддержка некоторых протоколов баз данных в Istio очень нестабильна в зависимости от версии. Linkerd не справляется с AMQP. И обе выдают странные ошибки для HTTPS. Видимо, написать прозрачный сетевой прокси не так-то просто. Пока я доверил бы service mesh только HTTP. С другой стороны, мне и не нужны другие протоколы для взаимодействия между сервисами Kubernetes.


Сетевые вызовы контейнера приложения не работают, если не запущен sidecar-прокси

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


Были какие-то разговоры о нативных sidecar в Kubernetes (чтобы помечать контейнер в поде как sidecar, который должен запускаться первым делом). Ожидалось, что они появятся в версии 1.20, но в итоге предпочтение отдали фичам, которые охватывают максимальное количество вариантов использования.


Обходные решения, конечно, есть, но тогда service mesh не будет полностью прозрачной для разработчика — придется менять код или деплой.


Init-контейнеры и cronjob не могут использовать service mesh

Почему? Контейнер прокси в service mesh никогда не завершает работу, а значит контейнеры init и cronjob никогда не выполняются до конца. В первом случае контейнер приложения так и не запустится, а во втором — время ожидания cronjob истечет и задание завершится ошибкой.


Для этого, вроде, тоже есть обходные пути, но я ни одного годного не встречал.


Использую ли я service mesh?


У меня получалось успешно использовать их в кластерах в продакшене и стейджинге в двух случаях: sidecar-прокси отслеживают только HTTP-трафик и mTLS настроен как необязательный (при этом условии под за пределами mesh может общаться с подом в mesh).


Я не использую service mesh в кластерах для ревью — запускать ревью приложений в service mesh слишком хлопотно.


Почему я удалил Istio?


Главная причина — его было очень сложно использовать. На изучение Istio у меня ушло примерно столько же времени, сколько на изучение Kubernetes.


Мне понадобилось несколько недель на конфигурацию Helm-чарта для деплоймента Istio (обычно я укладываюсь в один день).


Для Istio нужно слишком много CRD (Custom Resource Definition). Я стараюсь избегать их, чтобы не попадать в зависимость от вендора. У меня ушло много времени и сил, чтобы разобраться с CRD для основных ресурсов, вроде Gateway, VirtualService и DestinationRule, а в документацию приходилось заглядывать гораздо чаще, чем хотелось бы.


Если честно, я побаивался Istio. Это же огромная единая точка отказа. Самое ужасное у нас случилось, когда один из разработчиков неправильно назвал секрет Kubernetes с секретом TLS для шлюза. Все шлюзы сломались и потянули за собой весь кластер. Был такой баг, из-за которого Istio, не найдя нужный секрет, просто не настраивалась и переставала работать совсем. Мы чуть с ума не сошли, пока искали ошибку, — в логах на нее вообще ничего не указывало. Это не единственный случай, когда Istio полностью отказывает. Обычно это связано с передачей конфигурации в прокси Envoy. В документации это называется Break Glass Configuration (аварийная конфигурация).


Наконец самое важное — в Istio отказались от Helm в пользу собственной утилиты командной строки istioctl… а потом снова вернули Helm. Я не хочу деплоить сорок с лишним инструментов поддержки на кластерах кучей разных методов, поэтому я расстроился, когда они прекратили поддержку Helm, который используется у меня в каждом втором инструменте. Еще больше я огорчился, когда все вернули назад и мне пришлось снова все восстанавливать, чтобы проапгрейдиться до последней версии Istio.


Почему я вообще выбрал Istio?


Когда Kubernetes только появился, у него было три главных конкурента — Mesos, Nomad и Swarm, но все очень быстро поняли, что Kubernetes победит.


Никогда не слышал, чтобы кто-то использовал Mesos (нелегко им пришлось без поддержки крупной корпорации), но знаю, что они сильно повлияли на оркестрацию контейнеров.
Swarm использовали чаще, но только потому, что он «проще», чем Kubernetes. Лично я не верил в успех этого проекта — за простотой на самом деле скрывался недостаток функционала. В Kubernetes все тоже несложно, если им не сильно пользоваться.


Nomad пока никуда не делся и, в принципе, неплохо работает с оркестрацией процессов прямо на серверах. Если вам нужна только оркестрация контейнеров, очень рекомендую Kubernetes.
В общем, когда появилась Istio, все было примерно так же. У неё был только один конкурент — Linkerd (который лично у меня почему-то ассоциировался со Swarm), при этом Istio тоже была детищем Google. Вот её я и выбрал.


А потом service mesh начали появляться, как грибы после дождя, — сначала AppMesh от AWS, потом Maesh от Traefik, потом Azure Open Service Mesh (название, видимо, намекает на то, что Istio упорно не входит в CNCF) и service mesh от Nginx. И это еще не все. Обычно для создания service mesh вендоры (например, Kuma и Consul Connect) используют прокси Envoy.


Явного победителя я тут не вижу.


Что я использую сейчас?


Сравнив несколько service mesh, я остановился на оригинале — Linkerd. Остальные варианты либо пытаются привязать меня к вендору, либо делают не то, что я хочу (например, Maesh добавляет прокси к ноде, а не к поду).


Что мне нравится в Linkerd:


  • Она поддерживает деплои с Helm (правда, я использую модифицированную версию Helm и немного кастомного кода, чтобы избежать конфигурации вручную извне).
  • С ней просто работать. Нужно только одно CRD, а Helm-чарт было легко освоить.
  • У неё приятный дашборд. Istio использует Grafana/Promethus и Kiali. Linkerd тоже использует Grafana/Prometheus, а еще специальный кастомный дашборд, который легко использовать.
  • Они написали собственный прокси на Rust (в версии 2). Сначала я засомневался, ведь Envoy так популярен, а потом понял, что так Linkerd стала только динамичнее. Envoy разросся до огромных размеров и пытается поддерживать очень много вендоров, а Linkerd вольны делать со своим прокси что захотят, и это серьезно ускоряет разработку. И все написано на Rust! Круто же?
  • Они входят в CNCF. В отличие от Istio.
  • Linkerd выбрали правильный подход. Istio сначала хватили лишнего с разными деплойментами, которыми нам приходилось управлять, а теперь перешли на единый деплоймент. Linkerd с этого начали. Другие деплойменты у них тоже есть, но не основные. Они добавляют новые фичи, но заботиться нужно только о главном деплойменте.

Что мне не нравится в Linkerd?


Всего одна мелочь, и та скорее про маркетинг — они заявляют, что service mesh можно установить и настроить всего за пять минут. Но, как вы понимаете, service mesh вряд ли можно назвать почти готовым решением. У Linkerd те же проблемы, что и у остальных, например, отсутствие нативных sidecar или ненадежная обработка других протоколов, кроме HTTP.


Заключение


Может быть, однажды мы перестанем заморачиваться выбором service mesh — как сейчас мало кто знает, какую оверлейную сеть он использует с Kubernetes. Каждая service mesh внедряет SMI (Service Mesh Interface), так что когда-нибудь, будем надеяться, service mesh станет просто нативным ресурсом в Kubernetes. Принятие открытых стандартов — первый шаг в этом направлении.


Мне не нравится, что Istio нет в CNCF, и объяснения Криса Дибоны (Chris DiBona) в Kubernetes Podcast меня не переубедили.


Linkerd входит в CNCF, и если они не будут ничего усложнять, я планирую пока остаться с ними.


Жду с нетерпением, когда в Kubernetes появится нативное решение для sidecar.

Теги:
Хабы:
+22
Комментарии 5
Комментарии Комментарии 5

Публикации

Информация

Сайт
slurm.io
Дата регистрации
Дата основания
Численность
51–100 человек
Местоположение
Россия
Представитель
Антон Скобин