Amazon ANS-C01: Контейнерные и бессерверные сети — Руководство по подготовке

By Laurynas Brazys · 3 August 2026 · #amazon #ans-c01 #certification #exam-prep #study-guide

Часть AWS Advanced Networking Specialty ANS-C01 — Руководство по подготовке. Практикуйтесь с проверенными ответами в центре экзаменов Amazon, или пройдите тесты на время на ExamRoll.io.

Сетевое взаимодействие в EKS (CNI, сеть подов)

Сетевое взаимодействие подов в Amazon EKS в основном реализуется через плагин Amazon VPC CNI (amazon-vpc-cni-k8s), который присваивает каждому поду IP-адрес из VPC и направляет трафик подов непосредственно в сеть VPC. Такая архитектура обеспечивает предсказуемый контроль безопасности на уровне VPC (группы безопасности, NACL) и маршрутизацию с низкой задержкой, но требует тщательного планирования емкости IP-адресов и ENI, поскольку количество вторичных IPv4-адресов на один ENI и количество ENI на тип инстанса ограничены аппаратно. DaemonSet aws-node управляет выделением IP-адресов и операциями подключения/отключения (attach/detach); его ConfigMap редактируется с помощью kubectl для настройки поведения (например, для установки WARM_IP_TARGET, WARM_ENI_TARGET или ENABLE_PREFIX_DELEGATION). Режимы делегирования префиксов и ENI для подов уменьшают проблему исчерпания IP-адресов на узле, позволяя узлу выделять целые префиксы /28 для одного ENI (ENABLE_PREFIX_DELEGATION=true) или назначая выделенный ENI для каждого пода (полезно для изоляции с высокими требованиями к безопасности).

Альтернативы Amazon VPC CNI, такие как Cilium (eBPF) или Calico, могут предложить другие компромиссы. Cilium может заменить kube-proxy и реализовать высокопроизводительную пересылку на уровнях L3/L4 с использованием eBPF, обеспечить прозрачное шифрование между узлами (WireGuard или IPsec) и снизить нагрузку на IP-адреса на уровне узлов за счет использования оверлейных сетей или маскарадинга. С Cilium вы по-прежнему интегрируетесь с маршрутизацией VPC для исходящего и входящего трафика, но избегаете частых операций подключения/отключения ENI; это важно при высокой частоте смены подов (pod churn). При очень большом количестве соединений и строгих требованиях к поведению на уровне L7 также следует рассмотреть настройку режима kube-proxy (IPVS) и параметров ядра узла: настройте conntrack_max, tcp_tw_recycle/tcp_tw_reuse и ip_local_port_range и передайте их через kubelet или init-скрипты DaemonSet, чтобы избежать исчерпания эфемерных портов при тысячах одновременных долгоживущих gRPC-соединений.

Сетевые режимы ECS и интеграция Lambda с VPC

Сетевое взаимодействие задач ECS имеет три основных режима: bridge, host и awsvpc. Режим awsvpc наиболее сравним с сетевым взаимодействием подов в Kubernetes, поскольку он подключает ENI к каждой задаче (или группе задач) и назначает приватный IP-адрес и группы безопасности непосредственно задаче. Режим awsvpc настраивается путем указания awsvpcConfiguration с подсетями (subnets) и группами безопасности (securityGroups) в вызовах API RunTask или CreateService. Fargate принудительно использует режим awsvpc и, следовательно, обеспечивает сетевую изоляцию на уровне задач и интегрируется с AWS Cloud Map для обнаружения сервисов. Используйте awsvpc, когда вам нужна фильтрация трафика для каждой задачи на основе групп безопасности или когда необходимо использовать стандартную маршрутизацию и метрики VPC.

Lambda-функции, которым нужен доступ к VPC, подключаются к нему через ENI в настроенных для функции подсетях и группах безопасности. Эти ENI создаются и управляются плоскостью управления Lambda, но создание ENI может добавлять задержку при холодном старте и исторически ограничивало быстрое масштабирование, если это не смягчалось использованием provisioned concurrency или применением VPC-эндпоинтов (AWS PrivateLink) и тщательно спроектированной архитектуры подсетей. При размещении множества Lambda-функций в VPC убедитесь, что в подсетях есть доступные IP-адреса, используйте NAT Gateway или NAT-инстансы для исходящего трафика по мере необходимости и отдавайте предпочтение VPC-эндпоинтам (эндпоинты com.amazonaws.* через AWS::EC2::VPCEndpoint), чтобы по возможности избежать маршрутизации исходящего трафика через интернет. Отслеживайте подключение/отключение ENI с помощью CloudWatch Logs и VPC Flow Logs для наблюдения за поведением масштабирования и устранения проблем с троттлингом, связанным с параллелизмом.

App Mesh и обнаружение сервисов

AWS App Mesh использует sidecar-контейнеры Envoy в качестве плоскости данных (data plane) и обеспечивает наблюдаемость на уровнях L3–L7, формирование трафика (traffic shaping), повторные попытки и управление установкой/завершением TLS-соединений. Определите меши, виртуальные узлы и виртуальные сервисы через API App Mesh (CreateMesh, CreateVirtualNode, CreateVirtualService) или контроллер App Mesh для Kubernetes. App Mesh поддерживает mTLS путем настройки TLS-блока в listener‘е VirtualNode с clientPolicy и центром сертификации, и вы можете интегрироваться с AWS Certificate Manager (ACM) или SDS для распространения сертификатов. Однако обратите внимание, что sidecar-контейнеры App Mesh по своей архитектуре завершают и повторно шифруют трафик; если требование предписывает, что трафик приложения должен оставаться зашифрованным end-to-end между клиентом и подом приложения (без расшифровки в сетевом прокси), вы должны убедиться, что TLS завершается только на уровне пода и избегать его завершения на ingress-шлюзе меша или балансировщике нагрузки.

Обнаружение сервисов (service discovery) обычно выполняется с помощью Kubernetes Services и CoreDNS для EKS, с помощью Cloud Map (CreateService, RegisterInstance) для кросс-платформенных решений и с помощью приватных хостируемых зон Route 53 для поиска на основе DNS. AWS Cloud Map напрямую интегрируется с ECS и App Mesh, позволяя использовать SRV- или A-записи и проверки состояния через API. В динамических средах, где инстансы быстро масштабируются, комбинируйте короткие TTL для DNS и проверки состояния Cloud Map, чтобы избежать получения устаревших данных; если вам нужна немедленная согласованность, используйте API плоскости управления service mesh для получения эндпоинтов, а не полагайтесь на кэширование DNS.

Паттерны проектирования и компромиссы

При проектировании крупномасштабных систем gRPC over TLS с mTLS необходимо решить, где будет терминироваться TLS. Терминирование на балансировщике нагрузки (ALB) позволяет перенести управление сертификатами в ACM и упрощает их ротацию, но нарушает сквозное шифрование (end-to-end) и не может обеспечить взаимную аутентификацию TLS (mTLS) для бэкенд-подов, если только бэкенд не устанавливает TLS-соединение заново, используя переданную информацию о сертификате клиента. Для настоящего сквозного mTLS, где конечные точки приложения аутентифицируют клиентов напрямую, используйте шлюз L4 с режимом passthrough, такой как Network Load Balancer, и позвольте поду/приложению обрабатывать TLS/mTLS. Используйте тип цели NLB ip в сочетании с аннотацией AWS Load Balancer Controller

undefined

, чтобы регистрировать IP-адреса подов напрямую; этот паттерн хорошо масштабируется, поскольку NLB рассчитан на миллионы соединений и поддерживает долгоживущие сессии TCP/gRPC без терминирования TLS.

Для входящего трафика (ingress) и маршрутизации на основе пути с терминированием HTTPS лучше подходит Application Load Balancer, так как он поддерживает правила на основе хоста/пути, перенаправления и интеграцию с WAF. Чтобы сохранить IP-адреса клиентов при терминировании TLS на ALB, используйте заголовки X-Forwarded-For; бэкенд-веб-серверы должны обрабатывать и логировать X-Forwarded-For, а для проверки следует включить журналы доступа ALB. Если на уровне сервера вам нужен истинный адрес сокета клиента (например, для устаревшего ПО), используйте NLB с proxy protocol v2 и убедитесь, что бэкенд-сервисы поддерживают этот протокол.

Связность сервисов между несколькими аккаунтами AWS и VPC масштабируется по-разному в зависимости от выбранного паттерна. VPC peering прост в настройке, но сложность управления растет по закону N^2; Transit Gateway централизует маршрутизацию и лучше масштабируется для большого количества VPC благодаря разделению таблиц маршрутизации; AWS PrivateLink (Interface VPC Endpoints) предоставляет наиболее гранулярную модель доступа на уровне отдельных сервисов с учетом идентификации, поскольку вы предоставляете сервис-endpoint через NLB, а потребители создают interface endpoints в своих VPC. Для общих сервисов в мультиаккаунтной среде со строгим контролем доступа и масштабируемым подключением новых потребителей предпочтительнее использовать PrivateLink, так как он изолирует маршрутизацию (не требует изменений в таблицах маршрутизации в VPC потребителей) и использует группы безопасности для тонкой настройки контроля.

Распространенные ошибки и критерии принятия решений

Часто встречающаяся ошибка — предположение, что одна и та же сетевая модель подходит для всех рабочих нагрузок. Для нагрузок с отслеживанием состояния или долгоживущими соединениями (gRPC, базы данных) предпочтительнее использовать сквозную передачу L4 (NLB) с терминированием TLS на уровне подов или паттерны hostPort/hostNetwork, чтобы избежать задержек, вносимых прокси-сервером; HTTP-микросервисы, которым требуется маршрутизация на основе путей, WAF или терминирование WebSocket, выигрывают от использования функций ALB и App Mesh. Другая ошибка — не учитывать ограничения по количеству ENI/IP при масштабировании узлов EKS или задач ECS в режиме awsvpc: всегда сверяйтесь с таблицей ENI и IP-на-ENI для типа инстанса EC2 и используйте делегирование префиксов или оверлейные сети Cilium, когда требуется высокая плотность подов.

Мониторинг и отладка требуют использования нескольких источников: VPC Flow Logs и метрики ENI для отслеживания входящего/исходящего трафика, метрики CloudWatch для AWS Load Balancers (ActiveFlowCount, ProcessedBytes) и телеметрия на уровне приложения от Envoy/App Mesh или агента AWS X-Ray. Для Lambda и Fargate помните, что холодные старты, связанные с операциями ENI, можно смягчить с помощью provisioned concurrency или путем перепроектирования паттернов доступа для использования VPC-эндпоинтов и PrivateLink, чтобы функциям не требовался широкий доступ к исходящему трафику.

Практическая задача: сценарий использования

Название компании: Acme Payments Inc. Задача: Acme Payments использует gRPC-сервис на Amazon EKS, который должен поддерживать тысячи одновременных TLS-соединений на TCP-порту 443, использовать взаимный TLS (mTLS), чтобы сертификат клиента проверялся бэкенд-сервисом, и позволять кластеру EKS автоматически масштабироваться с помощью Cluster Autoscaler и HPA без разрыва соединений или необходимости терминировать TLS на балансировщике нагрузки.

Пошаговый подход:

1. Развернуть сервис с TLS на уровне пода и взаимной аутентификацией, реализованной в приложении или в sidecar-контейнере, который не терминирует сквозное TLS-шифрование для внешних клиентов. Хранить серверные/клиентские сертификаты в AWS Secrets Manager и монтировать их через Kubernetes CSI secrets store или использовать механизм распространения сертификатов, который работает с жизненным циклом пода.
2. Использовать AWS Load Balancer Controller для создания Network Load Balancer, добавив аннотацию к сервису (service.beta.kubernetes.io/aws-load-balancer-type: “nlb”), и установить тип цели на IP (service.beta.kubernetes.io/aws-load-balancer-target-type: “ip”), затем создать TCP-слушатель на порту 443. Это гарантирует, что NLB будет выполнять сквозную передачу на уровне L4 и не будет терминировать TLS.
3. Настроить целевую группу NLB с протоколом TCP и динамически регистрировать IP-адреса подов (Load Balancer Controller вызовет CreateTargetGroup и RegisterTargets). Убедиться, что проверки состояния настроены на TCP или на пользовательскую проверку на основе TCP с коротким интервалом, чтобы цели быстро помечались как исправные во время автомасштабирования (aws elbv2 create-target-group –protocol TCP –port 443 –target-type ip; aws elbv2 create-listener –protocol TCP –port 443 …).
4. Настроить Amazon VPC CNI для поддержки высокой плотности подов и уменьшения текучести ENI: включить делегирование префиксов, если оно поддерживается (установить ENABLE_PREFIX_DELEGATION=true в ConfigMap aws-node), настроить WARM_IP_TARGET для поддержания запаса адресов и отслеживать метрики aws-node (логи daemonset’а kube-system и пользовательские метрики CloudWatch). Если ограничения IP на уровне узла вызывают беспокойство, рассмотрите возможность использования Cilium с eBPF для более высокой плотности подов и сокращения операций с ENI.
5. Безопасно масштабировать кластер: убедиться, что Cluster Autoscaler имеет правильные теги для групп узлов и разрешения IAM, установить PodDisruptionBudgets и проверить, что проверки состояния целевой группы и сброс соединений NLB (connection draining) настроены так, чтобы избежать разрыва долгоживущих gRPC-соединений во время уменьшения масштаба.
6. Обеспечить ротацию сертификатов и управление доверием: автоматизировать ротацию сертификатов с помощью ACM Private CA или Secrets Manager и убедиться, что поды получают обновленные наборы доверенных сертификатов без необходимости перенастройки NLB. Использовать пробы готовности/работоспособности Kubernetes (readiness/liveness probes), которые отражают готовность к mTLS-рукопожатию.

Обоснование со стороны AWS: Network Load Balancer в режиме IP-целей сохраняет TLS до самого пода (истинное сквозное шифрование) и поддерживает миллионы постоянных TCP-соединений, что делает его подходящим для тысяч одновременных gRPC-сессий. Прямая регистрация IP-адресов подов позволяет избежать сложностей с hostPort или регистрацией целей на уровне инстансов и корректно работает с Cluster Autoscaler/HPA, поскольку AWS Load Balancer Controller будет регистрировать и отменять регистрацию IP-адресов подов по мере их масштабирования. Настройка VPC CNI или внедрение data plane на основе eBPF предотвращает исчерпание IP-адресов и снижает задержки при подключении/отключении ENI, что крайне важно для быстрого автомасштабирования и нагрузок с большим количеством соединений. Хранение и доставка артефактов mTLS через Secrets Manager или CSI-провайдер делает жизненный цикл сертификатов управляемым без необходимости изменять конфигурацию балансировщика нагрузки.

← Автоматизация · Все домены

Отработать эти вопросы → · Тесты на время на ExamRoll.io →

Просмотреть Amazon →