AWS eks documentation change
Summary
Restructured documentation for static capacity node pools with updated sections, constraints, best practices, troubleshooting, and examples. Added details about capacity reservations and operational behaviors.
Security assessment
The changes primarily focus on documentation restructuring, operational constraints, and configuration examples. While there is a new example showing security group selector terms (`securityGroupSelectorTerms`), this is part of normal EC2 configuration rather than addressing a specific security vulnerability or introducing new security features. No security advisories, vulnerability mitigations, or explicit security controls are added.
Diff
diff --git a/eks/latest/userguide/auto-static-capacity.md b/eks/latest/userguide/auto-static-capacity.md index 4291b8022..fa177e2c0 100644 --- a//eks/latest/userguide/auto-static-capacity.md +++ b//eks/latest/userguide/auto-static-capacity.md @@ -5 +5 @@ -Basic exampleConfigure a static-capacity node poolStatic-capacity node pool constraintsScale a static-capacity node poolMonitor static-capacity node poolsExample configurationsBest practicesTroubleshooting +Configure a static capacity node poolStatic capacity node pool considerationsBest practicesScale a static capacity node poolMonitor static capacity node poolsTroubleshootingExamples @@ -11 +11 @@ To contribute to this user guide, choose the **Edit this page on GitHub** link t -# Static-Capacity Node Pools in EKS Auto Mode +# Static Capacity Node Pools in EKS Auto Mode @@ -13 +13 @@ To contribute to this user guide, choose the **Edit this page on GitHub** link t -Amazon EKS Auto Mode supports static-capacity node pools that maintain a fixed number of nodes regardless of pod demand. Static-capacity node pools are useful for workloads that require predictable capacity, reserved instances, or specific compliance requirements where you need to maintain a consistent infrastructure footprint. +Amazon EKS Auto Mode supports static capacity node pools that maintain a fixed number of nodes regardless of pod demand. Static capacity node pools are useful for workloads that require predictable capacity, reserved instances, or specific compliance requirements where you need to maintain a consistent infrastructure footprint. @@ -15 +15 @@ Amazon EKS Auto Mode supports static-capacity node pools that maintain a fixed n -Unlike dynamic node pools that scale based on pod scheduling demands, static-capacity node pools maintain the number of nodes that you have configured. +Unlike dynamic node pools that scale based on pod scheduling demands, static capacity node pools maintain the number of nodes that you have configured. @@ -17 +17 @@ Unlike dynamic node pools that scale based on pod scheduling demands, static-cap -## Basic example +## Configure a static capacity node pool @@ -19 +19 @@ Unlike dynamic node pools that scale based on pod scheduling demands, static-cap -Here’s a simple static-capacity node pool that maintains 5 nodes: +To create a static capacity node pool, set the `replicas` field in your NodePool specification. The `replicas` field defines the exact number of nodes that the node pool will maintain. See Examples for how to configure `replicas`. @@ -20,0 +21 @@ Here’s a simple static-capacity node pool that maintains 5 nodes: +## Static capacity node pool considerations @@ -22,6 +23 @@ Here’s a simple static-capacity node pool that maintains 5 nodes: - apiVersion: karpenter.sh/v1 - kind: NodePool - metadata: - name: my-static-nodepool - spec: - replicas: 5 # Maintain exactly 5 nodes +Static capacity node pools have several important constraints and behaviors: @@ -29,6 +25 @@ Here’s a simple static-capacity node pool that maintains 5 nodes: - template: - spec: - nodeClassRef: - group: eks.amazonaws.com - kind: NodeClass - name: default +**Configuration constraints:** @@ -36,7 +27 @@ Here’s a simple static-capacity node pool that maintains 5 nodes: - requirements: - - key: "eks.amazonaws.com/instance-category" - operator: In - values: ["m", "c"] - - key: "topology.kubernetes.io/zone" - operator: In - values: ["us-west-2a", "us-west-2b"] + * **Cannot switch modes** : Once you set `replicas` on a node pool, you cannot remove it. The node pool cannot switch between static and dynamic modes. @@ -44,2 +29 @@ Here’s a simple static-capacity node pool that maintains 5 nodes: - limits: - nodes: 8 + * **Limited resource limits** : Only the `limits.nodes` field is supported in the limits section. CPU and memory limits are not applicable. @@ -47 +31 @@ Here’s a simple static-capacity node pool that maintains 5 nodes: -## Configure a static-capacity node pool + * **No weight field** : The `weight` field cannot be set on static capacity node pools since node selection is not based on priority. @@ -49 +32,0 @@ Here’s a simple static-capacity node pool that maintains 5 nodes: -To create a static-capacity node pool, set the `replicas` field in your NodePool specification. The `replicas` field defines the exact number of nodes that the node pool will maintain. @@ -51 +33,0 @@ To create a static-capacity node pool, set the `replicas` field in your NodePool -## Static-capacity node pool constraints @@ -53 +34,0 @@ To create a static-capacity node pool, set the `replicas` field in your NodePool -Static-capacity node pools have several important constraints and behaviors: @@ -55 +36 @@ Static-capacity node pools have several important constraints and behaviors: -**Configuration constraints:** +**Operational behavior:** @@ -57 +38 @@ Static-capacity node pools have several important constraints and behaviors: - * **Cannot switch modes** : Once you set `replicas` on a node pool, you cannot remove it. The node pool cannot switch between static and dynamic modes. + * **No consolidation** : Nodes in static capacity pools are not considered for consolidation. @@ -59 +40 @@ Static-capacity node pools have several important constraints and behaviors: - * **Limited resource limits** : Only the `limits.nodes` field is supported in the limits section. CPU and memory limits are not applicable. + * **Scaling operations** : Scale operations bypass node disruption budgets but still respect PodDisruptionBudgets. @@ -61 +42 @@ Static-capacity node pools have several important constraints and behaviors: - * **No weight field** : The `weight` field cannot be set on static-capacity node pools since node selection is not based on priority. + * **Node replacement** : Nodes are still replaced for drift (such as AMI updates) and expiration based on your configuration. @@ -66 +47 @@ Static-capacity node pools have several important constraints and behaviors: -**Operational behavior:** +## Best practices @@ -68 +49 @@ Static-capacity node pools have several important constraints and behaviors: - * **No consolidation** : Nodes in static-capacity pools are not considered for consolidation based on utilization. +**Capacity planning:** @@ -70 +51,12 @@ Static-capacity node pools have several important constraints and behaviors: - * **Scaling operations** : Scale operations bypass node disruption budgets but still respect PodDisruptionBudgets. + * Set `limits.nodes` higher than `replicas` to allow for temporary scaling during node replacement operations. + + * Consider the maximum capacity needed during node drift or AMI updates when setting limits. + + + + +**Instance selection:** + + * Use specific instance types when you have Reserved Instances or specific hardware requirements. + + * Avoid overly restrictive requirements that might limit instance availability during scaling. @@ -72 +63,0 @@ Static-capacity node pools have several important constraints and behaviors: - * **Node replacement** : Nodes are still replaced for drift (such as AMI updates) and expiration based on your configuration. @@ -75,0 +67,5 @@ Static-capacity node pools have several important constraints and behaviors: +**Disruption management:** + + * Configure appropriate disruption budgets to balance availability with maintenance operations. + + * Consider your application’s tolerance for node replacement when setting budget percentages. @@ -77 +72,0 @@ Static-capacity node pools have several important constraints and behaviors: -## Scale a static-capacity node pool @@ -79 +74,27 @@ Static-capacity node pools have several important constraints and behaviors: -You can change the number of replicas in a static-capacity node pool using the `kubectl scale` command: + + +**Monitoring:** + + * Regularly monitor the `status.nodes` field to ensure your desired capacity is maintained. + + * Set up alerts for when the actual node count deviates from the desired replicas. + + + + +**Zone distribution:** + + * For high availability, spread static capacity across multiple Availability Zones. + + * When you create a static capacity node pool that spans multiple availability zones, EKS Auto Mode distributes the nodes across the specified zones, but the distribution is not guaranteed to be even. + + * For predictable and even distribution across availability zones, create separate static capacity node pools, each pinned to a specific availability zone using the `topology.kubernetes.io/zone` requirement. + + * If you need 12 nodes evenly distributed across three zones, create three node pools with 4 replicas each, rather than one node pool with 12 replicas across three zones. + + + + +## Scale a static capacity node pool + +You can change the number of replicas in a static capacity node pool using the `kubectl scale` command: @@ -87 +108 @@ When scaling down, EKS Auto Mode will terminate nodes gracefully, respecting Pod -## Monitor static-capacity node pools +## Monitor static capacity node pools @@ -89 +110 @@ When scaling down, EKS Auto Mode will terminate nodes gracefully, respecting Pod -Use the following commands to monitor your static-capacity node pools: +Use the following commands to monitor your static capacity node pools: @@ -103 +124,32 @@ The `status.nodes` field shows the current number of nodes managed by the node p -## Example configurations +## Troubleshooting + +**Nodes not reaching desired replicas:** + + * Check if the `limits.nodes` value is sufficient + + * Verify that your requirements don’t overly constrain instance selection + + * Review AWS service quotas for the instance types and regions you’re using + + + + +**Node replacement taking too long:** + + * Adjust disruption budgets to allow more concurrent replacements + + * Check if PodDisruptionBudgets are preventing node termination + + + + +**Unexpected node termination:** + + * Review the `expireAfter` and `terminationGracePeriod` settings + + * Check for manual node terminations or AWS maintenance events + + + + +## Examples @@ -105 +157 @@ The `status.nodes` field shows the current number of nodes managed by the node p -### Basic static-capacity node pool +### Basic static capacity node pool @@ -133 +185 @@ The `status.nodes` field shows the current number of nodes managed by the node p -### Static-capacity with specific instance types +### Static capacity with specific instance types @@ -173 +225 @@ The `status.nodes` field shows the current number of nodes managed by the node p -### Multi-zone static-capacity node pool +### Multi-zone static capacity node pool @@ -214,18 +266 @@ The `status.nodes` field shows the current number of nodes managed by the node p -## Best practices - -**Capacity planning:** - - * Set `limits.nodes` higher than `replicas` to allow for temporary scaling during node replacement operations. - - * Consider the maximum capacity needed during node drift or AMI updates when setting limits. - - - - -**Instance selection:** - - * Use specific instance types when you have Reserved Instances or specific hardware requirements. - - * Avoid overly restrictive requirements that might limit instance availability during scaling. -