kapp tries to list resources from deprecated api versions
praveenrewar opened this issue · comments
What steps did you take:
I tried deploying an app that consists of a horizontal pod autoscaler (api version v2) on a Kubernetes cluster v1.25.
What happened:
kapp tries to make a list call to /apis/autoscaling/v2beta2/horizontalpodautoscalers which is deprecated and there's no resource in my app with this apiVersion.
What did you expect:
I expected kapp to only list the api versions that are part of my app.
Anything else you would like to add:
Currently we scope list calls to unique GKs, so we try to make a list call for all versions. We need to be smart enough to exclude such deprecated apis.
Environment:
- kapp version (use
kapp --version): - OS (e.g. from
/etc/os-release): - Kubernetes version (use
kubectl version)
Vote on this request
This is an invitation to the community to vote on issues, to help us prioritize our backlog. Use the "smiley face" up to the right of this comment to vote.
👍 "I would like to see this addressed as soon as possible"
👎 "There are other more important things to focus on right now"
We are also happy to receive and review Pull Requests if you want to help working on this issue.
We should be conscious about how this affects diffing during migrating CRs from to a newer api version. We should probably verify how ignoring older versions would affect diffs and the end result.
cc: @rcmadhankumar
this blocks automatic upgrades on gke when using kapp
@tylerphelan could you be more specific about the scenario here?
We might have flags that you can use during an upgrade consciously to help it go through.
@100mik gke checks for uses of deprecated apis in the last 30 days and blocks auto-upgrading the k8s cluster if there are any so when we're using kapp all the time GKE never auto-upgrades our clusters off of deprecated versions.
That is helpful, we might have to think about how we can have better control knobs for this behaviour after gauging the impact on not relying on the cluster resources