Сети

Сетевая часть выглядит сложной, пока не разложить её по задачам. Компонентов четыре, и у каждого своя работа — экзамен спрашивает именно распределение ролей, а не настройки.

Cilium — основа

Отвечает за то, чтобы поды видели друг друга, и за сетевые политики. Работает на eBPF — технологии, которая позволяет исполнять программы прямо в ядре Linux, не переключаясь в пространство пользователя на каждый пакет.

Практическое следствие: сетевые правила применяются в ядре, без длинных цепочек iptables, и не деградируют по мере роста их числа.

Именно Cilium исполняет ту изоляцию между тенантами, о которой шла речь во втором уроке.

Есть и третья роль, которую легко пропустить: Cilium заменяет собой kube-proxy (kube-proxy replacement). Обычно сервисы Kubernetes обслуживает kube-proxy через iptables, а здесь поиск нужного адресата идёт по хеш-таблице и стоит одинаково при любом числе сервисов. На платформе с сотнями тенантов это заметно.

Разделение труда между ним и Kube-OVN стоит запомнить, потому что оба называются «сетью»: Cilium — основной CNI, он даёт сеть подам и применяет политики для всех. Kube-OVN работает поверх и отвечает за наложенную сеть, выдачу адресов и VPC тенантов.

Kube-OVN — сети тенантов

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

Централизованная выдача адресов (centralized IPAM): адреса раздаются из одного места, а не отдельно на каждом узле, и весь кластер по умолчанию живёт в одном общем диапазоне подов.

Стабильные адреса подов (stable pod IPs): под сохраняет свой адрес, когда переезжает на другой узел. Контейнеру это удобство, а виртуальной машине — необходимость: гостевые системы, лицензии и правила межсетевых экранов обычно привязаны к адресу, и смена адреса при каждой миграции сломала бы их.

Ещё Kube-OVN даёт VPC — приватные сети со своим адресным пространством. И VPC, и виртуальный маршрутизатор (virtual-router) — позиции каталога: тенант заказывает их так же, как базу данных.

Ближайшая аналогия из привычного мира — VPC у облачных провайдеров или сети NSX.

MetalLB — внешние адреса

В публичном облаке сервис типа LoadBalancer получает адрес от провайдера. На своём железе провайдера нет, и без MetalLB такой сервис вечно висит в ожидании.

MetalLB держит пул адресов и раздаёт их сервисам, а затем объявляет их в сеть — либо по ARP, либо через BGP, если сеть построена на маршрутизации. Начиная с версии 1.5 за сторону BGP отвечает FRR-K8s (FRR-K8s) — именно он объявляет маршруты физическим роутерам.

Именно он нужен, чтобы виртуалка или приложение получили адрес, доступный снаружи кластера.

Ingress — вход для HTTP

Для веб-приложений выдавать каждому свой адрес расточительно. Ingress принимает запросы на общий адрес и раскладывает их по именам и путям.

Особенность платформы: точка входа (ingress) своя у каждого тенанта. Это не общий контроллер на весь кластер — тенант с включённым ingress получает собственный ingress-nginx, со своими правилами, своим внешним адресом от MetalLB и своими сертификатами. Тенант без него пользуется родительским, как и с остальными сервисами.

TenantGateway — путь Gateway API

Kubernetes постепенно уходит со старого Ingress на Gateway API — более выразительный стандарт маршрутизации трафика. В платформе он появился в версии 1.5 в виде объекта TenantGateway.

Пакеты через него носит Cilium: nginx в этом пути нет вовсе. И это не замена ingress-nginx, а альтернатива — в 1.5 живут оба варианта.

Сертификаты TenantGateway умеет выпускать в двух режимах проверки. HTTP-01 — центр сертификации забирает токен по обычному HTTP, значит домен должен быть виден из интернета. DNS-01 — проверка через DNS-запись; только этот режим годится для wildcard-сертификатов вида *.apps.example.com и для точек входа, не выставленных наружу.

Имена и сертификаты

Три помощника, которых обычно не замечают, пока они работают.

CoreDNS разрешает имена внутри кластера — поэтому в настройках приложений пишут postgres-db-rw, а не адрес: имя переживает переезд базы на другой узел, а адрес нет.

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

cert-manager выпускает сертификаты и продлевает их сам, без напоминаний.

Всё это работает ровно до первого сбоя. О том, как о сбое узнать и что стоит подготовить заранее, — следующий урок.

Подробнее: сети платформы