-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chore(k8sclusterreceiver): 🔥 remove deprecated kubernetes API resources #26516
chore(k8sclusterreceiver): 🔥 remove deprecated kubernetes API resources #26516
Conversation
Signed-off-by: Prashant Shahi <[email protected]>
Signed-off-by: Prashant Shahi <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@prashant-shahi thank you for the PR. Can you please add a changelog entry?
Can we drop support for the hpa and cronjob beta apis? I am not sure if we have a compatibility matrix with k8s versions. Hpa was promoted to stable in v1.23 and cronjob in v1.21. Upstream k8s currently maintains 1.25 to 1.28. Below are EOL dates for the major managed clusters, all of which have no support for 1.22 (the last version which would need the hpa beta): https://endoflife.date/google-kubernetes-engine I think if we can commit to some k8s version compatibility window, it would make maintenance of k8s receivers simpler. A good place to start might be to keep up with the major managed cluster providers. |
@jinja2, that makes sense. It depends on the definition of "support" from the collector side. Should we support collecting metrics from the deprecated resource versions? I believe we should. In that case, dropping them now makes the supported window pretty narrow: 1.28, 1.27, 1.26 due to HPA beta removal in 1.26. I'm in favor of introducing this config option to provide a smoother transition. This will likely be needed going forward as well. |
…rces Signed-off-by: Prashant Shahi <[email protected]>
Signed-off-by: Prashant Shahi <[email protected]>
ignore_deprecated_resource
configignore_deprecated_resources
config
Changelog has been updated.
Absolutely. Introducing this option can also help the folks who do not want to upgrade to newest K8s version but want to get rid of the deprecation warning. Also, the usage of the deprecated K8s API causes the failure of managed clusters to auto-upgrade to newer k8s version (as reported in GKE and OpenShift). The |
I have started a new issue which provides more context on api versioning in k8s. The tldr is that we can use the |
@jinja2 Thanks for the detailed issue on the behaviour. It was really informative. Updating the PR to remove the deprecated APIs instead of adding the flag. |
…iles Signed-off-by: Prashant Shahi <[email protected]>
ignore_deprecated_resources
configSigned-off-by: Prashant Shahi <[email protected]>
Signed-off-by: Prashant Shahi <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM other than the changelog issue
Signed-off-by: Prashant Shahi <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you, @prashant-shahi!
Signed-off-by: Prashant Shahi <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Based on this issue, we should update the README that this breaks <= 1.22 users right?
@TylerHelmuth Include that in changelog? Yeah, sure. However, I am not sure if we need to include it in README. |
@prashant-shahi if a user enabled this component in a k8s 1.22 cluster with the default values would the collector crash? If so I think we should call that out in the README since there are definitely still people using <= 1.22. |
@TylerHelmuth it won't crash, the receiver will start up ok but HPA metrics will stop. I think a user-facing changelog entry to call out dropped support for the api is good enough. |
…s.yaml Co-authored-by: Dmitrii Anoshin <[email protected]>
…s.yaml Co-authored-by: Dmitrii Anoshin <[email protected]>
@dmitryax @jinja2 @TylerHelmuth Thanks for the thorough review and suggestions in the PR. Can the related issues be closed now or after the next release? |
@prashant-shahi you can close it now |
Thank you @prashant-shahi for resolving it! |
@TylerHelmuth I am unable to close them. Since the related issues were created by other folks. |
Description:
Remove support for deprecated Kubernetes API resources:
batch/v1beta1
autoscaling/v2beta2
This also resolves the issue with double reporting metrics for hpa and cronjob in certain k8s versions.
Link to tracking Issue(s):
#23612 #26551
Testing:
From source, built the custom image coolboi567/otelcontribcol:0.83.1 and tested in kubernetes cluster
v1.25
as well asv1.27
.In K8s
v1.25
, we no longer see the warnings in the logs about usage of deprecated APIs.Documentation:
N/A