Битва сервисных сеток Kubernetes: Istio против Consul

Появление сервисных сеток значительно упростило работу по облегчению (и регулированию) взаимодействия между микросервисами. До того, как Consul или Istio появились в экосистеме Kubernetes, запуск микросервисов в продакшене был и вполовину не таким простым, как развертывание. Хотя Kubernetes отлично справляется с абстрагированием инфраструктуры, обеспечивая единообразие развертывания, единообразие во время выполнения по-прежнему оставляет желать лучшего.

Это связано не только с эфемерной природой контейнеров, но и с тем фактом, что при неправильном управлении межпроцессное взаимодействие может довольно быстро выйти из-под контроля. Кроме того, сам масштаб и объем, в котором обычно работают эти службы, делают задачу ручного отслеживания их одновременно сложной и неустойчивой. Именно здесь вступает в действие технология Service Mesh, которая позволяет абстрагироваться от сложностей, связанных с контролем и мониторингом трафика между микросервисами.

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

Чемпион

Istio, одна из наиболее широко используемых сервисных сеток, поддерживаемая Google, IBM, Lyft, Red Hat, Pivotal и Cisco, предоставляет функции уровня 7 как для маршрутизации трафика, так и для телеметрии. Подобно тому, как функционирует SDN, Istio разделен на плоскость данных и плоскость управления, где плоскость данных состоит из дополнительных прокси-серверов, а плоскость управления дополнительно разделена на три компонента. Политики доступа можно настроить как для свойств уровня 7, так и для уровня 4.

В то время как первый компонент под названием Pilot помогает пользователям настраивать плоскость данных, второй компонент под названием Mixer, который собирает метрики и отвечает на запросы из плоскости данных, вскоре будет переписан на C++ и напрямую встроен в Envoy для экономии времени обработки. Третий компонент под названием Citadel упрощает создание сред с нулевым доверием на основе идентификатора службы.

Фирменные ходы

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

Кроме того, Istio — это наглядность и прозрачность, позволяющие вам понять всю сложность взаимоотношений внутри службы. Он не зависит от платформы, поэтому пользователи могут беспрепятственно управлять трафиком между микросервисами на различных платформах. Это особенно полезно в многооблачных или гибридных облачных средах, которые охватывают как локальные объекты, так и общедоступные облака. Он также поставляется со всеми встроенными функциями Envoy, такими как обнаружение сервисов, балансировка нагрузки, завершение TLS, маршрутизация подмножества, прокси-серверы gRPC и проверки работоспособности, а также собственные возможности управления трафиком, безопасности, наблюдения и интеграции.

Претендент

Общеизвестно, что чем больше компонентов или «подвижных частей» состоит из вашей сервисной сетки, тем больше времени требуется на обработку и тем ниже общая производительность. В то время как Istio интегрировал свой компонент Mixer с Envoy, чтобы снизить требования к ресурсам и повысить производительность, Consul пошел еще дальше, включив как данные, так и плоскость управления в один двоичный файл.

Это достигается с помощью «агентной» модели, в которой на каждом узле работает клиент с локальным кешем, который постоянно обновляется сервером. Это не только снижает потребность во внешних коммуникациях, но также позволяет быстро и эффективно вносить изменения на периферии. Кроме того, это чрезвычайно упрощенный и портативный дизайн, что делает его настоящим полносвязным сервисом, где API-интерфейсы реагируют намного быстрее и где нет централизованных плоскостей, которые могут создавать узкие места и отрицательно влиять на производительность.

Свобода подключения

Consul поставляется с подключаемой плоскостью данных, которая поддерживает сторонние прокси, такие как Envoy. Однако это также дает вам возможность использовать встроенный прокси-сервер, который проще в использовании, но имеет значительный компромисс в производительности. Разные прокси лучше подходят для разных приложений, а возможность выбора дает пользователям гибкость в развертывании прокси, лучше всего подходящего для задачи. Это также немного расширяет возможности, поскольку теперь у вас есть один двоичный файл, который не только запускает вашу сервисную сетку, но и интегрируется с такими мощными инструментами, как Jenkins, Grafana и Telegraf.

Если поддержки сторонних прокси-серверов недостаточно с точки зрения гибкости, приложения также могут «нативно» интегрироваться с протоколом Connect. Consul Connect — еще одна «встроенная» функция, использующая Transport Layer Security (TLS) для обеспечения межсервисного шифрования, а также авторизации. Преимущество этого заключается в том, что, несмотря на незначительное снижение производительности, все приложения, поддерживающие Connect, могут взаимодействовать с другими службами, поддерживающими Connect, независимо от того, используют ли они прокси-сервер или также являются приложениями Connect-native.

Большой бой

Хотя Consul является заманчивым вариантом, поскольку он чрезвычайно легкий и оптимизированный, у него есть несколько недостатков: он обеспечивает авторизацию и идентификацию только для уровня 4, хотя в будущем планируется добавить функции уровня 7. Однако подключаемый уровень данных компенсирует этот недостаток, и пользователи могут использовать прокси-сервер, который поддерживает необходимые функции уровня 7. Кроме того, хотя оба сервиса поддерживают TLS, только Istio поддерживает встроенное управление сертификатами. Это означает, что в отличие от Consul, где все управляется за вас, Istio позволяет вам вручную изменять или отзывать сертификаты в случае их взлома.

Istio, будучи более популярным из двух, имеет гораздо большее сообщество и богатый опыт, заключенный в нем. Однако, с другой стороны, тот факт, что в Consul нет центрального уровня управления, позволяет пользователям вносить быстрые изменения на периферии без необходимости обращаться к центральному сервису, такому как Mixer в Istio. Consul также позволяет вам делать интересные вещи, например хранить половину ваших микросервисов в Kubernetes, а другую половину — в виртуальных машинах. Вот почему с точки зрения абсолютной универсальности и актуальности с точки зрения того, что действительно нужно корпоративным клиентам прямо сейчас, Consul является довольно хорошим выбором. Его базовый архитектурный дизайн также делает его намного более масштабируемым, чем другие сервисные сетки, доступные прямо сейчас. Преимущество также в том, что для использования Consul не нужно устанавливать никаких дополнительных систем. Эта архитектура позволяет легко установить Consul на любую платформу, в том числе непосредственно на «голое железо».

Сервисные сетки очень похожи на SDN с их плоскостями данных и управления, но большая разница заключается в том, что они предназначены для изменчивых, эфемерных сред и ориентированы на «интеллектуальную» сеть с множеством вспомогательных функций. И у Istio, и у Consul есть свои плюсы и минусы, но правда в том, что они оба одинаково важны, если рассматривать экосистему Kubernetes как общую картину. Смысл в том, чтобы иметь решение для всех, поэтому, если вы ищете многофункциональный опыт с множеством поддержки, пошаговых руководств и других людей с такими же проблемами, как и вы, Istio — это то, что вам нужно. Однако, если ресурсы являются вашим приоритетом, Consul — это то, что вам нужно, или, по крайней мере, до тех пор, пока кто-то не придумает «легковесную» сетку, которая не работает ни на чем и не использует ресурсы.