Резюме сессии: Диагностика K8s (Штурвал), VDC и архитектура провайдера (2026-09-20)

1. Инфраструктурный контекст

ВМ 213 (jump-host / dev):
- SSH: ssh vps (5.172.178.213, user naeel, key ~/.ssh/naeel_vm_id_ed25519).
- kubectl контекст по умолчанию: tazetdinovn@gmail.com@naeel-test-3.
Кластер naeel-test-3:
- API: https://185.247.187.146:6443.
- Узлы: 6 нод (3 control-plane, 3 workers), версия v1.34.1 / платформа Штурвал 2.12.1.
Кластер devclustername:
- API: https://185.247.187.226:6443.
- Статус: порт 6443 на Edge доступен, но TLS сбрасывается (connection reset by peer) — виртуальные машины кластера находятся в suspend / выключены.

2. Что было сделано и починено в кластере `naeel-test-3`

Проблема:

В веб-интерфейсе Штурвала кластер висел в статусе «Работает с ошибками» (⚠️ 2/4 по NodeConfigItems).

Причина:

На активном воркере naeel-test-3-workers-5p8w7-vxzch висело ожидание применения конфигураций (RebootPending с типом drainonly).
Очередь на применение/drain была заблокирована (SlotsOccupied), так как в CRD nodeconfigs.node.shturval.tech осталась старая удалённая нода naeel-test-3-workers-5p8w7-nqkr2 с зависшим флагом rebootallowed: true.

Решение:

Вычищены все фантомные объекты nodeconfigs, которых уже нет среди реальных K8s-нод (сняты блокирующие finalizers).
Слот освободился: контроллер shturval-node-config корректно выполнил drainonly на воркере vxzch (под pythonk8s переехал на соседний воркер wwqj2).
Применились оставшиеся NodeConfigItem (generic-init-config, all-to-nubes-registry).
Текущий статус:
- Все 6 нод в статусе Ready.
- Все 6 nodeconfigs в статусе READY: true.
- Все 4 nodeconfigitems в статусе ready: true (4/4, статус кластера зелёный).
- Под pythonk8s (drhider.pythonk8s.dev.nubes.ru, ns 20a75175-a58c-49cb-b8fa-e86367b1a8dc) поднят и работает (1/1 Running).
- Потребление ресурсов: среднее ~22m CPU и ~103 MiB RAM на под; суммарно на весь 6-узловой кластер ~1.6 CPU и ~7.5 GiB RAM (минимальный фоновый простой).

3. Блокировка операций в личном кабинете облака (Suspend / Modify)

Симптом:

При попытке выполнить операцию suspend кластера в UI облака возникает ошибка: Concurrent operations are not supported (job status: cannot obtain job result) There is a started operation on this instance

Диагностика через API Gateway (`lk-api-gateway-dev.ngcloud.ru`):

Инстанс кластера: e78a40b9-7de1-4c88-af7a-ad7f7efaa7c2.
Зависшая операция: modify (opUid: 2fb7dd59-732a-4bb9-add2-6bddd7329f72).
Причина зависания: оркестратор CFS поймал таймаут (Timeout has been exceeded), выполнил откат, записал лог ошибки, но не проставил dtFinish и isSuccessful в БД.
Статус операции в API остался незакрытым, из-за чего API Gateway блокирует любые новые операции над инстансом.
Внимание: это баг бэкенда платформы облака (CFS/оркестратора). Средствами kubectl внутри кластера это не лечится — требуется сброс статуса операции на стороне API платформы или через поддержку.
Ошибка в истории операций: Не удалось включить кластер. Ошибка: Error not found from 'parseTerraformError' — вызвана тем, что общий обработчик бэкенда облака по ошибке прогнал текст через парсер ошибок Terraform. Внутри K8s Terraform не используется.

4. Архитектурные правила по VDC и Terraform-провайдеру

Почему возникает ошибка дубликата VDC:

VDC с именем 'WZ03709-saas-snb1-i24-vcpu50' уже существует внутри организации 'WZ03709-saas'

Имя VDC генерируется бэкендом детерминированно: {org}-{type}-{segment}-{cpu}-vcpu{reservation}.
В одном сегменте организации существует максимум два класса VDC:
- vcpu50 (50% гарантия vCPU — для dev/test, оверселлинг, дешевле);
- vcpu80 (80% гарантия vCPU — для prod/баз данных, жесткая фиксация ресурсов).
Создавать третий VDC с тем же процентом SLA в рамках одной организации невозможно (конфликт уникальности имен в vCloud) и бессмысленно: изоляция проектов внутри VDC делается через vApp, сети (Org Networks) и правила фаервола. При нехватке ресурсов VDC масштабируется через modify.
Канон Terraform: при работе с уже созданными VDC в манифесте указывать:
```
adopt_existing_on_create = true
```
(согласно docs/60_strategy/provider_philosophy.md).

Зачем нужны дочерние ресурсы-действия (Action / Sub-resources):

Цепочка развертывания vCloud/NSX-T имеет циклические зависимости:

vcOrg -> create
vcVdc -> create
vcNsxt -> create (Edge Gateway)
vcOrg -> modify (выделение белых IP в организацию, так как появился Edge)
vcNsxt -> modify (настройка SNAT под конкретный выделенный IP)
k8sShturval -> create (нодам нужен интернет через SNAT)

Чтобы пользователю не приходилось делать несколько ручных прогонов terraform apply с ручным редактированием .tf файлов между шагами, в провайдере создаются дочерние ресурсы-действия.

Под капотом провайдера эти дочерние ресурсы транслируются в точечные вызовы modify над родительскими объектами.
Это стандартная практика в Terraform (аналог aws_security_group_rule для aws_security_group).

5. Что делать дальше в новом чате

Если продолжаем работу с провайдером Nubes:
- Проверить статус зависшей операции 2fb7dd59-732a-4bb9-add2-6bddd7329f72 в API Gateway.
- Разрабатывать/тестировать логику дочерних ресурсов (action/sub-resources) и modify-пайплайна по стандарту docs/60_strategy/provider_philosophy.md.
Если требуется проверить второй кластер (devclustername / 185.247.187.226):
- Убедиться, что кластер выведен из suspend в веб-интерфейсе (чтобы поднялся API server на порту 6443).

8.2 KiB Raw Blame History Unescape Escape