Describe how to create a cluster without node pools

latest/ug/automode/create-node-class.adoc

@@ -45,6 +45,60 @@ kubectl apply -f nodeclass.yaml
 
 Next, reference the Node Class in your Node Pool configuration. For more information, see <<create-node-pool>>.
 
+[#auto-node-access-entry]
+== Create node class access entry
+
+If you create a custom node class, you need to create an EKS Access Entry to permit the nodes to join the cluster. EKS automatically creates access entries when you use the built-in node class and node pools. 
+
+For information about how Access Entries work, see <<access-entries>>.
+
+When creating access entries for EKS Auto Mode node classes, you need to use the `EC2` access entry type. 
+
+=== Create access entry with CLI
+
+*To create an access entry for EC2 nodes and associate the EKS Auto Node Policy:*
+
+Update the following CLI commands with your cluster name, and node role ARN. The node role ARN is specified in the node class YAML. 
+
+[source,bash]
+----
+# Create the access entry for EC2 nodes
+aws eks create-access-entry \
+  --cluster-name <cluster-name> \
+  --principal-arn <node-role-arn> \
+  --type EC2
+
+# Associate the auto node policy
+aws eks associate-access-policy \
+  --cluster-name <cluster-name> \
+  --principal-arn <node-role-arn> \
+  --policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSAutoNodePolicy \
+  --access-scope cluster
+----
+
+=== Create access entry with CloudFormation
+
+*To create an access entry for EC2 nodes and associate the EKS Auto Node Policy:*
+
+Update the following CloudFormation with your cluster name, and node role ARN. The node role ARN is specified in the node class YAML. 
+
+[source,yaml]
+----
+EKSAutoNodeRoleAccessEntry:
+  Type: AWS::EKS::AccessEntry
+  Properties:
+    ClusterName: <cluster-name>
+    PrincipalArn: <node-role-arn>
+    Type: "EC2"
+    AccessPolicies:
+      - AccessScope:
+          Type: cluster
+        PolicyArn: arn:aws:eks::aws:cluster-access-policy/AmazonEKSAutoNodePolicy
+  DependsOn: [ <cluster-name> ] # previously defined in CloudFormation
+----
+
+For information about deploying CloudFormation stacks, see link:AWSCloudFormation/latest/UserGuide/GettingStarted.html["Getting started with CloudFormation", type="documentation"]
+
 == Node Class Specification 
 
 [source,yaml]
@@ -88,6 +142,11 @@ spec:
     size: "80Gi"    # Range: 1-59000Gi or 1-64000G or 1-58Ti or 1-64T
     iops: 3000      # Range: 3000-16000
     throughput: 125 # Range: 125-1000
+
+  # IAM role to use for EC2 instance role
+  # If unspecified, EKS will create a role
+  # If specified, role requires access entry described above
+  role: arn:aws:iam::123456789012:role/MyNodeRole  
 
   # Optional: Additional EC2 tags
   tags:

latest/ug/automode/create-node-pool.adoc

@@ -178,6 +178,34 @@ spec:
 ** `node.kubernetes.io/windows-build`
 ** `kubernetes.io/os`
 
+== Disable built-in node pools
+
+If you create custom node pools, you can disable the built-in node pools. For more information, see <<set-builtin-node-pools>>.
+
+== Cluster without built-in node pools
+
+You can create a cluster without the built-in node pools. This is helpful when your organization has created customized node pools. 
+
+*Overview:*
+
+. Create an EKS cluster with the both `nodePools` and `nodeRoleArn` values empty.
+** Sample eksctl `autoModeConfig`:
++
+[source,yaml]
+----
+autoModeConfig:
+  enabled: true
+  nodePools: []
+  # Do not set a nodeRoleARN
+----
++
+For more information, see <<automode-get-started-eksctl>>
+. Create a custom node class with a node role ARN
+** For more information, see <<create-node-class>>
+. Create an access entry for the custom node class
+** For more information, see <<auto-node-access-entry>>
+. Create a custom node pool, as described above.
+
 == Disruption
 
 You can configure EKS Auto Mode to disrupt Nodes through your NodePool in multiple ways. You can use `spec.disruption.consolidationPolicy`, `spec.disruption.consolidateAfter`, or `spec.template.spec.expireAfter`. You can also rate limit EKS Auto Mode's disruption through the NodePool’s `spec.disruption.budgets`. You can also control the time windows and number of simultaneous Nodes disrupted. For instructions on configuring this behavior, see https://karpenter.sh/docs/concepts/disruption/[Disruption] in the Karpenter Documentation. 

latest/ug/automode/set-builtin-node-pools.adoc

@@ -23,12 +23,14 @@ Both built-in NodePools:
 * Use the C, M, and R EC2 instance families
 * Require generation 5 or newer EC2 instances
 
-## Prerequisites
+== Procedure
+
+=== Prerequisites
 
 * The latest version of the {aws} Command Line Interface ({aws} CLI) installed and configured on your device. To check your current version, use `aws --version`. To install the latest version, see link:cli/latest/userguide/getting-started-install.html["Installing",type="documentation"] and link:cli/latest/userguide/cli-chap-configure.html#cli-configure-quickstart-config["Quick configuration",type="documentation"] with aws configure in the {aws} Command Line Interface User Guide.
 ** Login to the CLI with sufficent IAM permissions to create {aws} resources including IAM Policies, IAM Roles, and EKS Clusters. 
 
-== Enable with {aws} CLI
+=== Enable with {aws} CLI
 
 Use the following command to enable both built-in NodePools:
 
@@ -45,7 +47,7 @@ aws eks update-cluster-config \
 
 You can modify the command to selectively enable the NodePools. 
 
-== Disable with {aws} CLI 
+=== Disable with {aws} CLI 
 
 Use the following command to disable both built-in NodePools:
 
@@ -55,3 +57,4 @@ aws eks update-cluster-config \
   --name <cluster-name> \
   --compute-config '{"nodePools": []}'
 ----
+

latest/ug/manage-access/k8s-access/access-entries.adoc

@@ -142,9 +142,15 @@ Before creating access entries, consider the following:
 ** If the type of the access entry is anything other than `STANDARD` (see next consideration about types), the ARN must be in the same {aws} account that your cluster is in. If the type is `STANDARD`, the ARN can be in the same, or different, {aws} account than the account that your cluster is in.
 ** You can't change the IAM principal after the access entry is created.
 ** If you ever delete the IAM principal with this ARN, the access entry isn't automatically deleted. We recommend that you delete the access entry with an ARN for an IAM principal that you delete. If you don't delete the access entry and ever recreate the IAM principal, even if it has the same ARN, the access entry won't work. This is because even though the ARN is the same for the recreated IAM principal, the `roleID` or `userID` (you can see this with the `aws sts get-caller-identity` {aws} CLI command) is different for the recreated IAM principal than it was for the original IAM principal. Even though you don't see the IAM principal's `roleID` or `userID` for an access entry, Amazon EKS stores it with the access entry.
-* Each access entry has a _type_. You can specify `EC2_LINUX` (for an IAM role used with Linux or Bottlerocket self-managed nodes), `EC2_Windows` (for an IAM role used with Windows self-managed nodes), `FARGATE_LINUX` (for an IAM role used with {aws} Fargate (Fargate)), `HYBRID_LINUX` (for an IAM role used with hybrid nodes) or `STANDARD` as a type. If you don't specify a type, Amazon EKS automatically sets the type to `STANDARD`. It's unnecessary to create an access entry for an IAM role that's used for a managed node group or a Fargate profile. EKS will create access entries (if enabled), or update the auth config map (if access entries are unavailable).
-+
-You can't change the type after the access entry is created.
+* Each access entry has a _type_. If you don't specify a type, Amazon EKS automatically sets the type to `STANDARD`
+** `EC2_LINUX` - For an IAM role used with Linux or Bottlerocket self-managed nodes
+** `EC2_WINDOWS` - For an IAM role used with Windows self-managed nodes
+** `FARGATE_LINUX` - For an IAM role used with {aws} Fargate (Fargate)
+** `HYBRID_LINUX` - For an IAM role used with hybrid nodes
+** `STANDARD` - Default type if none specified
+** `EC2` - For EKS Auto Mode custom node classes. For more information, see <<auto-node-access-entry>>. 
+** You can't change the type after the access entry is created.
+* It's unnecessary to create an access entry for an IAM role that's used for a managed node group or a Fargate profile. EKS will create access entries (if enabled), or update the auth config map (if access entries are unavailable)
 * If the type of the access entry is `STANDARD`, you can specify a _username_ for the access entry. If you don't specify a value for username, Amazon EKS sets one of the following values for you, depending on the type of the access entry and whether the IAM principal that you specified is an IAM role or IAM user. Unless you have a specific reason for specifying your own username, we recommend that don't specify one and let Amazon EKS auto-generate it for you. If you specify your own username:
 +
 ** It can't start with `system:`, `eks:`, `aws:`, `amazon:`, or `iam:`.