From 24e02672ca89fb90ac1c2b418bbdf0fe4098b24e Mon Sep 17 00:00:00 2001 From: Geoffrey Cline Date: Thu, 23 Jan 2025 21:35:35 -0600 Subject: [PATCH 1/2] ticket fixes --- latest/ug/automode/automode.adoc | 2 +- latest/ug/automode/create-node-pool.adoc | 4 +++- latest/ug/clusters/kubernetes-versions-standard.adoc | 2 +- latest/ug/clusters/zone-shift.adoc | 2 +- .../ug/manage-access/aws-access/service-accounts.adoc | 11 ++--------- .../ug/manage-access/k8s-access/access-entries.adoc | 2 +- latest/ug/storage/ebs-csi.adoc | 4 +++- 7 files changed, 12 insertions(+), 15 deletions(-) diff --git a/latest/ug/automode/automode.adoc b/latest/ug/automode/automode.adoc index 804aee2a6..c363f4382 100644 --- a/latest/ug/automode/automode.adoc +++ b/latest/ug/automode/automode.adoc @@ -29,7 +29,7 @@ EKS Auto Mode provides the following high-level features: **Application Availability**: EKS Auto Mode dynamically adds or removes nodes in your EKS cluster based on the demands of your Kubernetes applications. This minimizes the need for manual capacity planning and ensures application availability. //what? -**Efficiency**: EKS Auto Mode is designed to compute costs while adhering to the flexibility defined by your NodePool and workload requirements. It also terminates unused instances and consolidates workloads onto other nodes to improve cost efficiency. +**Efficiency**: EKS Auto Mode is designed to optimize compute costs while adhering to the flexibility defined by your NodePool and workload requirements. It also terminates unused instances and consolidates workloads onto other nodes to improve cost efficiency. **Security**: EKS Auto Mode uses AMIs that are treated as immutable for your nodes. These AMIs enforce locked-down software, enable SELinux mandatory access controls, and provide read-only root file systems. Additionally, nodes launched by EKS Auto Mode have a maximum lifetime of 21 days (which you can reduce), after which they are automatically replaced with new nodes. This approach enhances your security posture by regularly cycling nodes, aligning with best practices already adopted by many customers. diff --git a/latest/ug/automode/create-node-pool.adoc b/latest/ug/automode/create-node-pool.adoc index 92a44feb8..3a800d23d 100644 --- a/latest/ug/automode/create-node-pool.adoc +++ b/latest/ug/automode/create-node-pool.adoc @@ -7,6 +7,8 @@ include::../attributes.txt[] Amazon EKS node pools provide a flexible way to manage compute resources in your Kubernetes cluster. This topic demonstrates how to create and configure node pools using Karpenter, a node provisioning tool that helps optimize cluster scaling and resource utilization. With Karpenter's NodePool resource, you can define specific requirements for your compute resources, including instance types, availability zones, architectures, and capacity types. +You cannot modify the built in `system` and `general-purpose` node pools. You can only enable or disable them. For more information, see <>. + The NodePool specification allows for fine-grained control over your EKS cluster's compute resources through various supported labels and requirements. These include options for specifying EC2 instance categories, CPU configurations, availability zones, architectures (ARM64/AMD64), and capacity types (spot/on-demand). You can also set resource limits for CPU and memory usage, ensuring your cluster stays within desired operational boundaries. EKS Auto Mode leverages well-known Kubernetes labels to provide consistent and standardized ways of identifying node characteristics. These labels, such as `topology.kubernetes.io/zone` for availability zones and `kubernetes.io/arch` for CPU architecture, follow established Kubernetes conventions. Additionally, EKS-specific labels (prefixed with `eks.amazonaws.com/`) extend this functionality with {aws}-specific attributes like instance types, CPU manufacturers, GPU capabilities, and networking specifications. This standardized labeling system enables seamless integration with existing Kubernetes tooling while providing deep {aws} infrastructure integration. @@ -41,7 +43,7 @@ Ensure that your NodePool references a valid NodeClass that exists in your clust apiVersion: karpenter.sh/v1 kind: NodePool metadata: - name: default + name: my-node-pool spec: template: metadata: diff --git a/latest/ug/clusters/kubernetes-versions-standard.adoc b/latest/ug/clusters/kubernetes-versions-standard.adoc index 1eabb4d7b..66f7f7ae4 100644 --- a/latest/ug/clusters/kubernetes-versions-standard.adoc +++ b/latest/ug/clusters/kubernetes-versions-standard.adoc @@ -99,7 +99,7 @@ For the complete [.noloc]`Kubernetes` `1.31` changelog, see https://github.com/k * Starting with Amazon EKS version `1.30` or newer, any newly created managed node groups will automatically default to using Amazon Linux 2023 (AL2023) as the node operating system. Previously, new node groups would default to Amazon Linux 2 (AL2). You can continue to use AL2 by choosing it as the AMI type when creating a new node group. -+ +** For information about migrating from AL2 to AL2023, see <>. ** For more information about Amazon Linux, see link:linux/al2023/ug/compare-with-al2.html[Comparing AL2 and AL2023,type="documentation"] in the Amazon Linux User Guide. ** For more information about specifiying the operating system for a managed node group, see <>. diff --git a/latest/ug/clusters/zone-shift.adoc b/latest/ug/clusters/zone-shift.adoc index 094b42358..a956cd398 100644 --- a/latest/ug/clusters/zone-shift.adoc +++ b/latest/ug/clusters/zone-shift.adoc @@ -53,7 +53,7 @@ For zonal shift to work successfully in EKS, you need to setup your cluster envi * Pre-scale your Pods (including CoreDNS) in every AZ * Spread multiple Pod replicas across all AZs to ensure that shifting away from a single AZ will leave you with sufficient capacity * Co-locate interdependent or related Pods in the same AZ -* Test that your cluster environment would work as expected with on less AZ by manually starting a zonal shift. Alternatively, you can enable zonal autoshift and reply on the autoshift practice runs. This is not required for zonal shift to work in EKS but it's strongly recommended. +* Test that your cluster environment would work as expected with one less AZ by manually starting a zonal shift. Alternatively, you can enable zonal autoshift and reply on the autoshift practice runs. This is not required for zonal shift to work in EKS but it's strongly recommended. === Provision Your EKS Worker Nodes Across Multiple AZs diff --git a/latest/ug/manage-access/aws-access/service-accounts.adoc b/latest/ug/manage-access/aws-access/service-accounts.adoc index d2f1cc697..636cadba3 100644 --- a/latest/ug/manage-access/aws-access/service-accounts.adoc +++ b/latest/ug/manage-access/aws-access/service-accounts.adoc @@ -205,15 +205,8 @@ To use EKS Pod Identities, the cluster must have a platform version that is the |Kubernetes version |Platform version - -|`1.31` -|`eks.4` - -|`1.30` -|`eks.2` - -|`1.29` -|`eks.1` +|Kubernetes versions not listed +|All platform versions support |`1.28` |`eks.4` diff --git a/latest/ug/manage-access/k8s-access/access-entries.adoc b/latest/ug/manage-access/k8s-access/access-entries.adoc index f15ee46c2..68392f452 100644 --- a/latest/ug/manage-access/k8s-access/access-entries.adoc +++ b/latest/ug/manage-access/k8s-access/access-entries.adoc @@ -20,7 +20,7 @@ Learn how to manage access entries for IAM principals to your Amazon EKS cluster EKS access entries it the best way to grant users access to the Kubernetes API. For example, you can use access entries to grant developers access to use kubectl. -Fundamentally, an EKS access entry associates a set of Kubernetes permissions with an IAM identity, such as an IAM role. For example, a develoer may assume an IAM role and use that to authenticate to an EKS Cluster. +Fundamentally, an EKS access entry associates a set of Kubernetes permissions with an IAM identity, such as an IAM role. For example, a developer may assume an IAM role and use that to authenticate to an EKS Cluster. You can attach Kubernetes permissions to access entries in two ways: diff --git a/latest/ug/storage/ebs-csi.adoc b/latest/ug/storage/ebs-csi.adoc index d10f1a15f..e7713ac05 100644 --- a/latest/ug/storage/ebs-csi.adoc +++ b/latest/ug/storage/ebs-csi.adoc @@ -45,7 +45,9 @@ To use the snapshot functionality of the Amazon EBS CSI driver, you must first i ---- aws eks describe-addon-versions --addon-name aws-ebs-csi-driver ---- -* An existing {aws} Identity and Access Management (IAM) [.noloc]`OpenID Connect` ([.noloc]`OIDC`) provider for your cluster. To determine whether you already have one, or to create one, see <>. +* The EBS CSI driver needs {aws} IAM Permissions. +** {aws} suggests using EKS Pod Identities. For more information, see <>. +** For information about IAM Roles for Service Accounts, see <>. * If you're using a cluster wide restricted <>, make sure that the add-on is granted sufficient permissions to be deployed. For the permissions required by each add-on [.noloc]`Pod`, see the https://github.com/kubernetes-sigs/aws-ebs-csi-driver/tree/master/deploy/kubernetes/base[relevant add-on manifest definition] on GitHub. From 29fa945fb4698cb7b4bf282b183ad0dbce252f7f Mon Sep 17 00:00:00 2001 From: Geoffrey Cline Date: Fri, 24 Jan 2025 15:28:07 -0600 Subject: [PATCH 2/2] replace version references with attribute --- latest/ug/attributes.txt | 7 +++++++ latest/ug/clusters/create-cluster.adoc | 10 +++++----- latest/ug/clusters/kubernetes-versions.adoc | 4 ++-- latest/ug/clusters/platform-versions.adoc | 2 +- latest/ug/clusters/update-cluster.adoc | 7 +------ latest/ug/getting-started/install-kubectl.adoc | 2 +- .../cni-custom-network-tutorial.adoc | 4 ++-- latest/ug/networking/external-snat.adoc | 2 +- latest/ug/nodes/launch-node-bottlerocket.adoc | 2 +- latest/ug/nodes/launch-node-ubuntu.adoc | 2 +- latest/ug/nodes/migrate-stack.adoc | 10 +++++----- latest/ug/nodes/retrieve-windows-ami-id.adoc | 2 +- .../self-managed-windows-server-2022.adoc | 2 +- latest/ug/nodes/update-managed-node-group.adoc | 4 ++-- latest/ug/nodes/update-stack.adoc | 6 +++--- latest/ug/workloads/creating-an-add-on.adoc | 18 +++++++++--------- latest/ug/workloads/updating-an-add-on.adoc | 4 ++-- 17 files changed, 45 insertions(+), 43 deletions(-) diff --git a/latest/ug/attributes.txt b/latest/ug/attributes.txt index 784e706d0..926d3cdc2 100644 --- a/latest/ug/attributes.txt +++ b/latest/ug/attributes.txt @@ -6,6 +6,13 @@ :auto-cli-v2-version: 2.12.3 :auto-cli-v1-version: 1.27.160 +// Kubernetes Versions + +:k8s-n: 1.32 +:k8s-n-1: 1.31 +:k8s-n-2: 1.30 + + // Words Geoffrey often spells wrong or doesn't like to type :ret: retrieve diff --git a/latest/ug/clusters/create-cluster.adoc b/latest/ug/clusters/create-cluster.adoc index 54c7c38ab..ec41e44f6 100644 --- a/latest/ug/clusters/create-cluster.adoc +++ b/latest/ug/clusters/create-cluster.adoc @@ -26,7 +26,7 @@ This topic provides an overview of the available options and describes what to c == Prerequisites * An existing VPC and subnets that meet <>. Before you deploy a cluster for production use, we recommend that you have a thorough understanding of the VPC and subnet requirements. If you don't have a VPC and subnets, you can create them using an <>. -* The `kubectl` command line tool is installed on your device or {aws} CloudShell. The version can be the same as or up to one minor version earlier or later than the [.noloc]`Kubernetes` version of your cluster. For example, if your cluster version is `1.29`, you can use `kubectl` version `1.28`, `1.29`, or `1.30` with it. To install or upgrade `kubectl`, see <>. +* The `kubectl` command line tool is installed on your device or {aws} CloudShell. The version can be the same as or up to one minor version earlier or later than the [.noloc]`Kubernetes` version of your cluster. To install or upgrade `kubectl`, see <>. * Version `2.12.3` or later or version `1.27.160` or later of the {aws} Command Line Interface ({aws} CLI) installed and configured on your device or {aws} CloudShell. To check your current version, use `aws --version | cut -d / -f2 | cut -d ' ' -f1`. Package managers such `yum`, `apt-get`, or [.noloc]`Homebrew` for [.noloc]`macOS` are often several versions behind the latest version of the {aws} CLI. To install the latest version, see link:cli/latest/userguide/cli-chap-install.html[Installing, updating, and uninstalling the {aws} CLI,type="documentation"] and link:cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config[Quick configuration with aws configure,type="documentation"] in the _{aws} Command Line Interface User Guide_. The {aws} CLI version that is installed in {aws} CloudShell might also be several versions behind the latest version. To update it, see link:cloudshell/latest/userguide/vm-specs.html#install-cli-software[Installing {aws} CLI to your home directory,type="documentation"] in the _{aws} CloudShell User Guide_. * An link:IAM/latest/UserGuide/id_roles.html#iam-term-principal[IAM principal,type="documentation"] with permissions to `create` and `describe` an Amazon EKS cluster. For more information, see <> and <>. @@ -93,7 +93,7 @@ You can create a cluster by using: . Create an Amazon EKS `IPv4` cluster with the Amazon EKS default [.noloc]`Kubernetes` version in your default {aws} Region. Before running command, make the following replacements: . Replace [.replaceable]`region-code` with the {aws} Region that you want to create your cluster in. . Replace [.replaceable]`my-cluster` with a name for your cluster. The name can contain only alphanumeric characters (case-sensitive) and hyphens. It must start with an alphanumeric character and can't be longer than 100 characters. The name must be unique within the {aws} Region and {aws} account that you're creating the cluster in. -. Replace [.replaceable]`1.29` with any xref:kubernetes-versions[Amazon EKS supported version,linkend=kubernetes-versions]. +. Replace [.replaceable]`{k8s-n}` with any xref:kubernetes-versions[Amazon EKS supported version,linkend=kubernetes-versions]. . Change the values for `vpc-private-subnets` to meet your requirements. You can also add additional IDs. You must specify at least two subnet IDs. If you'd rather specify public subnets, you can change `--vpc-private-subnets` to `--vpc-public-subnets`. Public subnets have an associated route table with a route to an internet gateway, but private subnets don't have an associated route table. We recommend using private subnets whenever possible. + The subnets that you choose must meet the <>. Before selecting subnets, we recommend that you're familiar with all of the <>. @@ -102,7 +102,7 @@ The subnets that you choose must meet the <>. + -The [.noloc]`Kubernetes` project tests compatibility between the control plane and nodes for up to three minor versions. For example, `1.27` nodes continue to operate when orchestrated by a `1.30` control plane. However, running a cluster with nodes that are persistently three minor versions behind the control plane isn't recommended. For more information, see https://kubernetes.io/docs/setup/version-skew-policy/[Kubernetes version and version skew support policy] in the [.noloc]`Kubernetes` documentation. We recommend maintaining the same [.noloc]`Kubernetes` version on your control plane and nodes. +The [.noloc]`Kubernetes` project tests compatibility between the control plane and nodes for up to three minor versions. For example, `{k8s-n-3}` nodes continue to operate when orchestrated by a `{k8s-n}` control plane. However, running a cluster with nodes that are persistently three minor versions behind the control plane isn't recommended. For more information, see https://kubernetes.io/docs/setup/version-skew-policy/[Kubernetes version and version skew support policy] in the [.noloc]`Kubernetes` documentation. We recommend maintaining the same [.noloc]`Kubernetes` version on your control plane and nodes. *Are [.noloc]`Pods` running on Fargate automatically upgraded with an automatic cluster control plane version upgrade?*:: diff --git a/latest/ug/clusters/platform-versions.adoc b/latest/ug/clusters/platform-versions.adoc index 3828100b4..392067df4 100644 --- a/latest/ug/clusters/platform-versions.adoc +++ b/latest/ug/clusters/platform-versions.adoc @@ -7,7 +7,7 @@ include::../attributes.txt[] Amazon EKS platform versions represent the capabilities of the Amazon EKS cluster control plane, such as which [.noloc]`Kubernetes` API server flags are enabled, as well as the current [.noloc]`Kubernetes` patch version. Each [.noloc]`Kubernetes` minor version has one or more associated Amazon EKS platform versions. The platform versions for different [.noloc]`Kubernetes` minor versions are independent. You can <> using the {aws} CLI or {aws-management-console}. If you have a local cluster on {aws} Outposts, see <> instead of this topic. -When a new [.noloc]`Kubernetes` minor version is available in Amazon EKS, such as 1.30, the initial Amazon EKS platform version for that [.noloc]`Kubernetes` minor version starts at `eks.1`. However, Amazon EKS releases new platform versions periodically to enable new [.noloc]`Kubernetes` control plane settings and to provide security fixes. +When a new [.noloc]`Kubernetes` minor version is available in Amazon EKS, such as {k8s-n}, the initial Amazon EKS platform version for that [.noloc]`Kubernetes` minor version starts at `eks.1`. However, Amazon EKS releases new platform versions periodically to enable new [.noloc]`Kubernetes` control plane settings and to provide security fixes. When new Amazon EKS platform versions become available for a minor version: diff --git a/latest/ug/clusters/update-cluster.adoc b/latest/ug/clusters/update-cluster.adoc index 5be4c0255..bc387b6de 100644 --- a/latest/ug/clusters/update-cluster.adoc +++ b/latest/ug/clusters/update-cluster.adoc @@ -237,12 +237,7 @@ kubectl apply -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/vX.X + ** If you are using Amazon EKS add-ons, select *Clusters* in the Amazon EKS console, then select the name of the cluster that you updated in the left navigation pane. Notifications appear in the console. They inform you that a new version is available for each add-on that has an available update. To update an add-on, select the *Add-ons* tab. In one of the boxes for an add-on that has an update available, select *Update now*, select an available version, and then select *Update*. ** Alternately, you can use the {aws} CLI or `eksctl` to update add-ons. For more information, see <>. -. If necessary, update your version of `kubectl`. You must use a `kubectl` version that is within one minor version difference of your Amazon EKS cluster control plane. For example, a `1.29` `kubectl` client works with [.noloc]`Kubernetes` `1.28`, `1.29`, and `1.30` clusters. You can check your currently installed version with the following command. -+ -[source,bash,subs="verbatim,attributes"] ----- -kubectl version --client ----- +. If necessary, update your version of `kubectl`. You must use a `kubectl` version that is within one minor version difference of your Amazon EKS cluster control plane. [[downgrade-cluster,downgrade-cluster.title]] diff --git a/latest/ug/getting-started/install-kubectl.adoc b/latest/ug/getting-started/install-kubectl.adoc index 2ced97f88..63cf437cc 100644 --- a/latest/ug/getting-started/install-kubectl.adoc +++ b/latest/ug/getting-started/install-kubectl.adoc @@ -30,7 +30,7 @@ This topic helps you to download and install, or update, the `kubectl` binary on [NOTE] ==== -You must use a `kubectl` version that is within one minor version difference of your Amazon EKS cluster control plane. For example, a `1.30` `kubectl` client works with [.noloc]`Kubernetes` `1.29`, `1.30`, and `1.31` clusters. +You must use a `kubectl` version that is within one minor version difference of your Amazon EKS cluster control plane. For example, a `{k8s-n-1}` `kubectl` client works with [.noloc]`Kubernetes` `{k8s-n-2}`, `{k8s-n-1}`, and `{k8s-n}` clusters. ==== diff --git a/latest/ug/networking/cni-custom-network-tutorial.adoc b/latest/ug/networking/cni-custom-network-tutorial.adoc index 4e763ee2f..9d4845b2a 100644 --- a/latest/ug/networking/cni-custom-network-tutorial.adoc +++ b/latest/ug/networking/cni-custom-network-tutorial.adoc @@ -15,7 +15,7 @@ Complete the following before you start the tutorial: * Review the considerations * Familiarity with how the [.noloc]`Amazon VPC CNI plugin for Kubernetes` creates secondary network interfaces and assigns IP addresses to [.noloc]`Pods`. For more information, see https://github.com/aws/amazon-vpc-cni-k8s#eni-allocation[ENI Allocation] on [.noloc]`GitHub`. * Version `2.12.3` or later or version `1.27.160` or later of the {aws} Command Line Interface ({aws} CLI) installed and configured on your device or {aws} CloudShell. To check your current version, use `aws --version | cut -d / -f2 | cut -d ' ' -f1`. Package managers such `yum`, `apt-get`, or [.noloc]`Homebrew` for [.noloc]`macOS` are often several versions behind the latest version of the {aws} CLI. To install the latest version, see link:cli/latest/userguide/cli-chap-install.html[Installing, updating, and uninstalling the {aws} CLI,type="documentation"] and link:cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config[Quick configuration with aws configure,type="documentation"] in the _{aws} Command Line Interface User Guide_. The {aws} CLI version that is installed in {aws} CloudShell might also be several versions behind the latest version. To update it, see link:cloudshell/latest/userguide/vm-specs.html#install-cli-software[Installing {aws} CLI to your home directory,type="documentation"] in the _{aws} CloudShell User Guide_. -* The `kubectl` command line tool is installed on your device or {aws} CloudShell. The version can be the same as or up to one minor version earlier or later than the [.noloc]`Kubernetes` version of your cluster. For example, if your cluster version is `1.29`, you can use `kubectl` version `1.28`, `1.29`, or `1.30` with it. To install or upgrade `kubectl`, see <>. +* The `kubectl` command line tool is installed on your device or {aws} CloudShell. To install or upgrade `kubectl`, see <>. * We recommend that you complete the steps in this topic in a Bash shell. If you aren't using a Bash shell, some script commands such as line continuation characters and the way variables are set and used require adjustment for your shell. Additionally, the quoting and escaping rules for your shell might be different. For more information, see link:cli/latest/userguide/cli-usage-parameters-quoting-strings.html[Using quotation marks with strings in the {aws} CLI,type="documentation"] in the {aws} Command Line Interface User Guide. For this tutorial, we recommend using the [.replaceable]`example values`, except where it's noted to replace them. You can replace any [.replaceable]`example value` when completing the steps for a production cluster. We recommend completing all steps in the same terminal. This is because variables are set and used throughout the steps and won't exist in different terminals. @@ -532,7 +532,7 @@ kube-system kube-proxy-wx9vk 1/1 Running 0 7m15s 19 + You can see that the coredns [.noloc]`Pods` are assigned IP addresses from the `192.168.1.0` CIDR block that you added to your VPC. Without custom networking, they would have been assigned addresses from the `192.168.0.0` CIDR block, because it was the only CIDR block originally associated with the VPC. + -If a [.noloc]`Pod's` `spec` contains `hostNetwork=true`, it's assigned the primary IP address of the node. It isn't assigned an address from the subnets that you added. By default, this value is set to `false`. This value is set to `true` for the `kube-proxy` and [.noloc]`Amazon VPC CNI plugin for Kubernetes` (`aws-node`) [.noloc]`Pods` that run on your cluster. This is why the `kube-proxy` and the plugin's `aws-node` [.noloc]`Pods` aren't assigned `192.168.1.[.replaceable]``x``` addresses in the previous output. For more information about a [.noloc]`Pod's` `hostNetwork` setting, see https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.30/#podspec-v1-core[PodSpec v1 core] in the [.noloc]`Kubernetes` API reference. +If a [.noloc]`Pod's` `spec` contains `hostNetwork=true`, it's assigned the primary IP address of the node. It isn't assigned an address from the subnets that you added. By default, this value is set to `false`. This value is set to `true` for the `kube-proxy` and [.noloc]`Amazon VPC CNI plugin for Kubernetes` (`aws-node`) [.noloc]`Pods` that run on your cluster. This is why the `kube-proxy` and the plugin's `aws-node` [.noloc]`Pods` aren't assigned `192.168.1.[.replaceable]``x``` addresses in the previous output. For more information about a [.noloc]`Pod's` `hostNetwork` setting, see https://kubernetes.io/docs/reference/generated/kubernetes-api/v{k8s-n}/#podspec-v1-core[PodSpec v1 core] in the [.noloc]`Kubernetes` API reference. [[custom-network-delete-resources,custom-network-delete-resources.title]] diff --git a/latest/ug/networking/external-snat.adoc b/latest/ug/networking/external-snat.adoc index 7fe59a7ea..76541838a 100644 --- a/latest/ug/networking/external-snat.adoc +++ b/latest/ug/networking/external-snat.adoc @@ -49,5 +49,5 @@ The `AWS_VPC_K8S_CNI_EXTERNALSNAT` and `AWS_VPC_K8S_CNI_EXCLUDE_SNAT_CIDRS` CNI [[snat-exception,snat-exception.title]] == Host networking -^^*^^If a [.noloc]`Pod's` spec contains `hostNetwork=true` (default is `false`), then its IP address isn't translated to a different address. This is the case for the `kube-proxy` and [.noloc]`Amazon VPC CNI plugin for Kubernetes` [.noloc]`Pods` that run on your cluster, by default. For these [.noloc]`Pods`, the IP address is the same as the node's primary IP address, so the [.noloc]`Pod's` IP address isn't translated. For more information about a [.noloc]`Pod's` `hostNetwork` setting, see https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.30/#podspec-v1-core[PodSpec v1 core] in the [.noloc]`Kubernetes` API reference. +^^*^^If a [.noloc]`Pod's` spec contains `hostNetwork=true` (default is `false`), then its IP address isn't translated to a different address. This is the case for the `kube-proxy` and [.noloc]`Amazon VPC CNI plugin for Kubernetes` [.noloc]`Pods` that run on your cluster, by default. For these [.noloc]`Pods`, the IP address is the same as the node's primary IP address, so the [.noloc]`Pod's` IP address isn't translated. For more information about a [.noloc]`Pod's` `hostNetwork` setting, see https://kubernetes.io/docs/reference/generated/kubernetes-api/v{k8s-n}/#podspec-v1-core[PodSpec v1 core] in the [.noloc]`Kubernetes` API reference. diff --git a/latest/ug/nodes/launch-node-bottlerocket.adoc b/latest/ug/nodes/launch-node-bottlerocket.adoc index 6189ca609..3e460cec5 100644 --- a/latest/ug/nodes/launch-node-bottlerocket.adoc +++ b/latest/ug/nodes/launch-node-bottlerocket.adoc @@ -61,7 +61,7 @@ kind: ClusterConfig metadata: name: my-cluster region: region-code - version: '1.30' + version: '{k8s-n}' iam: withOIDC: true diff --git a/latest/ug/nodes/launch-node-ubuntu.adoc b/latest/ug/nodes/launch-node-ubuntu.adoc index 75891fb89..2462ae15f 100644 --- a/latest/ug/nodes/launch-node-ubuntu.adoc +++ b/latest/ug/nodes/launch-node-ubuntu.adoc @@ -53,7 +53,7 @@ kind: ClusterConfig metadata: name: my-cluster region: region-code - version: '1.30' + version: '{k8s-n}' iam: withOIDC: true diff --git a/latest/ug/nodes/migrate-stack.adoc b/latest/ug/nodes/migrate-stack.adoc index 8b12f5237..d187578b3 100644 --- a/latest/ug/nodes/migrate-stack.adoc +++ b/latest/ug/nodes/migrate-stack.adoc @@ -71,7 +71,7 @@ For more available flags and their descriptions, see https://eksctl.io/. ---- eksctl create nodegroup \ --cluster my-cluster \ - --version 1.30 \ + --version {k8s-n} \ --name standard-nodes-new \ --node-type t3.medium \ --nodes 3 \ @@ -176,11 +176,11 @@ kubectl scale deployments/cluster-autoscaler --replicas=0 -n kube-system kubectl taint nodes node_name key=value:NoSchedule ---- + -If you're upgrading your nodes to a new [.noloc]`Kubernetes` version, you can identify and taint all of the nodes of a particular [.noloc]`Kubernetes` version (in this case, `1.28`) with the following code snippet. The version number can't be later than the [.noloc]`Kubernetes` version of your control plane. It also can't be more than two minor versions earlier than the [.noloc]`Kubernetes` version of your control plane. We recommend that you use the same version as your control plane. +If you're upgrading your nodes to a new [.noloc]`Kubernetes` version, you can identify and taint all of the nodes of a particular [.noloc]`Kubernetes` version (in this case, `{k8s-n-2}`) with the following code snippet. The version number can't be later than the [.noloc]`Kubernetes` version of your control plane. It also can't be more than two minor versions earlier than the [.noloc]`Kubernetes` version of your control plane. We recommend that you use the same version as your control plane. + [source,bash,subs="verbatim,attributes"] ---- -K8S_VERSION=1.28 +K8S_VERSION={k8s-n-2} nodes=$(kubectl get nodes -o jsonpath="{.items[?(@.status.nodeInfo.kubeletVersion==\"v$K8S_VERSION\")].metadata.name}") for node in ${nodes[@]} do @@ -215,11 +215,11 @@ kubectl scale deployments/coredns --replicas=2 -n kube-system kubectl drain node_name --ignore-daemonsets --delete-local-data ---- + -If you're upgrading your nodes to a new [.noloc]`Kubernetes` version, identify and drain all of the nodes of a particular [.noloc]`Kubernetes` version (in this case, [.replaceable]`1.28`) with the following code snippet. +If you're upgrading your nodes to a new [.noloc]`Kubernetes` version, identify and drain all of the nodes of a particular [.noloc]`Kubernetes` version (in this case, [.replaceable]`{k8s-n-2}`) with the following code snippet. + [source,bash,subs="verbatim,attributes"] ---- -K8S_VERSION=1.28 +K8S_VERSION={k8s-n-2} nodes=$(kubectl get nodes -o jsonpath="{.items[?(@.status.nodeInfo.kubeletVersion==\"v$K8S_VERSION\")].metadata.name}") for node in ${nodes[@]} do diff --git a/latest/ug/nodes/retrieve-windows-ami-id.adoc b/latest/ug/nodes/retrieve-windows-ami-id.adoc index 78c6779f1..8278553e4 100644 --- a/latest/ug/nodes/retrieve-windows-ami-id.adoc +++ b/latest/ug/nodes/retrieve-windows-ami-id.adoc @@ -35,7 +35,7 @@ Here's an example command after placeholder replacements have been made. [source,bash,subs="verbatim,attributes,quotes"] ---- -aws ssm get-parameter --name /aws/service/ami-windows-latest/Windows_Server-[.replaceable]`2022`-English-[.replaceable]`Core`-EKS_Optimized-[.replaceable]`1.31`/image_id \ +aws ssm get-parameter --name /aws/service/ami-windows-latest/Windows_Server-[.replaceable]`2022`-English-[.replaceable]`Core`-EKS_Optimized-[.replaceable]`k8s-n-2`/image_id \ --region [.replaceable]`us-west-2` --query "Parameter.Value" --output text ---- diff --git a/latest/ug/nodes/self-managed-windows-server-2022.adoc b/latest/ug/nodes/self-managed-windows-server-2022.adoc index a5caafc22..36e6debf7 100644 --- a/latest/ug/nodes/self-managed-windows-server-2022.adoc +++ b/latest/ug/nodes/self-managed-windows-server-2022.adoc @@ -26,7 +26,7 @@ kind: ClusterConfig metadata: name: windows-2022-cluster region: region-code - version: '1.31' + version: '{k8s-n}' nodeGroups: - name: windows-ng diff --git a/latest/ug/nodes/update-managed-node-group.adoc b/latest/ug/nodes/update-managed-node-group.adoc index 50e73e608..8007b9425 100644 --- a/latest/ug/nodes/update-managed-node-group.adoc +++ b/latest/ug/nodes/update-managed-node-group.adoc @@ -61,7 +61,7 @@ NOTE: If you're upgrading a node group that's deployed with a launch template to You can't directly upgrade a node group that's deployed without a launch template to a new launch template version. Instead, you must deploy a new node group using the launch template to update the node group to a new launch template version. -You can upgrade a node group to the same version as the control plane's [.noloc]`Kubernetes` version. For example, if you have a cluster running [.noloc]`Kubernetes` `1.29`, you can upgrade nodes currently running [.noloc]`Kubernetes` `1.28` to version `1.29` with the following command. +You can upgrade a node group to the same version as the control plane's [.noloc]`Kubernetes` version. For example, if you have a cluster running [.noloc]`Kubernetes` `{k8s-n}`, you can upgrade nodes currently running [.noloc]`Kubernetes` `{k8s-n-1}` to version `{k8s-n}` with the following command. [source,bash,subs="verbatim,attributes"] ---- @@ -69,7 +69,7 @@ eksctl upgrade nodegroup \ --name=node-group-name \ --cluster=my-cluster \ --region=region-code \ - --kubernetes-version=1.29 + --kubernetes-version={k8s-n} ---- == {aws-management-console} [[console_update_managed_nodegroup]] diff --git a/latest/ug/nodes/update-stack.adoc b/latest/ug/nodes/update-stack.adoc index b304f3b5e..efdc44a4b 100644 --- a/latest/ug/nodes/update-stack.adoc +++ b/latest/ug/nodes/update-stack.adoc @@ -75,14 +75,14 @@ https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2022-12-23/amazon-e NOTE: The supported instance types for the latest version of the https://github.com/aws/amazon-vpc-cni-k8s[Amazon VPC CNI plugin for Kubernetes] are shown in https://github.com/aws/amazon-vpc-cni-k8s/blob/master/pkg/vpc/vpc_ip_resource_limit.go[vpc_ip_resource_limit.go] on [.noloc]`GitHub`. You might need to update your [.noloc]`Amazon VPC CNI plugin for Kubernetes` version to use the latest supported instance types. For more information, see <>. + IMPORTANT: Some instance types might not be available in all {aws} Regions. -** *NodeImageIdSSMParam* – The Amazon EC2 Systems Manager parameter of the AMI ID that you want to update to. The following value uses the latest Amazon EKS optimized AMI for [.noloc]`Kubernetes` version `1.30`. +** *NodeImageIdSSMParam* – The Amazon EC2 Systems Manager parameter of the AMI ID that you want to update to. The following value uses the latest Amazon EKS optimized AMI for [.noloc]`Kubernetes` version `{k8s-n}`. + [source,none,subs="verbatim,attributes"] ---- -/aws/service/eks/optimized-ami/1.30/amazon-linux-2/recommended/image_id +/aws/service/eks/optimized-ami/{k8s-n}/amazon-linux-2/recommended/image_id ---- + -You can replace [.replaceable]`1.30` with a <> that's the same. Or, it should be up to one version earlier than the [.noloc]`Kubernetes` version running on your control plane. We recommend that you keep your nodes at the same version as your control plane. You can also replace [.replaceable]`amazon-linux-2` with a different AMI type. For more information, see <>. +You can replace [.replaceable]`{k8s-n}` with a <> that's the same. Or, it should be up to one version earlier than the [.noloc]`Kubernetes` version running on your control plane. We recommend that you keep your nodes at the same version as your control plane. You can also replace [.replaceable]`amazon-linux-2` with a different AMI type. For more information, see <>. + NOTE: Using the Amazon EC2 Systems Manager parameter enables you to update your nodes in the future without having to look up and specify an AMI ID. If your {aws} CloudFormation stack is using this value, any stack update always launches the latest recommended Amazon EKS optimized AMI for your specified [.noloc]`Kubernetes` version. This is even the case even if you don't change any values in the template. ** *NodeImageId* – To use your own custom AMI, enter the ID for the AMI to use. diff --git a/latest/ug/workloads/creating-an-add-on.adoc b/latest/ug/workloads/creating-an-add-on.adoc index 8b1b3cae7..6d3967cc3 100644 --- a/latest/ug/workloads/creating-an-add-on.adoc +++ b/latest/ug/workloads/creating-an-add-on.adoc @@ -43,11 +43,11 @@ You can create an Amazon EKS add-on using `eksctl`, the {aws-management-console} == Create add-on (eksctl) -. View the names of add-ons available for a cluster version. Replace [.replaceable]`1.30` with the version of your cluster. +. View the names of add-ons available for a cluster version. Replace [.replaceable]`{k8s-n}` with the version of your cluster. + [source,bash,subs="verbatim,attributes"] ---- -eksctl utils describe-addon-versions --kubernetes-version 1.30 | grep AddonName +eksctl utils describe-addon-versions --kubernetes-version {k8s-n} | grep AddonName ---- + An example output is as follows. @@ -65,11 +65,11 @@ An example output is as follows. "AddonName": "factorhouse_kpow", [...] ---- -. View the versions available for the add-on that you would like to create. Replace [.replaceable]`1.30` with the version of your cluster. Replace [.replaceable]`name-of-addon` with the name of the add-on you want to view the versions for. The name must be one of the names returned in the previous step. +. View the versions available for the add-on that you would like to create. Replace [.replaceable]`{k8s-n}` with the version of your cluster. Replace [.replaceable]`name-of-addon` with the name of the add-on you want to view the versions for. The name must be one of the names returned in the previous step. + [source,bash,subs="verbatim,attributes"] ---- -eksctl utils describe-addon-versions --kubernetes-version 1.30 --name name-of-addon | grep AddonVersion +eksctl utils describe-addon-versions --kubernetes-version {k8s-n} --name name-of-addon | grep AddonVersion ---- + The following output is an example of what is returned for the add-on named `vpc-cni`. You can see that the add-on has several available versions. @@ -86,7 +86,7 @@ The following output is an example of what is returned for the add-on named `vpc + [source,bash,subs="verbatim,attributes"] ---- -eksctl utils describe-addon-versions --kubernetes-version 1.30 --name name-of-addon | grep ProductUrl +eksctl utils describe-addon-versions --kubernetes-version {k8s-n} --name name-of-addon | grep ProductUrl ---- + If no output is returned, then the add-on is an Amazon EKS. If output is returned, then the add-on is an {aws} Marketplace add-on. The following output is for an add-on named `teleport_teleport`. @@ -167,11 +167,11 @@ Retaining the default role name enables EKS to pre-select the role for add-ons i == Create add-on ({aws} CLI) . You need version `2.12.3` or later or version `1.27.160` or later of the {aws} Command Line Interface ({aws} CLI) installed and configured on your device or {aws} CloudShell. To check your current version, use `aws --version | cut -d / -f2 | cut -d ' ' -f1`. Package managers such `yum`, `apt-get`, or [.noloc]`Homebrew` for [.noloc]`macOS` are often several versions behind the latest version of the {aws} CLI. To install the latest version, see link:cli/latest/userguide/cli-chap-install.html[Installing, updating, and uninstalling the {aws} CLI,type="documentation"] and link:cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config[Quick configuration with aws configure,type="documentation"] in the _{aws} Command Line Interface User Guide_. The {aws} CLI version that is installed in {aws} CloudShell might also be several versions behind the latest version. To update it, see link:cloudshell/latest/userguide/vm-specs.html#install-cli-software[Installing {aws} CLI to your home directory,type="documentation"] in the _{aws} CloudShell User Guide_. + -. Determine which add-ons are available. You can see all available add-ons, their type, and their publisher. You can also see the URL for add-ons that are available through the {aws} Marketplace. Replace [.replaceable]`1.30` with the version of your cluster. +. Determine which add-ons are available. You can see all available add-ons, their type, and their publisher. You can also see the URL for add-ons that are available through the {aws} Marketplace. Replace [.replaceable]`{k8s-n}` with the version of your cluster. + [source,bash,subs="verbatim,attributes"] ---- -aws eks describe-addon-versions --kubernetes-version 1.30 \ +aws eks describe-addon-versions --kubernetes-version {k8s-n} \ --query 'addons[].{MarketplaceProductUrl: marketplaceInformation.productUrl, Name: addonName, Owner: owner Publisher: publisher, Type: type}' --output table ---- + @@ -198,11 +198,11 @@ An example output is as follows. ---- + Your output might be different. In this example output, there are three different add-ons available of type `networking` and five add-ons with a publisher of type `eks`. The add-ons with `aws-marketplace` in the `Owner` column may require a subscription before you can install them. You can visit the URL to learn more about the add-on and to subscribe to it. -. You can see which versions are available for each add-on. Replace [.replaceable]`1.30` with the version of your cluster and replace [.replaceable]`vpc-cni` with the name of an add-on returned in the previous step. +. You can see which versions are available for each add-on. Replace [.replaceable]`{k8s-n}` with the version of your cluster and replace [.replaceable]`vpc-cni` with the name of an add-on returned in the previous step. + [source,bash,subs="verbatim,attributes"] ---- -aws eks describe-addon-versions --kubernetes-version 1.30 --addon-name vpc-cni \ +aws eks describe-addon-versions --kubernetes-version {k8s-n} --addon-name vpc-cni \ --query 'addons[].addonVersions[].{Version: addonVersion, Defaultversion: compatibilities[0].defaultVersion}' --output table ---- + diff --git a/latest/ug/workloads/updating-an-add-on.adoc b/latest/ug/workloads/updating-an-add-on.adoc index 5bdcd8c48..ad0b4541b 100644 --- a/latest/ug/workloads/updating-an-add-on.adoc +++ b/latest/ug/workloads/updating-an-add-on.adoc @@ -150,11 +150,11 @@ An example output is as follows. ---- v1.10.4-eksbuild.1 ---- -. Determine which versions of the add-on are available for your cluster's version. Replace [.replaceable]`1.30` with your cluster's version and [.replaceable]`vpc-cni` with the name of the add-on that you want to update. +. Determine which versions of the add-on are available for your cluster's version. Replace [.replaceable]`{k8s-n}` with your cluster's version and [.replaceable]`vpc-cni` with the name of the add-on that you want to update. + [source,bash,subs="verbatim,attributes"] ---- -aws eks describe-addon-versions --kubernetes-version 1.30 --addon-name vpc-cni \ +aws eks describe-addon-versions --kubernetes-version {k8s-n} --addon-name vpc-cni \ --query 'addons[].addonVersions[].{Version: addonVersion, Defaultversion: compatibilities[0].defaultVersion}' --output table ---- +