doitintl / kube-no-trouble Goto Github PK

View Code? Open in Web Editor NEW

2.9K 18.0 157.0 854 KB

Easily check your clusters for use of deprecated APIs

License: MIT License

Makefile 2.17% Go 84.37% Open Policy Agent 10.31% Shell 2.76% Dockerfile 0.40%

hacktoberfest gke kubernetes k8s kube cluster

kube-no-trouble's Issues

panic: interface conversion: interface {} is nil, not string

Running into the below issue while running kubent, can someone help?

panic: interface conversion: interface {} is nil, not string

goroutine 1 [running]:
github.com/doitintl/kube-no-trouble/pkg/judge.(*RegoJudge).Eval(0xc00015fc10, 0xc000273500, 0x29c, 0x2a0, 0x29c, 0x2a0, 0x0, 0x1f4, 0xc0002f4390)
	/__w/kube-no-trouble/kube-no-trouble/pkg/judge/rego.go:76 +0x7c2
main.main()
	/__w/kube-no-trouble/kube-no-trouble/cmd/kubent/main.go:97 +0x3be

Go version - go1.15.5 darwin/amd64

kubent version - 0.3.2

Collect all resources in cluster collector

Currently, when adding/updating new resources, changes have to be made at two places, in-sync - the rego rules, and cluster collector. This is difficult to keep in sync. Also, the specific API versions hardcoded in cluster collector are expected to cause issues when running against a cluster that does not support these.

I see 3 options to move forward:
a) Collect all resources, in all API versions
b) Collect specific resource, in all API versions
c) Come up with a better/automated mechanism that wouldn't require editing things at two places. Potentially connected with #154 - consider coming with some format to describe rule metadata, incl. what resources are we interested in.

Use go embed instead of static

Want to avoid using generate and load the rules into the go binary at either build time or run time.

See https://tip.golang.org/pkg/embed/

over static

Clarify that APIs are not just deprecated, but removed

it should be more clear that APIs are deprecated from the output, and in 1.16 and other will be removed and not useable anymore.

Upgrade to go 1.15

Go 1.15 is out, should we use it?

Add tests for empty output format

Add tests for empty output format to make sure we keep consistent output with regards to use in CI/integration (#31)

text stdout output should be empty if no issues are found
json output should return an empty array

kubent 0.3.0 NOT reporting 1.16 usage of deprecated apis that ARE reported by kubent 0.2.0

Version 0.2.0 reports ...

10:33AM INF >>> Kube No Trouble `kubent` <<<
10:33AM INF version 0.2.0 (git sha b9b45f347c7e67cf488d8dd6e20c8b848c595a3e)
...
10:33AM INF Loaded ruleset name=deprecated-1-16.rego
10:33AM INF Loaded ruleset name=deprecated-1-20.rego
..
>>> 1.16 Deprecated APIs <<<
------------------------------------------------------------------------------------------
KIND         NAMESPACE     NAME                          API_VERSION
DaemonSet    <REDACTED>   <REDACTED>        extensions/v1beta1
Deployment   <REDACTED>   <REDACTED>         extensions/v1beta1
Deployment   <REDACTED>   <REDACTED>         apps/v1beta2
Deployment   <REDACTED>   <REDACTED>         extensions/v1beta1
Deployment   <REDACTED>   <REDACTED>         extensions/v1beta1
Deployment   <REDACTED>   <REDACTED>         extensions/v1beta1
Deployment   <REDACTED>   <REDACTED>         extensions/v1beta1
__________________________________________________________________________________________
...
>>> 1.20 Deprecated APIs <<<
------------------------------------------------------------------------------------------
A long list similar to that for 1.16 above

BUT
Latest version 0.3.0 for same cluster reports

$ kubent_30 -k kubeconfig-readonly.yaml
10:40AM INF >>> Kube No Trouble `kubent` <<<
10:40AM INF version 0.3.0 (git sha dev)
...
10:40AM INF Loaded ruleset name=deprecated-1-16.rego
10:40AM INF Loaded ruleset name=deprecated-1-22.rego
________________________________________________________________________________________
>>> Deprecated APIs removed in 1.22 <<<
------------------------------------------------------------------------------------------
KIND      NAMESPACE   NAME                          API_VERSION          
Ingress   <REDACTED> <REDACTED>             extensions/v1beta1

showing NOTHING for 1.16 Deprecated APIs

Am I doing something wrong ?

Review and add rules for Deprecated API Migration Guide

K8s docs now have handy page Deprecated API Migration Guide.

Go over it and make sure we support those resources or add them otherwise.

Fix very slow `TestNewClusterCollectorValidEmptyCollector` (330.810s)

This collector tests take currently 5m+. that's a bit too slow ;), it seems to be the TestNewClusterCollectorValidEmptyCollector test:

=== RUN   TestNewClusterCollectorValidEmptyCollector
....
--- PASS: TestNewClusterCollectorValidEmptyCollector (330.04s)
ok      github.com/doitintl/kube-no-trouble/pkg/collector       330.810s        coverage: 45.4% of statements

Flaky test - stable file order

Looks like the order when splitting files is not stable - https://github.com/doitintl/kube-no-trouble/runs/1151087906?check_suite_focus=true

Either stabilise or ref. test.

New release

rbac.authorization.k8s.io/v1beta1 should be flagged deprecated also

All resources within the rbac.authorization.k8s.io/v1beta1 API groups are deprecated in favor of rbac.authorization.k8s.io/v1

$ kubectl get --raw /apis/rbac.authorization.k8s.io/v1beta1/clusterrolebindings > /dev/null
Warning: rbac.authorization.k8s.io/v1beta1 ClusterRoleBinding is deprecated in v1.17+, unavailable in v1.22+; use rbac.authorization.k8s.io/v1 ClusterRoleBinding

https://v1-17.docs.kubernetes.io/docs/setup/release/notes/#deprecations-and-removals

All resources within the rbac.authorization.k8s.io/v1alpha1 and rbac.authorization.k8s.io/v1beta1 API groups are deprecated in favor of rbac.authorization.k8s.io/v1, and will no longer be served in v1.20. (#84758, @liggitt)

Add module updates

Dependabot is nice to keep us up-to-date

Detect K8s version and suggest only relevant issues

We can try to detect a version of the cluster a user is running and suggest only updates relevant for the existing/next minor version, since we have info on since what version are the replacement resources available.

I.e. if user runs 1.15, and is dealing with upgrade to 1.16, no point flagging deprecation in 1.22 that are only available for replacement in 1.18.

Add test for storeCollector - err in particular

Add tests for storeCollector, in particular cover when collector fails to be initialised #25, #32

Add module vulnerability scanning

Snyk is good & free for OSS repos

Add docs about how to install on windows

Or script even? not sure. But at lease mention the script is for Linux, and on Win you should download & extract manually.

CI mode

The tool should provide a way for CI to fail. This is typically done by returning a non-zero exit code.

Add support for installing latest nightly to install script

Just as a convenience option.

New release

Refactor to support resource version evolution

As we want to provide most relevant advice to users, current implementation has its limitation as it's not able to support incremental recommendations, example being Ingress:

"Ingress": {
    "old": ["extensions/v1beta1", "networking.k8s.io/v1beta1"],
    "new": "networking.k8s.io/v1",
    "since": "1.14",
},

This does not allow to reflect the real situation where networking.k8s.io/v1 is only available since 1.19, and networking.k8s.io/v1beta1 since 1.14.

I.e. for someone running 1.18 we should ideally recommend upgrade to networking.k8s.io/v1beta1, but not v1, as that is not available yet. To allow this type of recommendations we need to capture version evolution properly, perhaps smth. like:

"Ingress": {
    "versions": [
        "extensions/v1beta1": { "since": "", deprecated: "1.16", removed: "1.22" },
        "networking.k8s.io/v1beta1": {"since": "1.19", deprecated: "1.16", removed: "1.22"},
        "networking.k8s.io/v1": {"since": "1.19", deprecated: "1.", "removed": "1.22"},
    ],
},

Maybe smth. like might be easier to work with:

"Ingress": {
    "versions": [
        [ "1.0": "extensions/v1beta1"],
        [ "1.14": "networking.k8s.io/v1beta1"],
        [ "1.19": "networking.k8s.io/v1"],
    ],
},

We also need to support the case when a version is removed but does not have any replacement.
Do we need info when version is removed? or deprecated really? We only care if it has replacement, and perhaps removal without replacement could be smth. like:
```
[ "1.22": ""],
```
Implementation-wise:
- How easy is it to find if resource needs to be replaced?
- And with what version?
- Is this still a good use for rego? Or should we move this to Go...?

VolumeSnaphosts are moving to v1

https://kubernetes.io/blog/2020/12/10/kubernetes-1.20-volume-snapshot-moves-to-ga/

Research and consider adding a warning for old API versions (alphas v1/v2 + beta)

Remove UPX

Cluster/context selection and multi-file KUBECONFIG

I have access to multiple k8s clusters, they are defined in multiple config files, all pointed-to by the KUBECONFIG env var, separated with ::

$ echo $KUBECONFIG
/home/foo/.kube/config:/home/foo/.minikube/kubeconfig

kubent doesn't support context selection, it seems to use the default context on the first config file, and if it points to a context defined in another file it fails: ERR Failed to initialize collector: <nil> error="invalid configuration: [context was not found for specified context: bar-context, cluster has no server defined]"

Currently I workaround that by setting the current context and edit KUBECONFIG, that's not ideal.

Ideally:

kubent supports multi-file KUBECONFIG
kubent supports context selection (technically as an indirect selector for cluster) with --context (alas the standard -c is already used for something else)

Using Kube-no-trouble in windows OS

Good morning,

There're some way to use kubent into windows OS system?
unfortunadle, I use windows to work with kubernetes clusters and we want to upgrade our clusters to 1.16 and need some way to use kubent to locate used deprecated API versions in 1.16.

Good job and thanks!, regards.

networking.k8s.io/v1beta1 should be flagged deprecated also

Since 1.19 has moved ingress to v1 could we alert on both v1beta1 strings?

	"Ingress": {
		"old": ["extensions/v1beta1"],
		"new": "networking.k8s.io/v1beta1"

https://v1-19.docs.kubernetes.io/docs/setup/release/notes/#deprecations-and-removals
Ingress and IngressClass resources have graduated to networking.k8s.io/v1. Ingress and IngressClass types in the extensions/v1beta1 and networking.k8s.io/v1beta1 API versions are deprecated and will no longer be served in 1.22+

Once again thanks for the fantastic tool!

Add simple integration test

Start with checking one resource that should be flagged as deprecated, and make sure it is detected, and same resource with updated API version, and make sure it isn't. Perhaps use Kind to run this inside GH Actions.

Automate release notes

As part of rethinking auto-release CI - #17, add auto-release notes generation

Testing and ENV variables

These are some notes on tests with Env variables, mostly discussed in context of #127, so not to forget:

Tests preferably should not rely on ENV variables, however, there are some, where we test functionality that is directly related to env variable (such as TestNewFromFlagsKubeconfigHome). In such cases it would be nice to:

Test should not rely on external environment, i.e. it should set/unset its variables at the beginning (i.e. should be self-contained)
Test should return the env to a previous state, i.e. no variables should be leaked (it should not just unset the var, but actually revert, also there's a diff between var being empty and unset(
Ideally, we keep in mind tests can be run in parallel -> i.e. in case tests happen to use same variable this should be accounted for, perhaps some locking mechanism might be needed.
- By default go does not run tests in the same file in parallel, unless t.Parallel() is called
- However, tests in different packages are by default run in parallel
@dark0dave added some notes just not to forget ;)

Create ARM Build

Lots of M1 mac chips and people running arm servers, means we should probably make an arm build

Unable to run binary

Hi Stepan,

I downloaded Linux release and after unpacking and executing ./kubent nothing happens.
/chmod 777 kubent did not help
executing ./kubent -h also shows nothing

I have admin role in cluster and running
kube config is in default location
I'm using 18.04.4 LTS (Bionic Beaver)

Rules tests

Write test to see how good rules.

display target api to use

Hello

I did run your script and it's nice, but would be cool to specify some helpful information if possible.

1:24PM INF >>> Kube No Trouble `kubent` <<<
1:24PM INF version 0.2.0 (git sha b9b45f347c7e67cf488d8dd6e20c8b848c595a3e)
1:24PM INF Initializing collectors and retrieving data
1:24PM INF Retrieved 70 resources from collector name=Cluster
1:24PM INF Retrieved 0 resources from collector name="Helm v2"
1:24PM INF Retrieved 0 resources from collector name="Helm v3"
1:24PM INF Loaded ruleset name=deprecated-1-16.rego
1:24PM INF Loaded ruleset name=deprecated-1-20.rego
________________________________________________________________________________________
>>> 1.20 Deprecated APIs <<<
----------------------------------------------------------------------------------------
KIND      NAMESPACE    NAME                 API_VERSION    NEW_API_VERSION
Ingress   test         test-ingress    extensions/v1beta1  networking.k8s.io/v1beta1

or event a link to the current version for deprecation api.
Example : https://kubernetes.io/blog/2019/07/18/api-deprecations-in-1-16/ or https://v1-14.docs.kubernetes.io/docs/concepts/services-networking/ingress/

Native support for CustomResourceDefinition

First of all thanks a lot for this nice utility.

Problem Statement

I was just wandering why the CustomResourceDefinition object isn't natively supported. So basically if I have something like:

apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
  name: mystuff.crd.k8s.myorga.com
spec:
  group: crd.k8s.myorga.com
  names:
    kind: MyStuff
...

Attempting to apply the following to a cluster with a recent version of k8s e.g. 1.20 I get a message like:

Warning: apiextensions.k8s.io/v1beta1 CustomResourceDefinition is deprecated in v1.16+, unavailable in v1.22+; use apiextensions.k8s.io/v1 CustomResourceDefinition

That being said, running kubent doesn't print out this object at all.

Proposed Solution

I would love to see a native support for the CRD definition object itself (CustomResourceDefinition) similar to other k8s objects like Ingress, ClusterRole, Service, .. etc.

Current Workaround

The current workaround is to use the -a flag of kubent e.g.:

$  kubent -a CustomResourceDefinition.v1beta1.apiextensions.k8s.io

In such case I get:

4:17PM INF >>> Kube No Trouble `kubent` <<<
4:17PM INF version 0.4.0 (git sha 3d82a3f0714c97035c27374854703256b3d69125)
4:17PM INF Initializing collectors and retrieving data
4:17PM INF Retrieved 207 resources from collector name=Cluster
4:17PM INF Retrieved 0 resources from collector name="Helm v2"
4:17PM INF Retrieved 266 resources from collector name="Helm v3"
4:17PM INF Loaded ruleset name=custom.rego.tmpl
4:17PM INF Loaded ruleset name=deprecated-1-16.rego
4:17PM INF Loaded ruleset name=deprecated-1-22.rego
__________________________________________________________________________________________
>>> Additional resources (custom) <<<
------------------------------------------------------------------------------------------
KIND                       NAMESPACE     NAME                                         API_VERSION                    REPLACE_WITH (SINCE)
CustomResourceDefinition   <undefined>   mystuff.crd.k8s.myorga.com             apiextensions.k8s.io/v1beta1           <na> (<na>+)
__________________________________________________________________________________________
>>> Deprecated APIs removed in 1.22 <<<
------------------------------------------------------------------------------------------
KIND      NAMESPACE     NAME                     API_VERSION          REPLACE_WITH (SINCE)
Ingress   kube-system   ingress-kube-dashboard   extensions/v1beta1   networking.k8s.io/v1beta1 (1.14+)
Ingress   kube-system   ingress-master           extensions/v1beta1   networking.k8s.io/v1beta1 (1.14+)

Be possible to run kubent against manifest

One issue I found in kubent is that it requires to run it against the cluster, I would prefer using local manifests.

This will avoid putting credentials inside a CI/CD and be able to detect deprecated api during development or allow to prepare migration to new version not yet deployed.

I heard from @drewboswell that kubeval could provide the model.
e.x:

kubent --local 1.6.1

helm deployments return undefined namespaces

for some reason helm deployments seem to return namespaces as undefined

Add test to cover collector logic

Cover #30 - kube fake client should help here - https://gianarb.it/blog/unit-testing-kubernetes-client-in-go

Add a link to blog post to README

https://blog.doit-intl.com/kubernetes-how-to-automatically-detect-and-deal-with-deprecated-apis-f9a8fc23444c

KUBECONFIG env variable would be nice to support

Firstly thanks for a great tool!

Then minor issue and a workaround for anyone having the same problem

Actual result:

$ kubent
10:54AM INF >>> Kube No Trouble `kubent` <<<
10:54AM INF version 0.3.2 (git sha 919129b596890475965cda2b972cb6fded71f40b)
10:54AM INF Initializing collectors and retrieving data
10:54AM ERR Failed to initialize collector: <nil> error="stat /home/<redacted>/.kube/config: no such file or directory"
...
$ env | grep KUBECONFIG
KUBECONFIG=/path/to/my/kube.config

Expected result:
using the KUBECONFIG - env variable for the path (like kubectl does)

Workaround:

$ kubent -k ${KUBECONFIG}

Doesn't find all deprecated APIs

kubent didn't find all the deprecated APIs...

The list of all deprecated APIs is here:
https://kubernetes.io/blog/2019/07/18/api-deprecations-in-1-16/

kubent finds this:

$ ./kubent -k kubeconfig
3:57PM INF >>> Kube No Trouble `kubent` <<<
3:57PM INF version 0.3.2 (git sha 919129b596890475965cda2b972cb6fded71f40b)
3:57PM INF Initializing collectors and retrieving data
3:57PM INF Retrieved 8 resources from collector name=Cluster
3:57PM INF Retrieved 0 resources from collector name="Helm v2"
3:57PM INF Retrieved 636 resources from collector name="Helm v3"
3:57PM INF Loaded ruleset name=deprecated-1-16.rego
3:57PM INF Loaded ruleset name=deprecated-1-22.rego
__________________________________________________________________________________________
>>> Deprecated APIs removed in 1.16  <<<
------------------------------------------------------------------------------------------
KIND         NAMESPACE     NAME                   API_VERSION          
Deployment   <undefined>   metabase-metabase      extensions/v1beta1   
Deployment   <undefined>   sonarqube-postgresql   extensions/v1beta1   
__________________________________________________________________________________________
>>> Deprecated APIs removed in 1.22 <<<
------------------------------------------------------------------------------------------
KIND      NAMESPACE     NAME                                 API_VERSION          
Ingress   <undefined>   harbor-harbor-ingress-notary         extensions/v1beta1   
Ingress   <undefined>   alice-frontend-generic-app   extensions/v1beta1   
Ingress   <undefined>   frontend-ingress              extensions/v1beta1   
Ingress   <undefined>   frontend-generic-app                 extensions/v1beta1   
Ingress   <undefined>   ganache-cli-generic-app              extensions/v1beta1   
Ingress   <undefined>   harbor-harbor-ingress                extensions/v1beta1   
Ingress   <undefined>   api-generic-app                      extensions/v1beta1   
Ingress   <undefined>   metabase-metabase                    extensions/v1beta1   
Ingress   <undefined>   alice-api-generic-app        extensions/v1beta1   
Ingress   <undefined>   pomerium                             extensions/v1beta1   
Ingress   <undefined>   chartmuseum-chartmuseum              extensions/v1beta1   
Ingress   <undefined>   sonarqube-sonarqube                  extensions/v1beta1   
Ingress   <undefined>   temp-api-generic-app                 extensions/v1beta1   
Ingress   <undefined>   temp-frontend-generic-app            extensions/v1beta1   
Ingress   <undefined>   verdaccio-verdaccio                  extensions/v1beta1

but there is no mention of other deprecated APIs like NetworkPolicy:

$ k get networkpolicy -A -o json | jq '.items[] | select(.apiVersion != "networking.k8s.io/v1") | .apiVersion,.metadata.name,.metadata.namespace'
"extensions/v1beta1"
"redis"
"alice-dev"
"extensions/v1beta1"
"redis"
"alice-prod"
"extensions/v1beta1"
"redis"
"alice-test"
"extensions/v1beta1"
"redis"
"barry-dev"
"extensions/v1beta1"
"redis"
"barry-prod"

Add a "dev" build from master

It would be nice to have a binary for the latest version of the master published, so it's easy to download and test latest features before a release is cut.

File collector not reporting all resources or reporting them inconsistently

Hi. Thanks for the great tool. We were trying to run it on manifests using the -f option (the File collector) and found it to not always pick up deprecations in all the resources in the files specified or to pick them up differently when the tool is run again on the same files.

To reproduce, start with these 3 manifest files (I tried to trim them so they may not actually work as resources in a real cluster but they demonstrate this issue):

ingress.yaml

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: app
  namespace: prod
spec:
  rules:
  - host: app.example.com
    http:
      paths:
      - backend:
          serviceName: backend
          servicePort: 8080
        path: /

stateful-set.yaml

---
apiVersion: apps/v1beta2
kind: StatefulSet
metadata:
  name: memecached
  namespace: prod
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: memcached
      app.kubernetes.io/instance: memcached
  serviceName: memcached
  template:
    metadata:
      labels:
        app.kubernetes.io/name: memcached
        app.kubernetes.io/instance: memcached
    spec:
      securityContext:
        fsGroup: 1001
      containers:
      - name: memcached
        image: memcached:1.5.20
        imagePullPolicy: ""
        securityContext:
          runAsUser: 1001
        command:
        - memcached
        - -m 64
        - -o
        - modern
        - -v
        ports:
        - name: memcache
          containerPort: 11211
        livenessProbe:
          tcpSocket:
            port: memcache
          initialDelaySeconds: 30
          timeoutSeconds: 5
        readinessProbe:
          tcpSocket:
            port: memcache
          initialDelaySeconds: 5
          timeoutSeconds: 1
        resources:
          requests:
            cpu: 50m
            memory: 64Mi
  updateStrategy:
    type: RollingUpdate

combined.yaml - this is just stateful-set.yaml appended to the end of ingress.yaml

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: app
  namespace: prod
spec:
  rules:
  - host: app.example.com
    http:
      paths:
      - backend:
          serviceName: backend
          servicePort: 8080
        path: /
---
apiVersion: apps/v1beta2
kind: StatefulSet
metadata:
  name: memecached
  namespace: prod
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: memcached
      app.kubernetes.io/instance: memcached
  serviceName: memcached
  template:
    metadata:
      labels:
        app.kubernetes.io/name: memcached
        app.kubernetes.io/instance: memcached
    spec:
      securityContext:
        fsGroup: 1001
      containers:
        - name: memcached
          image: memcached:1.5.20
          imagePullPolicy: ""
          securityContext:
            runAsUser: 1001
          command:
            - memcached
            - -m 64
            - -o
            - modern
            - -v
          ports:
            - name: memcache
              containerPort: 11211
          livenessProbe:
            tcpSocket:
              port: memcache
            initialDelaySeconds: 30
            timeoutSeconds: 5
          readinessProbe:
            tcpSocket:
              port: memcache
            initialDelaySeconds: 5
            timeoutSeconds: 1
          resources:
            requests:
              cpu: 50m
              memory: 64Mi
  updateStrategy:
    type: RollingUpdate

Running on just the ingress.yaml file seems to always work:

$ kubent -c=false --helm2=false --helm3=false -f ingress.yaml
3:47PM INF >>> Kube No Trouble `kubent` <<<
3:47PM INF version 0.3.1 (git sha dev)
3:47PM INF Initializing collectors and retrieving data
3:47PM INF Retrieved 1 resources from collector name=File
3:47PM INF Loaded ruleset name=deprecated-1-16.rego
3:47PM INF Loaded ruleset name=deprecated-1-22.rego
__________________________________________________________________________________________
>>> Deprecated APIs removed in 1.22 <<<
------------------------------------------------------------------------------------------
KIND      NAMESPACE   NAME      API_VERSION
Ingress   prod        app       extensions/v1beta1
$

As does running on just stateful-set.yaml:

$ kubent -c=false --helm2=false --helm3=false -f stateful-set.yaml
3:48PM INF >>> Kube No Trouble `kubent` <<<
3:48PM INF version 0.3.1 (git sha dev)
3:48PM INF Initializing collectors and retrieving data
3:48PM INF Retrieved 1 resources from collector name=File
3:48PM INF Loaded ruleset name=deprecated-1-16.rego
3:48PM INF Loaded ruleset name=deprecated-1-22.rego
__________________________________________________________________________________________
>>> Deprecated APIs removed in 1.16  <<<
------------------------------------------------------------------------------------------
KIND          NAMESPACE   NAME         API_VERSION
StatefulSet   prod        memecached   apps/v1beta2
$

But running on both files only ever seems to pick up the resource in the last file, never both:

$ kubent -c=false --helm2=false --helm3=false -f ingress.yaml,stateful-set.yaml
3:50PM INF >>> Kube No Trouble `kubent` <<<
3:50PM INF version 0.3.1 (git sha dev)
3:50PM INF Initializing collectors and retrieving data
3:50PM INF Retrieved 2 resources from collector name=File
3:50PM INF Loaded ruleset name=deprecated-1-16.rego
3:50PM INF Loaded ruleset name=deprecated-1-22.rego
__________________________________________________________________________________________
>>> Deprecated APIs removed in 1.16  <<<
------------------------------------------------------------------------------------------
KIND          NAMESPACE   NAME         API_VERSION
StatefulSet   prod        memecached   apps/v1beta2
$ kubent -c=false --helm2=false --helm3=false -f stateful-set.yaml,ingress.yaml
3:50PM INF >>> Kube No Trouble `kubent` <<<
3:50PM INF version 0.3.1 (git sha dev)
3:50PM INF Initializing collectors and retrieving data
3:50PM INF Retrieved 2 resources from collector name=File
3:50PM INF Loaded ruleset name=deprecated-1-16.rego
3:50PM INF Loaded ruleset name=deprecated-1-22.rego
__________________________________________________________________________________________
>>> Deprecated APIs removed in 1.22 <<<
------------------------------------------------------------------------------------------
KIND      NAMESPACE   NAME      API_VERSION
Ingress   prod        app       extensions/v1beta1
$

(Notice the flipping of the order of the files in the -f option in the above 2 calls)

And weirdest of all, when run on the combined.yaml file, sometimes it reports 1 resource and sometimes the other (but I've never seen it report both)

$ kubent -c=false --helm2=false --helm3=false -f combined.yaml
3:52PM INF >>> Kube No Trouble `kubent` <<<
3:52PM INF version 0.3.1 (git sha dev)
3:52PM INF Initializing collectors and retrieving data
3:52PM INF Retrieved 2 resources from collector name=File
3:52PM INF Loaded ruleset name=deprecated-1-16.rego
3:52PM INF Loaded ruleset name=deprecated-1-22.rego
__________________________________________________________________________________________
>>> Deprecated APIs removed in 1.16  <<<
------------------------------------------------------------------------------------------
KIND          NAMESPACE   NAME         API_VERSION
StatefulSet   prod        memecached   apps/v1beta2
$ kubent -c=false --helm2=false --helm3=false -f combined.yaml
3:52PM INF >>> Kube No Trouble `kubent` <<<
3:52PM INF version 0.3.1 (git sha dev)
3:52PM INF Initializing collectors and retrieving data
3:52PM INF Retrieved 2 resources from collector name=File
3:52PM INF Loaded ruleset name=deprecated-1-16.rego
3:52PM INF Loaded ruleset name=deprecated-1-22.rego
__________________________________________________________________________________________
>>> Deprecated APIs removed in 1.22 <<<
------------------------------------------------------------------------------------------
KIND      NAMESPACE   NAME      API_VERSION
Ingress   prod        app       extensions/v1beta1
$

Sometimes this last one is not easy to reproduce. I had to run it over 10 times (all identical and on the same file) to get it to show the Ingress resource instead of the StatefulSet resource. Other times it seems to flip back and forth more often.

Notice that the resource count its reporting always seems to be correct even if its not detecting or reporting all the deprecations.

I tried to see if I could spot where it was but I don't know go and couldn't see anything obvious.

Thanks!

Fix Git sha in build

When running, kubent should display correst sha from which it was built, instead of:

3:47PM INF version 0.3.1 (git sha dev)

Dependencies - Helm v2 blocking from upgrading to k8s.io v0.18+

Helm v2 is not compatible with k8s.io v0.18+ modules.

At the same time, this is stopping us from upgrading to latest Helm v3 (last compatible seems to be v3.1.3).

Go does not seem to support multiple minor versions of the same package. Solutions:

Not upgrade
Drop Helm v2 support
Fork helm v2 & lock dependencies by replace & importing them under a different name

We should also be careful as not to lose support for older K8s clusters like v 1.15 -> this calls for integration testing.

Add support for krew plugin

https://github.com/kubernetes-sigs/krew

Tracing bad yaml code - eval_builtin_error: json.unmarshal: invalid character ']'

Thank you for this fantastic tool!

This has worked in several clusters, but in one I receive this message. It may be indicative of some odd yaml somewhere in our cluster, but I'm not sure how to trace it, and since it's being retrieved from the cluster it suggests that it may be valid yaml but misinterpreted. Also the rule returned whether 1.16/1.20 rotates randomly between the 2, and --debug doesn't seem to print any more to screen.

$ kubent --debug -k ~/Kubeconfig-prd1 --helm2=false --helm3=false
10:38AM INF >>> Kube No Trouble kubent <<<
10:38AM INF version 0.2.0 (git sha b9b45f3)
10:38AM INF Initializing collectors and retrieving data
10:38AM INF Retrieved 3843 resources from collector name=Cluster
10:38AM INF Loaded ruleset name=deprecated-1-16.rego
10:38AM INF Loaded ruleset name=deprecated-1-20.rego
10:38AM FTL Failed to evaluate input error="deprecated-1-16.rego:14: eval_builtin_error: json.unmarshal: invalid character ']' after object key:value pair" name=Rego

panic: runtime error: invalid memory address or nil pointer dereference

Error on WSL1 windows OS

`❯ kubent
2:44PM INF >>> Kube No Trouble kubent <<<
2:44PM INF version 0.3.0 (git sha dev)
2:44PM INF Initializing collectors and retrieving data
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x1154c15]

goroutine 1 [running]:
github.com/doitintl/kube-no-trouble/pkg/collector.(*ClusterCollector).Name(0x0, 0x1823920, 0xc000361b80)
:1 +0x5
main.storeCollector(0x182ac00, 0x0, 0x1823920, 0xc000361b80, 0x2331290, 0x0, 0x0, 0x0, 0x0, 0x16649b5)
/__w/kube-no-trouble/kube-no-trouble/cmd/kubent/main.go:40 +0x151
main.initCollectors(0xc000223630, 0x16649b5, 0x2b, 0xc0002ce540)
/__w/kube-no-trouble/kube-no-trouble/cmd/kubent/main.go:51 +0x3a7
main.main()
/__w/kube-no-trouble/kube-no-trouble/cmd/kubent/main.go:88 +0x31c`

Continue processing other manifests, even if one fails

Even if one or more manifests fail to be parsed, we should still continue to process others. This is improvement after adding better error reporting in #20 to address #13

This will require some ref. around handling errors, I imagine the collector should return multiple "non-fatal" errors in this case, and these should be logged to user.

Feature request: Customizing ruleset

It would be good to have functionalities like checking objects deployed using some specific Helm version i.e. Helm v2 which is gonna be deprecated soon and report that also. In short, allowing to incorporate custom rules also on top of K8s deprecation rules.

kubent shows deployment which does not exist

Hello,
I am seeing deployment which does not exist as part of cluster, infact the namespace itself does not exist.

Thanks,
Snehil Belekar

doitintl / kube-no-trouble Goto Github PK

kube-no-trouble's Issues

Problem Statement

Proposed Solution

Current Workaround

Recommend Projects

Recommend Topics

Recommend Org