Связывание кластеров Kubernettes с VPC на AWS

Несколько месяцев назад кто-то спросил меня, как лучше всего подключить сервисы, работающие в разных кластерах Amazon EKS (EKS), работающих в двух разных VPC. Мысли о подключении сетевых ресурсов через AWS VPC напомнили мне о первых днях AWS, когда вам нужно было реализовать [сложную архитектуру с концентраторами и лучами] (https://docs.aws.amazon.com/whitepapers/latest/building-scalable- secure-multi-vpc-network-infrastructure/transit-vpc-solution.html) для подключения к виртуальной частной сети Amazon (VPC). К счастью, у AWS есть новые сервисы, которые упрощают взаимодействие VPC.

Клиенты AWS могут подключать сетевые ресурсы в разных аккаунтах AWS с помощью пиринга VPC, AWS Transit Gateway, общего доступа к VPC, AWS PrivateLink или сторонних решений.

Учитывая, что вариантов так много, я не был уверен, какое решение порекомендовать. Вопрос, который мне задали, требовал лучшего понимания сетевых сервисов AWS. Вот исследование, которое я провел, чтобы понять наиболее оптимальный подход к подключению размещенных сервисов Kubernetes, работающих в отдельных VPC.

Примечание. Я не эксперт по сетям AWS. Этот пост был взят из документации AWS и этого AWS whitepaper .

Симметричный и асимметричный поток

Прежде чем выбрать решение для соединения сервисов между разными VPC, вы должны рассмотреть свои требования к подключению данных. Существует два типа шаблонов подключения между набором сетевых ресурсов.

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

Симметричный поток противоположен. В этом шаблоне подключения к данным любая сторона (клиент или сервер) может инициировать подключение.

Клиенты, желающие подключить приложения, размещенные на Kubernetes, работающие в разных учетных записях AWS, должны будут начать с определения шаблонов подключения к данным, которые будут использовать их приложения и сервисы.

Подключение сервисов, размещенных в разных учетных записях AWS

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

При соединении частных служб, которым требуется симметричный поток, любая служба должна иметь возможность инициировать соединение с другой службой. Обнаружение служб является обязательным условием подключения. Службы должны знать, как подключаться к нижестоящим службам. Как только эта проблема будет решена (используя DNS или [Консул] (https://www.consul.io) и т. д.), есть два основных способа подключения сервисов:

1. Пиринг VPC (включая TGW) или совместное использование VPC

1. Приватная ссылка AWS

Основное различие между этими двумя подходами заключается в том, что после настройки пиринга или совместного использования VPC сетевые ресурсы (экземпляры EC2, модули, контейнеры) в VPC могут соединяться по умолчанию.

AWS PrivateLink обеспечивает безопасный доступ к сервисам, размещенным в других VPC, без пиринга или совместного использования VPC. Вы делаете это, настраивая конечную точку интерфейса для доступа к сервису в другом VPC. Поскольку управление доступом является более точным, вам может потребоваться создать конечную точку интерфейса на базе PrivateLink для каждой размещенной службы Kubernetes, использующей другой балансировщик сетевой нагрузки.

Со временем большинство крупных предприятий будут (многие уже используют) использовать комбинацию сетевых сервисов AWS в зависимости от варианта использования. В следующем разделе мы рассмотрим сетевые сервисы AWS и определим сценарии, в которых они подходят.

🛟Пиринг VPC

Когда службы должны потреблять другие службы, работающие в разных VPC, что требует симметричного потока, пиринг VPC — это самый простой способ обеспечить взаимосвязь.

Вы можете подключить VPC, в которых находятся ваши кластеры EKS, если у вас есть возможность заранее спланировать CIDR VPC (обратите внимание на преднамеренную избыточность 🙂) и не иметь слишком много VPC для соединения или требовать [транзитивного маршрутизация] (https://docs.aws.amazon.com/vpc/latest/peering/invalid-peering-configurations.html).

🚉 Транзитный шлюз AWS

AWS Transit Gateway (TGW) — это еще один вариант подключения VPC везде, где сервисы должны соединяться с симметричным потоком.

TGW предназначен для упрощения создания и управления несколькими одноранговыми соединениями VPC в масштабе. Он может выступать в качестве центрального маршрутизатора для крупномасштабных глобально распределенных сетей корпоративного уровня.

TGW — это выбор по умолчанию для пользователей EKS, которым необходимо соединить свои кластеры с более чем 10 VPC и которым нужен симметричный поток.

Есть ли причины не использовать TGW?

Старый добрый пиринг VPC все еще имеет в рукаве некоторые хитрости, которые TGW еще не освоила. Вот несколько причин, по которым TGW может не подойти вам:

• Низкая стоимость — при пиринге VPC вы платите только за передачу данных. Transit Gateway взимает почасовую плату за вложение в дополнение к плате за передачу данных. Например, в США-Восток-1:

• Без ограничений по пропускной способности — при использовании Transit Gateway максимальная пропускная способность (в пакетном режиме) на зону доступности для каждого соединения VPC составляет 50 Гбит/с. Пиринг VPC не имеет совокупной пропускной способности. Ограничения производительности сети отдельных экземпляров и ограничения потока (10 Гбит/с в группе размещения и 5 Гбит/с в остальных случаях) применяются к обоим вариантам. Только пиринг VPC поддерживает группы размещения.

• Задержка - В отличие от пиринга VPC, Transit Gateway — это дополнительный переход между VPC.

• Совместимость групп безопасности - Ссылки на группы безопасности работают с внутрирегиональным пирингом VPC.

TGW (или пиринг VPC) обеспечивает межрегиональный пиринг VPC, что полезно, когда ваши кластеры EKS находятся в разных регионах AWS.

🫱🏽‍🫲🏼Обмен Amazon VPC

Вот третий способ обеспечить симметричный поток: совместно использовать VPC с несколькими учетными записями AWS.

AWS Resource Access Manager (ОЗУ) позволяет вам совместно использовать VPC (среди прочего) с другими учетными записями AWS в вашей организации AWS.

ОЗУ позволяет сетевым администраторам централизованно создавать VPC и управлять ими. Общий VPC позволяет сетевым ресурсам в разных учетных записях AWS беспрепятственно обмениваться данными, как если бы они находились в одном VPC и одной учетной записи. Вы по-прежнему можете контролировать трафик с помощью групп безопасности и сетевых ACL.

Вы можете поделиться своими VPC, чтобы использовать неявную маршрутизацию внутри VPC для приложений, требующих высокой степени взаимосвязи и находящихся в пределах одних и тех же границ доверия. Это уменьшает количество VPC, которые вы создаете и которыми управляете, используя отдельные учетные записи для выставления счетов и управления доступом.

Преимущества совместного использования VPC:

• Упрощенный дизайн — отсутствие сложностей с подключением между VPC

• Меньше управляемых VPC

• Разделение обязанностей между сетевыми командами и владельцами приложений

• Лучшее использование адресов IPv4

• Более низкие затраты — отсутствие платы за передачу данных между экземплярами, принадлежащими разным учетным записям в одной и той же зоне доступности.

Согласно техническому документу, клиенты могут использовать совместное использование VPC вместе с TGW для оптимизации затрат и производительности. Совместное использование VPC имеет несколько ограничений, убедитесь, что вы учитываете их в своем дизайн.

🎯AWS PrivateLink

Вам не терпится узнать варианты, если вам нужно подключение к асимметричному потоку? Нет. Позвольте мне сказать вам в любом случае. 😄

AWS PrivateLink обеспечивает подключение по частному IP-адресу между VPC, чтобы клиенты могли подключаться к сервисам, размещенным в других VPC.

Ключевым преимуществом по сравнению с совместным использованием или пирингом VPC является то, что PrivateLink соединяет сервисы, даже если они работают в разных VPC с перекрывающимися CIDR. Его также проще настроить, поскольку он не требует изменений в таблицах маршрутизации, подсетях или TGW.

В Prescriptive Guidance AWS есть руководство по использованию PrivateLink и NLB с EKS.

Симметричный поток с PrivateLink

Если вы решите соединять службы с помощью PrivateLink, вы по-прежнему можете обеспечить поддержку симметричного потока. Вам придется добавить еще один PrivateLink для поддержки соединений, исходящих с противоположного конца.

Сравнение затрат

Я изучил [цены на PrivateLink] (https://aws.amazon.com/privatelink/pricing/) и не смог найти справедливого сравнения с [Transit Gateway] (https://aws.amazon.com/transit-gateway). /цена/). К сожалению, векторов слишком много, чтобы обеспечить обобщенное сравнение цен. Я рекомендую привлечь архитектора решений AWS для детального анализа.

Вывод

AWS предоставляет множество способов подключения сервисов, работающих в разных VPC. В этом посте рассматриваются варианты, доступные для клиентов EKS.

Вы можете упростить топологию сети, соединив общие Amazon VPC с помощью таких функций подключения, как AWS PrivateLink, транзитные шлюзы и пиринг VPC.

Вот элементарное дерево решений, которое поможет вам начать работу.

Я что-то не так понял? Пожалуйста, напишите мне свой отзыв на @realz.

Дальнейшее чтение

Информационный документ AWS: [Безопасный доступ к сервисам через AWS PrivateLink] (https://d1.awsstatic.com/whitepapers/aws-privatelink.pdf)

Технический документ AWS: Создание масштабируемой и безопасной сетевой инфраструктуры AWS с несколькими VPC

Также опубликовано здесь