AWS ECS: конечные точки VPC и шлюзы NAT

Согласно документации AWS по шлюзам NAT , они не могут отправлять трафик через конечные точки VPC, если только он настраивается следующим образом:

Шлюз NAT не может отправлять трафик через конечные точки VPC [...]. Если вашим экземплярам в частной подсети требуется доступ к ресурсам через конечную [...] точку VPC, используйте таблицу маршрутов частной подсети для маршрутизации трафика непосредственно на эти устройства.

После этого в документации, я создал следующую конфигурацию для своего приложения ECS:

  1. VPC (vpc-app) с CIDR 172.31.0.0/16.
  2. Подсеть приложения (subnet-app) со следующей таблицей маршрутов:
    Destination     |  Target
    ----------------|-----------
    172.31.0.0/16   |   local  
    0.0.0.0/0       |  nat-main
  1. Шлюз NAT (nat-main) в vpc-app в подсети default-1 со следующей таблицей маршрутов:
    Destination     |    Target
    ----------------|--------------
    172.31.0.0/16   |     local  
    0.0.0.0/0       |  igw-xxxxxxxx
  1. Группа безопасности (sg-app) с портом 443, открытым для subnet-app.
  2. Конечные точки VPC (тип интерфейса) с vpc-app, subnet-app и sg-app для следующих служб:
    com.amazonaws.eu-west-1.ecr.api  
    com.amazonaws.eu-west-1.ecr.dkr  
    com.amazonaws.eu-west-1.ecs  
    com.amazonaws.eu-west-1.ecs-agent  
    com.amazonaws.eu-west-1.ecs-telemetry  
    com.amazonaws.eu-west-1.s3 (Gateway)

Также важно отметить, что я включил Разрешение DNS и имена хостов DNS для vpc-app, а также параметр Включить частное DNS-имя для ecr-dkr и ecr-api VPCE, вот два скриншота раздела "Подробности": ecr-dkr и ecr-api.

Я также пробовал работать только с контейнерами Fargate, поскольку они не имеют дополнительных сложностей, связанных с агентом ECS, и потому, что, согласно документации:

Для задач, использующих тип запуска Fargate, требуется только конечная точка Amazon ECR VPC com.amazonaws.region.ecr.dkr и конечная точка шлюза Amazon S3, чтобы воспользоваться этой функцией.

Это также не работает, и каждый раз, когда мои задачи Fargate выполняются, я вижу всплеск байтов до источника в разделе Мониторинг nat-main.

Что бы я ни пытался, экземпляры EC2 (и задачи Fargate) в subnet-app по-прежнему извлекают изображения с использованием nat-main и не переходят на локальный адрес службы ECR.

Я перезапустил Агент ECS и обязательно установил все флажки в Руководство по конечным точкам VPC интерфейса ECS И Конечные точки интерфейса ECR.

Что мне здесь не хватает?

Любая помощь будет оценена по достоинству.


amazon-web-services amazon-vpc amazon-ecs amazon-ecr
person kutacoder    schedule 28.04.2019    source источник
comment
Нужны ли какие-либо изменения в группе безопасности?   -  person Ankit Deshpande    schedule 29.04.2019
comment
Да, вам нужно разрешить доступ по порту 443 для подсети, что я и сделал.   -  person kutacoder    schedule 29.04.2019

Ответы (2)


arrow_upward
3
arrow_downward

Конечные точки интерфейса VPC работают с разрешением DNS, а не с маршрутизацией.

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

введите здесь описание изображения

Из документации:

Когда вы создаете конечную точку интерфейса, мы генерируем специфичные для конечной точки имена хоста DNS, которые вы можете использовать для связи со службой. Для сервисов AWS и партнерских сервисов AWS Marketplace вы можете дополнительно включить частный DNS для конечной точки. Этот параметр связывает частную размещенную зону с вашим VPC. Размещенная зона содержит набор записей для DNS-имени по умолчанию для службы (например, ec2.us-east-1.amazonaws.com), которое разрешается в частные IP-адреса сетевых интерфейсов конечных точек в вашем VPC. Это позволяет вам делать запросы к службе, используя ее имя хоста DNS по умолчанию, а не имена хоста DNS, зависящие от конечной точки. Например, если ваши существующие приложения отправляют запросы к сервису AWS, они могут продолжать делать запросы через конечную точку интерфейса, не требуя каких-либо изменений конфигурации.

Альтернативный вариант - обновить приложение, чтобы использовать имена хостов DNS, зависящие от конечной точки.

Обратите внимание, что для использования частных имен DNS для вашего VPC должны быть включены разрешение DNS и имена хостов DNS:

введите здесь описание изображения

Также обратите внимание, что для использования ECR / ECS без шлюза NAT вам необходимо настроить конечную точку S3 (шлюз, требуется обновление таблицы маршрутов), чтобы позволить экземплярам загружать слои изображений из базовых частных корзин Amazon S3, в которых они размещены. Подробнее см. Настройка AWS PrivateLink для Amazon ECS и Amazon ECR

person jogold    schedule 29.04.2019
comment
Благодарим вас за ответ. Я включил разрешение DNS и имена хостов DNS для VPC, а также опцию «Включить частное DNS-имя» для ECR + ECR-API VPCE. Я обновил свой вопрос, чтобы включить эти включенные параметры как часть конфигурации. Что именно вы имеете в виду под: Интерфейсные конечные точки VPC работают с разрешением DNS, а не с маршрутизацией.? - person kutacoder; 29.04.2019
comment
Можете ли вы запустить dig +short ecr.eu-west-1.amazonaws.com из своего VPC? Я имею в виду, что ваше приложение по-прежнему будет пытаться достичь ecr.eu-west-1.amazonaws.com, но оно должно разрешить IP-адрес одного из ENI для конечной точки. Это не похоже на S3, который нужно настраивать в таблице маршрутов. - person jogold; 29.04.2019
comment
Только что прогнал ваше предложение, у меня публичный IP, а не внутренний, что я могу попытаться выяснить, почему это происходит? - person kutacoder; 29.04.2019
comment
Можете ли вы поделиться снимком экрана вкладки Подробности одной из ваших конечных точек? - person jogold; 29.04.2019
comment
Конечно, вот подробности: ECR DKR VPCE и ECR API VPCE. Я также запустил dig +short dkr.ecr.eu-west-1.amazonaws.com и dig +short api.ecr.eu-west-1.amazonaws.com из экземпляра EC2 в vpc-app, и я получил частный IP-адрес для них обоих, что дает? :( - person kutacoder; 29.04.2019
comment
Я даже пошел дальше и проверил dig +short <acount-id>.dkr.ecr.eu-west-1.amazonaws.com, который является URI репозитория, где хранятся мои изображения, и я также получил частный IP-адрес. - person kutacoder; 29.04.2019
comment
Тот факт, что когда я смотрю на Packets out to destination (Count) в разделе Monitoring шлюза NAT, я ясно вижу, что в среднем мой счетчик составляет приблизительно 1500, и как только я запускаю свою задачу Fargate из интерфейса командной строки, не имея ничего, кроме /bin/echo hey в CMD контейнера Docker, я вижу скачок почти до 20 000! Образ весит почти 400 МБ, что объясняет всплеск. Это стоит мне целое состояние, и я не могу понять почему. - person kutacoder; 29.04.2019
comment
Значение больше нуля для PacketsOutToDestination указывает на то, что есть трафик, идущий в Интернет от клиентов, находящихся за шлюзом NAT (= загрузка). - person jogold; 29.04.2019
comment
Вы можете убедиться, что ваши конечные точки VPC для ECR работают, временно выключив шлюз NAT и попытавшись получить / запустить задачу. - person jogold; 29.04.2019
comment
Я только что провел тест, который вы предложили, и вы правы, при выключении NAT задачи все еще могут успешно извлекать образы, что означает, что VPCE работают правильно. Но меня по-прежнему беспокоит одно: как получилось, что когда у меня был только один простой экземпляр EC2 с таким же объемом трафика, что и мое недавно созданное приложение ECS, затраты были почти нулевыми, и теперь они выглядят как это? Имеет значение, сколько подключений к NAT? Если я настрою три задачи Fargate, которые запускаются каждые 12 минут, будет ли это то же самое, что и три экземпляра EC2, которые всегда работают? - person kutacoder; 29.04.2019
comment
Количество подключений не имеет значения, вы платите в зависимости от трафика (обработанных ГБ данных). Что-то еще должно было измениться в вашей схеме движения ... - person jogold; 29.04.2019
comment
@cudacoder Я столкнулся с проблемой, которая может быть такой же, как и у вас - я часто запускаю задачи Fargate, и каждый раз, когда они инициализируются, они вытягивают докеры из ECR через мой шлюз NAT, что в конечном итоге приводит к большой пропускной способности, тогда как с задачами на основе EC2 этого не происходит, потому что изображения кэшируются локально. Я действительно думаю о переходе на задачи на основе EC2 именно по этой причине. - person matthewcummings516; 23.05.2019
comment
@ matthewcummings516 Это очень похоже на мою ситуацию, дело в том, что я запускаю как задачи на основе EC2, так и Fargates для общих запланированных задач, но вам не нужно переключаться, если Fargate подходит для вашего случая лучше, чем задачи на основе EC2, просто сделайте обязательно следуйте руководствам, которые я добавил к своему вопросу, и обязательно проверьте настройки конечных точек S3, как предлагает jogold, и вы сможете настроить его довольно легко, также не забудьте спросить на эту ветку за помощью. - person kutacoder; 26.05.2019
comment
@cudacoder, это забавно, я тоже столкнулся с проблемой конечной точки S3, я забыл, что я здесь прокомментировал. . . это определенно немного шатко / нелогично. Кроме того, я не верю, что задания ECS на основе EC2 ведут себя так, как я ожидал, я думаю, вам нужно установить ECS_IMAGE_PULL_BEHAVIOR в агенте на prefer-cached. - person matthewcummings516; 27.05.2019

arrow_upward
5
arrow_downward

После многих часов проб и ошибок и с большой помощью @jogold недостающий фрагмент был найден в это сообщение блога:

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

После того, как я создал S3 Gateway VPCE, я забыл добавить его адрес в таблицу маршрутизации subnet-app, поэтому, хотя первоначальный запрос на мой ECR URI был сделан с использованием внутреннего адреса, загрузка изображения из S3 по-прежнему использовала шлюз NAT.

После добавления записи использование шлюза NAT в сети резко упало.

Дополнительную информацию о настройке шлюза VPCE можно найти на здесь.

person kutacoder    schedule 29.04.2019
comment
Замечательно, что вы нашли решение, добавлю в свой ответ примечание о конечной точке S3. - person jogold; 29.04.2019
comment
Поскольку ваш первый ответ более обширен и включает примечание о конечной точке S3, я решил принять ваш ответ как правильный, спасибо за помощь! - person kutacoder; 29.04.2019