Модель сети VPC

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

Модель сети VPC бесшовно объединяет маршрутизацию VPC с базовой сетью, делая её идеальной для сценариев с высокой производительностью. Однако максимальное количество узлов, допускаемых в кластере, определяется квотой маршрутов VPC. В модели сети VPC CIDR‑блоки контейнеров отделены от CIDR‑блоков узлов. Для назначения IP‑адресов подам, работающим на узле кластера, каждому узлу в кластере выделяется диапазон IP‑адресов подов фиксированного количества. Модель сети VPC превосходит модель сети контейнерного туннеля по производительности, поскольку она не имеет накладных расходов на инкапсуляцию туннеля. Когда модель сети VPC используется в кластере, маршруты между CIDR‑блоками контейнеров и CIDR‑блоками VPC автоматически настраиваются в таблице маршрутов VPC. Это означает, что поды внутри кластера могут быть доступны напрямую с облачных серверов в том же VPC, даже если они находятся вне кластера.

Рисунок 1 Модель сети VPC

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

Преимущества и Недостатки

• Высокая производительность и упрощённое обнаружение сетевых неисправностей достигаются за счёт устранения необходимости туннельной инкапсуляции
• Таблица маршрутизации VPC автоматически настраивает маршруты между блоками CIDR контейнеров и блоками CIDR VPC. Это позволяет ресурсам VPC напрямую взаимодействовать с контейнерами в кластере
  Note

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

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

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

• Требования к высокой производительности: так как туннельная инкапсуляция не требуется, модель сети VPC обеспечивает производительность, близкую к производительности сети VPC, по сравнению с моделью сети контейнерных туннелей. Поэтому модель сети VPC применяется в сценариях с высокими требованиями к производительности, таких как AI computing и big data computing.
• Небольшие и средние сети: из‑за ограничений таблиц маршрутов VPC рекомендуется, чтобы количество узлов в кластере было меньше или равно 1000.

Управление IP‑адресами Pod

• Отдельные блоки CIDR: CIDR-блок контейнера полностью отделён от CIDR-блоков узлов. Они не перекрываются. Это предотвращает конфликты IP-адресов между узлами и pod‑ами. Кроме того, эти CIDR-блоки можно настраивать отдельно.
• Каждый узел заранее выделил фиксированного размера pod CIDR‑блок: Фиксированного размера pod CIDR‑блок заранее выделяется каждому узлу из CIDR‑блока контейнера. Например, каждому узлу может быть выделено 128 IP‑адресов (/25 маска). Размер CIDR‑блока можно настроить при создании кластера, чтобы каждый узел имел достаточно IP‑адресов для своих pod‑ов.
• Каждому узлу последовательно назначается pod CIDR‑блок: При добавлении узла заранее определённый по размеру pod CIDR‑блок последовательно назначается ему из CIDR‑блока контейнера. Например, если CIDR‑блок контейнера 172.16.0.0/16, то 172.16.0.0/25 назначается первому узлу, 172.16.0.128/25 — второму узлу и так далее, пока CIDR‑блок контейнера не будет исчерпан, как показано в Рисунок 2.
• Каждому pod назначается IP‑адрес из pod CIDR‑блока узла: После того как Под запланирован на узел, он получает IP‑адрес из CIDR‑блока Под, предварительно выделенного этому узлу последовательно. IP‑адреса Под не могут превышать диапазон CIDR‑блока Под на узле.

Рисунок 2 Управление IP‑адресами сети VPC

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

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

Пример доступа к сети VPC

1. Используйте kubectl для доступа к кластеру. Подробнее см. Доступ к Кластеру с помощью kubectl.
2. Создать развертывание в кластере.

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

   kind: Deployment
   apiVersion: apps/v1
   metadata:
     name: example
     namespace: default
   spec:
     replicas: 4
     selector:
       matchLabels:
         app: example
     template:
       metadata:
         labels:
           app: example
       spec:
         containers:
           - name: container-0
             image: 'nginx:perl'
         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-86b9779494-l8qrw   1/1     Running   0          14s   172.16.0.6   192.168.0.99   <none>           <none>
   example-86b9779494-svs8t   1/1     Running   0          14s   172.16.0.7   192.168.0.99   <none>           <none>
   example-86b9779494-x8kl5   1/1     Running   0          14s   172.16.0.5   192.168.0.99   <none>           <none>
   example-86b9779494-zt627   1/1     Running   0          14s   172.16.0.8   192.168.0.99   <none>           <none>
   
   

4. Используйте облачный сервер в том же VPC, чтобы напрямую получить доступ к IP-адресу pod из‑за пределов кластера. Вы также можете получить доступ к pod, используя его IP-адрес внутри pod или с узла в кластере. В следующем примере доступ к IP-адресу pod осуществляется внутри pod. example-86b9779494-l8qrw это имя pod, и 172.16.0.7 это IP-адрес pod.

   kubectl exec -it example-86b9779494-l8qrw -- curl 172.16.0.7
   
   

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

   <!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>
   
   

Helpful Links

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