You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Use the `--namespace-config` flag to deploy addons to a custom namespace instead of the default namespace.
100
+
====
101
+
92
102
During addon creation, if a self-managed version of the addon already exists on the cluster, you can choose how potential `configMap` conflicts shall be resolved by setting `resolveConflicts` option via the config file, e.g.
93
103
94
104
[,yaml]
@@ -195,6 +205,7 @@ addons:
195
205
====
196
206
Bear in mind that when addon configuration values are being modified, configuration conflicts will arise.
197
207
====
208
+
198
209
Thus, we need to specify how to deal with those by setting the `resolveConflicts` field accordingly.
199
210
As in this scenario we want to modify these values, we'd set `resolveConflicts: overwrite`.
The namespace configuration cannot be updated once an addon is created. The `--namespace-config` flag is only available during addon creation.
282
+
234
283
Similarly to addon creation, When updating an addon, you have full control over the config changes that you may have previously applied on that add-on's `configMap`. Specifically, you can preserve, or overwrite them. This optional functionality is available via the same config file field `resolveConflicts`. e.g.,
Copy file name to clipboardExpand all lines: docs/clusters/eksctl-karpenter.adoc
+60-30Lines changed: 60 additions & 30 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -4,13 +4,11 @@
4
4
= Karpenter Support
5
5
:info_doctype: section
6
6
7
-
`eksctl`supports adding https://karpenter.sh/[Karpenter] to a newly created cluster. It will create all the necessary
7
+
`eksctl`provides support for adding https://karpenter.sh/[Karpenter] to a newly created cluster. It will create all the necessary
8
8
prerequisites outlined in Karpenter's https://karpenter.sh/docs/getting-started/[Getting Started] section including installing
9
-
Karpenter itself using Helm. We currently support installing versions starting `0.20.0` and above.
9
+
Karpenter itself using Helm. We currently support installing versions `0.28.0+`. See the https://karpenter.sh/docs/upgrading/compatibility/[Karpenter compatibility] section for further details.
10
10
11
-
Use the `eksctl` cluster config field `karpenter` to install and configure it.
12
-
13
-
The following yaml outlines a typical installation configuration:
11
+
The following cluster configuration outlines a typical Karpenter installation:
14
12
15
13
[,yaml]
16
14
----
@@ -20,14 +18,14 @@ kind: ClusterConfig
20
18
metadata:
21
19
name: cluster-with-karpenter
22
20
region: us-west-2
23
-
version: '1.24'
21
+
version: '1.32' # requires a version of Kubernetes compatible with Karpenter
24
22
tags:
25
23
karpenter.sh/discovery: cluster-with-karpenter # here, it is set to the cluster name
26
24
iam:
27
25
withOIDC: true # required
28
26
29
27
karpenter:
30
-
version: 'v0.20.0' # Exact version must be specified
28
+
version: '1.2.1' # Exact version should be specified according to the Karpenter compatibility matrix
31
29
32
30
managedNodeGroups:
33
31
- name: managed-ng-1
@@ -42,45 +40,77 @@ to be set:
42
40
[,yaml]
43
41
----
44
42
karpenter:
45
-
version: 'v0.20.0'
43
+
version: '1.2.1'
46
44
createServiceAccount: true # default is false
47
45
defaultInstanceProfile: 'KarpenterNodeInstanceProfile' # default is to use the IAM instance profile created by eksctl
48
46
withSpotInterruptionQueue: true # adds all required policies and rules for supporting Spot Interruption Queue, default is false
49
47
----
50
48
51
49
OIDC must be defined in order to install Karpenter.
52
50
53
-
Once Karpenter is successfully installed, add a https://karpenter.sh/docs/concepts/provisioners/[Provisioner] so Karpenter
54
-
can start adding the right nodes to the cluster.
51
+
Once Karpenter is successfully installed, add https://karpenter.sh/docs/concepts/nodepools/[NodePool(s)] and https://karpenter.sh/docs/concepts/nodeclasses/[NodeClass(es)] to allow Karpenter
52
+
to start adding nodes to the cluster.
53
+
54
+
The NodePool's `nodeClassRef` section must match the name of an `EC2NodeClass`. For example:
55
55
56
-
The provisioner's `instanceProfile` section must match the created `NodeInstanceProfile` role's name. For example:
56
+
[,yaml]
57
+
----
58
+
apiVersion: karpenter.sh/v1
59
+
kind: NodePool
60
+
metadata:
61
+
name: example
62
+
annotations:
63
+
kubernetes.io/description: "Example NodePool"
64
+
spec:
65
+
template:
66
+
spec:
67
+
requirements:
68
+
- key: kubernetes.io/arch
69
+
operator: In
70
+
values: ["amd64"]
71
+
- key: kubernetes.io/os
72
+
operator: In
73
+
values: ["linux"]
74
+
- key: karpenter.sh/capacity-type
75
+
operator: In
76
+
values: ["on-demand"]
77
+
- key: karpenter.k8s.aws/instance-category
78
+
operator: In
79
+
values: ["c", "m", "r"]
80
+
- key: karpenter.k8s.aws/instance-generation
81
+
operator: Gt
82
+
values: ["2"]
83
+
nodeClassRef:
84
+
group: karpenter.k8s.aws
85
+
kind: EC2NodeClass
86
+
name: example # must match the name of an EC2NodeClass
Note that you must specify one of `role` or `instanceProfile` for lauch nodes. If you choose to use `instanceProfile`
110
+
the name of the profile created by `eksctl` follows the pattern: `eksctl-KarpenterNodeInstanceProfile-<cluster-name>`.
83
111
84
112
## Automatic Security Group Tagging
85
113
86
114
`eksctl` automatically tags the cluster's shared node security group with `karpenter.sh/discovery` when both Karpenter is enabled (`karpenter.version` specified) and the `karpenter.sh/discovery` tag exists in `metadata.tags`. This enables AWS Load Balancer Controller compatibility.
115
+
116
+
Note with karpenter 0.32.0+, Provisioners have been deprecated and replaced by https://karpenter.sh/docs/concepts/nodepools/[NodePool].
WARNING: If a nodegroup includes the `attachPolicyARNs` it *must* also include the default node policies, like `AmazonEKSWorkerNodePolicy`, `AmazonEKS_CNI_Policy` and `AmazonEC2ContainerRegistryReadOnly` in this example.
103
+
WARNING: If a nodegroup includes the `attachPolicyARNs` it **must** also include the default node policies, like `AmazonEKSWorkerNodePolicy`, `AmazonEKS_CNI_Policy` and `AmazonEC2ContainerRegistryPullOnly` in this example.
0 commit comments