Commit ef86974

or 1e1 pass as the integers they decode to, and a leading-zero

spelling passes as whatever YAML reads it as. A bare numeric zero

is left alone: it is falsy, so the pool renders without domain.cpu

talos-reconcile-job.yaml, so the TalosConfigTemplate name this file

{{- $allocatableMi := divf $allocatableBytes 1048576.0 | floor }}

capacity.cluster-autoscaler.kubernetes.io/memory: "{{ $allocatableMi }}Mi"

{{- end }}

{{- $sysCpuMillisA := include "kubernetes.cpuToMillicores" $systemReservedCpu | float64 }}

{{- $kubeCpuMillisA := include "kubernetes.cpuToMillicores" $kubeReservedCpu | float64 }}

{{- $effectiveCpuMillisA := float64 $effectiveCpuMillicoresA }}

{{- $allocatableCpuMillis := subf $effectiveCpuMillisA (addf $sysCpuMillisA $kubeCpuMillisA) }}

{{- $allocatableCpuMillisInt := $allocatableCpuMillis | ceil | int }}

- failedTemplate:

errorPattern: 'nodeGroup md0: resources.cpu \(0\) must be a whole number of vCPU cores between 1 and 4294967295'

# The schema's quantity pattern admits a leading minus.

- it: refuses a negative core count

set:

- equal:

path: spec.template.spec.numCores

value: 1

path: spec.template.spec.containers[0].command[2]

pattern: 'kubeReserved:\s*\n\s+cpu: "100m"\s*\n\s+memory: "512Mi"'

# On proxmox the worker kubelet runs with an external cloud provider: the

# node is tainted uninitialized until the cloud-controller-manager clears it

# and applies the topology labels the CSI node plugin needs. On kubevirt no

}

},

"resources": {

"type": "object",

"default": {},

"properties": {

roles: []

resources: {}

## @param {quantity} [podCpuLimit] - CPU limit for the worker VM's virt-launcher `compute` container, which is the ceiling the guest vCPU threads, the QEMU emulator thread and the IO threads share. Distinct from `resources.cpu`, which sizes the guest itself. Cannot be combined with `instanceType` sizing: KubeVirt refuses a VM that references an instancetype and also sets `domain.resources.limits.cpu`, so the chart rejects that combination at render time. Sizing the pool by `resources` (both `cpu` and `memory`) is what drops the instancetype from the VM, which is where the limit is usable. When unset, KubeVirt derives the limit from the guest vCPU count in any namespace carrying a ResourceQuota that limits CPU, so a worker sized at N vCPUs runs under a ceiling of N with the emulation overhead taken out of the same N. Setting a value declares the limit on the VM directly, which is both what lands it on the container and what stops KubeVirt deriving one. It moves the CPU request with it: KubeVirt copies a declared CPU limit into the CPU request when the VM declares no request of its own, so a pool that sets only this field asks the scheduler for its whole ceiling instead of the fraction of the vCPU count it asked for before, and a ceiling the nodes cannot spare leaves the workers Pending on `Insufficient cpu`. Pair it with `podCpuRequest` to move the ceiling without moving the request. Zero means no ceiling at all rather than the tightest one, since the kubelet turns a zero CPU limit into no CFS quota while the declared key still stops KubeVirt deriving one — but it is only accepted together with `podCpuRequest: 0`, because KubeVirt keeps deriving a request from the vCPU count when the VM declares none and a request above a declared limit of zero is rejected when the worker's Pod is created. A negative value is refused at render time. Changing it rolls the pool, because the worker VM template is named by a hash of its content. Keep in sync with the parent kubernetes chart.