Облачная платформаAdvanced

Выбор сети

Язык статьи: Русский
Показать оригинал
Страница переведена автоматически и может содержать неточности. Рекомендуем сверяться с английской версией.

CCE использует собственные высокопроизводительные дополнения сетевого контейнера для поддержки tunnel, Cloud Native 2.0 и VPC сетей.

Caution

После создания кластера тип сети изменить нельзя.

  • tunnel network — это независимая сеть контейнеров, построенная с использованием VXLAN‑туннелей на основе базовой VPC‑сети. Эта модель применяется в типовых сценариях. VXLAN инкапсулирует Ethernet‑пакеты в UDP‑пакеты для передачи через туннель. Хотя может возникнуть некоторый оверхед производительности, инкапсуляция пакетов и передача через туннель обеспечивают большую совместимость и совместимость с расширенными функциями, такими как изоляция на основе сетевых политик, в большинстве типовых сценариев.

    Рисунок 1 Container tunnel network


  • VPC network бесшовно сочетает маршрутизацию VPC с базовой сетью, что делает её идеальной для высокопроизводительных сценариев. Однако максимальное количество узлов, разрешённое в кластере, определяется квотой маршрутов VPC. Каждый узел в кластере, использующий VPC network, получает CIDR‑блок с фиксированным числом IP‑адресов. Производительность VPC network превосходит контейнерные туннельные сети, поскольку отсутствует оверхед инкапсуляции туннеля. Кроме того, когда маршруты, предназначенные для узлов и контейнеров, добавляются в таблицу маршрутов VPC, контейнеры могут быть доступны напрямую извне кластера.

    Рисунок 2 VPC network


  • Cloud Native 2.0 network глубоко интегрирует интерфейсы VPC, использует CIDR‑блок VPC для выделения IP‑адресов контейнеров и поддерживает сквозную сетевую связь pod‑ов через балансировщики нагрузки для обеспечения высокой производительности.

    Рисунок 3 Cloud Native network 2.0


В таблице ниже перечислены различия между этими типами сетей.

Таблица 1 Сравнение различных типов сетей

Категория

Tunnel Network

VPC Network

Cloud Native 2.0 Network

Сценарии применения

  • Низкие требования к производительности: поскольку сеть контейнерных туннелей требует дополнительного инкапсуляции VXLAN‑туннеля, она теряет примерно от 5 % до 15 % производительности по сравнению с другими двумя типами контейнерных сетей. Поэтому сети контейнерных туннелей применимы в сценариях, где высокая производительность не требуется, например, веб‑приложения, а также средние и серверные службы с небольшим количеством запросов доступа.
  • Крупномасштабные сети: в отличие от сети VPC, ограниченной квотой маршрутов VPC, сеть контейнерных туннелей не имеет ограничений на инфраструктуру. Кроме того, сеть контейнерных туннелей управляет широковещательным доменом на уровне узла. Кластер, использующий туннельную сеть, поддерживает максимум 2 000 узлов.
  • Высокие требования к производительности: поскольку инкапсуляция туннеля не требуется, сеть VPC обеспечивает производительность, близкую к VPC, по сравнению с сетью контейнерных туннелей. Поэтому сети VPC применимы в сценариях, где необходима высокая производительность, например, AI и вычисления больших данных.
  • Малые и средние сети: из‑за ограничения таблиц маршрутов VPC рекомендуется, чтобы количество узлов в кластере было не более 1 000.
  • Высокие требования к производительности: сети Cloud Native 2.0 используют сети VPC для построения контейнерных сетей. Инкапсуляция туннеля или NAT между контейнерными коммуникациями не требуется. Это делает сети Cloud Native 2.0 идеальными для сценариев, где необходима высокая пропускная способность и низкая задержка.
  • Крупномасштабные сети: кластер, использующий сеть Cloud Native 2.0, поддерживает максимум 2 000 узлов ECS и 100 000 pods.

Основные технологии

OVS

IPvlan и VPC route

сетевые интерфейсы VPC и дополнительные сетевые интерфейсы

Применимый кластер

CCE standard cluster

CCE standard cluster

CCE Turbo cluster

Изоляция сети контейнеров

Сетевые политики Kubernetes-native для pod‑ов

Не поддерживается

Изоляция на основе групп безопасности для pod‑ов

Подключение pod‑ов к балансировщику нагрузки

Подключено через NodePort

Подключено через NodePort

Прямое подключение с использованием выделенного балансировщика нагрузки

Подключено с использованием общего балансировщика нагрузки через NodePort

Управление IP‑адресами pod

  • Требуются отдельные CIDR‑блоки контейнеров. CIDR‑блоки контейнеров не могут пересекаться с любыми CIDR‑блоками VPC.
  • После создания кластера CIDR‑блок контейнеров нельзя расширять. Чтобы избежать нехватки IP‑адресов, рекомендуется установить маску подсети CIDR‑блока контейнеров не более 19 бит.
  • Требуются отдельные CIDR‑блоки контейнеров. CIDR‑блоки контейнеров не могут пересекаться с любыми CIDR‑блоками VPC.
  • Можно добавить несколько CIDR‑блоков контейнеров.
  • После создания кластера можно добавить дополнительные CIDR‑блоки контейнеров.
  • Сначала каждому узлу назначается фиксированная подсеть из контейнерного CIDR‑блока. Затем все IP‑адреса pod на каждом узле назначаются из выделенной подсети.
  • Можно указать подсеть VPC в качестве контейнерного CIDR‑блока.
  • После создания кластера можно добавить дополнительные контейнерные CIDR‑блоки.
  • IP‑адреса pod выделяются напрямую из VPC, потребляя большое количество IP‑адресов. Рекомендуется заранее спланировать большой CIDR‑блок VPC.

Максимальное количество pod на узле

Определяется максимальным количеством pod, которое может быть создано на узле (параметр kubelet maxPods).

Определяется меньшим значением из следующих вариантов:

  • Максимальное количество pod, которое может быть создано на узле (параметр kubelet maxPods).
  • Количество IP‑адресов pod, зарезервированных для каждого узла.

Определяется меньшим значением из следующих вариантов:

  • Максимальное количество pod, которое может быть создано на узле (параметр kubelet maxPods).
  • Количество сетевых интерфейсов на узле.

Сетевая производительность

Существует определённая потеря производительности из‑за инкапсуляции VXLAN.

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

Потери производительности нет, поскольку сеть контейнеров интегрирована с сетью VPC.

Масштаб сети

Поддерживается максимум 2 000 узлов.

Подходит для небольших и средних сетей из‑за ограничения таблиц маршрутизации VPC. Рекомендуется, чтобы количество узлов в кластере было не более 1 000.

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

Поддерживается максимум 2 000 узлов.

В кластере, использующем сеть Cloud Native 2.0, IP‑адреса pod назначаются из блока VPC CIDR, поэтому количество pod ограничено этим блоком CIDR. Оцените ограничения масштаба кластера перед его созданием.

Поддержка IPv4/IPv6

Поддерживается

Не поддерживается

Поддерживается

Notice
  1. Масштаб кластера, использующего модель сети VPC, ограничен пользовательскими маршрутами VPC. Поэтому необходимо оценить количество требуемых узлов перед созданием кластера.
  2. По умолчанию сеть маршрутизации VPC поддерживает прямую связь между контейнерами и хостами в одной VPC. Если между VPC и другой VPC настроена политика peering connection, контейнеры могут напрямую взаимодействовать с хостами в VPC‑партнёре. Кроме того, в гибридных сетевых сценариях, таких как Direct Connect и VPN, связь между контейнерами и хостами на стороне партнёра также может быть реализована при надлежащем планировании.