Tunnel Network Model

Model Definition

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

Figure 1 Контейнерная туннельная сеть

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

Преимущества и Недостатки

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

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

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

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

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

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

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

Рисунок 2 Распределение IP‑адресов контейнерной туннельной сети

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

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

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

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. Проверьте работающие pods.

   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>
   
   

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

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