aws / aws/containers-roadmap

[EKS] [Enhancement]: EKS Upgrade Insights: False positives persist for 30 days after fixing deprecated APIs

Open
#2,569 2 comments 0 reactions 0 assignees View on GitHub
EKS Proposed
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.