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

• VPC CIDR Block

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

• Subnet CIDR Block

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

  Figure 1 VPC CIDR block architecture

  
  

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

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

• Container (Pod) CIDR Block

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

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

• Container Subnet (Only for CCE Turbo Clusters)

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

• Service CIDR Block

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

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

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

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

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

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

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

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

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

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

• CIDR‑блок VPC — это место размещения кластера. Размер этого CIDR‑блока влияет на максимальное количество узлов, которые можно создать в кластере.
• CIDR‑блок подсети не может перекрываться с любым CIDR‑блоком pod.
• CIDR-блоки pod всех кластеров могут перекрываться друг с другом. В этом случае pod в разных кластерах нельзя напрямую получить доступ по IP-адресам pod. Для доступа к pod в разных кластерах требуются Service. Рекомендуются 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, не могут перекрываться друг с другом.
• Service CIDR blocks всех этих кластеров могут перекрываться друг с другом, но не могут перекрываться с любым subnet CIDR block или pod CIDR block кластеров.

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

Clusters Using the VPC Networks

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

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

• VPC, к которым принадлежат кластеры, не должны перекрываться друг с другом. В каждом кластере subnet CIDR block не может перекрываться с pod CIDR block.
• pod CIDR blocks кластеров на обеих сторонах не могут перекрываться друг с другом, но Service CIDR blocks могут.
• Если кластер‑запрос использует VPC‑сеть, check whether the node security group in the peer cluster allows the pod CIDR block of the request end cluster. Если да, pod в этих кластерах могут напрямую обращаться друг к другу по pod IP‑адресам. Аналогично, если узлы, работающие в кластерах на обеих сторонах VPC peering connection, должны обращаться друг к другу, node security group должна разрешать VPC CIDR block peer‑кластера.
• Обе VPC route tables должны содержать маршруты к peer CIDR block. Например, route table VPC 1 должна включать маршрут к CIDR‑block VPC 2, и аналогично, route table VPC 2 должна включать маршрут к CIDR‑block VPC 1.
  • Add the peer cluster's VPC CIDR block: После добавления маршрута VPC CIDR block pod могут получать доступ к узлам в другом кластере, например к NodePort Service.
  • Add the peer cluster's pod CIDR block: После добавления маршрута pod CIDR block pod могут напрямую обращаться к pod в другом кластере, используя их IP‑адреса.

Clusters Using the Tunnel Networks

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

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

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

CCE Turbo Clusters Using the Cloud Native 2.0 Networks

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

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

Clusters Using Different Networks

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

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

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

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

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

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