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

Выбор сети

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

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

Caution

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

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

    Рисунок 1 Container tunnel network


  • VPC network бесшовно объединяет маршрутизацию VPC с базовой сетью, что делает её идеальной для сценариев с высокой производительностью. Однако максимальное количество узлов, разрешённое в кластере, определяется квотой маршрутов VPC. Каждый узел в кластере, использующий VPC network, получает блок CIDR с фиксированным числом IP‑адресов. Производительность VPC network превосходит container tunnel networks, поскольку отсутствует оверхед инкапсуляции туннеля. Кроме того, когда маршруты, предназначенные для узлов и контейнеров, добавляются в таблицу маршрутов 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 Network 2.0

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

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

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

OVS

IPvlan and VPC route

VPC network interfaces and supplementary network interfaces

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

CCE standard cluster

CCE standard cluster

CCE Turbo cluster

Изоляция сети Pod

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

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

Изоляция на основе Security group для pods

Подключение pods к load balancer

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

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

Прямое соединение с использованием выделенного load balancer

Соединено с использованием общего load balancer через NodePort

Управление IP-адресами Pod

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

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

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

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

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

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

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

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

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

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

Потери производительности нет, потому что pod network интегрирована с VPC network.

Масштаб сети

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

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

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

По умолчанию поддерживается 2,000 узлов. Максимум поддерживается 20,000 узлов.

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

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

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

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

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

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