Cloud Native Network 2.0

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

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

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

Notes and Constraints

Advantages and Disadvantages

• VPC служат основой для построения сетей контейнеров. Каждый pod имеет собственный сетевой интерфейс и IP‑адрес, что упрощает решение сетевых проблем и повышает производительность.
• В той же VPC сетевые интерфейсы привязываются напрямую к pod в кластере, чтобы ресурсы за пределами кластера могли напрямую взаимодействовать с контейнерами внутри кластера.
  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, где находится кластер, не могут конфликтовать с Service CIDR-блоками.
• Каждый CIDR-блок имеет достаточное количество IP-адресов.
  • IP-адреса в кластерных CIDR-блоках должны соответствовать масштабу кластера. В противном случае узлы не могут быть созданы из‑за недостаточного количества IP-адресов.
  • IP-адреса в контейнерных CIDR-блоках должны соответствовать масштабу сервиса. В противном случае pods не могут быть созданы из‑за недостаточного количества 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. Проверьте работающие pods.

   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>
   
   

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

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

4. Войдите в ECS в том же VPC и получите доступ к IP-адресу pod из внешней сети кластера. В этом примере IP-адрес доступа pod 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>
   
   

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

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