Модель сети 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‑блоке контейнера.
• Подам нельзя напрямую использовать такие функции, как EIP и группы безопасности.

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

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

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

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

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

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

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

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

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

   Создайте 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‑адресу пода извне кластера. Вы также можете получить доступ к поду, используя его IP‑адрес внутри пода или с узла кластера. В следующем примере показан доступ к IP‑адресу пода внутри пода. example-86b9779494-l8qrw — имя пода, а 172.16.0.7 — IP‑адрес пода.

   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>
   
   

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

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