Skip to content
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -85,6 +85,8 @@ worker mycluster-pool0 ip-10-1-6-225.eu-central-1.compute.internal
worker mycluster-pool0 ip-10-1-6-67.eu-central-1.compute.internal
```

To run a pool on AWS Graviton (arm64) instance types, see [Using arm64 worker nodes](#arm64-nodes) below.

{{< /tab >}}
{{< tab id="nodepool-capa-karpenter-config" for-impl="capa_ec2_karpenter" >}}

Expand Down Expand Up @@ -470,6 +472,67 @@ Using multiple instance types in a node pool has some benefits:

- Even without spot instances, AWS has a limited number of instances per type in each Availability Zone. It can happen that your selected instance type is temporarily out of stock just in the moment you are in demand of more worker nodes. Allowing the node pool to use multiple instance types reduces this risk and increases the likelihood that your node pool can grow when in need.

## Using arm64 worker nodes {#arm64-nodes}

On {{% impl_title "capa_ec2" %}}, you can run worker nodes on the AWS Graviton (arm64) instance families by setting the `architecture` field on a node pool. The cluster's control plane is always x86_64. This applies to worker pools only.

Available starting with Giant Swarm release version 35.

Three settings must stay aligned for an arm64 pool to come up:

- **`architecture: arm64`**: selects the matching CAPI Flatcar arm64 Amazon Machine Image (AMI).
- **`instanceType`**: must be an arm64 family (for example `m7g.xlarge`, `t4g.medium`). x86_64 instance types will fail to boot.
- **A `kubernetes.io/arch=arm64:NoSchedule` taint** under `customNodeTaints`: prevents amd64-only workloads from being scheduled onto the pool. This taint is not added automatically, intentionally, so it doesn't override existing taint configuration.

An example of configuration values mixing x86_64 and arm64 pools in the same cluster:

```yaml
apiVersion: v1
kind: ConfigMap
metadata:
labels:
giantswarm.io/cluster: test-cluster
name: test-cluster-userconfig
namespace: org-giantswarm
data:
values: |
global:
metadata:
name: test-cluster
organization: giantswarm
nodePools:
worker-amd:
instanceType: m5.xlarge
minSize: 1
maxSize: 3
worker-arm:
instanceType: m7g.xlarge
architecture: arm64
minSize: 1
maxSize: 3
customNodeTaints:
- key: kubernetes.io/arch
value: arm64
effect: NoSchedule
providerSpecific:
region: "eu-west-1"
release:
version: 35.0.0
```

Pods that should run on the arm64 pool need a matching toleration and a `kubernetes.io/arch: arm64` `nodeSelector` (or `nodeAffinity`):

```yaml
spec:
tolerations:
- key: kubernetes.io/arch
operator: Equal
value: arm64
effect: NoSchedule
nodeSelector:
kubernetes.io/arch: arm64
```

## Node pools and autoscaling {#autoscaling}

{{< tabs >}}
Expand Down
Loading