Модель туннельной сети

Контейнерная туннельная сеть создает отдельную сетевую плоскость для контейнеров, используя туннельную инкапсуляцию в плоскости сети хоста. Эта модель сети использует VXLAN для туннельной инкапсуляции и Open vSwitch в качестве бэкенда виртуального коммутатора. VXLAN — протокол, инкапсулирующий Ethernet‑пакеты в UDP‑пакеты для передачи их через туннели. Open vSwitch — открытый виртуальный коммутатор, предоставляющий функции, такие как изоляция сети и пересылка данных.

Хотя могут возникнуть некоторые затраты производительности, инкапсуляция пакетов и передача через туннель обеспечивают большую совместимость и совместную работу с расширенными функциями, такими как изоляция на основе сетевых политик, в большинстве типовых сценариев.

Рисунок 1 Container tunnel network

В кластере, использующем модель контейнерного туннеля, пути коммуникации между pod‑ами на одном узле и между pod‑ами на разных узлах различаются.

• Взаимодействие pod‑ов на одном узле: пакеты напрямую пересылаются через мост OVS на узле.
• Взаимодействие pod‑ов на разных узлах: пакеты инкапсулируются в мосте OVS, а затем пересылаются к целевому pod‑у на соседнем узле через сетевой интерфейс хоста.

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

• Контейнерная сеть отделена от сети узла и не ограничивается квотами VPC и скоростью отклика (например, количеством маршрутов VPC, количеством сетевых интерфейсов и скоростью создания).
• Поддерживается изоляция сети. Подробности см. в Configuring Network Policies to Restrict Pod Access.
• Поддерживаются ограничения пропускной способности.
• Поддерживается масштабная сеть с максимумом в 2000 узлов.

Недостатки

• Высокие накладные расходы на инкапсуляцию приводят к низкой производительности и затрудняют поиск сетевых неисправностей.
• Pods не могут напрямую использовать такие функции, как EIPs и группы безопасности.
• IP-адреса Pod не могут быть напрямую доступны внешними сетями.

• Низкие требования к производительности: поскольку container tunnel network требует дополнительной инкапсуляции VXLAN‑туннеля, она теряет примерно от 5 % до 15 % производительности по сравнению с другими двумя container network models. Поэтому container tunnel network применяется в сценариях, не имеющих высоких требований к производительности, таких как веб‑приложения, а также middle-end и back-end сервисы с небольшим количеством запросов.
• Крупномасштабные сети: в отличие от сети VPC, ограниченной квотой маршрутов VPC, container tunnel network не имеет ограничений на инфраструктуру. Кроме того, container tunnel network контролирует широковещательный домен на уровне узла. container tunnel network поддерживает максимум 2000 узлов.

container tunnel network выделяет IP-адреса pod в соответствии со следующими правилами:

• Separate CIDR blocks: CIDR‑блок контейнера полностью отделён от CIDR‑блоков узлов. Они не перекрываются. Это предотвращает конфликты IP‑адресов между узлами и pod. Кроме того, эти CIDR‑блоки можно настраивать отдельно.
• CIDR blocks dynamically assigned to nodes by block: CIDR‑блоки pod фиксированного размера (по умолчанию 16 IP‑адресов, то есть маска /28) выделяются из CIDR‑блока контейнера. Эти CIDR‑блоки последовательно назначаются узлам в кластере.

• Pod IP addresses added after exhaustion: После исчерпания назначенного узлу CIDR‑блока pod автоматически применяется новый CIDR‑блок pod из CIDR‑блока контейнера, чтобы обеспечить достаточное количество IP‑адресов pod для создания pod‑ов.
• Cyclic allocation of container CIDR block: CIDR‑блоки pod распределяются между новыми и существующими узлами циклически в порядке последовательности CIDR‑блока контейнера, чтобы предотвратить чрезмерное заполнение некоторых CIDR‑блоков pod.
• Pod IP addresses allocated from the CIDR blocks assigned to nodes: После того как pod‑ы запланированы на узел, они получают IP‑адреса из одного или нескольких CIDR‑блоков pod, назначенных узлу, последовательно, чтобы обеспечить последовательное и уникальное распределение IP‑адресов. Например, если CIDR‑блоки pod, назначенные узлу, — 172.16.0.0/28 и 172.16.1.16/28, и IP‑адреса в 172.16.0.0/28 исчерпаны, IP‑адреса pod будут выделяться из 172.16.1.16/28.

Максимальное количество узлов, которые можно создать в кластере с использованием container tunnel network = количество IP‑адресов в CIDR‑блоке контейнера / размер IP‑CIDR‑блока, выделяемого узлу из CIDR‑блока контейнера за один раз (по умолчанию 16)

Например, если CIDR‑блок контейнера — 172.16.0.0/16, количество IP‑адресов составляет 65 536. Если маска CIDR‑блока контейнера, выделяемого каждому узлу, равна 28 (каждый раз выделяется в общей сложности 16 IP‑адресов pod), можно создать максимум 4 096 (65536/16) узлов. Это экстремальный случай. Если создано 4 096 узлов, для каждого узла можно создать максимум 16 pod, поскольку каждому узлу выделяется только CIDR‑блок с 16 IP‑адресами. Количество узлов, которое можно добавить в кластер, также определяется доступными IP‑адресами в подсети узлов и масштабом кластера.

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

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

Ниже приведён пример создания рабочей нагрузки в кластере с использованием модели container tunnel network:

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'
             resources:
               limits:
                 cpu: 250m
                 memory: 512Mi
               requests:
                 cpu: 250m
                 memory: 512Mi
         imagePullSecrets:
           - name: default-secret
   
   

   Создайте рабочую нагрузку.

   kubectl apply -f deployment.yaml
   
   

3. Проверьте запущенные pod.

   kubectl get pod -owide
   
   

   Вывод команды:

   NAME                       READY   STATUS    RESTARTS   AGE     IP          NODE           NOMINATED NODE   READINESS GATES
   example-5bdc5699b7-5rvq4   1/1     Running   0          3m28s   10.0.0.20   192.168.0.42   <none>           <none>
   example-5bdc5699b7-984j9   1/1     Running   0          3m28s   10.0.0.21   192.168.0.42   <none>           <none>
   example-5bdc5699b7-lfxkm   1/1     Running   0          3m28s   10.0.0.22   192.168.0.42   <none>           <none>
   example-5bdc5699b7-wjcmg   1/1     Running   0          3m28s   10.0.0.52   192.168.0.64   <none>           <none>
   
   

4. Используйте облачный сервер в том же VPC для прямого доступа к IP-адресу pod из внешней сети кластера. Доступ не удался.

   Вы можете получить доступ к pod, используя его IP-адрес внутри pod или с узла в кластере. В следующем примере доступ к IP-адресу pod осуществляется внутри pod. example-5bdc5699b7-5rvq4 — имя pod, а 10.0.0.21 — IP-адрес pod.

   kubectl exec -it example-5bdc5699b7-5rvq4 -- curl 10.0.0.21
   
   

   Если отображается следующая информация, workload можно получить:

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