@oondemand/oon-core-back 0.7.22 → 0.7.27

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (2) hide show
  1. package/package.json +1 -1
  2. package/src/delivery/runtime.js +7 -4
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@oondemand/oon-core-back",
3
- "version": "0.7.22",
3
+ "version": "0.7.27",
4
4
  "repository": {
5
5
  "type": "git",
6
6
  "url": "git+https://github.com/oondemand/oon-platform.git",
package/src/delivery/runtime.js CHANGED
@@ -209,13 +209,16 @@ spec:
209
209
  spec:
210
210
  serviceAccountName: oon-runtime
211
211
  terminationGracePeriodSeconds: ${TERMINATION_GRACE_SECONDS}
212
- # DoNotSchedule: com ScheduleAnyway as 2 réplicas de Apps globais ficaram
213
- # no mesmo nó. Com maxSkew 1 o pod extra do rolling update ainda cabe e,
214
- # com um único nó, o desvio é zero e nada fica pendente.
212
+ # Distribuição preferencial por nó, contando só os pods da mesma revisão
213
+ # (matchLabelKeys): era a contagem dos pods da revisão anterior que deixava
214
+ # as réplicas novas juntas. ScheduleAnyway, e não a regra obrigatória: com o
215
+ # cluster cheio, a regra obrigatória deixava a réplica Pending ("Insufficient
216
+ # cpu" num nó, spread no outro) e o rollout estourava o prazo.
215
217
  topologySpreadConstraints:
216
218
  - maxSkew: 1
217
219
  topologyKey: kubernetes.io/hostname
218
- whenUnsatisfiable: DoNotSchedule
220
+ whenUnsatisfiable: ScheduleAnyway
221
+ matchLabelKeys: [pod-template-hash]
219
222
  labelSelector:
220
223
  matchLabels: { app.kubernetes.io/name: ${context.appCode} }
221
224
  imagePullSecrets: [{ name: ${infra.REGISTRY_PULL_SECRET_NAME || "ghcr-oon"} }]