Getting failed to get k8s object, cause: failed to get k8s resulting object error cause: apiservices.apiregistration.k8s.io "v1beta1.external.metrics.k8s.io" not found

[aniket-searce]

Description

Hi there,
We have deployed the "Helm Dashboard" on GCP's Cloud Run Service, and we are connecting to our Auto-Pilot GKE Cluster
through it, Dashboard is getting connected successfully, able to see the list of Helm Charts, but though the cloud run configurations like CPU and Memory are not getting utilised much still facing performance issue, and when tried to open any of the Helm Charts getting below error message:-
"failed to get k8s object, cause: failed to get k8s resulting object, cause: apiservices.apiregistration.k8s.io "v1beta1.external.metrics.k8s.io" not found"

Screenshots

Additional information

No response

[undera]

Hello,
From your explanation, I did not understood what is "CPU and Memory are not getting utilised much" and how it relates to Helm Dashboard. Helm Dashboard has nothing to do with monitoring.

As for the error message, looks like some resource in your chart causes problems with retrieving its details from k8s. Current code of dashboard fails to display all the resources when one failed to retrieve the info. So I'll make it to say that gracefully. It will become a part of next release. Then, you will be able to tell resource is problematic.

[aniket-searce]

HI Andrey, Thanks for you quick response, About the "cpu and memory utilization":- I mean to say as I have hosted the container of "Helm Dashboard" tool over GCP's Cloud Run, so that hosted container's resource utilization is not that much, but still "Helm Dashboard" is taking too much time to load the details of my microservice's Helm chart which are on an autopilot GKE cluster. So just wanted to know the reason behind performance of "Helm Dashboard" tool, or is it due to large numbers of Helm Charts that I am having on my GKE cluster (Currently there are 387 helm charts) It would be great if you can address this issue as soon as possible, and I will be thankful to you. Regards,

…

On Fri, Mar 24, 2023 at 11:07 PM Andrey Pokhilko ***@***.***> wrote: Hello, From your explanation, I did not understood what is "CPU and Memory are not getting utilised much" and how it relates to Helm Dashboard. Helm Dashboard has nothing to do with monitoring. As for the error message, looks like some resource in your chart causes problems with retrieving its details from k8s. Current code of dashboard fails to display all the resources when one failed to retrieve the info. So I'll make it to say that gracefully. It will become a part of next release. Then, you will be able to tell resource is problematic. — Reply to this email directly, view it on GitHub <#301 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A5KIE3RIUIZCH5TNWHRX7U3W5XLVDANCNFSM6AAAAAAWGIZBQE> . You are receiving this because you authored the thread.Message ID: ***@***.***>

-- [image: Profile Photo] *Aniket Bhatagalikar* Senior Cloud Reliability Engineer M: +91-8087818134 [image: Searce Logo] <https://www.searce.com/home/?utm_source=email&utm_medium=emailsignature> We identify better ways of doing things [image: LinkedIn] <https://www.linkedin.com/company/searceinc/> [image: Facebook] <https://www.facebook.com/Searce.Inc/> [image: Twitter] <https://twitter.com/searce> The information contained in this communication is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. It may contain confidential or legally privileged information. If you are not the intended recipient you are hereby notified that any disclosure, copying, distribution or taking any action in reliance on the contents of this information is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by responding to this email and then delete it from your system. Searce is neither liable for the proper and complete transmission of the information contained in this communication nor for any delay in its receipt.

[undera]

It's hard to diagnose the exact reason for slowness. It would depend on performance of each request to Cloud Run, and also on the amount of the charts you have.

One of the workarounds is to limit the scope of namespaces via -n argument.

[SGudbrandsson]

@undera is it possible to analyse this somehow on our end?
How do you debug UX in the app?

[undera]

The application is simple backend and JS frontend. You can open Chrome Developer tools' Network tab and investigate the timings of various XHR requests there. The one the would look the bulkiest - is likely to be a problem. Or there will be a lot of small requests in sequence that take time to load.