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

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

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

Рисунок 1 Контейнерная туннельная сеть

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

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

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

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

Недостатки

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

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

Сеть туннеля контейнеров выделяет pod IP addresses в соответствии со следующими правилами:

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

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

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
   
   

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

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