Два шага к тому, чтобы под задачи наконец поехал.
--- 1. S3 через vault-аннотации, а не Secret в namespace ---
Аннотации созданного пода показали точное поведение движка:
agent-inject-secret-yc-s3: <VAULT_MOUNT_PATH>
agent-inject-template-yc-s3: {{- with secret "<VAULT_MOUNT_PATH>" -}}
{{ index .Data.data "yc-s3-service-account.json" }}
secret-volume-path-yc-s3: /etc/sarex/yc-s3
То есть VAULT_MOUNT_PATH вопреки имени — не корень KV, а ПОЛНЫЙ путь
секрета, а имя ключа в нём должно совпадать с именем файла. Путь исправлен
на secrets/data/apps/processing/yc-s3 (форма чтения KV v2), и заведён
соответствующий секрет с ключом yc-s3-service-account.json.
Инжекция уже подтверждена на живом поде: agent-inject-status: injected,
том vault-secrets-custom-0, Secret yc-s3 в namespace больше не монтируется.
--- 2. Секрет реестра для подов задач ---
Под задачи вставал в Init:0/1:
Unable to retrieve some image pull secrets (dockerhub)
Движок проставляет Job'ам imagePullSecrets: dockerhub, и это имя зашито в
бинарник — настраиваемой переменной нет, из pull-настроек существует только
DEFAULT_IMAGE_PULL_POLICY. Поэтому заводим секрет с таким именем в namespace
задач через существующий механизм registry_secrets; содержимое то же, что у
regcred.
Сборка contour_a03d37da-dirty2 умеет не монтировать в Job готовый Secret, а
вешать на него аннотации vault-agent — тогда файл с кредами кладёт агент, и
Secret в namespace задач не нужен. Так это и работает в UGMK, где никакого
yc-s3 в namespace нет.
В master workflows-engine этого кода нет (сборка с невлитой ветки), поэтому
набор переменных восстановлен по строкам бинарника: VAULT_ROLE, VAULT_SA,
VAULT_MOUNT_PATH плюс аннотации role/secret-volume-path/agent-inject-*.
В base задан только VAULT_USE=true, остальных трёх нет ни в одном кластере
репозитория. Оттого аннотации выходили неполными, агент в под задачи ничего
не клал и файл читался как пустой.
Значения предварительные: точный путь Vault, который движок запрашивает,
будет виден в аннотациях созданного пода задачи — по нему и уточним.
В комментарии стоял тег contour_3ef5b462 — он был взят грепом по репозиторию
ДО первого слияния с master, а master поднял образ до contour_a03d37da-dirty2
(коммит f55f254), и в кластере всё это время крутится именно он. Утверждение
"образ о переменной не знает" поэтому необоснованно: сборка ручная и сделана
тем же коммитом, что добавил переменную.
Сам вывод не меняется: селектор задаётся явно, потому что проверить поддержку
переменной нечем, а не потому что её точно нет.
Симптом: движок брал задачу и падал на её создании —
ERROR create k8s job: create k8s job: unknown service
Ни одного пода при этом не создавалось.
Причина — моя правка. Я выставил ENABLE_TOLERATION=0, чтобы поды задач не
получали nodeSelector dedicated=processing на несуществующие выделенные
ноды. Но в движке ЭТОТ ЖЕ флаг управляет регистрацией классов ресурсов:
if resCfg.EnableToleration {
services[HighResources] = Service{...}
}
(pkg/kube_services/services.go)
Поэтому задача с service_request "high-resources" отваливалась не на
планировании, а раньше — на разборе, как неизвестный сервис. В логе при
этом ни слова про nodeSelector, связь с флагом неочевидна.
Вместо выключения флага селектор переведён на метку, которая есть на всех
трёх нодах контура, — kubernetes.io/os=linux. Класс сервисов остаётся
зарегистрированным, nodeSelector совпадает с любой нодой, toleration на
несуществующий taint безвреден. То же сделано для HIGH_MEM и PERSISTENT и
для DEFAULT_NODE_SELECTOR_*, которые раньше были пустыми строками.
Ресурсы не трогаем: в base это 1 CPU и 1Gi.
IGNORE_TAINTS_AND_NODE_SELECTOR, приехавший в base из master, для этого не
подходит: в исходниках workflows-engine такой переменной нет вовсе, образ
contour_3ef5b462 о ней не знает.
master добавил в apps/processing/base/engine-low.yaml переменную
IGNORE_TAINTS_AND_NODE_SELECTOR, из-за чего всё начиная с индекса 21
сдвинулось на единицу. Патчи оверлея адресуются по индексу, и сборка
слоя apps упала:
testing value /spec/values/services/backend/envs/22/name failed
Это ровно то, ради чего перед каждым replace стоит op: test — вместо
тихой перезаписи соседней переменной получили явную остановку сборки.
Индексы сдвинуты: 21→22, 22→23, 25→26, 26→27, 27→28, 28→29, 30→31,
31→32, 32→33, 66→67, 69→70, 70→71. Индексы 2, 5 и 6 не изменились.
Сама новая переменная патча не требует: в base у неё "true", то есть
апстрим теперь по умолчанию игнорирует taint'ы и nodeSelector — как раз
то поведение, ради которого здесь зануляются ENABLE_TOLERATION и
DEFAULT_NODE_SELECTOR_*. Прежние правки оставлены: они не мешают, а
убирать их вслепую, не зная приоритета флагов внутри engine, рискованно.
Фронтенд был исключён из-за адресов, вшитых в бандл на этапе сборки через
константу __BUILD_ENV__. Опасение не подтвердилось: сборка обращается к тому
же origin относительными путями — иначе в yc-k8s-test и d8-ugmk-prod не
понадобился бы отдельный маршрут /workflows/api/ перед /workflows/.
Маршруты добавлены на домен платформы, а не на отдельный поддомен: поддомен
потребовал бы пересборки образа с другим __BUILD_ENV__.
/workflows/api/ -> rewrite /api/ -> backend-svc.processing
/workflows/ -> rewrite / -> frontend-svc.processing
Порядок внутри пары значим: /workflows/api/ обязан идти перед /workflows/,
иначе запросы к API уйдут в раздачу статики. Оба стоят перед /api/ и / —
правила django их бы перехватили.
Маршруты положены в существующий VirtualService platform, а не в отдельный:
Istio не сливает несколько VirtualService на одной паре хост+gateway, и часть
правил молча потерялась бы.
Развёрнут частично, и это осознанно:
* engine удалён — в base у него replicaCount 0, то есть он выключен и там,
а образ прибит к тегу с опечаткой в имени (workflows-endigne_prod);
* frontend удалён — адреса бэкендов зашиты в образ на этапе сборки через
__BUILD_ENV__, и ни один готовый профиль не смотрит на домен контура.
Подключать его имеет смысл только вместе с пересборкой образа.
Отключены смежные сервисы, которых в контуре нет: documentations (PDM,
filestream), resources, bim-api, workspace, issues, comparisons, mailgun,
SMTP. Оставлен только S3. Вместе с флагом ENABLE_SMTP убрана аннотация
инжекции secrets/vault/common/smtp_auth — секрета нет, и vault-agent-init
оставил бы под в Init:Error, не дойдя до флага.
S3 приезжает из Vault отдельным файлом: приложение читает по пути из
S3_SERVICE_ACCOUNT целый JSON, а не пару переменных. Набор ключей повторяет
engine/yc-s3-service-account.json из compose-стека, который так же смотрел
в MinIO.
Планирование подов задач: engine работает kubernetes-исполнителем и сам
создаёт Job'ы, подставляя им nodeSelector dedicated=processing. Выделенных
нод в контуре нет, поды висли бы в Pending — как это уже было у postgresql.
ENABLE_TOLERATION и DEFAULT_NODE_SELECTOR_* сняты.
Заодно у celery поправлены четыре адреса на wb.sarex.io — чужой контур,
недостижимый из aero. У backend те же переменные уже вели внутрь кластера;
при WORKFLOWS_USE=1 расхождение давало бы зависания вместо явной ошибки.
Патчи адресуются по индексу env, поэтому перед каждым replace стоит op: test
на имя переменной: смена порядка в base уронит сборку явно, а не перезапишет
соседнее значение.
