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

Определение модели

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

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

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

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

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

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

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

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

Управление IP‑адресами контейнеров

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

Рисунок 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>