[EKS] [Enhancement]: EKS Upgrade Insights: False positives persist for 30 days after fixing deprecated APIs
- 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**
Enhance EKS Upgrade Insights to validate the current state of resources flagged for deprecated API usage, rather than relying solely on the 30-day audit log window.
### **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?**
Currently, EKS Upgrade Insights scans cluster audit logs using a 30-day rolling window to detect deprecated API usage. This creates a significant problem for automated upgrade workflows:
1. When a deprecated API call is detected, it's flagged in Upgrade Insights
2. Even after fixing the resource to use the current API version, the error persists in Upgrade Insights for up to 30 days (until the original audit log entry falls outside the rolling window)
3. This blocks automated cluster upgrades that rely on Upgrade Insights for validation, even though the actual resources are using supported API versions
Impact:
- Forces unnecessary use of --force flag in automated upgrades
- Reduces reliability of automation workflows
- Creates false positives that need manual verification
- Could lead to skipping important upgrade readiness checks due to reliance on --force
### **Are you currently working around this issue?**
Currently, we have two suboptimal workarounds:
1. Wait 30 days after fixing deprecated APIs before attempting upgrades
2. Use the --force flag to bypass Upgrade Insights validation, which defeats the purpose of having the validation
### **Additional context**
Proposed enhancement:
When Upgrade Insights detects a deprecated API usage from audit logs, it should:
1. Check the current state of the flagged resource
2. If the resource now uses a supported API version, remove the error from Upgrade Insights
3. Keep the historical audit log data for reference but don't block upgrades based on resolved issues
This would maintain the value of Upgrade Insights while eliminating false positives that currently force the use of --force flag or 30-day waiting periods.
### **Attachments**
N/A
### **References**
1. https://docs.aws.amazon.com/eks/latest/userguide/update-cluster.html#update-cluster-control-plane
Contributor guide
Research direction
Start by reviewing the linked EKS cluster update documentation and the issue's description of the 30-day audit-log behavior. Done means Upgrade Insights rechecks flagged resources, removes resolved deprecated-API findings from upgrade blockers, and retains historical audit data for reference.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- aws, kubernetes
- Domain
- cloud, devops
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100