У нас сейчас такие конфиги postgresql: enabled: false global: edition: community auth: enabled: false logging: level: info database: type: external secretName: "airbyte-config-secrets" host: "yx1-dwh-airbyte-1" port: "5432" name: "airbyte" userSecretKey: "database-user" passwordSecretKey: "database-password" jobs: resources: requests: cpu: 100m memory: 256Mi limits: cpu: 500m memory: 768Mi manifestServer: enabled: true replicaCount: 1 resources: requests: cpu: 100m memory: 256Mi limits: cpu: 500m memory: 512Mi worker: replicaCount: 3 maxSyncWorkers: 1 maxCheckWorkers: 1 maxDiscoverWorkers: 1 maxSpecWorkers: 1 resources: requests: cpu: 250m memory: 512Mi limits: cpu: 1 memory: 1Gi workloadLauncher: replicaCount: 1 parallelism: 3 resources: requests: cpu: 250m memory: 256Mi limits: cpu: 1 memory: 1Gi workloadApiServer: resources: requests: cpu: 100m memory: 256Mi limits: cpu: 500m memory: 1Gi server: replicaCount: 1 resources: requests: cpu: 200m memory: 512Mi limits: cpu: 1 memory: 1536Mi temporal: resources: requests: cpu: 200m memory: 512Mi limits: cpu: 1 memory: 1536Mi на сервере 18гб ram, почему у нас не стартуют синки и из 18 гб 13 держится под cache + buffer и только 1 гб свободного ram

Судя по предоставленным знаниям, однозначного ответа «почему именно у вас не стартуют синки» нет — в источниках нет ваших логов/ошибок. Ниже — что можно уверенно сказать по документации и похожим кейсам. 1. Память ОС (cache + buffers) — это не проблема сама по себе Linux почти всю «свободную» память использует под кэш, но при необходимости быстро её освобождает. То, что вы видите 13 ГБ в cache+buffers и ~1 ГБ free, не означает, что Airbyte реально «упёрся» в 1 ГБ. Это нормальное поведение ОС и не объясняет само по себе, почему не стартуют sync‑джобы. 2. *Ресурсы для job‑подов задаются через

global.jobs.resources

/ `JOB_MAIN_CONTAINER_*`* В Helm‑чарте ресурсы для коннекторных подов (source/destination/orchestrator) берутся из

global.jobs.resources

, которые мапятся на переменные

JOB_MAIN_CONTAINER_CPU_REQUEST/LIMIT

и

JOB_MAIN_CONTAINER_MEMORY_REQUEST/LIMIT

.[Scaling enterprise][Configuring resources]У вас сейчасglobal jobs: resources: requests: cpu: 100m memory: 256Mi limits: cpu: 500m memory: 768MiЭто довольно маленькие лимиты, но они не должны мешать старту подов, если в кластере есть ресурсы. Обычно при нехватке ресурсов вы бы видели

FailedScheduling

/

Insufficient cpu/memory

в событиях пода или

ResourceConstraintException

в логах worker/workload‑launcher.[Issue 73346] 3. *Есть известные баги, когда ресурсы job‑подов игнорируются или берутся из других мест*Если у вас одна из затронутых версий, то реальные ресурсы подов могут не совпадать с тем, что вы задали в values.yaml. ◦ Для некоторых версий Airbyte/Helm ресурсы для replication/check/discover подов игнорируют

global.jobs.resources

и/или env‑переменные, и поды стартуют с «жёстко прошитыми» значениями (например, 2Gi/2 CPU), что может приводить к

FailedScheduling

или OOM, даже если вы задали другие лимиты.[Issue 48816][Issue 73346] ◦ Для orchestrator‑контейнера есть отдельный баг: он всегда стартует с 1Gi, игнорируя

CONTAINER_ORCHESTRATOR_MEMORY_LIMIT

и т.п.[Issue 72833] 1. *Что проверить в первую очередь (по документации/issue):*kubectl -n namespace describe pod replication-pod-nameОбратите внимание на: -

Events:

— есть ли

FailedScheduling

,

Insufficient cpu/memory

,

OOMKilled

и т.п. (в issue 48816 именно так диагностировали OOM).[Issue 48816] -

Limits:

/

Requests:

для контейнеров

source

,

destination

,

orchestrator

— совпадают ли они с вашими 256Mi/768Mi или там другие значения (например, 2Gi). a. События и ресурсы конкретного репликационного пода Для любого не стартующего sync‑job пода выполните: b. Логи

worker

и

workload-launcher

В похожих кейсах при нехватке ресурсов или неправильной конфигурации видно: ▪︎ `ResourceConstraintException: Unable to start the REPLICATION pod. This may be due to insufficient system resources.`[Issue 73346] ▪︎ или ошибки

DEADLINE_EXCEEDED

/

context deadline exceeded

от Temporal при слишком слабых ресурсах.[Forum 861][Issue 59730] b. Версию Airbyte и Helm‑чарта В источниках явно указано, что проблемы с игнорированием ресурсов есть в конкретных версиях (например, Helm 1.2.0, 2.0.19, Airbyte 2.0.1 и др.).[Issue 48816][Issue 73346] Если вы на одной из них, поведение с ресурсами может быть багом, а не вашей конфигурацией. 1. *Рекомендации по настройке (в рамках документации):*global: jobs: resources: requests: cpu: "250m" memory: 512Mi limits: cpu: "1" memory: 1GiЭто соответствует рекомендациям по масштабированию и обычно достаточно для небольших sync‑ов.[Scaling enterprise] ◦ Для начала можно увеличить instance‑wide ресурсы для job‑контейнеров до более безопасных значений, например: ◦ Если выяснится, что реальные лимиты подов всё равно другие (из‑за багов), временные обходные пути из issue: ▪︎ Задавать

resource_requirements

на уровне connection или actor_definition напрямую в БД (работает для source/destination, но не для orchestrator).[Configuring resources][Issue 72833] ▪︎ Использовать Mutating Webhook в Kubernetes, чтобы патчить ресурсы orchestrator‑контейнера (как описано пользователем в issue 72833).[Issue 72833] Чтобы ответить точнее «почему именно не стартуют синки» по вашей установке, по документации нужно как минимум: 1.

kubectl describe pod

для одного не стартующего replication/check/discover пода. 2. Фрагмент логов

worker

и

workload-launcher

вокруг момента запуска sync. Без этих данных знания не позволяют однозначно указать причину, только возможные направления диагностики и известные баги с ресурсами. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.