generated from amazon-archives/__template_Apache-2.0
-
Notifications
You must be signed in to change notification settings - Fork 271
Open
aws-controllers-k8s/eks-controller
#171Description
Describe the bug
Two problems observed with the ACK EKS controller when EKS Auto Mode is not in use:
- Nil pointer panic (runtime error: invalid memory address or nil pointer dereference) in
updateComputeConfig
when the controller attempts an Auto Mode related update while.spec.computeConfig
is absent (which is expected for non–Auto Mode clusters). - Persistent reconcile drift because
eks:DescribeCluster
may includekubernetesNetworkConfig.elasticLoadBalancing.enabled = false
while the Cluster CR spec omitselasticLoadBalancing
entirely. The controller treats “absent” vs “false” as a real difference and invokesupdateComputeConfig
unnecessarily.
Details
- Some EKS clusters’
eks:DescribeCluster
output omitskubernetesNetworkConfig.elasticLoadBalancing
. Others include:elasticLoadBalancing: { enabled: false }
. - None of the clusters actually use EKS Auto Mode.
- Because line triggering the update path checks any diff at
Spec.ComputeConfig
/Spec.StorageConfig
/Spec.KubernetesNetworkConfig
, a diff caused solely byelasticLoadBalancing
(false vs absent) leads toupdateComputeConfig
invocation even whenspec.computeConfig
isnil
. - This resulted in repeated reconcile attempts and a panic.
- We rolled back to controller version v1.5.4 (pre Auto Mode support) to avoid crashes; v1.5.5 and 1.6+ exhibit the issue.
- AWS Support ticket is open regarding the non-deterministic presence of
elasticLoadBalancing
ineks:DescribeCluster
for clusters not using Auto Mode.
Impact
- Crash loops (nil pointer) in
updateComputeConfig
- Unnecessary UpdateClusterConfig attempts
- Forces divergent CR specs (adding
elasticLoadBalancing.enabled: false
to silence drift) even though feature is unused.
Expected Behavior
- No panic when
.spec.computeConfig
is absent. - Absence of
elasticLoadBalancing
andelasticLoadBalancing.enabled=false
should be treated as equivalent for non–Auto Mode clusters. - Auto Mode update path should run only when the cluster is actually in Auto Mode.
Suggested Direction
- Introduce an explicit Auto Mode detection: treat cluster as Auto Mode only if s
pec.computeConfig.enabled == true
(or a documented status/field fromeks:DescribeCluster
confirms it). - Skip
updateComputeConfig
entirely when not Auto Mode. - Normalize or ignore the “absent vs false”
elasticLoadBalancing
difference when Auto Mode is not enabled. - Document authoritative indicator of Auto Mode (if one exists) for controllers.
Environment
- Some EKS clusters return
eks:DescribeCluster
withoutkubernetesNetworkConfig.elasticLoadBalancing
. - Other clusters return the same section with:
"elasticLoadBalancing": { "enabled": false }
. - We do not have EKS Auto Mode enabled on any cluster.
- An AWS Support ticket is open to understand why the API response is inconsistent and when (or if) the field should appear by default.
- EKS Controller versions: v1.5.5 and v1.6+ (we rolled back to v1.5.4 to avoid crash loops).
- Region: eu-west-3.
- Kubernetes version/platform: 1.32 / eks.16.
Jerome-w6n and gdlx
Metadata
Metadata
Assignees
Labels
No labels