1

2026-09-20 18:15:17 +03:00
parent 8f552ecacc
commit a44894d877
2 changed files with 89 additions and 0 deletions
@@ -0,0 +1,89 @@
+# Резюме сессии: Диагностика 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).