karpenter_arch

Description

The karpenter_arch parameter sets the CPU architecture for Karpenter workload nodes.

Default Value

The default value is empty (auto-detected from node_type).

Setting the Parameter

$ convox rack params set karpenter_arch=arm64 -r rackName
Updating parameters... OK

For mixed-architecture workloads:

$ convox rack params set karpenter_arch=amd64,arm64 -r rackName
Updating parameters... OK

Additional Information

• Validation: Must be amd64, arm64, or amd64,arm64. Empty is the initial default (auto-detect), not a settable value.
• Write the mixed value with no spaces: amd64,arm64.
• When unset, Karpenter auto-detects the architecture from the Rack's node_type instance family, so enabling Karpenter on an existing Rack keeps the architecture that Rack was already running and this parameter does not need to be set. Convox Console Karpenter install templates pre-set the parameters a Karpenter Rack needs.
• When both architectures are specified, Karpenter selects the optimal architecture based on pod requirements and instance availability.
• Once set, the parameter cannot be cleared back to auto-detect; set it explicitly to the desired value instead.
• With karpenter_arch=amd64,arm64, Convox Builds produce a multi-architecture image index, so Services schedule onto either architecture with no nodeSelectorLabels pinning.
• With a single value, Builds on the workload and build pools produce one image for that architecture. On a Rack with build_node_enabled=true, the build pod runs in the build pool, whose architecture follows build_node_type, falling back to node_type, not karpenter_arch. Setting karpenter_arch=arm64 by hand on such a Rack whose node_type is x86 therefore moves the workload pool to arm64 while leaving the build pool on amd64. From Rack version 3.25.9 those Builds still produce arm64 images, built under emulation, which is slower than a native Build. Set build_node_type to a Graviton type in the same change to keep Builds native. Before 3.25.9 every new Build on such a Rack produced an image the workload pool could not run, and Processes failed with an exec format error. A Rack that inherits both from node_type is always consistent. With the default build_node_enabled=false there is no build pool, Builds run on workload nodes, and build_node_type has no effect.
• See Architecture Selection and Mixed-Architecture Racks for the full Build output matrix, which platforms convox builds import-image copies, and how an additional_karpenter_nodepools_config entry with a differing arch also switches the Rack into multi-architecture Builds.

See Also

• Karpenter for the full Karpenter configuration reference
• BuildArch for pinning an individual App's Build to one architecture
• build_node_type for the build node instance type
• node_type for primary node instance type