Cloud Native Network 2.0

Проприетарная, следующего поколения Cloud Native Network 2.0 объединяет сетевые интерфейсы и дополнительные сетевые интерфейсы VPC. Это позволяет привязывать сетевые интерфейсы или дополнительные сетевые интерфейсы к подам, предоставляя каждому поду уникальный IP‑адрес внутри VPC. Cloud Native Network 2.0 также поддерживает такие функции, как сквозное сетевое соединение ELB и ассоциацию групп безопасности и EIPs с подами. Поскольку инкапсуляция контейнерного туннеля и NAT не требуются, Cloud Native Network 2.0 обеспечивает более высокую сетевую производительность, чем сети контейнерного туннеля и VPC.

В кластере, использующем Cloud Native Network 2.0, поды полагаются на сетевые интерфейсы и дополнительные сетевые интерфейсы для доступа к внешним сетям.

• Поды, работающие на ECS, используют дополнительные сетевые интерфейсы для доступа к внешним сетям. Дополнительные сетевые интерфейсы присоединяются к elastic network interfaces ECS через подинтерфейсы VLAN.
• Чтобы запустить под, привяжите к нему сетевой интерфейс. Максимальное количество подов, которые могут работать на отдельном узле, зависит от количества сетевых интерфейсов, которые можно привязать к узлу, и от количества доступных портов сетевых интерфейсов на узле.
• Трафик для взаимодействия между подами на одном узле, между подами на разных узлах и доступа подов к сетям за пределами кластера передаётся через elastic или дополнительные сетевые интерфейсы VPC.

Эта модель сети доступна только для кластеров CCE Turbo.

Преимущества

• VPC служат основой для построения контейнерных сетей. Каждый под имеет собственный сетевой интерфейс и IP‑адрес, что упрощает решение сетевых проблем и повышает производительность.
• В той же VPC сетевые интерфейсы напрямую привязываются к подам в кластере, что позволяет ресурсам за пределами кластера напрямую взаимодействовать с контейнерами внутри кластера.
  Note

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

• Функции балансировки нагрузки, группы безопасности и EIP, предоставляемые VPC, могут быть напрямую использованы pods.

Недостатки

Контейнерные сети построены на VPC, при этом каждый pod получает IP‑адрес из CIDR‑блока VPC. Поэтому перед созданием кластера необходимо тщательно планировать CIDR‑блок контейнеров.

• Требования к высокой производительности: Cloud Native Network 2.0 использует сети VPC для построения контейнерных сетей, устраняя необходимость туннельной инкапсуляции или NAT, требуемых для коммуникаций контейнеров. Это делает Cloud Native Network 2.0 идеальным для сценариев, требующих высокой пропускной способности и низкой задержки.
• Крупномасштабные сети: Cloud Native Network 2.0 поддерживает до 2 000 узлов ECS и 100 000 pods.

Как объяснено в Cluster Network Structure, в кластере существует три сети: сеть кластера, контейнерная сеть и сеть Service. При планировании сетевых адресов учитывайте следующее:

• Все подсети (включая созданные из вторичных CIDR‑блоков) в VPC, где находится кластер, не должны конфликтовать с CIDR‑блоками Service.
• Каждый CIDR‑блок имеет достаточное количество IP‑адресов.
  • IP‑адреса в CIDR‑блоках кластера должны соответствовать масштабу кластера. В противном случае узлы не могут быть созданы из‑за недостаточного количества IP‑адресов.
  • IP‑адреса в CIDR‑блоках контейнеров должны соответствовать масштабу сервиса. В противном случае pods не могут быть созданы из‑за недостаточного количества IP‑адресов.

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

После создания кластера можно добавить подсети в CIDR‑блок контейнеров, чтобы увеличить количество доступных IP‑адресов. При этом убедитесь, что добавленные подсети не конфликтуют с другими подсетями в CIDR‑блоке контейнеров.

В этом примере создаётся CCE Turbo кластер, и кластер содержит три ECS инстанса.

Вы можете проверить базовую информацию о узле в консоли ECS. Вы увидите, что к узлу привязан основной сетевой интерфейс и расширенный сетевой интерфейс. Оба являются эластичными сетевыми интерфейсами. IP‑адрес расширенного сетевого интерфейса принадлежит блоку CIDR контейнера и используется для привязки дополнительных сетевых интерфейсов к подам на узле.

В следующем примере показано, как создать рабочую нагрузку в кластере, использующем Cloud Native Network 2.0.

1. Используйте kubectl для доступа к кластеру. Подробнее см. Accessing a Cluster Using kubectl.
2. Создайте Deployment в кластере.

   Создайте файл deployment.yaml. Ниже приведён пример:

   kind: Deployment
   apiVersion: apps/v1
   metadata:
     name: example
     namespace: default
   spec:
     replicas: 6
     selector:
       matchLabels:
         app: example
     template:
       metadata:
         labels:
           app: example
       spec:
         containers:
           - name: container-0
             image: 'nginx:perl'
             resources:
               limits:
                 cpu: 250m
                 memory: 512Mi
               requests:
                 cpu: 250m
                 memory: 512Mi
         imagePullSecrets:
           - name: default-secret
   
   

   Создайте рабочую нагрузку.

   kubectl apply -f deployment.yaml
   
   

3. Проверьте работающие поды.

   kubectl get pod -owide
   
   

   Вывод команды:

   NAME                       READY   STATUS    RESTARTS   AGE   IP            NODE         NOMINATED NODE   READINESS GATES
   example-5bdc5699b7-54v7g   1/1     Running   0          7s    10.1.18.2     10.1.0.167   <none>           <none>
   example-5bdc5699b7-6dzx5   1/1     Running   0          7s    10.1.18.216   10.1.0.186   <none>           <none>
   example-5bdc5699b7-gq7xs   1/1     Running   0          7s    10.1.16.63    10.1.0.144   <none>           <none>
   example-5bdc5699b7-h9rvb   1/1     Running   0          7s    10.1.16.125   10.1.0.167   <none>           <none>
   example-5bdc5699b7-s9fts   1/1     Running   0          7s    10.1.16.89    10.1.0.144   <none>           <none>
   example-5bdc5699b7-swq6q   1/1     Running   0          7s    10.1.17.111   10.1.0.167   <none>           <none>
   
   

   Все поды используют дополнительные сетевые интерфейсы, которые привязаны к расширенному сетевому интерфейсу узла.

   Например, IP‑адрес расширенного сетевого интерфейса на узле (10.1.0.167) — 10.1.17.172. На странице сетевых интерфейсов вы можете увидеть, что к расширенному сетевому интерфейсу с IP‑адресом 10.1.17.172 привязаны три дополнительных сетевых интерфейса. IP‑адреса, привязанные к этим дополнительным сетевым интерфейсам, являются IP‑адресами подов, работающих на узле.

4. Войдите в ECS в той же VPC и получите доступ к IP‑адресу пода из внешней сети кластера. В этом примере IP‑адрес запрашиваемого пода — 10.1.18.2.

   curl 10.1.18.2
   
   

   Если отображается следующая информация, к рабочей нагрузке можно получить доступ:

   <!DOCTYPE html>
   <html>
   <head>
   <title>Welcome to nginx!</title>
   <style>
       body {
           width: 35em;
           margin: 0 auto;
           font-family: Tahoma, Verdana, Arial, sans-serif;
       }
   </style>
   </head>
   <body>
   <h1>Welcome to nginx!</h1>
   <p>If you see this page, the nginx web server is successfully installed and
   working. Further configuration is required.</p>
   
   <p>For online documentation and support please refer to
   <a href="http://nginx.org/">nginx.org</a>.<br/>
   Commercial support is available at
   <a href="http://nginx.com/">nginx.com</a>.</p>
   
   <p><em>Thank you for using nginx.</em></p>
   </body>
   </html>
   
   

• Для получения подробной информации о максимальном количестве pods, которые могут работать на узле в кластере с различными сетевыми моделями, см. Maximum Number of Pods That Can Be Created on a Node.