Если на площадке, где работает Deckhouse Kubernetes Platform (DKP), есть требования для ограничения сетевого взаимодействия между серверами на уровне инфраструктуры, то необходимо соблюсти следующие условия:

  • Включен режим туннелирования трафика между подами (настройки для CNI Cilium, настройки для CNI Flannel).
  • Разрешена передача трафика между podSubnetCIDR, инкапсулированного внутри VXLAN (если выполняется инспектирование и фильтрация трафика внутри VXLAN-туннеля).
  • В случае необходимости интеграции с внешними системами (например, LDAP, SMTP или прочие внешние API), с ними разрешено сетевое взаимодействие.
  • Локальное сетевое взаимодействие полностью разрешено в рамках каждого отдельно взятого узла кластера.
  • Разрешено взаимодействие между узлами по портам, приведенным в таблицах на текущей странице. Обратите внимание, что большинство портов входит в диапазон 4200-4299. При добавлении новых компонентов платформы им будут назначаться порты из этого диапазона (при наличии возможности).

Как проверить текущий порт VXLAN...

d8 k -n d8-cni-cilium get cm cilium-config -o yaml | grep tunnel

Пример вывода команды:

routing-mode: tunnel
tunnel-port: "4298"
tunnel-protocol: vxlan

Изменения, связанные с добавлением, удалением или переопределением портов в таблицах, перечислены в подразделе «Сеть» соответствующей версии DKP на странице «История изменений».

Требования к сетевым задержкам между master-узлами

В DKP поддерживается режим HA с использованием arbiter-узлов. Приведенные ниже требования к сетевым задержкам также применимы и к arbiter-узлам.

Etcd подтверждает запись только после того, как изменение реплицировано на большинство master-узлов. Поэтому круговая задержка сети (RTT, round-trip time) между master-узлами напрямую определяет скорость работы кластера. Одна операция в кластере обычно состоит из нескольких последовательных записей, поэтому с ростом задержки заметно замедляются применение манифестов, работа операторов и отклик Kubernetes API.

Сумма RTT и джиттера между master-узлами не должна превышать 100 мс.

Указана круговая задержка (RTT), а не задержка в одну сторону: например команда ping возвращает RTT.

Джиттер — разброс задержки — добавляется к RTT. Например, при RTT 90 мс и джиттере 20 мс сумма составляет 110 мс, и требование не выполняется, хотя само значение RTT укладывается в 100 мс.

При планировании кластера рекомендуется добиваться задержки не более 50 мс между будущими master-узлами, то есть двукратного запаса к требованию. Запас необходим по следующим причинам:

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

Откуда взято значение 100 мс...

DKP использует стандартные значения etcd:

  • ETCD_HEARTBEAT_INTERVAL — 100 мс, частота отправки heartbeat-сообщений от лидера остальным членам кластера.
  • ETCD_ELECTION_TIMEOUT — 1000 мс, время ожидания heartbeat-сообщений, после которого член кластера начинает перевыборы лидера.

Документация etcd требует, чтобы таймаут перевыборов был не менее 10x RTT. Отсюда максимально допустимое значение:

1000 мс / 10 = 100 мс

Возможные проблемы

Главное следствие повышенного RTT — пропорциональное замедление кластера. Задержка сети переходит во время записи один к одному: при RTT 300 мс каждая запись в etcd займёт не менее 300 мс. Порога здесь нет, деградация идёт непрерывно с ростом задержки.

Вторая проблема — перевыборы лидера etcd. Вызываются они не величиной задержки, а её полным пропаданием: член кластера начинает перевыборы, если не получает сообщений от лидера в течение времени, заданного ETCD_ELECTION_TIMEOUT (с учётом встроенного в etcd механизма рандомизации — от 1000 до 2000 мс). При интервале heartbeat 100 мс это соответствует 10–20 не полученным подряд heartbeat-сообщениям. Типичные причины:

  • обрыв связи или потеря пакетов на протяжении 1–2 секунд;
  • задержки записи на диск на узле-лидере, из-за которых etcd не успевает отправлять heartbeat-сообщения;
  • перезапуск пода etcd.

Отдельные всплески задержки к перевыборам не приводят: heartbeat-сообщения приходят, но с опозданием. Замедляются только записи, попавшие в момент всплеска.

Однако высокий RTT делает перевыборы затяжными, когда они всё же случаются. Голоса собираются за время одного RTT и должны уложиться в ETCD_ELECTION_TIMEOUT. Если RTT близок к этому таймауту, перевыборы не успевают завершиться и начинаются заново, а кластер остаётся без лидера. Десятикратный запас нужен, чтобы перевыборы прошли с первой попытки.

Во время перевыборов etcd не обслуживает запросы на запись, поэтому Kubernetes API возвращает ошибки. О частых перевыборах сигнализирует алерт KubeEtcdHighNumberOfLeaderChanges — более трёх перевыборов лидера за 10 минут.

Проверка текущих задержек

Задержку и её разброс можно измерить с помощью ping. Команда выполняется на одном из master-узлов, а при планировании кластера — на сервере, который предполагается сделать master-узлом. Для такой проверки достаточно ICMP, который уже входит в требования к трафику между узлами:

ping -c 100 -i 0.2 <IP-адрес другого master-узла>

Пример итоговой строки вывода:

rtt min/avg/max/mdev = 25.085/25.502/35.933/1.185 ms

Здесь avg — средний RTT, mdev — разброс задержки (джиттер), max — фактический максимум, то есть RTT с учётом всплесков. Складывать RTT и джиттер вручную не нужно: сравнивать с требованиями следует значение max. При планировании кластера рекомендуем укладываться в 50 мс, на работающем кластере — не превышать 100 мс.

Сетевые задержки на остальных узлах

Для работы control plane требований к сетевым задержкам на узлах, не являющихся master-узлами, нет: величина задержки на них не влияет на устойчивость кластера. Значение имеет только длительность потери связи с master-узлами — по умолчанию через 40 секунд узел переходит в состояние Unreachable, а через 5 минут его поды переносятся на другие узлы. Оба порога настраиваются параметрами nodeMonitorGracePeriodSeconds и failedNodePodEvictionTimeoutSeconds.

При этом задержки влияют на скорость работы всего, что запущено на узлах, — в том числе компонентов самой платформы. Для компонентов, обращающихся к Kubernetes API (операторы DKP, Prometheus, Ingress-контроллеры), задержка до master-узлов добавляется к каждому запросу. Задержка между узлами добавляется к каждому сетевому запросу между подами и к разрешению DNS-имён, а при использовании реплицируемого хранилища — ко времени записи на диск.

Таким образом допустимое значение определяется требованиями запускаемой нагрузки. Для кластеров, распределённых между удалёнными площадками, это означает, что платформа продолжит работать, но задержки приложений будут отражать географию размещения узлов.

Трафик между master-узлами

Порт Протокол Назначение
2379, 2380 TCP

Репликация etcd
4200 TCP

Вебхук-обработчик Cluster API
4201 TCP

Вебхук-обработчик для cloud-провайдера VMware Cloud Director
4223 TCP

Вебхук-обработчик контроллера Deckhouse

Трафик от master-узлов к узлам

Порт Протокол Назначение
22 TCP

SSH для первичной настройки статичных узлов статичным провайдером
10250 TCP

kubelet
4221 TCP

apiserver bashible для доставки конфигурации на узлы
4227 TCP

Вебхук-обработчик компонента runtime-audit-engine

Трафик от узлов к master-узлам

Порт Протокол Назначение
4234 UDP

NTP для синхронизации времени между узлами
6443 TCP

kube-apiserver для контроллеров, работающих в сетевом пространстве имен узла
4203 TCP

Метрики компонента machine-controller-manager
4219 TCP

Прокси для пакетов registry registry-packages-proxy
4222 TCP

Метрики контроллера Deckhouse

Трафик между узлами

Порт Протокол Назначение
— ICMP

ICMP для мониторинга связности между узлами
4202 TCP

Метрики агента sds-node-configurator
4204 TCP

Debug для контроллера Deckhouse
4205 TCP

Метрики модуля ebpf-exporter
4206 TCP

Метрики модуля node-exporter
4207 TCP

Метрики контроллера ingress-nginx для инлета HostWithFailover
4208 TCP

Метрики контроллера ingress-nginx для инлета HostWithFailover
4209 TCP

Метрики управляющего слоя Kubernetes
4210 TCP

Метрики kube-proxy
4211 TCP

Метрики Cluster API
4212 TCP

Метрики модуля runtime-audit-engine
4213 TCP

Метрики kube-router
4214 TCP

API агента модуля sds-replicated-volume
4215 TCP

Метрики агента sds-replicated-volume
4216 TCP

Метрики агента storage-status
4218 TCP/UDP

Синхронизация компонентов speaker модулей metallb через протокол memberlist
4220 TCP

Метрики компонентов speaker модулей metallb
4224 TCP

Метрики node-local-dns
4225 TCP/UDP

Синхронизация компонентов speaker модулей metallb через протокол memberlist
4226 TCP

Метрики компонентов speaker модулей metallb
4228 TCP

Healthcheck агента модуля sds-node-configurator
4229 TCP

Healthcheck CSI-контроллера модуля csi-nfs
4230 TCP

Healthcheck CSI-агентов модуля csi-nfs
4231 TCP

Healthcheck CSI-контроллера модуля csi-hpe
4232 TCP

Healthcheck CSI-агентов модуля csi-hpe
4235 TCP

Healthcheck CSI-контроллера модуля csi-s3
4236 TCP

Healthcheck CSI-агентов модуля csi-s3
4237 TCP

Healthcheck CSI-контроллера модуля csi-scsi-generic
4238 TCP

Healthcheck CSI-агентов модуля csi-scsi-generic
4239 TCP

Healthcheck агента модуля storage-status
4240 TCP

Порт для процедуры healthcheck соседних узлов в CNI Cilium
4241 TCP

Метрики агентов CNI Cilium
4242 TCP

Метрики оператора CNI Cilium
4244 TCP

API для модуля cilium-hubble
4245 TCP

Метрики chrony-exporter
4246 TCP

Healthcheck CSI-контроллера CephFS модуля csi-ceph
4247 TCP

Healthcheck CSI-контроллера RBD модуля csi-ceph
4248 TCP

Healthcheck CSI-контроллера модуля csi-yadro-tatlin-unified
4249 TCP

Healthcheck CSI-агентов модуля csi-yadro-tatlin-unified
4250 TCP

Healthcheck CSI-контроллера модуля sds-local-volume
4251 TCP

Healthcheck CSI-агентов модуля sds-local-volume
4252 TCP

Healthcheck CSI-агентов RBD модуля csi-ceph
4253 TCP

Healthcheck CSI-агентов CephFS модуля csi-ceph
4254 TCP

Healthcheck CSI-контроллера модуля csi-netapp
4255 TCP

Healthcheck CSI-агентов модуля csi-netapp
4256 TCP

Метрики CSI-контроллера модуля csi-netapp
4257 TCP

Порт API CSI-контроллера модуля csi-netapp
4258 TCP

Порт вебхука CSI-контроллера модуля csi-huawei
4259 TCP

Healthcheck CSI-агентов модуля csi-huawei
4260 TCP

Метрики CSI-контроллера модуля csi-huawei
4261 TCP

Healthcheck CSI-контроллера модуля sds-replicated-volume
4262 TCP

Healthcheck CSI-агентов модуля sds-replicated-volume
4263 TCP

Метрики модуля service-with-healthchecks
4269 TCP

Healthcheck CSI-агентов модуля sds-replicated-volume
4270 TCP

Метрики CSI-агентов модуля sds-replicated-volume
4271 TCP

Healthcheck CSI-контроллера модуля sds-replicated-volume
4272 TCP

Метрики CSI-контроллера модуля sds-replicated-volume
4135-4199 TCP

Туннели live migration модуля virtualization между узлами кластера
4280 TCP

Протокол USB over IP (usb/ip) модуля virtualization для проброса USB-устройств между узлами кластера
4286 TCP

Метрики Istio CNI
4287 UDP

Порт WireGuard для шифрования трафика в CNI Cilium
4288 TCP

Метрики monitoring-ping
4289 TCP

Метрики monitoring-ping
4295‑4297 UDP

Используется модулем cni-cilium для VXLAN-инкапсуляции трафика между подами при множественной вложенной виртуализации — когда DKP с включенным модулем virtualization развернут внутри виртуальных машин, также созданных в DKP с включенным модулем virtualization
4298 UDP

Используется модулем cni-cilium для VXLAN-инкапсуляции трафика между подами, если кластер был развернут на DKP, начиная с версии 1.71 (для кластеров, развернутых на DKP до версии 1.71, см. примечание для портов 4299/UDP, 8469/UDP и 8472/UDP)
4299 UDP

Для кластеров, развернутых на DKP версий 1.64–1.70. Используется модулем cni-cilium для VXLAN-инкапсуляции трафика между подами. Обновление DKP до более новых версий не изменит занимаемый порт, если не включается модуль virtualization.

Обратите внимание, что в таких кластерах включение модуля virtualization на DKP до версии 1.70 меняет порт на 4298/UDP
7000‑7999 TCP

Репликация DRBD для sds-replicated-volume
8469 UDP

Для кластеров, развернутых на DKP версии 1.63 и ниже с модулем virtualization, включенным до DKP версии 1.63. Используется модулем cni-cilium для VXLAN-инкапсуляции трафика между подами. Обновление DKP до более новых версий не изменит занимаемый порт
8472 UDP

Для кластеров, развернутых на DKP версии 1.63 и ниже. Используется модулем cni-cilium для VXLAN-инкапсуляции трафика между подами. Обновление DKP до более новых версий не изменит занимаемый порт, если не включается модуль virtualization.

Обратите внимание, что в таких кластерах включение модуля virtualization на DKP до версии 1.70 меняет порт:

  • включение модуля virtualization на DKP версии 1.63 и ниже изменит его на 8469/UDP и не изменит при последующих обновлениях DKP
  • включение модуля virtualization на DKP, начиная с версии 1.64, изменит его на 4298/UDP и не изменит при последующих обновлениях DKP

Статические порты модуля virtualization на узлах кластера (зарезервирован диапазон 4100-4134/TCP)

Порт Протокол Назначение
4100 TCP

Healthz и метрики virt-handler модуля virtualization
4101 TCP

Сервер консоли virt-handler модуля virtualization
4105 TCP

Порты liveness и readiness проб vm-route-forge модуля virtualization
4106 TCP

Порт pprof компонента vm-route-forge модуля virtualization в debug-режиме
4107 TCP

Порты gRPC liveness и readiness проб virtualization-dra модуля virtualization

Внешний трафик к master-узлам

Порт Протокол Назначение
22 TCP

SSH для инициализации Deckhouse Kubernetes Platform
6443 TCP

Прямой доступ к API-серверу

Внешний трафик к фронтенд-узлам

Порт Протокол Назначение
80, 443 TCP

Прикладные порты для запросов к Ingress-контроллеру по протоколам HTTP и HTTPS. Обратите внимание, что эти порты настраиваются в ресурсе IngressNginxController и могут отличаться в разных инсталляциях
5416 UDP

OpenVPN
5416 TCP

OpenVPN
10256 TCP

Healthcheck-порт для внешних балансировщиков
30000-32767 TCP

Диапазон портов NodePort

Внешний трафик для всех узлов

Порт Протокол Назначение
53 UDP

DNS
53 TCP

DNS
123 UDP

NTP для синхронизации с внешними серверами точного времени
179 TCP

BGP-стык с роутером инфраструктуры для балансировки сетевого трафика (модуль metallb)
443 TCP

Container registry

Дополнительные ресурсы