Amazon VPC CNI

Amazon VPC CNI (Container Network Interface) — это плагин для Kubernetes, реализующий сетевую модель, при которой каждый под (pod) получает IP-адрес непосредственно из виртуального частного облака (VPC) Amazon Web Services (AWS). Плагин является частью экосистемы Amazon Elastic Kubernetes Service (EKS) и управляется AWS, обеспечивая нативную интеграцию с сетевой инфраструктурой AWS.

Архитектура и принцип работы

В отличие от многих других CNI-плагинов, которые используют оверлейные сети (например, Flannel, Calico в режиме VXLAN), Amazon VPC CNI назначает каждому поду IP-адрес из диапазона VPC. Это достигается за счёт того, что плагин создаёт для каждого пода виртуальный сетевой интерфейс (Elastic Network Interface, ENI) и присваивает ему вторичный IP-адрес из подсети VPC. Таким образом, поды получают IP-адреса, которые маршрутизируемы в пределах VPC без дополнительной инкапсуляции.

Компоненты плагина

Плагин состоит из двух основных компонентов:

• aws-node DaemonSet — запускается на каждом узле (node) кластера. Отвечает за управление ENI и IP-адресами, а также за настройку правил маршрутизации и iptables.
• L-IPAMD (IP Address Management Daemon) — демон управления IP-адресами, работающий в составе aws-node. Поддерживает пул зарезервированных IP-адресов для быстрого назначения подам.

Процесс назначения IP-адреса

1. При создании пода kubelet обращается к CNI-плагину.
2. Плагин запрашивает у L-IPAMD свободный IP-адрес из пула.
3. L-IPAMD проверяет наличие доступных IP-адресов на ENI узла. Если пул пуст, он запрашивает у AWS API создание нового ENI или добавление вторичного IP-адреса к существующему интерфейсу.
4. После получения IP-адреса CNI-плагин настраивает сетевой интерфейс пода в пространстве имён (network namespace) и добавляет необходимые правила маршрутизации.
5. Под получает IP-адрес, который маршрутизируем в VPC.

История и развитие

Amazon VPC CNI был представлен в 2018 году вместе с запуском Amazon EKS. Изначально плагин поддерживал только назначение IP-адресов из VPC, что ограничивало количество подов на узел количеством доступных IP-адресов в подсети. В 2019 году была добавлена поддержка IPv6, что позволило значительно расширить адресное пространство.

В 2020 году вышла версия 1.6, которая ввела поддержку Security Groups for Pods — возможность назначать группам безопасности (security groups) на уровне отдельных подов, а не только узлов. В 2021 году была добавлена поддержка Custom Networking, позволяющая использовать отдельные подсети для подов, отличные от подсетей узлов.

В 2022 году плагин получил поддержку AWS Outposts и Local Zones, а также улучшенную интеграцию с AWS PrivateLink. В 2023 году была представлена версия 1.12, которая оптимизировала управление пулом IP-адресов и уменьшила задержки при назначении адресов.

Классификация и режимы работы

Amazon VPC CNI поддерживает несколько режимов работы, которые определяют, как поды получают IP-адреса:

Режим VPC (по умолчанию)

Поды получают IP-адреса из диапазона VPC. Каждый под имеет собственный IP-адрес, маршрутизируемый в VPC. Этот режим обеспечивает минимальную задержку и максимальную пропускную способность, но ограничивает количество подов на узел количеством доступных IP-адресов в подсети.

Режим с префиксами (Prefix Delegation)

В этом режиме вместо отдельных вторичных IP-адресов на ENI назначаются префиксы /28 (16 IP-адресов). Это позволяет значительно увеличить количество подов на узел без увеличения числа ENI. Режим доступен для узлов, работающих на инстансах с поддержкой префиксов (например, Nitro-системы).

Режим IPv6

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

Режим Custom Networking

Позволяет использовать отдельные подсети для подов, отличные от подсетей, в которых находятся узлы. Это полезно для разделения трафика подов и управления, а также для использования разных групп безопасности.

Характеристики и ограничения

Преимущества

• Низкая задержка — отсутствие оверлейной сети исключает накладные расходы на инкапсуляцию и декапсуляцию пакетов.
• Высокая пропускная способность — трафик подов передаётся напрямую через сеть VPC, без дополнительных прокси-серверов.
• Нативная интеграция с AWS — поддержка всех сетевых сервисов AWS (VPC Flow Logs, Security Groups, Network ACLs, AWS PrivateLink).
• Простота мониторинга — IP-адреса подов видны в VPC Flow Logs и других инструментах мониторинга AWS.
• Поддержка IPv6 — возможность использования глобального адресного пространства.

Ограничения

• Ограничение на количество подов на узел — в режиме VPC максимальное количество подов на узел ограничено количеством доступных IP-адресов в подсети. Для инстансов Nitro максимальное количество ENI и вторичных IP-адресов зависит от типа инстанса. Например, для t3.medium — до 6 IP-адресов на ENI, до 3 ENI, итого до 18 подов.
• Зависимость от AWS API — при создании новых ENI или добавлении IP-адресов плагин обращается к AWS API, что может вызывать задержки при масштабировании.
• Сложность управления пулом IP-адресов — необходимо тщательно планировать размер подсетей и резервировать IP-адреса для подов.
• Отсутствие поддержки мультитенантности — плагин не поддерживает изоляцию сетевого трафика между подами на уровне ядра, что может потребовать дополнительных средств (например, Calico).

Применение

Amazon VPC CNI является основным сетевым плагином для Amazon EKS. Он используется в большинстве кластеров Kubernetes, работающих в AWS, особенно в тех случаях, когда требуется высокая производительность сети и интеграция с сервисами AWS.

Типичные сценарии использования

• Продакшн-кластеры — где важна низкая задержка и высокая пропускная способность.
• Приложения, использующие AWS PrivateLink — для доступа к сервисам через приватные IP-адреса.
• Микросервисные архитектуры — где требуется прямое сетевое взаимодействие между подами.
• Приложения, требующие мониторинга трафика — с помощью VPC Flow Logs.

Альтернативные плагины

Несмотря на популярность, Amazon VPC CNI не является единственным сетевым плагином для EKS. Альтернативами являются:

• Calico — поддерживает как оверлейные сети, так и прямое подключение к VPC, а также предоставляет расширенные возможности сетевой политики.
• Cilium — использует eBPF для обеспечения высокой производительности и безопасности, поддерживает интеграцию с VPC.
• Flannel — простой оверлейный плагин, не требующий интеграции с AWS API.

Критика и ограничения

Основные критические замечания в адрес Amazon VPC CNI связаны с ограничением на количество подов на узел. В больших кластерах с высокой плотностью подов это может приводить к необходимости использовать больше узлов, чем при использовании оверлейных сетей. Кроме того, зависимость от AWS API при масштабировании может вызывать задержки, особенно при быстром создании и удалении подов.

В ответ на эти ограничения AWS разработала режим с префиксами, который позволяет увеличить количество подов на узел без увеличения числа ENI. Однако этот режим требует поддержки со стороны типа инстанса и не всегда доступен.

Интересные факты

• Amazon VPC CNI является одним из немногих CNI-плагинов, которые не используют оверлейные сети, что делает его уникальным среди крупных облачных провайдеров.
• Плагин написан на Go и имеет открытый исходный код, доступный на GitHub.
• В 2023 году AWS представила поддержку AWS Nitro Enclaves для подов, что позволяет запускать приложения с повышенными требованиями к безопасности.
• Плагин поддерживает Windows-узлы в кластерах EKS, что редкость для CNI-плагинов.

Источники

• Документация Amazon EKS: «Amazon VPC CNI plugin for Kubernetes»
• Исходный код плагина на GitHub: aws/amazon-vpc-cni-k8s
• AWS re:Invent 2022: «Deep dive into Amazon VPC CNI for Kubernetes»
• «Kubernetes Networking with Amazon VPC CNI» — AWS Whitepaper, 2021
• «Amazon EKS Best Practices Guide for Networking» — AWS Documentation, 2023