Два шага к тому, чтобы под задачи наконец поехал.
--- 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.
|
||
|---|---|---|
| .. | ||
| aero | ||
| base | ||
| brusnika-prod | ||
| brusnika-stage | ||
| d8-ugmk-prod | ||
| yc-k8s-test | ||
| workflows-api.CONFIGURATION.md | ||
| workflows-api.env.example | ||
| workflows-api.openapi.yaml | ||
| workflows-engine.CONFIGURATION.md | ||
| workflows-engine.env.example | ||
| workflows-frontend.ENDPOINTS.md | ||