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