operator-framework / operator-sdk

SDK for building Kubernetes applications. Provides high level APIs, useful abstractions, and project scaffolding.
https://sdk.operatorframework.io
Apache License 2.0
7.1k stars 1.73k forks source link

Unusually High Core Usage with Upstream Docker Image for helm operator. #6679

Open r4rajat opened 4 months ago

r4rajat commented 4 months ago

Bug Report

What did you do?

I am creating an helm based operator for Redhat Openshift. Earlier I was using the downstream image i.e registry.redhat.io/openshift4/ose-helm-operator:latest as my base image and my operator-controller-manager deployment was taking around 0.06-0.08 cores, image

Then I updated my base image to the upstream image i.e quay.io/operator-framework/helm-operator:latest and the core usage for the same operator-controller-manager increased very much to like 0.8-0.9 cores. image

What did you expect to see?

Usual core usage around 0.05-0.06

What did you see instead? Under which circumstances?

Very high core usage around 1

Environment

Operator type:

/language helm

Kubernetes cluster type:

OpenShift v4.13.4

$ operator-sdk version

root@rajat-gupta:/repo# operator-sdk version
operator-sdk version: "v1.24.1", commit: "1a1c56f7d0c7cfcc16e1ff2140caaa6d831b669b", kubernetes version: "1.24.2", go version: "go1.18.7", GOOS: "linux", GOARCH: "amd64"

$ go version (if language is Go)

root@rajat-gupta:/repo# go version
go version go1.21.6 linux/amd64

$ kubectl version

root@rajat-gupta:/repo# kubectl version
WARNING: This version information is deprecated and will be replaced with the output from kubectl version --short.  Use --output=yaml|json to get the full version.
Client Version: version.Info{Major:"1", Minor:"27", GitVersion:"v1.27.7", GitCommit:"07a61d861519c45ef5c89bc22dda289328f29343", GitTreeState:"clean", BuildDate:"2023-10-18T11:42:32Z", GoVersion:"go1.20.10", Compiler:"gc", Platform:"linux/amd64"}
Kustomize Version: v5.0.1
Server Version: version.Info{Major:"1", Minor:"26", GitVersion:"v1.26.5+7d22122", GitCommit:"2fc599b5fd3f060dd20094b520f0f529fd2f52db", GitTreeState:"clean", BuildDate:"2023-06-07T20:30:17Z", GoVersion:"go1.19.9", Compiler:"gc", Platform:"linux/amd64"}

Possible Solution

Additional context

varshaprasad96 commented 3 months ago

@r4rajat Could you specify what version (and SHA) you are referring to for the respective upstream and downstream latest tags?

Also, it would be super helpful if you could run a profiler and let us know what is actually consuming the memory. Due to a shortage of active maintainers, its maybe really difficult for us to pick this up. Any help in solving this would be greatly appreciated!

openshift-bot commented 1 day ago

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale. Stale issues rot after an additional 30d of inactivity and eventually close. Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale