# Резюме сессии: Диагностика 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)**.

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

### Решение:
1. Вычищены все фантомные объекты `nodeconfigs`, которых уже нет среди реальных K8s-нод (сняты блокирующие finalizers).
2. Слот освободился: контроллер `shturval-node-config` корректно выполнил `drainonly` на воркере `vxzch` (под `pythonk8s` переехал на соседний воркер `wwqj2`).
3. Применились оставшиеся `NodeConfigItem` (`generic-init-config`, `all-to-nubes-registry`).
4. **Текущий статус**:
   - Все 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 в манифесте указывать:
  ```hcl
  adopt_existing_on_create = true
  ```
  (согласно `docs/60_strategy/provider_philosophy.md`).

### Зачем нужны дочерние ресурсы-действия (Action / Sub-resources):
Цепочка развертывания vCloud/NSX-T имеет циклические зависимости:
1. `vcOrg -> create`
2. `vcVdc -> create`
3. `vcNsxt -> create` (Edge Gateway)
4. `vcOrg -> modify` (выделение белых IP в организацию, так как появился Edge)
5. `vcNsxt -> modify` (настройка SNAT под конкретный выделенный IP)
6. `k8sShturval -> create` (нодам нужен интернет через SNAT)

Чтобы пользователю не приходилось делать несколько ручных прогонов `terraform apply` с ручным редактированием `.tf` файлов между шагами, в провайдере создаются **дочерние ресурсы-действия**.
- Под капотом провайдера эти дочерние ресурсы транслируются в точечные вызовы **`modify`** над родительскими объектами.
- Это стандартная практика в Terraform (аналог `aws_security_group_rule` для `aws_security_group`).

---

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