Cloud Native Network 2.0

Определение модели

Рисунок 1 Cloud Native Network 2.0

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

Примечания и ограничения

Плюсы и минусы

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

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

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

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

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

Рекомендации по планированию CIDR‑блока

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

Пример доступа к Cloud Native Network 2.0

1. Используйте kubectl для доступа к кластеру. Подробнее см. Доступ к кластеру с помощью 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>Добро пожаловать в nginx!</title>
   <style>
       body {
           width: 35em;
           margin: 0 auto;
           font-family: Tahoma, Verdana, Arial, sans-serif;
       }
   </style>
   </head>
   <body>
   <h1>Добро пожаловать в nginx!</h1>
   <p>Если вы видите эту страницу, веб‑сервер nginx успешно установлен и работает. Требуется дальнейшая настройка.</p>
   
   <p>Для онлайн‑документации и поддержки, пожалуйста, обратитесь к
   <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>Спасибо за использование nginx.</em></p>
   </body>
   </html>
   
   

Полезные ссылки

• Для получения подробностей о максимальном количестве подов, которые могут работать на узле в кластере с различными сетевыми моделями, см. Максимальное количество подов, которые могут быть созданы на узле.