[EKS] [request]: Insufficient information when nodegroup upgrade fails
- Dominant language
- Shell
- Stars
- 5.4k
- Forks
- 334
- PR merge metrics
- No merged PRs in 30d
Description
### Community Note
* Please vote on this issue by adding a 👍 [reaction](https://blog.github.com/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/) to the original issue to help the community and maintainers prioritize this request
* Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
* If you are interested in working on this issue or have submitted a pull request, please leave a comment
**Tell us about your request**
Currently the information returned to EKS is insufficient to act upon.
**Which service(s) is this request for?**
EKS
**Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?**
The message below is from cloudformation but is the same for EKS.
```
ResourceStatusReason": "Update failed due to [{ErrorCode: PodEvictionFailure,ErrorMessage: Reached max retries while trying to evict pods from nodes in node group prod-nodegroup,ResourceIds: [ip-10-233-150-169.eu-west-1.compute.internal]}]",
```
It would be handy to know on which pod it's failing.
**Are you currently working around this issue?**
-
**Additional context**
-
**Attachments**
-
Contributor guide
Research direction
Start by reviewing the EKS nodegroup upgrade failure described in the issue and how the CloudFormation ResourceStatusReason is surfaced. Confirm whether the failure identifies only the node or can identify the pod involved; done would mean actionable failure information that names the blocking pod when eviction retries are exhausted.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- kubernetes
- Domain
- cloud, infrastructure
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100