5 способов улучшить сетевую производительность контейнерных приложений
Сеть — это следующий рубеж в контейнерах сегодня. По мере того, как мир осваивает идею мультиоблака, препятствием, которое необходимо преодолеть на пути к этому, являются сети. Контейнерная сеть сложна по разным причинам. Контейнеры имеют короткий срок службы, намного меньше, чем у виртуальных машин, поэтому обнаружение сервисов имеет жизненно важное значение. Контейнеры приводят к распределенным системам, которые требуют более сложных моделей связи между контейнерами, модулями, службами и кластерами. Все контейнеры должны иметь возможность общаться со всеми другими контейнерами. Это заставило бы любого сетевого администратора съежиться, если бы он услышал это лет пять назад. Тем не менее, именно такие масштабные изменения привнесли контейнеры и контейнерные приложения в мир сетевых приложений.
1. Разберитесь с основами пространств имен контейнеров
Ключом к пониманию и работе с контейнерными сетями и контейнерными приложениями является концепция пространств имен. В одной из первых презентаций о контейнерах Docker Жером Петаццони объясняет роль пространств имен в функционировании контейнеров. По сути, пространство имен ограничивает то, что вы можете видеть в контейнере. Для каждого процесса, составляющего контейнер, существует несколько пространств имен, и вместе они ограничивают и разрешают доступ к контейнеру.
Kubernetes также следует тому же принципу пространств имен для изоляции различных компонентов, таких как модули, службы и контроллеры репликации. Между контейнерами, модулями, сервисами и даже внешними сервисами происходит взаимодействие. Трафик между модулями осуществляется с востока на запад, а связь с внешними службами — с севера на юг. Ingress — это когда трафик направляется из внешней службы во внутреннюю службу Kubernetes. Выход — это наоборот, когда служба Kubernetes выполняет вызов внешней службы. Несмотря на сложную маршрутизацию трафика, пространства имен по-прежнему являются основным механизмом управления, используемым для принятия решения о том, когда разрешить запрос, а когда отклонить его.
2. Используйте сеть на основе политик
Сеть играет ключевую роль в обеспечении не только функционирования, но и безопасности контейнеров, модулей и сервисов. Но чтобы сеть функционировала в массовом масштабе, характерном для Kubernetes, ею необходимо управлять с помощью политик. Вот почему сетевые политики имеют решающее значение для правильного построения сети.
Kubernetes поддерживает сетевые плагины, такие как Flannel, которые используются для управления сетевым взаимодействием. Когда дело доходит до применения политик, можно попробовать два ключевых плагина — Calico и Weave. Calico особенно завоевывает популярность среди пользователей и общеотраслевую поддержку со стороны поставщиков облачных услуг из-за своих сильных сторон в сетях на основе политик. Docker объявил, что они будут включать экземпляры Calico в Docker Enterprise 3.0 и свое предложение Windows Server. Точно так же Google Cloud объявил, что Calico станет частью ее службы GKE и поможет с настройкой гибридного облака. Ключевой проблемой здесь является сетевое взаимодействие между распределенными системами. В прошлом это было неприемлемо для сетевых администраторов, но сегодня это норма для рабочих нагрузок контейнеров. Поставщики публичных облаков работают с лучшими инструментами с открытым исходным кодом, чтобы обеспечить такую распределенную сетевую связь с помощью политик.
Сетевые политики можно использовать для разрешения или запрета всего трафика к службе Kubernetes. Их также можно использовать, чтобы разрешить связь со службами только определенным источникам из белого списка или заблокировать только определенные источники из черного списка. Самое приятное то, что после установки эти политики можно изменить в любое время, и изменение вступит в силу немедленно. Это обеспечивает большую эффективность при внесении изменений в настройку сети. В динамической контейнерной среде, где срок службы контейнеров невелик, наличие гибкого и столь же динамичного сетевого взаимодействия является обязательным.
3. Используйте сервисную сетку для разделения задач
Инструменты Service Mesh заняли центральное место на конференциях Kubernetes за последний год. В частности, Istio получил быстрое распространение в отрасли. Причиной этого является его способность разделять две задачи — данные и управление сетевым трафиком. Istio использует Envoy в качестве дополнительного прокси-сервера для управления сетевым трафиком. Существуют и другие варианты Service Mesh, такие как Linkerd и SuperGloo, но на сегодняшний день Istio занимает привилегированное положение. Azure недавно представила Service Mesh Interface в сотрудничестве с Buoyant (создатели Linkerd), Solo.io (создатели SuperGloo) и HashiCorp. Идея Microsoft состоит в том, чтобы не рисковать и не делать ставку на одну лошадь, а скорее следовать отраслевой тенденции в отношении сервисных сеток. Они хотят предоставить клиентам Azure возможность выбора любого инструмента сервисной сетки, который они хотели бы использовать, и им не нужно рисковать всем, выбирая какой-то один. Хотя экосистема с энтузиазмом относится к Istio, многие, такие как Microsoft, считают ее фрагментированной и предпочли бы выбрать более безопасный путь и не идти ва-банк с любимцем дня — Istio.
4. Мультиоблако требует подключения к нескольким кластерам
С момента приобретения Red Hat компанией IBM все чаще обсуждают мультиоблако. Действительно, сегодня большинство предприятий не привязаны только к одному поставщику облачных услуг, они смешивают и подбирают решения для удовлетворения потребностей каждого приложения и каждой команды. Некоторые могут запускать рабочие нагрузки на платформах поставщиков облачных услуг до пяти. В этом случае возрастает вероятность того, что кластерам Kubernetes потребуется взаимодействовать между облачными платформами или кластеру необходимо будет перенести его с одной платформы на другую. Зная это, Rancher представила Submariner, инструмент с открытым исходным кодом, который позволяет создавать многокластерные сети. Хотя в Kubernetes уже есть средства для межкластерной связи, для связи между кластерами требуются входные контроллеры и порты узлов. Submariner упрощает эту связь, создавая туннели и шаблоны маршрутизации между кластерами, даже если они находятся на разных общедоступных облачных платформах. Этот тип межоблачной связи станет более распространенным в будущих мультиоблачных приложениях, и сегодня создаются инструменты и решения для поддержки этого типа сетевого взаимодействия. 
5. Следите за облегченными виртуальными машинами на будущее
Интересная вещь о Kubernetes заключается в том, что обсуждается его роль гипервизора в будущем. Виртуальные машины не исчезнут полностью, но их превосходные возможности изоляции лучше подходят для сетей, ориентированных на безопасность. В таких отраслях, как финансовые услуги, в этом по-прежнему существует большая потребность. Появляются легкие решения для виртуальных машин, такие как Firecracker от AWS и Kata Containers. Для этих решений пока рано, но, учитывая, насколько сильно фрагментирован рынок, очень высока вероятность того, что они смогут найти себе постоянное место.
Контейнерные приложения: общение имеет ключевое значение
Сеть является ключом к контейнерным приложениям и управлению контейнерами. Чтобы контейнерные приложения были успешными, контейнеры должны взаимодействовать друг с другом, независимо от того, находятся ли они в одном модуле или на разных облачных платформах. Сеть — это то, что обеспечивает такой вид связи. Это начинается с понимания того, как пространства имен определяют, как происходит взаимодействие с контейнерами. Кроме того, когда сетевое взаимодействие необходимо масштабировать, сеть на основе политик является единственным выходом вперед. К счастью, такие инструменты, как Calico и Weave, справляются с этой задачей. Наряду с этими инструментами инструменты сервисной сетки, такие как Istio, созданы для упрощения всей этой сложности и предоставления сетевому администратору большего контроля над данными, которые проходят через сеть, и возможности легкого управления ими. Будущее примерно такое же: приложения становятся еще более фрагментированными из-за того, что они охватывают несколько облаков, а типы экземпляров стирают границы между контейнерами и виртуальными машинами. Чтобы преуспеть в мире контейнеров и множества облачных платформ, сеть является критическим компонентом. Зная об этом, сообщество открытого исходного кода и поставщики облачных услуг заняты разработкой самых сложных, масштабируемых и открытых сетевых решений, которые мы когда-либо использовали.