Tunnel Network Model

Model Definition

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

Figure 1 Туннельная сеть контейнеров

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

Advantages and Disadvantages

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

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

Application Scenarios

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

Pod IP Address Management

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

• IP‑адреса pod‑ов, добавляемые после исчерпания: После того как назначенный узлу CIDR‑блок pod‑ов исчерпан, из CIDR‑блока контейнера автоматически применяется новый CIDR‑блок pod‑ов, чтобы обеспечить достаточное количество IP‑адресов для создания pod‑ов.
• Циклическое распределение CIDR‑блока контейнера: CIDR‑блоки pod‑ов распределяются новым или существующим узлам циклически в порядке последовательности CIDR‑блока контейнера, чтобы предотвратить чрезмерное заполнение некоторых CIDR‑блоков pod‑ов.
• IP‑адреса pod‑ов, выделяемые из CIDR‑блоков, назначенных узлам: После того как 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.

Figure 2 Выделение IP‑адресов в туннельной сети контейнеров

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

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

Пример доступа к туннельной сети контейнеров

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

Helpful Links

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