kubent shows deployment which does not exist about kube-no-trouble HOT 9 CLOSED

Hi @Snehil03,

just to confirm - did you run it on kube-system namespace? (Or other namespace Tiller was installed in?) Helm v2 puts these Secrets/ConfigMaps into central namespace (as opposed to v3, which uses same namespace where the releases are deployed).

Because we see resources found by the v2, I'm confident these are there, somewhere.... :). Actually better command is to run both against all namespaces:

$ kubectl get configmaps --all-namespaces -l OWNER=TILLER

and

$ kubectl get secrets --all-namespaces -l OWNER=TILLER

from kube-no-trouble.

Hi Snehil,

thanks for reporting this. Are you using Helm2/3? And is this possibly a deployment that previously existed and was deleted?

Also, would you be able to share the full output of the kubent run?

from kube-no-trouble.

Hello @stepanstipl
I am using helm3
below is the output where the issue is where branding , infra and cloud-infra does not exist still it shows as part of kubent report

kubent
5:09PM INF >>> Kube No Trouble `kubent` <<<
5:09PM INF version 0.4.0 (git sha 3d82a3f0714c97035c27374854703256b3d69125)
5:09PM INF Initializing collectors and retrieving data
5:09PM INF Retrieved 10 resources from collector name=Cluster
5:09PM INF Retrieved 74 resources from collector name="Helm v2"
5:09PM INF Retrieved 277 resources from collector name="Helm v3"
5:09PM INF Loaded ruleset name=custom.rego.tmpl
5:09PM INF Loaded ruleset name=deprecated-1-16.rego
5:09PM INF Loaded ruleset name=deprecated-1-22.rego
__________________________________________________________________________________________
>>> Deprecated APIs removed in 1.16 <<<
------------------------------------------------------------------------------------------
KIND                NAMESPACE     NAME                            API_VERSION          REPLACE_WITH (SINCE)
DaemonSet           monitoring    cloudwatch-fluentd-cloudwatch   extensions/v1beta1   apps/v1 (1.9+)
Deployment          branding      branding                        extensions/v1beta1   apps/v1 (1.9+)
Deployment          infra         infra-chartmuseum               extensions/v1beta1   apps/v1 (1.9+)
Deployment          auth          login-oauth2-proxy              apps/v1beta2         apps/v1 (1.9+)
Deployment          cloud-infra   cloud-infra-chartmuseum         extensions/v1beta1   apps/v1 (1.9+)
PodSecurityPolicy   monitoring    cloudwatch-fluentd-cloudwatch   extensions/v1beta1   policy/v1beta1 (1.10+)

from kube-no-trouble.

Hi @Snehil03, thanks for further details. It looks like some resources are being picked up by the Helm v2 connector:

5:09PM INF Retrieved 74 resources from collector name="Helm v2"

So I'm assuming you were using Helm 2 before, and the issue might be that some of the manifests were left after it was removed/migrated to Helm v3.

Could you please check for this? By default, Tiller from Helm 2 is deployed in kube-system namespace and uses ConfigMaps. So unless you have changed it, can you run and share the output of the following:

kubectl get configmap -n kube-system -l "OWNER=TILLER"

from kube-no-trouble.

from kube-no-trouble.

Maybe you configured Tiller to use Secrets backend? Can you try with Secrets:

kubectl get secret -l OWNER=TILLER

from kube-no-trouble.

from kube-no-trouble.

from kube-no-trouble.

OK, thanks for confirming, I'm glad we've figured this out. So this looks like the V2 Helm has not been quite removed, I would suggest cleaning up. More about that in official docs Migrating Helm v2 to v3, and you should be able to use the cleanup command of the Helm 2to3 Plugin.

I hope that helps. As this is not a kubent issue, I'm going to close this.

from kube-no-trouble.