Настройка внутренней сети

В Deckhouse Kubernetes Platform (DKP) для настройки сети используются CNI-плагины. Рекомендуемый вариант — Cilium, подходит для большинства сценариев. Также поддерживаются CNI Flannel и Simple Bridge (обычно применяются для облачных провайдеров).

Сетевые параметры задаются при развертывании кластера DKP:

• указываются адресные пространства для подов и сервисов кластера;
• выбирается режим работы сети для Cilium (можно изменить позже).

Режимы работы внутренней сети

Режим работы определяется параметром tunnelMode в настройках модуля cni-cilium. Поддерживается два режима:

• классический,
• с использованием VXLAN-туннеля.

Выбор подходящего варианта зависит от особенностей сети кластера:

• Если узлы кластера находятся в одной сети, могут быть использованы оба варианта.
• Если узлы кластера находятся в разных сетях, рекомендуется использовать VXLAN для создания виртуальной изолированной сети поверх существующей. При этом обеспечивается возможность работы с различными сетевыми сегментами.

Различия в производительности между режимами минимальны. Особенности режимов приведены в таблице.

Настройка режима

Режим работы внутренней сети настраивается через ресурс ModuleConfig с именем cni-cilium.

Пример конфигурации:

apiVersion: deckhouse.io/v1alpha1
kind: ModuleConfig
metadata:
  name: cni-cilium
spec:
  version: 1
  enabled: true
  settings:
    tunnelMode: VXLAN

Подробнее о настройках модуля cni-cilium – в документации.

Сервисы

Сервисы в DKP реализуются средствами выбранного CNI, либо через kube-proxy.

Они обеспечивают доступ к группам подов, выполняющих одинаковые функции, и балансируют трафик между ними. Каждый объект Service задаёт:

• логическую группу конечных точек (подов),
• способ маршрутизации к ним.

Поддерживаемые типы сервисов

• ClusterIP — создаёт внутренний IP-адрес, который выбирается из сети сервисов. Весь трафик с этого IP перенаправляется на поды, указанные в селекторе. Тем самым обеспечивается балансировка.

  В этом типе сервиса можно отказаться от назначения IP-адреса. Тогда адрес из сети сервисов не будет назначаться, а сам сервис при обращении будет резолвиться в IP-адреса подов. Балансировка будет работать на уровне DNS (round-robin).

• NodePort — открывает указанный порт на каждом узле кластера и перенаправляет входящий трафик на поды. Из соображений безопасности в DKP порт слушается только на внутреннем IP узлов. Это поведение можно изменить, если добавить аннотацию node.deckhouse.io/nodeport-bind-internal-ip: "false" на группу узлов.
• LoadBalancer — создаётся в облачном провайдере, на котором установлена DKP, и принимает внешний трафик. В bare-metal-кластерах аналогичный функционал реализуется с помощью модуля metalLb.
• ExternalName — DNS-запись для обращения к сервису (по сути, CNAME).

Настройка сети сервисов через kube-proxy

Если используется Flannel или Simple Bridge, для работы сервисов требуется модуль kube-proxy. Он заменяет стандартные компоненты kube-adm (DaemonSet, ConfigMap, RBAC) своей конфигурацией.

По умолчанию в целях безопасности при использовании сервисов с типом NodePort подключения принимаются только на InternalIP узлов. Это поведение можно изменить через аннотацию на узле — node.deckhouse.io/nodeport-bind-internal-ip: "false".

Пример аннотации для NodeGroup:

apiVersion: deckhouse.io/v1
kind: NodeGroup
metadata:
  name: myng
spec:
  nodeTemplate:
    annotations:
      node.deckhouse.io/nodeport-bind-internal-ip: "false"