Comments 12
Очень крутая статья. Автор практически убедил меня, что нужно попробовать помимо Istio его детище — Linkerd.
С другой стороны, я полностью согласен с тем, что Большой Брат в лице Гугла очень навязывает нам две основные технологии в своем портфеле — Kubernetes и Istio да так, что все остальные аналоги (не всегда плохие!) остаются в тени.
Спасибо, отличная статья. А есть ли у кого-нибудь опыт использования Service Mesh на проде? Интересно было бы послушать.
Если у вас есть grpc и вы деплоитесь в Kubernetes, то у вас в общем-то не будет большого выбора внедрять или не внедрять service mesh.
Ну собственно HAProxy использовался как service mesh ещё когда такого набора слов даже не было, и по граблям с ним тоже походили (привет, пулы с протухшими соединениями). Интересно, как эта проблема решается в Istio/Linkerd
Так как горячие головы могут уверовать в технологию, сразу сообщаю, что всё будет не так просто. Есть некоторое количество серьёзных issue как в Linkerd2, так и в самом Kubernetes, которые если не препятствуют, так точно серьёзно усложняют обслуживание service mesh, при чём не только Linkerd.
Кроме того чисто технически растут накладные расходы, об этом в статье упомянуто. А вот о чём не сказано, так это то, что по-умолчанию Linkerd устанавливает MutatingWebhookConfiguration на который условно можно полагаться только в самых свежих версиях Kubernetes. Да и то я бы не рискнул, уж очень неприятные сайд-эффекты при проблемах. Так что automatic sidecar injection стоит заменять на ручную через CI, которая менее зависима от событий кубернетиса и не вызывает падение всего кластера в случае отказов.
В статье также не указывается одна важная мысль: linkerd в виде sidecar proxy НЕ является Ingress Controller. И все преимущества в виде retry/… НЕ будут доступны для внешних пользователей по-умолчанию, если ваш Ingress не встроен в service mesh. То есть это прежде всего _между сервисная коммуникация внутри кластера_, а не балансировщик нагрузки пользовательских запросов. А вот Linkerd v1 могла выполнять и функцию балансировки для конечных потребителей.
А ещё для того же Canary требуются сторонние тулзы.
Кроме того чисто технически растут накладные расходы, об этом в статье упомянуто. А вот о чём не сказано, так это то, что по-умолчанию Linkerd устанавливает MutatingWebhookConfiguration на который условно можно полагаться только в самых свежих версиях Kubernetes. Да и то я бы не рискнул, уж очень неприятные сайд-эффекты при проблемах. Так что automatic sidecar injection стоит заменять на ручную через CI, которая менее зависима от событий кубернетиса и не вызывает падение всего кластера в случае отказов.
В статье также не указывается одна важная мысль: linkerd в виде sidecar proxy НЕ является Ingress Controller. И все преимущества в виде retry/… НЕ будут доступны для внешних пользователей по-умолчанию, если ваш Ingress не встроен в service mesh. То есть это прежде всего _между сервисная коммуникация внутри кластера_, а не балансировщик нагрузки пользовательских запросов. А вот Linkerd v1 могла выполнять и функцию балансировки для конечных потребителей.
А ещё для того же Canary требуются сторонние тулзы.
Проведя поиск по фразе «service mesh», вы наткнетесь на кучу переработанного низкокалорийного контента, странных проектов и калейдоскопа искажений, достойных эхо-камеры. Любой модной новой технологии свойственно это, но в случае service mesh проблема стоит особенно остро.
Интересно, как скоро Service Mesh настигнет судьба REST?
А что с REST?
Аналогичная подмена понятий и девальвация термина из-за маркетингового хайпа.
https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
https://tyk.io/rest-never-crud/
https://stackoverflow.com/questions/19884295/soap-vs-rest-differences/19884975#19884975
https://www.infoq.com/articles/web-api-rest/
https://www.infoq.com/news/2016/07/microsoft-rest-api/
https://github.com/Microsoft/api-guidelines/pull/29
https://en.wikipedia.org/wiki/Talk:Representational_state_transfer
У Netflix была Hysterix, у Google была Stubby, у Twitter — библиотека Finagle. Finagle, например, была обязательной для каждого нового сервиса в Twitter.… Конечно, она работала только для JVM-языков… Однако ее функциональные возможности были почти такими же, как и у service mesh. (На самом деле первая версия Linkerd просто представляла собой Finagle, обернутый в форму прокси.)
… Должен был произойти еще один сдвиг, прежде чем она появилась.
То, что кубер стал популярным ещё не значит что надо сделать этот шаг, отказаться от библиотеки и наворачивать service mesh.
Единственный плюс который я вижу — если в компании действительно есть микросервисы на разных языках программирования.
Если всё пишется на одном — лучше общую либу.
вся модель service mesh основана на этом постулате: в мультисервисной системе, независимо от того, что делают отдельные сервисы, трафик между ними является идеальной точкой для добавления функциональности.
Так себе идея, размазывать логику между кодом и service mesh.
Интересный пост на twitter от коллег которые используют linkerd вместо istio: twitter.com/wm/status/1206998532659376128?s=19
Там скриншоты из внутреннего Slack, не могу скопировать сюда текстом.
Там скриншоты из внутреннего Slack, не могу скопировать сюда текстом.
Метрики можно собирать Zabbix'om, а сообщения гарантированно доставлять с помощью MQ или RPC. Прочитав так и не понял, что нового и уникального в этом софте. А еще так же не понятно как быстро это работает. В целом автор статьи пушит свою идею как паровоз, поэтому создает впечатление необъективной переоценки. Вобщем считаю это оверинжиниринг, как написал выше уже давно существуют проверенные инструменты, которые пишут свои команды. Простой вопрос, если коммуникация происходит через MQ, зачем ваше решение?
Sign up to leave a comment.
Service Mesh: что нужно знать каждому Software Engineer о самой хайповой технологии