Managed Kubernetes
TatNet разворачивает Kubernetes-кластеры, узлами которых служат обычные виртуальные машины платформы под управлением Talos Linux — иммутабельной ОС без SSH и пакетного менеджера, где всё состояние задаётся конфигурацией.
Платформа берёт на себя запуск и обновление узлов, сеть, сертификаты и
кластерные компоненты. Внутрь кластера вы ходите обычным kubectl.
Создание кластера
При создании указываются:
- Регион — где будут стоять узлы.
- Версия Kubernetes — из списка поддерживаемых.
- Пулы узлов — control-plane и рабочие: количество и конфигурация машин.
- Режим доступа к API — см. ниже.
Узлы создаются как виртуальные машины, но в списке ВМ проекта они не показываются и обычными операциями (остановить, удалить) не управляются: их жизненным циклом распоряжается кластер.
Доступ к API кластера
Три режима, как у EKS:
| Режим | Кто достаёт API |
|---|---|
public | из интернета |
public_private | из интернета и изнутри сети узлов |
private | только изнутри сети узлов |
Адрес в kubeconfig — DNS-имя вида <идентификатор>.k8s.tatnet.cloud, а
не IP. Поэтому смена режима доступа не делает выданный kubeconfig
недействительным.
kubeconfig скачивается из панели.
Сеть
CNI — Cilium, разворачивается автоматически. Узлы выходят в интернет через NAT платформы; в приватном режиме кластер работает без выхода наружу, а образы тянутся через зеркала реестров внутри региона.
Балансировщики нагрузки
Service типа LoadBalancer создаёт настоящий балансировщик платформы —
этим занимается встроенный cloud-controller-manager. Такие балансировщики
видны в панели, помечены принадлежностью к кластеру и управляются из
Kubernetes: удалять и настраивать их нужно через Service, иначе кластер
пересоздаст их снова.
Пошаговый пример с готовым манифестом и проверкой HTTP — «Создание балансировщика из Kubernetes».
Реальный IP клиента
Встроенный CCM направляет обычный TCP Service через нативный L4-путь:
VIP:порт → IP узла:NodePort. Балансировщик сохраняет IP клиента в самом
соединении. Чтобы Kubernetes также сохранил его до ingress или приложения,
установите externalTrafficPolicy: Local:
metadata:
annotations:
tatnet/lb-preserve-client-ip: "true"
spec:
type: LoadBalancer
externalTrafficPolicy: Local
Без PROXY-аннотаций сохранение IP включено по умолчанию. При политике Cluster
Kubernetes может подменить адрес между узлами; CCM показывает предупреждение
ClientIPAtNodeOnly. Списки адресов VM балансировщика для нативного режима
не нужны и не меняются при замене узлов.
spec.loadBalancerSourceRanges ограничивает источники на сетевом уровне,
включая прямой доступ к соответствующему NodePort. Health checks проверяют
каждый рабочий порт и исключают узлы без локального endpoint.
PROXY protocol — отдельный режим: tatnet/lb-proxy-protocol: v2. Получатель
должен явно уметь его читать. Существующие Services с этой аннотацией сохраняют
прежнее поведение. Для обычного TCP-прокси без PROXY можно явно установить
tatnet/lb-preserve-client-ip: "false". Нативное сохранение IP нельзя
совмещать с PROXY, HTTP health checks, stickiness или slow start; несовместимые
настройки отклоняются. Source ranges в режиме прокси также отклоняются,
а не игнорируются.
Поддерживаются AWS-аннотации aws-load-balancer-proxy-protocol: "*" и
aws-load-balancer-target-group-attributes с атрибутами
preserve_client_ip.enabled и proxy_protocol_v2.enabled, под префиксом
service.beta.kubernetes.io/. Противоречивые значения дают явную ошибку.
Ingress должен проверять whitelist по адресу соединения и удалять присланный
клиентом X-Forwarded-For перед формированием собственного заголовка. Например,
для HAProxy Technologies ingress в frontend-config-snippet:
http-request del-header X-Forwarded-For
forwarded-for: "true" затем добавит настоящий адрес. Если перед LB стоит
доверенный HTTP-прокси, задайте для него отдельное исключение по исходному IP.
Самостоятельно присланные заголовки не должны становиться основанием доступа.
Хранилище
В кластере доступны два класса:
| Класс | Что это |
|---|---|
tatnet-block | Блочный том платформы: переживает узел, переезжает между узлами |
tatnet-local-path | Каталог на диске узла: быстро, но умирает вместе с узлом |
Для данных, которые нельзя потерять, нужен tatnet-block: под, переехавший на
другой узел, найдёт свой том на месте.
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: data
spec:
accessModes: [ReadWriteOnce]
storageClassName: tatnet-block
resources:
requests:
storage: 20Gi
Тома создаются и удаляются по PersistentVolumeClaim. В панели они видны,
но доступны только для чтения — менять их нужно из кластера.
Расширение работает на живом поде: увеличьте PersistentVolumeClaim, и
файловая система вырастет без перезапуска.
Полный пример подключения, проверки сохранности данных, переноса и увеличения тома — в руководстве по блочным томам в Kubernetes.
Ограничения те же, что у блочных томов: один том — один узел одновременно
(ReadWriteOnce), снимков нет, регион менять нельзя.
S3-бакет можно подключить через GeeseFS CSI как общий каталог для датасетов, медиа и артефактов. Пошаговая инструкция — «S3 как том в Kubernetes».
Оплата
Кластер складывается из четырёх статей, и каждая оплачивается отдельно:
- Узлы. И рабочие, и control-plane — обычные виртуальные машины по цене выбранного тарифа. Control-plane не бесплатный именно потому, что это ваши машины: они занимают процессор, память и диск так же, как любые другие.
- Управление кластером. Одна плата на кластер, не зависящая от числа узлов: оркестрация, обновления Kubernetes и Talos, сеть кластера, сертификаты и endpoint API. Начисляется почасово, с создания до удаления.
- Публичный IP-адрес endpoint'а — один на кластер. У приватного кластера публичного адреса нет, и платы за него тоже.
- Тома и балансировщики, если вы их создаёте: блочные тома — по выделенному объёму, балансировщики — по числу узлов балансировщика.
Действующие цены показывает мастер создания кластера: смета в нём собирается из тех же ставок, по которым идёт списание.
Удаление кластера прекращает и плату за управление, и плату за узлы — в момент удаления, а не по завершении сноса.
Обновление версии
Версия Kubernetes обновляется из панели. Платформа катит обновление по узлам: сначала control-plane, затем рабочие, по одному, дожидаясь готовности каждого.
Масштабирование
Число рабочих узлов меняется в настройках пула. При уменьшении платформа корректно выводит лишние узлы: сначала переселяет с них поды, потом гасит машины.