Skip to content

Platform-aware autoscale from zero #11961

Open
@aleskandro

Description

@aleskandro

What would you like to be added (User Story)?

As a cluster administrator, I want the cluster autoscaler using Cluster API to scale out node groups from zero by considering the architecture of the node groups options to expand when requested by the pods in their node selector or node affinity requirements.

As a cluster administrator, I want the cluster autoscaler using Cluster API to scale out node groups from zero by considering the Operating System of the node groups options to expand when requested by the pods in their node selector or node affinity requirements.

Detailed Description

Today, the Cluster API providers can set the labels capacity annotation to a comma-separated list of key-value pairs representing the labels to expect for a node rendered from a MachineSet/MachineDeployment.

In previous works, the Cluster API has defined a contract to allow infrastructure providers to setup the capacity of a node using the status field of the InfrastructureMachineTemplate. However, the capacity field in the status of a node/InfastrucutreMachineTemplate is a ResourceList consisting of a map that should reflect the resource requests and limits of the pods (map[string]quantity). This is not sufficient for the infrastructure providers to set other information like operating system and architecture of the CPU in that status field.

Therefore, unless users have set the labels capacity annotation with the expected label (e.g., kubernetes.io/arch=arm64), the cluster autoscaler cannot filter out nodes that have a different CPU architecture than the one - possibly - set in the pod's nodeAffinity or nodeSelector.

Anything else you would like to add?

No response

Label(s) to be applied

/kind feature
One or more /area label. See https://github.com/kubernetes-sigs/cluster-api/labels?q=area for the list of labels.

/area provider/core

Metadata

Metadata

Assignees

No one assigned

    Labels

    area/provider/coreIssues or PRs related to the core providerkind/featureCategorizes issue or PR as related to a new feature.needs-priorityIndicates an issue lacks a `priority/foo` label and requires one.triage/acceptedIndicates an issue or PR is ready to be actively worked on.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions