Планирование блоков CIDR для Cluster

• Блок CIDR VPC

  VPC позволяет создавать логически изолированные, настраиваемые и управляемые виртуальные сети для cloud servers, cloud containers и cloud databases. В VPC можно настраивать блоки CIDR, подсети, группы безопасности и другие параметры, а также назначать EIP и пропускную способность вашим сервисным системам.

• Блок CIDR подсети

  Подсеть управляет сетевыми плоскостями ECS. Она поддерживает управление IP-адресами и DNS. ECS в подсети получают IP-адреса из этой подсети.

  Figure 1 архитектура блока CIDR VPC

  
  

  По умолчанию ECS в всех подсетях одного VPC могут взаимодействовать друг с другом, но ECS в разных VPC не могут.

  Можно создать соединение VPC peering, чтобы ECS в разных VPC могли взаимодействовать друг с другом.

• Блок CIDR контейнера (Pod)

  Pod — концепция Kubernetes. Каждый pod имеет IP-адрес.

  При создании кластера в CCE можно указать блок pod CIDR. Блок pod CIDR не может пересекаться с блоком VPC CIDR или блоком subnet CIDR. Например, если блок subnet CIDR равен 192.168.0.0/16, блок pod CIDR кластера не может быть 192.168.0.0/18 или 192.168.64.0/18, поскольку эти блоки CIDR покрываются 192.168.0.0/16.

• Container Subnet (Only for CCE Turbo Clusters)

  В кластере CCE Turbo контейнер получает IP-адрес из VPC CIDR block. Подсеть контейнера может перекрываться с subnet CIDR block. Обратите внимание, что выбранная подсеть определяет максимальное количество pods в кластере.

• Service CIDR Block

  Service также является концепцией Kubernetes. Каждый Service имеет IP-адрес. При создании кластера в CCE вы можете указать Service CIDR block. Аналогично, Service CIDR block не может перекрываться с VPC CIDR block, subnet CIDR block или pod CIDR block. Service CIDR block может использоваться только внутри кластера.

CCE standard clusters могут использовать сети VPC или контейнерные туннельные сети. Figure 2 показывает планирование CIDR block для CCE standard cluster.

• VPC CIDR block — это место размещения кластера. Размер этого CIDR block влияет на максимальное количество узлов, которые можно создать в кластере.
• Subnet CIDR block — это место размещения некоторых узлов кластера. Он включён в VPC CIDR block. Узлы в одном кластере могут быть распределены по разным subnet CIDR block.
• Pod CIDR block не может перекрываться с VPC CIDR block или subnet CIDR block.
• Service CIDR block не может перекрываться с VPC CIDR block, subnet CIDR block или pod CIDR block.

Figure 3 показывает планирование CIDR block для CCE Turbo cluster, использующего сеть Cloud Native 2.0.

• VPC CIDR block — это место размещения кластера. Размер этого CIDR block влияет на максимальное количество узлов, которые можно создать в кластере.
• Subnet CIDR block — это место размещения некоторых узлов кластера. Он включён в VPC CIDR block. Узлы в одном кластере могут быть распределены по разным subnet CIDR block.
• Под CIDR‑блок pod выделяется из CIDR‑блока VPC и может перекрываться с CIDR‑блоком подсети, или даже быть идентичным ему. Обратите внимание, что размер CIDR‑блока pod определяет максимальное количество pod‑ов в кластере, поскольку IP‑адреса выделяются напрямую pod‑ам из CIDR‑блока VPC. Установите более крупный CIDR‑блок для container subnet, чтобы обеспечить достаточное количество IP‑адресов для контейнеров.
• Service CIDR block не может перекрываться с CIDR‑блоком подсети или CIDR‑блоком pod.

Кластеры, использующие сети VPC

Пакеты pod пересылаются через маршруты VPC. CCE автоматически настраивает таблицу маршрутизации в маршрутах VPC для каждого pod CIDR block. Масштаб сети ограничен таблицей маршрутизации VPC. Рисунок 4 показывает планирование CIDR‑блоков такого кластера.

• CIDR‑блок VPC определяет место размещения кластера. Размер этого CIDR‑блока влияет на максимальное количество узлов, которые можно создать в кластере.
• CIDR‑блок подсети не может перекрываться с любым CIDR‑блоком pod.
• Если в одном VPC используется несколько кластеров, использующих сети VPC, CIDR‑блоки pod всех кластеров не могут перекрываться друг с другом, поскольку эти кластеры используют одну таблицу маршрутизации. В этом случае, если группа безопасности узлов в кластере разрешает CIDR‑блок pod из соседнего кластера, pod‑ы в кластере могут напрямую обращаться к pod‑ам в соседнем кластере по IP‑адресам pod.
• Service CIDR block может использоваться только в кластерах. Поэтому CIDR‑блоки Service разных кластеров могут перекрываться друг с другом, но не могут перекрываться с CIDR‑блоком подсети или CIDR‑блоком pod других кластеров.

Кластеры, использующие туннельные сети

В контейнерной туннельной сети контейнерная сеть представляет собой наложенную сеть, построенную поверх сети VPC. Несмотря на небольшие накладные расходы производительности из‑за инкапсуляции туннеля, такой тип сети обеспечивает высокую универсальность, отличную совместимость и полную поддержку продвинутых функций, таких как изоляция на основе сетевых политик, что делает её подходящей для большинства сценариев применения. Рисунок 5 показывает планирование CIDR‑блоков кластера.

• CIDR‑блок VPC определяет место размещения кластера. Размер этого CIDR‑блока влияет на максимальное количество узлов, которые можно создать в кластере.
• CIDR‑блок подсети не может перекрываться с любым CIDR‑блоком pod.
• CIDR-блоки pod всех кластеров могут перекрываться друг с другом. В этом случае pod в разных кластерах нельзя напрямую обращаться по pod IP-адресам. Для доступа к pod в разных кластерах требуются Services. Рекомендуются LoadBalancer Services.
• CIDR-блок Service может использоваться только в кластерах. Поэтому CIDR-блоки Service разных кластеров могут перекрываться друг с другом, но не могут перекрываться с CIDR-блоком подсети или CIDR-блоком pod других кластеров.

CCE Turbo Clusters, использующие Cloud Native 2.0 Networks

В сети Cloud Native 2.0 IP-адреса контейнеров выделяются из CIDR-блока VPC. Кластеры, использующие такой тип сети, поддерживают несколько возможностей на основе VPC, таких как сквозное сетевое соединение ELB к pod и прямое связывание групп безопасности с контейнерами. Они обеспечивают более быстрое сетевое соединение и пересылку.

• CIDR-блок VPC определяет расположение кластера. В CCE Turbo кластере размер CIDR-блока влияет на общее количество узлов и контейнеров, которые могут быть созданы в кластере.
• Для CIDR-блоков подсетей в CCE Turbo кластерах нет особых ограничений.
• CIDR-блок подсети контейнеров включён в CIDR-блок VPC. CIDR-блоки подсетей контейнеров в разных кластерах могут перекрываться друг с другом или с CIDR-блоком подсети. Однако рекомендуется использовать разные CIDR-блоки pod для разных кластеров и обеспечить, чтобы у CIDR-блоков pod было достаточное количество IP-адресов. В этом случае, если группа безопасности сетевого интерфейса кластера разрешает CIDR-блок pod соседнего кластера, pod в этих кластерах могут напрямую обращаться друг к другу по IP-адресам.
• CIDR-блоки Service ограничены кластером и могут перекрываться между кластерами. Однако они не должны перекрываться с любым CIDR-блоком подсети или CIDR-блоком pod в пределах одного кластера.

Кластеры, использующие разные сети

Для VPC, содержащего кластеры, использующие разные сети, соблюдайте следующие правила при создании кластера:

• Все эти кластеры находятся в одном CIDR-блоке VPC. Убедитесь, что в VPC доступно достаточное количество IP-адресов.
• CIDR-блок подсети не может перекрываться с любым CIDR-блоком pod. Даже в некоторых сценариях, например, когда также присутствуют CCE Turbo кластеры, CIDR-блок подсети может перекрываться с CIDR-блоком pod (подсети). Однако это не рекомендуется.
• CIDR-блоки pod кластеров, использующих the VPC networks, не могут перекрываться друг с другом.
• CIDR‑блоки Service всех этих кластеров могут перекрываться друг с другом, но не могут перекрываться с любым CIDR‑блоком подсети или CIDR‑блоком pod кластеров.

Разные VPC не могут взаимодействовать друг с другом. VPC peering connection может соединять VPC в одном регионе. Для двух подключенных VPC‑сетей вы можете использовать таблицы маршрутизации, чтобы настроить отправку пакетов в peer VPC.

Кластеры, использующие сети VPC

Чтобы кластеры, использующие сети VPC, могли получать доступ друг к другу через VPC, добавьте маршруты на обеих сторонах VPC peering после создания VPC peering connection.

При создании VPC peering connection для кластеров в разных VPC обратите внимание на следующие пункты:

• VPC, к которым принадлежат кластеры, не должны перекрываться друг с другом. В каждом кластере CIDR‑блок подсети не может перекрываться с CIDR‑блоком pod.
• CIDR‑блоки pod кластеров на обеих сторонах не могут перекрываться друг с другом, но CIDR‑блоки Service могут.
• Если кластер‑запрос использует сеть VPC, проверьте, разрешает ли node security group в peer cluster CIDR‑блок pod кластера‑запроса. Если да, pod в этих кластерах могут напрямую обращаться друг к другу по IP‑адресам pod. Аналогично, если узлы, работающие в кластерах на обеих сторонах VPC peering connection, должны обращаться друг к другу, node security group должна разрешать CIDR‑блок VPC peer cluster.
• Обе таблицы маршрутизации VPC должны включать маршруты к CIDR‑блоку peer. Например, таблица маршрутизации VPC 1 должна включать маршрут к CIDR‑блоку VPC 2, и аналогично, таблица маршрутизации VPC 2 должна включать маршрут к CIDR‑блоку VPC 1.
  • Добавьте CIDR‑блок VPC peer‑кластера: После добавления маршрута CIDR‑блока VPC pod могут получать доступ к узлам в другом кластере, например к NodePort Service.
  • Добавьте CIDR‑блок pod peer‑кластера: После добавления маршрута CIDR‑блока pod pod могут напрямую обращаться к pod в другом кластере, используя их IP‑адреса.

Кластеры, использующие туннельные сети

Чтобы кластеры, использующие туннельные сети, могли получать доступ друг к другу через VPC, добавьте маршруты на обеих сторонах VPC peering после создания VPC peering connection.

Обратите внимание на следующее:

• VPC CIDR blocks кластеров на обоих концах не должны перекрываться друг с другом.
• Pod CIDR blocks кластеров могут перекрываться, как и Service CIDR blocks.
• Если кластер‑запрос использует туннельную сеть, проверьте, разрешает ли группа безопасности узлов в целевом кластере CIDR‑блок VPC (включая подсети узлов) кластер‑запроса. Если да, узлы в обоих кластерах могут обращаться друг к другу. Однако pod‑ы в этих кластерах не могут напрямую обращаться друг к другу по pod‑IP‑адресам. Для этого требуются Services. Рекомендуются LoadBalancer Services.
• Обе таблицы маршрутизации VPC должны содержать маршруты к VPC CIDR block соседнего кластера. Например, таблица маршрутизации VPC 1 должна включать маршрут к VPC 2 CIDR block, и аналогично, таблица маршрутизации VPC 2 должна включать маршрут к VPC 1 CIDR block. После добавления маршрутов к CIDR‑блокам VPC pod‑ы могут обращаться к узлам в другом кластере, например к NodePort Service.

CCE Turbo Clusters Using the Cloud Native 2.0 Networks

После создания соединения VPC peering добавьте маршруты соединения VPC peering к обоим концам, чтобы два VPC могли взаимодействовать друг с другом. Обратите внимание на следующее:

• VPC CIDR blocks кластеров на обоих концах не должны перекрываться друг с другом.
• Если кластер‑запрос использует сеть Cloud Native 2.0, проверьте, разрешает ли группа безопасности сетевого интерфейса (именованная в формате {Cluster name}-cce-eni-{Random ID}) целевого кластера CIDR‑блок VPC (включая подсети узлов и CIDR‑блок pod) кластер‑запроса. Если да, pod‑ы в этих кластерах могут напрямую обращаться друг к другу по pod‑IP‑адресам. Аналогично, чтобы узлы в этих кластерах могли обращаться друг к другу, разрешите CIDR‑блок VPC соседнего кластера в группе безопасности узлов (именованной в формате {Cluster name}-cce-node-{Random ID}).
• Обе таблицы маршрутизации VPC должны содержать маршруты к VPC CIDR block соседнего кластера. Например, таблица маршрутизации VPC 1 должна включать маршрут к VPC 2 CIDR block, и аналогично, таблица маршрутизации VPC 2 должна включать маршрут к VPC 1 CIDR block. После добавления маршрутов к CIDR‑блокам VPC pod‑ы могут обращаться к pod‑ам или узлам в другом кластере.

Clusters Using Different Networks

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

• CIDR‑блок VPC кластера не может перекрываться с CIDR‑блоком VPC другого кластера.
• CIDR‑блоки подсетей не могут перекрываться с любыми CIDR‑блоками pod.
• pod CIDR blocks в этих кластерах не могут перекрываться друг с другом.
• Если pod‑ы или узлы в этих кластерах должны обращаться друг к другу, группы безопасности в кластерах с обеих сторон должны разрешать соответствующие CIDR‑блоки в соответствии со следующими правилами:
  • Если кластер‑запрос использует сеть VPC, группа безопасности узлов целевого кластера должна разрешать VPC CIDR block (включая подсети узлов и pod CIDR block) кластера‑запроса.
  • Если кластер‑запрос использует туннельную сеть, группа безопасности узлов целевого кластера должна разрешать VPC CIDR block (включая подсети узлов) кластера‑запроса.
  • Если кластер‑запрос использует сеть Cloud Native 2.0, группа безопасности сетевого интерфейса и группа безопасности узлов целевого кластера должны разрешать VPC CIDR block (включая подсети узлов и pod CIDR block) кластера‑запроса.
• Обе таблицы маршрутизации VPC должны включать маршруты к VPC CIDR block соседнего кластера. Например, таблица маршрутизации VPC 1 должна включать маршрут к CIDR block VPC 2, и аналогично, таблица маршрутизации VPC 2 должна включать маршрут к CIDR block VPC 1. После добавления маршрутов VPC CIDR block pod‑ы могут обращаться к узлам в другом кластере, например, к Service типа NodePort.

  Если один из кластеров использует сеть VPC, обе таблицы маршрутизации VPC также должны включать pod CIDR blocks. После добавления маршрутов pod CIDR blocks pod‑ы могут напрямую обращаться к pod‑ам в другом кластере по их IP‑адресам.

Кластеры CCE могут использоваться совместно с другими облачными сервисами, такими как RDS и Kafka. Чтобы обеспечить стабильную связь и избежать конфликтов сети, сеть кластера должна быть тщательно спроектирована. В частности, CIDR‑блоки, используемые другими сервисами, не должны перекрываться с блоками, используемыми кластером. Ниже приведены требования в зависимости от сети кластера:

• Для кластера, использующего сеть VPC: CIDR‑блоки других облачных сервисов не должны перекрываться с pod CIDR block или Service CIDR block внутри кластера.
• Для кластера, использующего туннельную сеть: CIDR‑блоки других облачных сервисов не должны перекрываться с pod CIDR block или Service CIDR block внутри кластера.
• Для кластера CCE Turbo, использующего сеть Cloud Native 2.0: CIDR‑блоки других облачных сервисов не должны перекрываться с Service CIDR block внутри кластера.

Подобно сценарию подключения VPC, некоторые CIDR‑блоки в VPC могут быть маршрутизированы к IDC, поэтому IP‑адреса pod в кластере CCE не должны пересекаться с этими CIDR‑блоками. Если IDC необходимо получить доступ к pod в кластере, соответствующие маршруты к частной линии также должны быть настроены в таблице маршрутизации IDC.