Add auto mode recommendations (#640)

* add auto mode recommendations

* Add FAQ section to AutoMode page

* Adding auto mode session on recommendation vpc-cni (#1)

* Adding auto mode session on recommendation vpc-cni

* Adding auto mode into loadbalancing section.

* minor cleanup of auto mode documentation in networking docs

* add auto-mode tips to the upgrades section

* Add advice on leaning on AWS support for troubleshooting auto mode components

* chore: style updates from Codium AI agent

* fixup for docs platform

---------

Co-authored-by: Yunjian Lu <[email protected]>
Co-authored-by: Geoffrey Cline <[email protected]>

Author: 3 people

Diff for: .prettierignore

@@ -0,0 +1 @@
+**

Diff for: content/index.md

@@ -18,7 +18,7 @@ We currently have published guides for the following topics:
 
 * [Best Practices for Security](security/docs/)
 * [Best Practices for Reliability](reliability/docs/)
-* Best Practices for Cluster Autoscaling: [karpenter](karpenter/), [cluster-autoscaler](cluster-autoscaling/)
+* Best Practices for Cluster Autoscaling: [karpenter](karpenter/), [cluster-autoscaler](cluster-autoscaling/), [EKS Auto Mode](auto-mode/)
 * [Best Practices for Networking](networking/index/)
 * [Best Practices for Scalability](scalability/docs/)
 * [Best Practices for Cluster Upgrades](upgrades/)

Diff for: latest/bpg/autoscaling/auto-mode.adoc

@@ -0,0 +1,122 @@
+[."topic"]
+[[automode,automode.title]]
+= EKS Auto Mode
+:info_doctype: section
+:info_title: EKS Auto Mode
+:info_abstract: EKS Auto Mode
+:info_titleabbrev: EKS Auto Mode
+:imagesdir: images/autoscaling
+
+
+Amazon EKS Auto Mode represents a significant evolution in Kubernetes infrastructure management, combining secure and scalable cluster infrastructure with integrated Kubernetes capabilities managed by AWS . The service provides fully-managed worker node operations, eliminating the need for customers to set up Managed Node Groups or AutoScaling groups . 
+
+The key architectural difference is that EKS Auto Mode uses a Karpenter-based system that automatically provisions EC2 instances in response to pod requests . These instances run on Bottlerocket AMIs with pre-installed add-ons like EBS CSI drivers, making the infrastructure truly managed by AWS . In contrast to traditional scaling methods:
+
+* Traditional Cluster Autoscaler (CAS) requires manual node group management and can only create nodes with a single instance type per node group 
+* Self-managed Karpenter offers more flexibility by working with EC2 Fleet API and can provision different instance types, but requires customer management 
+* EKS Auto Mode handles all scaling operations automatically through managed NodePools and NodeClasses
+
+
+The new system introduces several operational improvements:
+
+* Automatic pod-driven scaling without manual node group configuration 
+* Built-in managed load balancer controllers that automatically create ALB/NLB based on Ingress resources 
+* Integrated security features with pre-configured Pod identity 
+* Maximum node runtime of 21 days with automatic replacement
+
+
+From a cost perspective, EKS Auto Mode maintains standard EC2 pricing while adding a management fee only for Auto Mode-managed nodes. Importantly, customers can still mix Auto Mode managed nodes with self-managed nodes in the same cluster . 
+
+While AWS handles most operational aspects, customers retain responsibility for https://docs.aws.amazon.com/eks/latest/userguide/update-cluster.html[cluster version management] and can perform controlled upgrades that trigger rolling updates of worker nodes . 
+
+== Reasons to use Auto Mode
+
+Auto Mode is geared towards users that want the benefits of Kubernetes and EKS but need to minimize operational burden around Kubernetes like upgrades and installation/maintenance of critical platform pieces like auto-scaling, load balancing, and storage.  Auto Mode takes EKS a step further in the minimization of the undifferentiated heavy lifting that goes along with Kubernetes maintenance
+
+
+== FAQ
+
+=== What is the difference between EKS Auto Mode and Open Source Karpenter?
+
+EKS Auto Mode is a large suite of features that make running production-grade 
+Kubernetes simple.  One of these features is the auto-scaling benefits of Karpenter, 
+fully managed.  From an operations standpoint, the only difference is in EKS
+Auto Mode you do not need to manage the deployment, scaling, and upgrade of
+the Karpenter pods themselves.  All other operations, like managed NodeClasses
+and NodePools works the same as with open source Karpenter.
+
+=== Can I run managed node groups alongside Auto Mode-managed nodes?
+
+Yes, you may run static nodes via a managed node groups alongside your autoscaling nodes provided with Auto Mode
+
+=== Can I migrate a cluster from standard EKS to EKS Auto Mode?
+
+Yes, instructions to enable EKS Auto Mode on an existing cluster can be found
+in the official https://docs.aws.amazon.com/eks/latest/userguide/auto-enable-existing.html[AWS Documentation]
+
+Things to note:
+1. After enabling Auto Mode, you'll want to uninstall any components you had installed that are now managed by Auto Mode, like Karpenter or the AWS Load Balancer Controller
+2. You need to make sure your installed add-ons are up-to-date.  See documentation.
+
+=== How do I configure NodePools in EKS Auto Mode?
+
+A new cluster will come pre-configured with two NodePools
+
+==== general-purpose
+
+image:gp_nodepool.png[General Purpose NodePool]
+
+This NodePool instructs Karpenter to launch nodes with the following characteristics:
+
+1. Capacity Type of “On Demand”
+2. Instance Types of C, M, or R
+3. Instance Generation of 4
+4. AMD architecture
+5. Linux OS
+
+
+It also defines what the scale down logic is by declaring that only 10% of all nodes may be in a disrupted state at any given time and that consolidation should only occur when nodes are empty or underutilized.
+
+
+==== system
+
+image:system_nodepool.png[System NodePool]
+
+
+This NodePool is similar to “general-purpose” except for the following differences:
+
+1. It allows for nodes with the ARM architecture as well as AMD architecture
+2. It taints these nodes with a NoSchedule unless there’s a toleration for “CriticalAddonsOnly”.  This is for internal use by EKS add-ons
+
+==== custom
+
+You may create your own custom NodePools depending on your needs.  To learn more about 
+NodePools please consult the https://karpenter.sh/docs/concepts/nodepools/[Karpenter Documentation].
+
+=== Can I customize the AMI used by Auto Mode when new nodes are launched?
+
+No, currently the only supported AMIs are for Amazon-provided Bottlerocket
+
+=== How can I install custom tooling or agents on my Kubernetes hosts? ===
+
+Because AMI customization is not supported, if you have a need for host-level software for things like security scanning you should 
+be deploying the workload as a Kubernetes https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/[DaemonSet].
+
+=== What components are running in my cluster data plane when I provision a new EKS Auto Mode cluster?
+
+By default, the only pods running in an EKS Auto Mode cluster are Kubernetes Metrics Server pods.  The other components of EKS Auto Mode
+like Karpenter, the AWS Load Balancer Controller, and the EBS CSI Driver are all running and managed off-cluster.
+
+=== What managed components are running to support my new EKS Auto Mode cluster?
+
+EKS Auto Mode completely automates the deployment most of the pieces of a data plane needed for production-grade Kubernetes.  This includes:
+
+* Karpenter, for auto-scaling the compute of your cluster
+* AWS Load Balancer Controller to allow you to easily expose Kubernetes services via automated Elastic Load Balancer integration
+* EBS CSI
+* VPC CNI
+* EKS Pod Identity Agent
+
+=== How do I troubleshoot the components of Auto Mode that used to run as pods in my cluster? ===
+
+With EKS Auto Mode, many of the components like the AWS Load Balancer Controller and Karpenter are managed for you outside of your cluster, therefore you won't have the same visibility into the logs that you are used to when self-managing.  If you are in a situation where you need to troubleshoot the functionality of a piece of Auto Mode functionality create an AWS Support Ticket.

Diff for: latest/bpg/autoscaling/index.adoc

@@ -26,3 +26,5 @@ include::karpenter.adoc[leveloffset=+1]
 
 include::cluster-autoscaler.adoc[leveloffset=+1]
 
+include::auto-mode.adoc[leveloffset=+1]
+

Diff for: latest/bpg/images/autoscaling/gp_nodepool.png

@@ -33,6 +33,7 @@ We currently have published guides for the following topics:
 * xref:reliability[Best Practices for Reliability]
 * xref:karpenter[Best Practices for Cluster Autoscaling: Karpenter]
 * xref:cas[Best Practices for Cluster Autoscaling: cluster-autoscaler]
+* xref:automode[Best Practices for Cluster Autoscaling: EKS Auto Mode]
 * xref:networking[Best Practices for Networking]
 * xref:scalability[Best Practices for Scalability]
 * xref:cluster-upgrades[Best Practices for Cluster Upgrades]

Diff for: latest/bpg/images/autoscaling/system_nodepool.png

@@ -102,6 +102,9 @@ The AWS Load Balancer Controller (LBC) has to be installed in the EKS
 clusters and provisions AWS load balancers that point to cluster Service
 or Ingress resources.
 
+If you are utilizing link: https://docs.aws.amazon.com/eks/latest/userguide/automode.html[EKS Auto Mode]
+the AWS Load Balancer is provided for you automatically; no installation necessary.
+
 In order for the LBC to manage the reconciliation of Kubernetes Service
 resources of type LoadBalancer, you need to offload the reconciliation
 from the in-tree controller to the LBC, explicitly. With

Diff for: latest/bpg/index.adoc

@@ -102,6 +102,10 @@ image::cni_image-5.png[illustration of multiple ENIs attached to a node]
 
 == Recommendations
 
+=== Deploy EKS cluster with Auto Mode
+
+When you use EKS Auto Mode to create a cluster, AWS manages the VPC Container Network Interface (CNI) configuration for your cluster. With Amazon EKS Auto Mode, you don’t need to install or upgrade networking add-ons. However, ensure your workloads are compatible with the managed VPC CNI configuration.
+
 === Deploy VPC CNI Managed Add-On
 
 When you provision a cluster, Amazon EKS installs VPC CNI automatically. Amazon EKS nevertheless supports managed add-ons that enable the cluster to interact with underlying AWS resources such as computing, storage, and networking. We highly recommend that you deploy clusters with managed add-ons including VPC CNI.

Diff for: latest/bpg/networking/loadbalancing.adoc

@@ -181,7 +181,10 @@ controllers, as required.
 kubectl.]
 . https://docs.aws.amazon.com/eks/latest/userguide/update-managed-node-group.html[Upgrade
 the cluster data plane.] Upgrade your nodes to the same Kubernetes minor
-version as your upgraded cluster.
+version as your upgraded cluster.  
+
+TIP: If your cluster was created using EKS Auto Mode you do not need to upgrade your cluster data plane. After upgrading your control plane, EKS Auto Mode will begin incrementally updating managed nodes while respecting all pod disruption budgets. Ensure to monitor these updates to verify compliance with your operational requirements.
+
 
 [[usedocs, usedocs.title]]
 == Use the EKS Documentation to create an upgrade checklist
@@ -275,6 +278,8 @@ Kubernetes minor version.
 * *Karpenter:* For installation and upgrade information, see the
 https://karpenter.sh/docs/upgrading/[Karpenter documentation.]
 
+TIP: You do not have to manually upgrade any of the capabilities of Amazon EKS Auto Mode, including the compute autoscaling, block storage, and load balancing capabilities.
+
 == Verify basic EKS requirements before upgrading
 
 AWS requires certain resources in your account to complete the upgrade