update docs

eksctl-io · Mar 28, 2024 · d535ddd · d535ddd
1 parent f4a9769
commit d535ddd
Show file tree

Hide file tree

Showing 6 changed files with 45 additions and 9 deletions.
diff --git a/pkg/nodebootstrap/README.md b/pkg/nodebootstrap/README.md
@@ -42,6 +42,39 @@ and then call `/etc/eks/bootstrap.sh`.
 
 For AL2, enabling either SSM or EFA will add `assets/install-ssm.al2.sh` or `assets/efa.al2.sh`.
 
+### AmazonLinux2023
+
+While AL2023 implements the `Bootstrapper` interface, the underlying userdata will be entirely different from other AMI families. Specifically, AL2023 introduces a new node initialization process nodeadm that uses a YAML configuration schema, dropping the use of `/etc/eks/bootstrap.sh` script. For self-managed nodes, and for EKS-managed nodes based on custom AMIs, eksctl will populate userdata in the fashion below:
+
+```
+MIME-Version: 1.0
+Content-Type: multipart/mixed; boundary=//
+
+--//
+Content-Type: application/node.eks.aws
+
+apiVersion: node.eks.aws/v1alpha1
+kind: NodeConfig
+spec:
+  cluster:
+    apiServerEndpoint: https://XXXX.us-west-2.eks.amazonaws.com
+    certificateAuthority: XXXX
+    cidr: 10.100.0.0/16
+    name: my-cluster
+  kubelet:
+    config:
+      clusterDNS:
+      - 10.100.0.10
+    flags:
+    - --node-labels=alpha.eksctl.io/cluster-name=my-cluster,alpha.eksctl.io/nodegroup-name=my-nodegroup
+    - --register-with-taints=special=true:NoSchedule (only for EKS-managed nodes)
+
+--//--
+
+```
+
+For EKS-managed nodes based on native AMIs, the userdata above is fulfilled automatically by the AWS SSM agent. 
+
 ## Troubleshooting
 
 ### Ubuntu

diff --git a/userdocs/src/getting-started.md b/userdocs/src/getting-started.md
@@ -1,6 +1,9 @@
 # Getting started
 
-!!! tip "New for 2023"
+!!! tip "New for 2024"
+    `eksctl` now supports AMIs based on AmazonLinux2023
+
+!!! tip "eksctl main features in 2023"
     `eksctl` now supports configuring cluster access management via [AWS EKS Access Entries](/usage/access-entries).
 
     `eksctl` now supports configuring fine-grained permissions to EKS running apps via [EKS Pod Identity Associations](/usage/pod-identity-associations)

diff --git a/userdocs/src/usage/arm-support.md b/userdocs/src/usage/arm-support.md
@@ -51,10 +51,7 @@ managedNodeGroups:
 eksctl create cluster -f cluster-arm-2.yaml
 ```
 
-The AMI resolvers, `auto` and `auto-ssm`, will infer the correct AMI based on the ARM instance type.
-
-???+ note
-    Note that currently there are only AmazonLinux2 EKS optimized AMIs for ARM.
+The AMI resolvers, `auto` and `auto-ssm`, will infer the correct AMI based on the ARM instance type. Only AmazonLinux2023, AmazonLinux2 and Bottlerocket families have EKS optimized AMIs for ARM.
 
 ???+ note
     ARM is supported for clusters with version 1.15 and higher.

diff --git a/userdocs/src/usage/container-runtime.md b/userdocs/src/usage/container-runtime.md
@@ -1,8 +1,8 @@
 # Define Container Runtime
 
 !!! warning
-    Starting with Kubernetes version `1.24`, dockershim support has been deprecated. Therefore, if you create a cluster using `eksctl` on version `1.24` or higher, the information below no longer applies, and the only supported container runtime is `containerd`. Trying to set it otherwise will return a validation error.
-    
+    Starting with Kubernetes version `1.24`, dockershim support has been deprecated. Therefore, if you create a cluster using `eksctl` on version `1.24` or higher, the information below no longer applies, and the only supported container runtime is `containerd`. Trying to set it otherwise will return a validation error. Additionally, AL2023 AMIs only support `containerd` regadless of K8s version.
+
     At some point, we will completely remove the option to set `containerRuntime` in config file, together with the support for older Kubernetes versions support (i.e. `1.22` or `1.23`).
 
 For AL2 ( AmazonLinux2 ) and Windows AMIs, it's possible to set container runtime to `containerd`.

diff --git a/userdocs/src/usage/custom-ami-support.md b/userdocs/src/usage/custom-ami-support.md
@@ -16,6 +16,7 @@ The flag can take the AMI image id for an image to explicitly use. It also can t
 ???+ note
     When setting `--node-ami` to an ID string, `eksctl` will assume that a custom AMI has been requested.
     For AmazonLinux2 and Ubuntu nodes, both EKS managed and self-managed, this will mean that `overrideBootstrapCommand` is required.
+    For AmazonLinux2023, since it stops using the `/etc/eks/bootstrap.sh` script for node bootstrapping, in favour of a nodeadm initialization process (for more information, please refer to [node bootstrapping docs](https://github.com/eksctl-io/eksctl/blob/main/pkg/nodebootstrap/README.md)), `overrideBootstrapCommand` is not supported.
 
 CLI flag examples:
 ```sh
@@ -55,6 +56,7 @@ The `--node-ami-family` can take following keywords:
 | Keyword                        |                                          Description                                                           |
 |--------------------------------|:--------------------------------------------------------------------------------------------------------------:|
 | AmazonLinux2                   | Indicates that the EKS AMI image based on Amazon Linux 2 should be used (default).                             |
+| AmazonLinux2023                | Indicates that the EKS AMI image based on Amazon Linux 2023 should be used.                                    |
 | Ubuntu2204                     | Indicates that the EKS AMI image based on Ubuntu 22.04 LTS (Jammy) should be used (available for EKS >= 1.29). |
 | Ubuntu2004                     | Indicates that the EKS AMI image based on Ubuntu 20.04 LTS (Focal) should be used (supported for EKS <= 1.29). |
 | Ubuntu1804                     | Indicates that the EKS AMI image based on Ubuntu 18.04 LTS (Bionic) should be used.                            |
@@ -84,7 +86,7 @@ managedNodeGroups:
 The `--node-ami-family` flag can also be used with `eksctl create nodegroup`. `eksctl` requires AMI Family to be explicitly set via config file or via `--node-ami-family` CLI flag, whenever working with a custom AMI.
 
 ???+ note
-    At the moment, EKS managed nodegroups only support the following AMI Families when working with custom AMIs: `AmazonLinux2`, `Ubuntu1804`, `Ubuntu2004` and `Ubuntu2204`
+    At the moment, EKS managed nodegroups only support the following AMI Families when working with custom AMIs: `AmazonLinux2023`, `AmazonLinux2`, `Ubuntu1804`, `Ubuntu2004` and `Ubuntu2204`
 
 ## Windows custom AMI support
 Only self-managed Windows nodegroups can specify a custom AMI. `amiFamily` should be set to a valid Windows AMI family.

diff --git a/userdocs/theme/home.html b/userdocs/theme/home.html
@@ -532,7 +532,8 @@ <h2><code>eksctl create cluster</code></h2>
                     <figure class="mdx-spotlight__feature"> 
                         <a href="/usage/outposts" tabindex="-1" title="Usage Outposts"><img src="assets/images/outposts.png" alt="Usage Outposts" loading="lazy"></a>
                         <figcaption class="md-typeset">
-                            <h2>New for {{ build_date_utc.strftime('%Y') }}</h2>
+                            <h2>Check out latest eksctl features</h2>
+                            <p>Support for AMIs based on AmazonLinux2023</p>
                             <p>Configuring cluster access management via <a href="/usage/access-entries">AWS EKS Access Entries</a>.</p>
                             <p>Configuring fine-grained permissions to EKS running apps via <a href="/usage/pod-identity-associations">EKS Pod Identity Associations</a>.</p>
                             <p>Creating fully private clusters on <a href="/usage/outposts">AWS Outposts</a>.</p>