Модель сети VPC

Модель сети VPC бесшовно сочетает маршрутизацию VPC с базовой сетью, что делает её идеальной для сценариев с высокой производительностью. Однако максимальное количество узлов, разрешённое в кластере, определяется VPC route quota. В модели сети VPC блоки CIDR контейнеров отделены от блоков CIDR узлов. Для назначения IP‑адресов pod‑ам, работающим на узле в кластере, каждому узлу в кластере выделяется pod IP range с фиксированным числом адресов. Модель сети VPC превосходит модель container tunnel network model по производительности, поскольку не имеет накладных расходов на туннельную инкапсуляцию. При использовании модели сети VPC в кластере маршруты между блоками CIDR контейнеров и блоками CIDR VPC автоматически настраиваются в VPC route table. Это означает, что pod‑ы внутри кластера могут быть доступны напрямую с облачных серверов в том же VPC, даже если они находятся за пределами кластера.

Рис. 1 модель сети VPC

В кластере, использующем модель сети VPC, пути сетевого взаимодействия следующие:

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

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

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

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

Недостатки

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

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

Сеть VPC распределяет IP‑адреса pod согласно правилам ниже. Основное правило — предварительно выделять pod CIDR‑блоки из контейнерного CIDR‑блока узлам, а затем распределять IP‑адреса из pod CIDR‑блоков 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‑блок, как показано на Figure 2.
• Каждому pod назначается IP‑адрес из pod CIDR‑блока на узле: После того как pod запланирован на узел, он получает IP‑адрес из pod CIDR‑блока, предварительно выделенного этому узлу, последовательно. IP‑адреса pod‑ов не могут выходить за пределы диапазона pod CIDR‑блока на узле.

Максимальное количество узлов, которые можно создать в кластере с использованием VPC network = Number of IP addresses in the container CIDR block/Number of IP addresses in the CIDR block allocated to the node by the container CIDR block

Например, если контейнерный CIDR‑блок — 172.16.0.0/16, количество IP‑адресов составляет 65 536. Маска контейнерного CIDR‑блока, выделенного узлу, равна 25. То есть количество pod IP‑адресов на каждом узле составляет 128. Следовательно, можно создать максимум 512 (65536/128) узлов. Количество узлов, которое можно добавить в кластер, также определяется доступными IP‑адресами в подсети узла и масштабом кластера. Подробнее см. Recommendation for CIDR Block Planning.

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

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

Предположим, что кластер содержит 200 узлов, а модель сети — VPC network.

В этом случае количество доступных IP‑адресов в выбранной подсети должно превышать 200. В противном случае узлы не могут быть созданы из‑за недостаточного количества IP‑адресов.

CIDR‑блок контейнера — 172.16.0.0/16, количество доступных IP‑адресов — 65 536. Как описано в Pod IP Address Management, VPC network получает CIDR‑блок фиксированного размера (маска используется для определения максимального количества IP‑адресов pod, выделяемых каждому узлу). Например, если верхний предел равен 128, кластер поддерживает максимум 512 (65536/128) узлов.

В этом примере создаётся кластер, использующий модель сети VPC, и кластер содержит один узел.

В консоли VPC найдите VPC, к которому относится кластер, и проверьте таблицу маршрутизации VPC.

Вы можете увидеть, что CCE создал пользовательский маршрут в таблице маршрутизации. Этот маршрут имеет адрес назначения, соответствующий CIDR‑блоку контейнера, назначенному узлу, а следующий переход направлен к целевому узлу. В примере CIDR‑блок контейнера для кластера — 172.16.0.0/16, с 128 IP‑адресами pod, назначенными каждому узлу. Следовательно, CIDR‑блок контейнера узла — 172.16.0.0/25, что обеспечивает в общей сложности 128 IP‑адресов pod.

Когда обращаются к IP‑адресу pod, маршрут VPC перенаправит трафик к узлу‑следующему переходу, соответствующему адресу назначения. Ниже приведён пример:

1. Используйте kubectl для доступа к кластеру. Подробности см. в Accessing a Cluster Using 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. Проверьте работающие pods.

   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>
   
   

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