[Системное администрирование, DevOps, Микросервисы, Kubernetes] Service Mesh Wars, прощаемся с Istio (перевод)
Автор
Сообщение
news_bot ®
Стаж: 6 лет 3 месяца
Сообщений: 27286
Фото 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.
===========
Источник:
habr.com
===========
===========
Автор оригинала: Eric Fossas
===========Похожие новости:
- [Управление разработкой, Управление проектами, Agile, Управление продуктом, Карьера в IT-индустрии] Гайд по сертификациям. Часть 1. Agile
- [Системное администрирование, PostgreSQL, Администрирование баз данных] Что нового в плане мониторинга в PostgreSQL 14
- [Amazon Web Services, Angular, DevOps] Сам себе DevOps: строим cloud-only CI для веб приложения
- [Разработка мобильных приложений, Тестирование мобильных приложений, Управление проектами, Аналитика мобильных приложений, Читальный зал] Подборка 150+ ресурсов для управления и работы IT-команды
- [DevOps] «No Windows no problems» What?
- [DevOps] Кастомизация внешнего вида Drone CI 2.0
- [Настройка Linux, Системное администрирование, Nginx, *nix] Немного об использовании regex в map nginx
- [IT-инфраструктура, Учебный процесс в IT, Распределённые системы] Kafka, Lamoda и непреодолимое желание учиться
- [Open source, Виртуализация, Карьера в IT-индустрии, Openshift] Quarkus и разработка еdge-систем IoT, шпаргалка по Kubernetes, а также электронная книга «Ansible for DevOps»
- [Системное администрирование, IT-компании] Как работает Team Viewer
Теги для поиска: #_sistemnoe_administrirovanie (Системное администрирование), #_devops, #_mikroservisy (Микросервисы), #_kubernetes, #_service_mesh, #_istio, #_linkerd, #_blog_kompanii_southbridge (
Блог компании Southbridge
), #_sistemnoe_administrirovanie (
Системное администрирование
), #_devops, #_mikroservisy (
Микросервисы
), #_kubernetes
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Май 01:30
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 3 месяца |
|
 Фото Brian McGowan, Unsplash.com Мы использовали Istio в продакшене почти два года, но больше не хотим. Я расскажу, чем мы недовольны и как выбрали другую service mesh. Начнем с начала. Зачем вообще нужна service mesh?
Получается, всего две функции. Зато какие полезные. Многие service mesh предлагают дополнительные фичи, например, разделение трафика, повторные попытки и т. д. Как по мне, не самые нужные функции. Во всяком случае для sidecar-proxy. Их часто используют не по назначению, чтобы закрыть проблемы, которые требуют другого решения. Сложно ли использовать service mesh? Да. Вы набьете немало шишек, пока не поймете, что: Service mesh пока стабильно работает только для HTTP-трафика
Сетевые вызовы контейнера приложения не работают, если не запущен sidecar-прокси
Были какие-то разговоры о нативных sidecar в Kubernetes (чтобы помечать контейнер в поде как sidecar, который должен запускаться первым делом). Ожидалось, что они появятся в версии 1.20, но в итоге предпочтение отдали фичам, которые охватывают максимальное количество вариантов использования. Обходные решения, конечно, есть, но тогда service mesh не будет полностью прозрачной для разработчика — придется менять код или деплой. Init-контейнеры и cronjob не могут использовать service mesh
Для этого, вроде, тоже есть обходные пути, но я ни одного годного не встречал. Использую ли я 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:
Что мне не нравится в 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. =========== Источник: habr.com =========== =========== Автор оригинала: Eric Fossas ===========Похожие новости:
Блог компании Southbridge ), #_sistemnoe_administrirovanie ( Системное администрирование ), #_devops, #_mikroservisy ( Микросервисы ), #_kubernetes |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Май 01:30
Часовой пояс: UTC + 5