Подсистема Network

В данном подразделе описана архитектура подсистемы Network (сетевой подсистемы) Deckhouse Kubernetes Platform (DKP).

В подсистему Network входят следующие модули:

• kube-dns — устанавливает компоненты CoreDNS для управления DNS в кластере Kubernetes;
• node-local-dns — разворачивает кеширующий DNS-сервер на каждом узле кластера и экспортирует данные в Prometheus для анализа работы DNS в кластере на дашборде Grafana. Архитектура кеширующего DNS-сервера описана на соответствующей странице данного подраздела;
• kube-proxy — управляет компонентами kube-proxy для сетевого взаимодействия и балансировки нагрузки в кластере;
• cni-cilium — обеспечивает работу сети в кластере Kubernetes с помощью CNI Cilium;
• ingress-nginx — устанавливает и управляет Ingress NGINX Controller с помощью кастомных ресурсов. Архитектура модуля описана на соответствующей странице данного подраздела.
• metallb — реализует механизм LoadBalancer для сервисов в bare-metal-кластерах.

Также в подразделе описаны:

• архитектура кластера с включенным Istio;
• архитектура прикладного сервиса с включенным Istio.

Модуль ingress-nginx устанавливает и управляет Ingress NGINX Controller с помощью кастомного ресурса IngressNginxController.

Модуль может работать в режиме высокой доступности (HA) и предоставляет гибкие настройки размещения Ingress-контроллеров на узлах кластера, а также параметры работы контроллера с учетом особенностей реализации инфраструктуры.

Модуль поддерживает запуск и раздельную конфигурацию нескольких экземпляров Ingress NGINX Controller. Это позволяет, например, разделять внешние и внутренние (intranet) Ingress-ресурсы приложений.

Архитектура модуля ingress-nginx на уровне 2 модели C4 и его взаимодействия с другими компонентами Deckhouse Kubernetes Platform (DKP) изображены на следующей диаграмме:

Модуль состоит из следующих компонентов:

1. Controller-nginx (Advanced DaemonSet) — нестандартный DaemonSet с продвинутыми возможностями, управляемый kruise-controller-manager.

Состоит из следующих контейнеров:

• controller — основной контейнер IngressNGINX controller, реализующий основную логику модуля. Является Open Source-проектом;
• protobuf-exporter — сайдкар-контейнер в поде ingress-controller, принимающий статистику NGINX в виде сообщений в формате protobuf. Разбирает и агрегирует сообщения по установленным правилам, а также экспортирует метрики в формате Prometheus. Является разработкой компании «Флант»;
• kube-rbac-proxy — сайдкар-контейнер с авторизующим прокси на основе Kubernetes RBAC для организации защищенного доступа к метрикам и состоянию контроллера и protobuf-exporter. Является Open Source-проектом;
• istio-proxy — сайдкар-контейнер Istio, добавляемый в под при включенном параметре spec.enableIstioSidecar кастомного ресурса IngressNginxController. В этом случае часть пользовательских запросов проходит через него.

2. Validator-nginx (Deployment) — состоит из одного контейнера. Validator — это Ingress NGINX Controller, запущенный в режиме валидации и обладающий ограниченным набором привилегий. Реализует вебхук-сервер, используемый для проверки Ingress-ресурсов через механику Validating Admission Controllers.

3. Kruise-controller-manager (Deployment) — контроллер, управляющий кастомным ресурсом Advanced DaemonSet. Данное расширение DaemonSet позволяет использовать продвинутые возможности при обновлении Ingress NGINX controller, отсутствующие в стандартной реализации DaemonSet-контроллера Kubernetes.

Состоит из следующих контейнеров:

• kruise — основной контейнер kruise-controller-manager;
• kruise-state-metrics — сайдкар-контейнер, отслеживающий состояние объектов API OpenKruise и предоставляющий соответствующие метрики (но не метрики работы самого kruise-controller-manager);
• kube-rbac-proxy — сайдкар-контейнер, обеспечивающий авторизованный доступа к метрикам и состоянию контроллера. Подробно описан выше.

4. Failover-cleaner (DaemonSet) — развертывается на узлах кластера, на которых установлен лейбл ingress-nginx-controller.deckhouse.io/need-hostwithfailover-cleanup=true. Представляет собой bash-скрипт, который актуализирует правила iptables в зависимости от используемого инлета контроллера. При штатной работе ingress-controller компонент failover-cleaner не запущен ни на одном узле.

Модуль взаимодействует со следующими компонентами:

1. Kube-apiserver:

• синхронизация конфигурации NGINX при изменении Ingress-ресурсов;
• авторизация запросов на получение метрик, статистики и проверки состояния контроллера;
• перенаправление внешних HTTP-запросов на эндпоинт API Kubernetes.

2. Dex-authenticator служебных сервисов и пользовательских приложений — используется для аутентификации запросов в dex через dex-authenticator, которые выполняют функции OAuth2 Proxy.

3. Служебные сервисы DKP (Console, Dashboard, Grafana и прочие) — модуль перенаправляет HTTP-запросы, прошедшие аутентификацию через Dex.

4. Пользовательские сервисы, развернутые в DKP — модуль перенаправляет на них внешние HTTP-запросы. Для этого пользователь должен создать соответствующие Ingress-ресурсы, а также кастомный ресурс DexAuthenticator, если требуется аутентификация через Dex.

С модулем взаимодействуют следующие внешние компоненты:

1. Kube-apiserver — использует validation-вебхук для проверки создаваемых или обновляемых Ingress-ресурсов.
2. Prometheus-main — собирает метрики контроллеров ingress и kruise, а также статистику NGINX.
3. Балансировщик нагрузки — балансировка HTTP/HTTPS-трафика между работоспособными экземплярами ingress-controller.

Способы приема трафика из внешней сети подробно описаны в параметре spec.inlet кастомного ресурса IngressNginxController.

Для инлетов вида LoadBalancer, LoadBalancerWithProxyProtocol и LoadBalancerWithSSLPassthrough указанный на схеме балансировщик нагрузки автоматически предоставляется облачным провайдером (при развертывании DKP в облаке), либо может быть реализован при помощи MetalLB-контроллера (при установке на bare-metal-хостах). С настройками модуля metallb можно ознакомиться в соответствующем разделе документации.

Для инлетов вида HostPort, HostPortWithProxyProtocol, HostPortWithSSLPassthrough и HostWithFailover балансировщик нагрузки разворачивается пользователем, либо может отсутствовать. В этом случае пользователь самостоятельно настраивает бэкенды балансировщика или обеспечивает сетевую связность до ingress-controller. Точкой входа в ingress-controller в этом случае являются порты на узлах кластера, на которых запущен контроллер.

Модуль metallb реализует механизм LoadBalancer для сервисов в bare-metal-кластерах.

Поддерживаются следующие режимы работы:

• Layer 2 — реализует улучшенный (по сравнению со стандартным режимом L2 в MetalLB) механизм балансировки в bare-metal-кластерах. Позволяет использовать несколько «публичных» IP-адресов для сервисов, равномерно распределяя их по доступным узлам кластера.
• BGP — полностью основан на решении MetalLB. Использует протокол BGP для построения маршрутов.

Архитектура модуля metallb на уровне 2 модели C4 и его взаимодействия с другими компонентами Deckhouse Kubernetes Platform (DKP) изображены на следующих диаграммах.

MetalLB в режиме Layer 2:

MetalLB в режиме BGP:

Модуль состоит из следующих компонентов:

1. Controller/l2lb-controller (Deployment) — контроллер MetalLB, отвечающий за назначение IP-адресов сервисам типа LoadBalancer.

Контроллер отслеживает изменения в сервисах Kubernetes и применяет конфигурацию IP-адресов, основываясь на заранее определённом пуле адресов, указанных в настройках.

Состоит из следующих контейнеров:

• controller/l2lb-controller — основной контейнер;
• kube-rbac-proxy — сайдкар-контейнер с авторизующим прокси на основе Kubernetes RBAC для организации защищенного доступа к метрикам контроллера. Является Open Source-проектом.

2. Speaker/l2lb-speaker (DaemonSet) — спикер MetalLB, запускаемый на каждом узле кластера, входящем в группу балансировки. Отвечает за реализацию протокола балансировки нагрузки на уровне сети.

В зависимости от режима работы выполняет следующие функции:

• в режиме L2 использует ARP для сопоставления виртуальных IP-адресов сервисов с физическими адресами узлов;
• в режиме BGP анонсирует маршруты к виртуальным IP-адресам через протокол BGP, обеспечивая доступность сервисов за пределами кластера.

Состоит из следующих контейнеров:

• speaker/l2lb-speaker — основной контейнер;
• kube-rbac-proxy — сайдкар-контейнер с авторизующим прокси на основе Kubernetes RBAC для организации защищенного доступа к метрикам спикера.

Модуль взаимодействует со следующими компонентами:

1. Kube-apiserver:

• отслеживает изменения в сервисах Kubernetes и применяет конфигурацию IP-адресов;
• авторизует запросы на получение метрик.

2. Сетевое оборудование — обеспечивает доступность виртуальных IP-адресов за пределами кластера:

• в режиме BGP — анонсирует маршруты к виртуальным IP-адресам по протоколу BGP;
• в режиме ARP — используя ARP/GARP, оповещает вышестоящий роутер о том, что виртуальные IP-адреса находятся за MAC-адресами определенных узлов.

С модулем взаимодействуют следующие внешние компоненты:

• Prometheus-main — сбор метрик контроллера и спикера MetalLB.

Компоненты Istio делятся на две категории:

• Control plane — управляющие и обслуживающие сервисы. Под control plane обычно подразумевают поды istiod.
• Data plane — прикладная часть Istio. Представляет собой контейнеры sidecar-proxy.

Все сервисы из data plane группируются в сервис-меш (service mesh). Его характеристики:

• Общий неймспейс для генерации идентификатора сервиса в формате /ns//sa/. У каждого сервис-меш есть идентификатор TrustDomain, который в данном случае совпадает с доменом кластера. Например, mycluster.local/ns/myns/sa/myapp.
• Аутентификация сервисов внутри одного сервис-меш с помощью доверенных корневых сертификатов.

Элементы control plane:

• Istiod — ключевой сервис, обеспечивающий решение следующих задач:

- Непрерывная связь с API Kubernetes и сбор информации о прикладных сервисах.

- Обработка и валидация с помощью механизма Kubernetes Validating Webhook всех кастомных ресурсов, которые связаны с Istio.

- Компоновка конфигурации для каждого sidecar-proxy индивидуально:

1. генерация правил авторизации, маршрутизации, балансировки и пр.;
2. распространение информации о других прикладных сервисах в кластере;
3. выпуск индивидуальных клиентских сертификатов для организации схемы Mutual TLS. Эти сертификаты не связаны с сертификатами, которые использует и контролирует сам Kubernetes для своих служебных нужд.

• Автоматическая подстройка манифестов, определяющих прикладные поды через механизм Kubernetes Mutating Webhook:

- внедрение дополнительного служебного контейнера sidecar-proxy;

- внедрение дополнительного init-контейнера для адаптации сетевой подсистемы (настройка DNAT для перехвата прикладного трафика);

- перенаправление readiness- и liveness-проб через sidecar-proxy.

• Operator — компонент, отвечающий за установку всех ресурсов, необходимых для работы control plane определенной версии.
• Kiali — панель управления и наблюдения за ресурсами Istio и пользовательскими сервисами под управлением Istio:

- визуализация связей между сервисами;

- диагностика проблемных связей;

- диагностика состояния control plane.

С включенным Istio поведение Ingress-контроллера изменяется следующим образом:

• К подам контроллера добавляется sidecar-proxy, который обслуживает только трафик от контроллера в сторону прикладных сервисов (параметр enableIstioSidecar ресурса IngressNginxController).
• Сервисы, которые не находятся под управлением Istio, продолжают работать в прежнем режиме, без перехвата запросов сайдкаром контроллера.
• Запросы к сервисам под управлением Istio перехватываются сайдкаром и обрабатываются в соответствии с правилами Istio. Подробнее об активации Istio для приложений можно почитать в соответствующем разделе документации.
• Контроллер istiod и каждый контейнер sidecar-proxy экспортируют собственные метрики, которые собирает кластерный Prometheus.

Внедрение Istio повлечёт за собой дополнительные расходы ресурсов, как для control plane (контроллер istiod), так и для data plane (istio-сайдкары приложений).

Контроллер istiod непрерывно наблюдает за конфигурацией кластера, компонует настройки для istio-сайдкаров data plane и рассылает их по сети. Соответственно, чем больше приложений и их экземпляров, чем больше сервисов и чем чаще эта конфигурация меняется, тем больше требуется вычислительных ресурсов и больше нагрузка на сеть.

Поддерживается два подхода к снижению нагрузки на экземпляры контроллеров:

• горизонтальное масштабирование (параметр controlPlane.replicasManagement модуля istio) — чем больше экземпляров контроллеров, тем меньше экземпляров istio-сайдкаров обслуживать каждому из них и тем меньше нагрузка на CPU и на сеть;
• сегментация data plane с помощью ресурса Sidecar (рекомендуемый подход) — чем меньше область видимости у отдельного istio-сайдкара, тем меньше требуется обновлять данных в data plane и тем меньше нагрузка на CPU и на сеть.

Примерная оценка накладных расходов для экземпляра control plane, который обслуживает 1000 сервисов и 2000 istio-сайдкаров — 1 vCPU и 1,5 ГБ RAM.

На потребление ресурсов data plane (istio-сайдкары) влияет множество факторов:

• количество соединений;
• интенсивность запросов;
• размер запросов и ответов;
• протокол (HTTP/TCP);
• количество ядер CPU;
• сложность конфигурации сервис-меш.

Примерная оценка накладных расходов для экземпляра istio-сайдкара — 0,5 vCPU на 1000 запросов/сек и 50 МБ RAM.

Istio-сайдкары также вносят задержку в сетевые запросы — примерно 2,5 мс на запрос.

• Sidecar-proxy: Каждый под прикладного сервиса получает дополнительный контейнер — sidecar-proxy, содержащий два приложения:

- Envoy — проксирует прикладной трафик и реализует все функции, которые предоставляет Istio, включая маршрутизацию, аутентификацию, авторизацию и пр.

- Pilot-agent — часть Istio, отвечающая за поддержание конфигурации Envoy в актуальном состоянии. Включает в себя кеширующий DNS-сервер.

• Настройки DNAT:

- В каждом поде с помощью дополнительного init-контейнера настраивается DNAT входящих и исходящих прикладных запросов в sidecar-proxy. В результате трафик будет перехватываться прозрачно для приложений.

- Поскольку входящий трафик перенаправляется в sidecar-proxy, это касается и readiness/liveness-проб. Так как подсистема Kubernetes не поддерживает пробы в формате Mutual TLS, все существующие пробы перенастраиваются на порт в sidecar-proxy, который передает их приложению без изменений.

• Ingress-контроллер:

- Каждый под Ingress-контроллера также включает sidecar-proxy, который обрабатывает трафик между контроллером и сервисами.

- Входящий трафик от пользователей обрабатывается непосредственно контроллером.

• Ресурсы типа Ingress: Эти ресурсы требуют минимальной доработки в виде добавления аннотаций:

- nginx.ingress.kubernetes.io/service-upstream: "true" — Ingress-контроллер в качестве upstream будет использовать ClusterIP сервиса вместо адресов подов. Балансировкой трафика между подами теперь занимается sidecar-proxy. Используйте эту опцию только если у вашего сервиса есть ClusterIP.

- nginx.ingress.kubernetes.io/upstream-vhost: "myservice.myns.svc" — sidecar-proxy Ingress-контроллера принимает решения о маршрутизации на основе заголовка Host. Без данной аннотации контроллер оставит заголовок с адресом сайта, например Host: example.com.

• Сервисы:

- Ресурсы типа Service не требуют изменений и продолжают работать без адаптации. Приложениям все так же доступны адреса сервисов вида servicename, servicename.myns.svc и пр.

• DNS-запросы:

В стандартной работе DNS в Kubernetes существует ряд проблем, которые могут привести к неоправданному снижению ключевых показателей работы сервиса:

• Linux-ядро по умолчанию не кеширует DNS-запросы, поэтому в подах локальный кеш отсутствует.
• Все DNS-запросы из контейнера влекут за собой сетевой запрос к кластерному DNS. Запросы к ресурсам в рамках одного узла все равно приводят к сетевым запросам.
• Запрос из пода сначала разрешается в кластерных DNS-зонах и только потом отправляется на внешние DNS-серверы. Например, запрос на ya.ru будет разрешаться сначала в кластерных зонах, таких как cluster.local, svc.cluster.local, .svc.cluster.local, и только после получения отрицательных ответов, то есть по сути только с более чем второго раза, будет разрешаться правильно.

При появлении небольших сетевых задержек качество сервиса может значительно деградировать из-за приведенных выше проблем.

Одно из решений — установить DNS-сервер на каждый узел. В Deckhouse Kubernetes Platform это реализуется с помощью модуля node-local-dns.

При использовании кеширующего DNS-сервера внешние запросы (но только отсутствующие в кеше) также будут сначала пытаться разрешаться по цепочке внутренних зон. При большой нагрузке (при большом количестве запросов на одни и те же записи в секунду, как это часто и бывает) кеширования достаточно для значительного улучшения DNS-резолвинга.

При разворачивании кеширующего DNS-сервера модуль node-local-dns выполняет на каждом узле кластера следующие настройки:

• Настраивает интерфейс с IP-адресом clusterIP сервиса kube-dns.
• Запускает кеширующий CoreDNS, который слушает на этом адресе.
• Добавляет правило в iptables: если сокет открыт, трафик перенаправляется на него, если не открыт — работает обычная Kubernetes-маршрутизация через ClusterIP:

Основные характеристики конфигурации CoreDNS:

• кеширование всех запросов;
• передача всех DNS-запросов в ClusterIP кластерного DNS.

Дашборд Kubernetes / DNS (node local) отображает:

1. общие графики (для оценки работы DNS в целом);
2. графики по узлам (для глубокого изучения найденной на общем графике проблемы узла);
3. графики по upstream (для оценки работы кластерного DNS и серверов узлов, указанных в /etc/resolv.conf).