From c516bac546b34fa847f5d3db490ae8bb06be8979 Mon Sep 17 00:00:00 2001 From: Guillaume Da Silva Date: Thu, 17 Sep 2026 11:08:34 +0200 Subject: [PATCH 1/3] docs: document stable nodepool tolerations and observability resource profiles The deployment.affinity.node.required reference showed a `stable` node pool example badged for Applications, Containers, Jobs and Cronjobs, without mentioning that the pool carries a nodepool/stable:NoSchedule taint. Qovery injects the matching toleration for Applications and Containers only, so following that example on a Job or Cronjob leaves pods in Pending. Documents which service types are covered, the automatic targeting rules, and points Helm users to the existing Helm section. The observability resource_profile levels (LOW, NORMAL, HIGH) were not documented anywhere, leaving no way to know what each level sets before changing a cluster-wide setting. Adds the per-component CPU and memory table and states what the profile does not change, notably retention. Reported through customer support (Pylon #4898). --- .../observability/qovery-observe.mdx | 31 +++++++++++++++++++ .../service-advanced-settings.mdx | 16 ++++++++++ 2 files changed, 47 insertions(+) diff --git a/docs/configuration/integrations/observability/qovery-observe.mdx b/docs/configuration/integrations/observability/qovery-observe.mdx index dc797a87..3d753719 100644 --- a/docs/configuration/integrations/observability/qovery-observe.mdx +++ b/docs/configuration/integrations/observability/qovery-observe.mdx @@ -69,6 +69,37 @@ Qovery's observability combines open-source tools to monitor your Kubernetes inf - **Thanos**: Raw metrics (15 days), 5-minute resolution (30 days), 1-hour resolution (30 days) - **Loki**: 12-week log retention +### Resource Profiles + +The observability stack runs under one of three resource profiles, set on the cluster through the `metrics_parameters.configuration.resource_profile` API field. `NORMAL` is the default. + +The profile changes the CPU and memory requests and limits of the observability components, and nothing else. Retention, scrape interval, replica counts and alerting configuration are the same on all three levels. + +CPU is shown as request/limit. Memory is shown as a single value when the request and the limit are equal, and as request/limit when they differ. + +| Component | LOW | NORMAL | HIGH | +|---|---|---|---| +| Prometheus | 500m/2000m, 1Gi | 1000m/4000m, 4Gi | 2000m/4000m, 8Gi | +| Prometheus Operator | 200m/1000m, 512Mi/1Gi | 200m/1000m, 1Gi | 500m/1000m, 1Gi | +| Node Exporter | 10m/20m, 32Mi | 10m/20m, 32Mi | 10m/20m, 32Mi | +| kube-state-metrics | 150m/150m, 512Mi | 150m/150m, 768Mi | 500m/500m, 1Gi | +| Thanos Query | 500m/500m, 512Mi | 1000m/1000m, 768Mi | 2000m/2000m, 1Gi | +| Thanos Store Gateway | 500m/500m, 512Mi | 500m/500m, 1Gi | 1000m/1000m, 2Gi | +| Thanos Compactor | 500m/500m, 1Gi | 2000m/2000m, 4Gi | 2000m/2000m, 6Gi | +| Prometheus Adapter | 250m/250m, 384Mi | 250m/250m, 384Mi | 400m/400m, 512Mi | +| AlertManager | 50m/100m, 128Mi/256Mi | 100m/200m, 256Mi/512Mi | 200m/500m, 512Mi/1Gi | +| CloudWatch Exporter | 150m/150m, 256Mi | 250m/250m, 512Mi | 500m/500m, 768Mi | + + +Lowering the profile reduces what the observability stack reserves on your cluster, not the data it keeps. Retention stays as described in [Data Retention](#data-retention) on every profile. + + + +`LOW` is intended for small or development clusters. It takes Prometheus from 4Gi to 1Gi and the Thanos Compactor from 4Gi to 1Gi. Compaction is memory-bound, so on clusters with a high number of series these limits can cause OOMKills. + + +A profile change applies on the next cluster deployment. + ### Key Features - **Per-cluster isolation**: Data protection and performance optimization diff --git a/docs/configuration/service-advanced-settings.mdx b/docs/configuration/service-advanced-settings.mdx index ade2b0fe..908b0acc 100644 --- a/docs/configuration/service-advanced-settings.mdx +++ b/docs/configuration/service-advanced-settings.mdx @@ -191,6 +191,22 @@ This value must be **greater than** the time your `deployment.lifecycle.pre_stop If no node matches the required labels, your pods will stay in `Pending` state. Make sure the target node pool or nodes exist before applying this setting. +#### Targeting the `stable` node pool on AWS with Karpenter + +The `stable` node pool carries a `nodepool/stable:NoSchedule` taint. Node affinity alone is not enough: a pod also needs a matching toleration, and this setting only controls the affinity. + +Qovery adds the toleration for you on **Applications** and **Containers**. Setting `{"karpenter.sh/nodepool": "stable"}` on those services is enough, and their pods schedule normally. Container-mode databases are pinned to `stable` automatically, with their toleration, and need no setting at all. + + +On **Jobs** and **Cronjobs**, the toleration is not added. Setting `{"karpenter.sh/nodepool": "stable"}` on a job applies the affinity without the toleration, and its pods stay in `Pending`. Jobs and cronjobs are pinned to the dedicated `cronjob` node pool instead, with their toleration handled automatically. + + + +Applications and Containers are placed on the `stable` node pool automatically, affinity and toleration included, when the service has `min_instances` set to `1` or when it has storage attached. In those cases you do not need to set this advanced setting yourself. + + +For Helm services, Qovery does not inject affinity or tolerations, so you declare both in your own `values.yaml`. See [Change the node pool of your service when using Helm](/configuration/integrations/kubernetes/eks/managed#change-the-node-pool-of-your-service-when-using-helm). + ### deployment.antiaffinity.pod From 98e2f7d4907547291299e8471f2a08186c6cbe2d Mon Sep 17 00:00:00 2001 From: Guillaume Da Silva Date: Thu, 17 Sep 2026 11:45:06 +0200 Subject: [PATCH 2/3] docs: address review feedback on nodepool tolerations and profiles Qualify the cronjob node pool as optional and stop restating its behavior: the `stable` toleration gap is the subject here, so point to the existing Dedicated Cronjob Node Pool section instead of duplicating it. State the EKS with Karpenter condition explicitly on the automatic stable placement rule. Stop repeating the memory figures in the LOW warning; refer to the table so the values live in one place. --- .../integrations/observability/qovery-observe.mdx | 2 +- docs/configuration/service-advanced-settings.mdx | 6 ++++-- 2 files changed, 5 insertions(+), 3 deletions(-) diff --git a/docs/configuration/integrations/observability/qovery-observe.mdx b/docs/configuration/integrations/observability/qovery-observe.mdx index 3d753719..5e01ef36 100644 --- a/docs/configuration/integrations/observability/qovery-observe.mdx +++ b/docs/configuration/integrations/observability/qovery-observe.mdx @@ -95,7 +95,7 @@ Lowering the profile reduces what the observability stack reserves on your clust -`LOW` is intended for small or development clusters. It takes Prometheus from 4Gi to 1Gi and the Thanos Compactor from 4Gi to 1Gi. Compaction is memory-bound, so on clusters with a high number of series these limits can cause OOMKills. +`LOW` is intended for small or development clusters. It cuts the memory available to Prometheus and to the Thanos Compactor, as shown in the LOW column above. Compaction is memory-bound, so on clusters with a high number of series those limits can cause OOMKills. A profile change applies on the next cluster deployment. diff --git a/docs/configuration/service-advanced-settings.mdx b/docs/configuration/service-advanced-settings.mdx index 908b0acc..c3fa683e 100644 --- a/docs/configuration/service-advanced-settings.mdx +++ b/docs/configuration/service-advanced-settings.mdx @@ -198,11 +198,13 @@ The `stable` node pool carries a `nodepool/stable:NoSchedule` taint. Node affini Qovery adds the toleration for you on **Applications** and **Containers**. Setting `{"karpenter.sh/nodepool": "stable"}` on those services is enough, and their pods schedule normally. Container-mode databases are pinned to `stable` automatically, with their toleration, and need no setting at all. -On **Jobs** and **Cronjobs**, the toleration is not added. Setting `{"karpenter.sh/nodepool": "stable"}` on a job applies the affinity without the toleration, and its pods stay in `Pending`. Jobs and cronjobs are pinned to the dedicated `cronjob` node pool instead, with their toleration handled automatically. +On **Jobs** and **Cronjobs**, the `stable` toleration is not added. Setting `{"karpenter.sh/nodepool": "stable"}` on those services applies the affinity without the toleration, and their pods stay in `Pending`. +This is separate from the optional `cronjob` node pool, which has its own taint and its own automatic toleration. See [Dedicated Cronjob Node Pool](/configuration/cronjob#dedicated-cronjob-node-pool). + -Applications and Containers are placed on the `stable` node pool automatically, affinity and toleration included, when the service has `min_instances` set to `1` or when it has storage attached. In those cases you do not need to set this advanced setting yourself. +On EKS clusters with Karpenter, Applications and Containers are placed on the `stable` node pool automatically, affinity and toleration included, when the service has `min_instances` set to `1` or when it has storage attached. In those cases you do not need to set this advanced setting yourself. For Helm services, Qovery does not inject affinity or tolerations, so you declare both in your own `values.yaml`. See [Change the node pool of your service when using Helm](/configuration/integrations/kubernetes/eks/managed#change-the-node-pool-of-your-service-when-using-helm). From 9176414399d7f4c6abc7c6cf112a1125084b5fc8 Mon Sep 17 00:00:00 2001 From: Guillaume Da Silva Date: Thu, 17 Sep 2026 11:45:41 +0200 Subject: [PATCH 3/3] docs: scope the resource profile to the metrics components Loki, Promtail and the Qovery Event Logger are listed on the same page as part of the stack but are sized independently, so name them explicitly rather than letting "the observability components" cover them. --- .../configuration/integrations/observability/qovery-observe.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/configuration/integrations/observability/qovery-observe.mdx b/docs/configuration/integrations/observability/qovery-observe.mdx index 5e01ef36..35668d6f 100644 --- a/docs/configuration/integrations/observability/qovery-observe.mdx +++ b/docs/configuration/integrations/observability/qovery-observe.mdx @@ -73,7 +73,7 @@ Qovery's observability combines open-source tools to monitor your Kubernetes inf The observability stack runs under one of three resource profiles, set on the cluster through the `metrics_parameters.configuration.resource_profile` API field. `NORMAL` is the default. -The profile changes the CPU and memory requests and limits of the observability components, and nothing else. Retention, scrape interval, replica counts and alerting configuration are the same on all three levels. +The profile changes the CPU and memory requests and limits of the metrics components listed below, and nothing else. Retention, scrape interval, replica counts and alerting configuration are the same on all three levels. Log and event collection are not affected: Loki, Promtail and the Qovery Event Logger are sized independently of this setting. CPU is shown as request/limit. Memory is shown as a single value when the request and the limit are equal, and as request/limit when they differ.