docs: document all changes and web-console plan
- doc/progress.md: funcs global service v0.1.x, URLs, next steps - doc/decisions/log.md: storage architecture, funcs service decision, web-console plan - doc/api/design.md: current + planned endpoints (/source, PATCH trigger) - doc/architecture/overview.md: funcs-service component, S3 storage diagram
This commit is contained in:
Naeel
@@ -2,6 +2,190 @@
|
||||
|
||||
> Сюда записываем проблемы с которыми столкнулись и как их решили.
|
||||
|
||||
---
|
||||
|
||||
## 2026-03-17 — Баг 3: PodLogOptions compile error (v0.1.31)
|
||||
|
||||
**Проблема:** Оператор не компилировался. Ошибка:
|
||||
```
|
||||
controllers/functionjob_controller.go: unknown field Stdout in corev1.PodLogOptions
|
||||
controllers/functionjob_controller.go: unknown field Stderr in corev1.PodLogOptions
|
||||
```
|
||||
|
||||
**Причина:** `corev1.PodLogOptions{}` в k8s API не имеет полей `Stdout` и `Stderr` — это поля из `corev1.ContainerState`. Код выглядел так:
|
||||
```go
|
||||
req := kube.CoreV1().Pods(namespace).GetLogs(pods.Items[0].Name, &corev1.PodLogOptions{
|
||||
Stdout: true, // не существует
|
||||
Stderr: true, // не существует
|
||||
})
|
||||
```
|
||||
|
||||
**Решение:** Убрать несуществующие поля. `GetLogs` по умолчанию возвращает stdout+stderr без дополнительных флагов:
|
||||
```go
|
||||
req := kube.CoreV1().Pods(namespace).GetLogs(pods.Items[0].Name, &corev1.PodLogOptions{})
|
||||
```
|
||||
|
||||
**Файл:** `controllers/functionjob_controller.go`, функция `getJobPodOutput`
|
||||
**Версия:** исправлено в `naeel/sless-operator:v0.1.31`
|
||||
|
||||
---
|
||||
|
||||
## 2026-03-17 — Главная причина провала POSTGRES example: неправильный nubes_endpoint
|
||||
|
||||
### Симптом
|
||||
|
||||
`terraform apply` для `examples/POSTGRES` падал с `"job failed, check pod logs"`. При этом `examples/simple-python` и `examples/hello-node` работали нормально на тест-стенде.
|
||||
|
||||
### Корневая причина
|
||||
|
||||
В `examples/POSTGRES/main.tf` в блоке `provider "sless"` был указан **продовый** endpoint Nubes API:
|
||||
|
||||
```hcl
|
||||
provider "sless" {
|
||||
endpoint = "https://sless-api.kube5s.ru"
|
||||
token = var.api_token
|
||||
nubes_endpoint = "https://deck-api.ngcloud.ru/api/v1" # ← ПРОД
|
||||
}
|
||||
```
|
||||
|
||||
При этом `provider "nubes"` уже указывал на тест:
|
||||
```hcl
|
||||
provider "nubes" {
|
||||
api_token = var.api_token
|
||||
api_endpoint = "https://deck-api-test.ngcloud.ru/api/v1/index.cfm" # ← тест ✓
|
||||
}
|
||||
```
|
||||
|
||||
Из-за этого `sless_function` и `sless_job` стучались в **продовый** Nubes API, где у тестового пользователя другой namespace и другой кластер. Postgres и pod запускались в контексте прода, а не тест-стенда. Поды не могли подключиться к базе.
|
||||
|
||||
### Фикс
|
||||
|
||||
```hcl
|
||||
# examples/POSTGRES/main.tf
|
||||
provider "sless" {
|
||||
endpoint = "https://sless-api.kube5s.ru"
|
||||
token = var.api_token
|
||||
nubes_endpoint = "https://deck-api-test.ngcloud.ru/api/v1" # ← тест
|
||||
}
|
||||
```
|
||||
|
||||
Аналогично исправлено в `examples/simple-python/main.tf`.
|
||||
|
||||
### Почему долго искали
|
||||
|
||||
Долгое расследование ушло на "split-brain" — API-созданные FunctionJob'ы были невидимы через `kubectl get functionjobs -A`. Это объяснялось тем что:
|
||||
1. Job завершался (Failed) за ~5 секунд
|
||||
2. Между завершением и опросом kubectl объект уже мог быть очищен
|
||||
3. Параллельно в кластере фигурировал другой namespace (`sless-ffd1f598c169b0ae` — прод) vs тест-namespace
|
||||
|
||||
На самом деле контроллер работал корректно. Проблема была исключительно в `nubes_endpoint`.
|
||||
|
||||
### Урок
|
||||
|
||||
**Всегда проверять**: когда в `main.tf` два провайдера (`nubes` + `sless`) — у обоих endpoint'ы должны указывать на **одну среду**. Смешивание прод/тест endpoint'ов в одном apply даёт непредсказуемые результаты.
|
||||
|
||||
---
|
||||
|
||||
## 2026-03-17 — Ошибка агента: локальный запуск terraform
|
||||
|
||||
**Проблема:** Агент запускал `terraform apply` **локально** (`/home/naeel/remote_dev/sless/examples/...`) вместо запуска на удалённом сервере `naeel@5.172.178.213`.
|
||||
|
||||
**Почему неправильно:**
|
||||
- Провайдер `terra.k8c.ru/naeel/sless` установлен только на удалённом сервере
|
||||
- Локальный terraform не имеет доступа к k8s кластеру напрямую
|
||||
- Потенциально затрагивал продовые API из локальной сети
|
||||
|
||||
**Правило:** Все `terraform init/plan/apply/destroy` для `examples/` — только через SSH на `naeel@5.172.178.213`:
|
||||
```bash
|
||||
ssh -i /home/naeel/remote_dev/common/id_ed25519.txt naeel@5.172.178.213 \
|
||||
'cd /home/naeel/terra/sless/examples/<example> && terraform apply -auto-approve -no-color'
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 2026-03-17 — FunctionJob всегда "job failed, check pod logs" — расследование и два бага
|
||||
|
||||
### Хронология расследования
|
||||
|
||||
**Симптом:** `terraform apply` на `examples/POSTGRES` завершается ошибкой:
|
||||
```
|
||||
job failed: job failed, check pod logs: kubectl logs -n sless-fn-sless-ffd1f598c169b0ae -l functionjob=pg-create-table-job-main-v12
|
||||
```
|
||||
Команда из сообщения — ничего не выдаёт (под не найден).
|
||||
|
||||
---
|
||||
|
||||
**Ошибка агента №1 — SQL-диагностика вместо анализа кода**
|
||||
|
||||
Первая реакция — запустить диагностические поды в кластере с psycopg2 чтобы проверить подключение к PostgreSQL. Это было **неправильно**: проблема не в подключении, а в том что job не запускался вообще. Пользователь остановил — "ПРИ ЧЁМ тут SQL запросы???".
|
||||
|
||||
---
|
||||
|
||||
**Ошибка агента №2 — не читал собственный код**
|
||||
|
||||
Раньше читались логи оператора и kubectl describe — но не исходный код контроллеров. Пользователь указал: "мы пишем ВСЁ сами, смотри в код". После прочтения `functionjob_controller.go` и `functions.go` картина сложилась за одно чтение.
|
||||
|
||||
---
|
||||
|
||||
### Баг 1 — k8s label `job-name` удалён в 1.27+
|
||||
|
||||
**Файл:** `controllers/functionjob_controller.go`, функция `getJobPodOutput`
|
||||
|
||||
**Код до:**
|
||||
```go
|
||||
pods, err := kube.CoreV1().Pods(namespace).List(ctx, metav1.ListOptions{
|
||||
LabelSelector: "job-name=" + jobName,
|
||||
})
|
||||
if err != nil || len(pods.Items) == 0 {
|
||||
return "completed successfully" // ← сюда всегда попадали
|
||||
}
|
||||
```
|
||||
|
||||
**Причина:** В k8s 1.27 лейбл `job-name` на pod-ах был deprecated, в 1.32+ удалён полностью. У нас кластер **1.34.1**. Поэтому `List` возвращал 0 подов всегда → fallback `"completed successfully"` → при `phase=Failed` финальное сообщение `"job failed, check pod logs: ..."`.
|
||||
|
||||
Логи реального сбоя никогда не попадали в `status.Message` FunctionJob, поэтому **корневая ошибка Python-функции была невидима**.
|
||||
|
||||
**Как нашли:** Проверили `kubectl get pod -l "batch.kubernetes.io/job-name"` — вернул поды. `kubectl get pod -l "job-name"` — не вернул. Версия кластера: `v1.34.1` (kubectl `v1.35.2`).
|
||||
|
||||
**Фикс:** Использовать собственный лейбл `functionjob=<fj.Name>`, который мы сами выставляем на PodTemplate и который работает независимо от версии k8s.
|
||||
|
||||
---
|
||||
|
||||
**Также:** В строке 211 подсказка для пользователя тоже использовала устаревший лейбл:
|
||||
```go
|
||||
"job failed, check pod logs: kubectl logs -n " + job.Namespace + " -l job-name=" + job.Name
|
||||
```
|
||||
Исправлено на `functionjob=<fj.Name>` — теперь команда реально работает.
|
||||
|
||||
---
|
||||
|
||||
### Баг 2 — Split-brain cached client при CreateFunction
|
||||
|
||||
**Файл:** `internal/api/handler/functions.go`, функция `CreateFunction`
|
||||
|
||||
**Проявление:** API возвращает `409 "function already exists"`, а `kubectl get function -A` функцию не видит. `terraform state rm sless_function.*` не помогает — следующий `terraform apply` снова получает 409.
|
||||
|
||||
**Причина:** `h.K8s` в handler — это **cached client** controller-runtime. Цепочка:
|
||||
1. Предыдущий `terraform destroy` вызвал `DELETE /functions/pg-create-table-runner`
|
||||
2. Handler вызвал `h.K8s.Delete(ctx, fn)` — объект удалён из **etcd**
|
||||
3. Кеш controller-runtime обновляется асинхронно (informer watch). Несколько секунд объект ещё жив в памяти оператора
|
||||
4. Следующий `terraform apply` → `POST /functions` → `h.K8s.Create(ctx, fn)` → `IsAlreadyExists` (кеш ещё видит объект)
|
||||
5. Код проверяет `phase == Failed` — но объект в кеше в фазе `Ready` → уходит в 409 навсегда
|
||||
|
||||
`kubectl get function` шёл **мимо кеша** (прямо в k8s API) → NotFound. API handler шёл **через кеш** → AlreadyExists. Поэтому они показывали разные результаты.
|
||||
|
||||
**Фикс:** При `IsAlreadyExists` делать `uncached Get` (через `client.ObjectKey` напрямую). Если объект реально не найден в etcd (`IsNotFound`) — значит кеш устарел, смело создаём заново. Если найден — возвращаем 409 как обычно (объект реально существует).
|
||||
|
||||
---
|
||||
|
||||
### Итог
|
||||
|
||||
| # | Баг | Файл | Строка | Тип |
|
||||
|---|-----|------|--------|-----|
|
||||
| 1 | `LabelSelector: "job-name="` deprecated k8s 1.27+ | `controllers/functionjob_controller.go` | 311 | Совместимость |
|
||||
| 1b | Подсказка `kubectl logs -l job-name=` тоже устарела | `controllers/functionjob_controller.go` | 211 | UX |
|
||||
| 2 | Cached client → perpetual 409 при CreateFunction | `internal/api/handler/functions.go` | 117-133 | Race condition |
|
||||
|
||||
## Шаблон записи
|
||||
|
||||
```
|
||||
|
||||
Reference in New Issue
Block a user