Implement the replicasets block for overview page

Add support for secrets

Is your feature request related to a problem? Please describe.
I would like to be able to scroll down the list of pods quickly, adding support for Page Up / Down via the same keys would aid with this.

Describe the solution you'd like
Allow for the Page Up and Page Down key to be used to perform page scrolls within any of the screens.

Describe alternatives you've considered
Scrolling down using the cursor keys is slow, an alternative would be to make the overal scroll performance faster

Describe the bug
A clear and concise description of what the bug is.
Application crashed while viewing utilization of K8s cluster

To Reproduce
Steps to reproduce the behavior or a screencast

1. Open application
2. Go to utilization tab
3. Play a bit with the grouping <g>
4. ???
5. Crash

Expected behavior
A clear and concise description of what you expected to happen.
The application does not crash

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS and OS version: [e.g. macOS 10.1 / Fedora 34 / WIndows 10]

Ubuntu 20.04 LTS
Linux artemis 5.4.0-77-generic #86-Ubuntu SMP Thu Jun 17 02:35:03 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

• Terminal name and version [e.g. Tilix, Yakuake, Gnome Terminal, Konsole, iTerm, Windows CMD]

Windows terminal using WSL2, though accessing a remote server over SSH

• Shell name and version [e.g. bash, zsh, fish, powershell]

GNU bash, version 5.0.17(1)-release (x86_64-pc-linux-gnu)

• Kubectl Client Version [e.g. 1.19]

Client Version: version.Info{Major:"1", Minor:"20", GitVersion:"v1.20.5", GitCommit:"6b1d87acf3c8253c123756b9e61dac642678305f", GitTreeState:"clean", BuildDate:"2021-03-18T01:10:43Z", GoVersion:"go1.15.8", Compiler:"gc", Platform:"linux/amd64"}

• Kubectl Server Version [e.g. 1.19]

Server Version: version.Info{Major:"1", Minor:"20", GitVersion:"v1.20.5", GitCommit:"6b1d87acf3c8253c123756b9e61dac642678305f", GitTreeState:"clean", BuildDate:"2021-03-18T01:02:01Z", GoVersion:"go1.15.8", Compiler:"gc", Platform:"linux/amd64"}

• KDash version [e.g. 0.0.8] 0.1.2

Additional context
Add any other context about the problem here.
Produced logs file:

tobias@artemis:~/kubernetes/manifests/system$ cat /tmp/report-310a52bb-fffa-45d3-bbfa-c68aa9d110aa.toml
name = 'kdash'
operating_system = 'unix:Ubuntu'
crate_version = '0.1.2'
explanation = '''
Panic occurred in file '/home/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/tui-0.15.0/src/widgets/table.rs' at line 359
'''
cause = 'index out of bounds: the len is 171 but the index is 171'
method = 'Panic'
backtrace = '''

   0: 0x7f29ada79c82 - <unresolved>
   1: 0x7f29add1dcae - <unresolved>
   2: 0x7f29adbeae03 - <unresolved>
   3: 0x7f29adccf1d2 - <unresolved>
   4: 0x7f29adbcc548 - <unresolved>
   5: 0x7f29adb6e092 - <unresolved>
   6: 0x7f29adbdf629 - <unresolved>
   7: 0x7f29adcc1a14 - <unresolved>
   8: 0x7f29adc509ea - <unresolved>
   9: 0x7f29adb2f8c3 - <unresolved>
  10: 0x7f29adc31f0d - <unresolved>
  11: 0x7f29ae16cfa9 - <unresolved>
  12: 0x7f29adc510e2 - <unresolved>

Add support for ingresses

Add support for Role bindings

Describe the bug
When running cargo install to install kdash, it'll fail to compile k8s-openapi:

  None of the v1_* features are enabled on the k8s-openapi crate.

  The k8s-openapi crate requires a feature to be enabled to indicate which version of Kubernetes it should support.

This is likely a configuration issue in kdash, and not a bug in k8s-openapi

To Reproduce

1. Run cargo install kdash
2. Observe

Expected behavior
cargo finishes successfully and kdash is installed

Screenshots
N,A.

Desktop (please complete the following information):

• OS and OS version: [e.g. macOS 10.1 / Fedora 34 / WIndows 10] Ubuntu 20.04 under WSL2 under Windows 10
• Terminal name and version [e.g. Tilix, Yakuake, Gnome Terminal, Konsole, iTerm, Windows CMD] Windows Terminal
• Shell name and version [e.g. bash, zsh, fish, powershell] Bash GNU bash, version 5.0.17(1)-release (x86_64-pc-linux-gnu)
• Kubectl Client Version [e.g. 1.19] 1.21
• Kubectl Server Version [e.g. 1.19] 1.21
• KDash version [e.g. 0.0.8] Tested on:

Fails on:

1. 0.2.3 (latest)
2. 0.2.2
3. 0.2.1
4. 0.2.0
5. 0.1.2

Works on:

1. 0.1.1 # Had to install libxcb-xfixes0-dev and libxcb-xfixes0 first.
2. 0.1.0

It appears the regression was thus introduced in 0.1.2

Additional context
Cargo version: cargo 1.55.0 (32da73ab1 2021-08-23)
rustc version: rustc 1.55.0 (c8dfcfe04 2021-09-06)
rustup version: rustup 1.24.3 (ce5817a94 2021-05-31)
stable toolchain

Full output:

tobias@DESKTOP-M130L88:~$ cargo install kdash --version 0.1.2
  Downloaded kdash v0.1.2
  Downloaded 1 crate (4.4 MB) in 2.25s
    Updating crates.io index
  Installing kdash v0.1.2
  Downloaded snafu v0.6.10
  Downloaded doc-comment v0.3.3
  Downloaded snafu-derive v0.6.10
  Downloaded dashmap v4.0.2
  Downloaded kube v0.56.0
  Downloaded kube-core v0.56.0
  Downloaded kube-runtime v0.56.0
  Downloaded k8s-openapi v0.11.0
  Downloaded 8 crates (5.4 MB) in 1.73s (largest was `k8s-openapi` at 5.3 MB)
   Compiling libc v0.2.102
   Compiling autocfg v1.0.1
   Compiling proc-macro2 v1.0.29
   Compiling unicode-xid v0.2.2
   Compiling syn v1.0.77
   Compiling cfg-if v1.0.0
   Compiling memchr v2.4.1
   Compiling log v0.4.14
   Compiling once_cell v1.8.0
   Compiling cc v1.0.70
   Compiling pin-project-lite v0.2.7
   Compiling serde_derive v1.0.130
   Compiling futures-core v0.3.17
   Compiling serde v1.0.130
   Compiling itoa v0.4.8
   Compiling bytes v1.1.0
   Compiling proc-macro-hack v0.5.19
   Compiling futures-task v0.3.17
   Compiling futures-channel v0.3.17
   Compiling lazy_static v1.4.0
   Compiling futures-sink v0.3.17
   Compiling proc-macro-nested v0.1.7
   Compiling ryu v1.0.5
   Compiling slab v0.4.4
   Compiling fnv v1.0.7
   Compiling pkg-config v0.3.20
   Compiling hashbrown v0.11.2
   Compiling bitflags v1.3.2
   Compiling pin-utils v0.1.0
   Compiling futures-io v0.3.17
   Compiling serde_json v1.0.68
   Compiling base64 v0.13.0
   Compiling adler v1.0.2
   Compiling matches v0.1.9
   Compiling foreign-types-shared v0.1.1
   Compiling openssl v0.10.36
   Compiling version_check v0.9.3
   Compiling crc32fast v1.2.1
   Compiling httparse v1.5.1
   Compiling percent-encoding v2.1.0
   Compiling tower-service v0.3.1
   Compiling try-lock v0.2.3
   Compiling parking_lot_core v0.8.5
   Compiling smallvec v1.6.1
   Compiling native-tls v0.2.8
   Compiling regex-syntax v0.6.25
   Compiling httpdate v1.0.1
   Compiling tinyvec_macros v0.1.0
   Compiling scopeguard v1.1.0
   Compiling openssl-probe v0.1.4
   Compiling unicode-width v0.1.9
   Compiling linked-hash-map v0.5.4
   Compiling tower-layer v0.3.1
   Compiling pin-project-internal v0.4.28
   Compiling k8s-openapi v0.11.0
   Compiling dtoa v0.4.8
   Compiling either v1.6.1
   Compiling unicode-bidi v0.3.6
   Compiling k8s-openapi v0.13.0
   Compiling static_assertions v1.1.0
   Compiling doc-comment v0.3.3
   Compiling unicode-segmentation v1.8.0
   Compiling untrusted v0.7.1
   Compiling spin v0.5.2
   Compiling strsim v0.8.0
   Compiling gimli v0.25.0
   Compiling vec_map v0.8.2
   Compiling ansi_term v0.11.0
   Compiling ppv-lite86 v0.2.10
   Compiling anyhow v1.0.44
   Compiling rustc-demangle v0.1.21
   Compiling termcolor v1.1.2
   Compiling smawk v0.3.1
   Compiling cassowary v0.3.0
   Compiling instant v0.1.11
   Compiling tokio v1.12.0
   Compiling num-traits v0.2.14
   Compiling futures-macro v0.3.17
   Compiling indexmap v1.7.0
   Compiling futures-util v0.3.17
   Compiling num-integer v0.1.44
   Compiling miniz_oxide v0.4.4
   Compiling openssl-src v111.16.0+1.1.1l
   Compiling tracing-core v0.1.20
   Compiling http v0.2.5
   Compiling ring v0.16.20
   Compiling backtrace v0.3.61
   Compiling foreign-types v0.3.2
   Compiling form_urlencoded v1.0.1
   Compiling proc-macro-error-attr v1.0.4
   Compiling proc-macro-error v1.0.4
   Compiling tinyvec v1.5.0
   Compiling lock_api v0.4.5
   Compiling textwrap v0.11.0
   Compiling yaml-rust v0.4.5
   Compiling itertools v0.10.1
   Compiling twox-hash v1.6.1
error: failed to run custom build command for `k8s-openapi v0.13.0`

Caused by:
  process didn't exit successfully: `/tmp/cargo-installG6ZlmT/release/build/k8s-openapi-80fb7a754af4404d/build-script-build` (exit status: 101)
  --- stderr
  thread 'main' panicked at '
  None of the v1_* features are enabled on the k8s-openapi crate.

  The k8s-openapi crate requires a feature to be enabled to indicate which version of Kubernetes it should support.

  If you're using k8s-openapi in a binary crate, enable the feature corresponding to the minimum version of API server that you want to support. It may be possible that your binary crate does not directly depend on k8s-openapi. In this case, add a dependency on k8s-openapi, then enable the corresponding feature.

  If you're using k8s-openapi in a library crate, add a dev-dependency on k8s-openapi and enable one of the features there. This way the feature will be enabled when buildings tests and examples of your library, but not when building the library itself. It may be possible that your library crate does not directly depend on k8s-openapi. In this case, add a dev-dependency on k8s-openapi, then enable the corresponding feature.

  Library crates *must not* enable any features in their direct dependency on k8s-openapi, only in their dev-dependency. The choice of Kubernetes version to support should be left to the final binary crate, so only the binary crate should enable a specific feature. If library crates also enable features, it can cause multiple features to be enabled simultaneously, which k8s-openapi does not support.

  If you want to restrict your library crate to support only a single specific version or range of versions of Kubernetes, please use the k8s_* version-specific macros to emit different code based on which feature gets enabled in the end.', /home/tobias/.cargo/registry/src/github.com-1ecc6299db9ec823/k8s-openapi-0.13.0/build.rs:9:42
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish...
error: failed to compile `kdash v0.1.2`, intermediate artifacts can be found at `/tmp/cargo-installG6ZlmT`

Caused by:
  build failed

Currently errors are shown in a popup and often it breaks UI.

• Show error popup only for panics/critical errors
• Show non-intrusive warning for other cases

Add support for Persistent Volume Claims

Implement the configmaps block for overview page

Implement the statefulsets block for overview page

Add support for Persistent volumes

Hey there,

First of all, loving the project so far! Keep up the awesome work.

I'm getting everything from the cluster, pods, etc all works file. But metrics, i.e cpu and memory show 0, which I doubt is correct.
What is required in terms of (special) K8s configuration to get these two metrics working?

Thanks!

Edit I'm on K8s 1.20

Log streaming seems to be broken, possibly rewrite log streaming to be more reliable as its quite buggy now

Related to #6

Add a command to run describe and show output for implemented resources

Ideally this should be done as generic as possible

Many TUI programs will use hjkl as an alternate way to use the arrow keys, following the vim-style of keybindings. I noticed that kdash does not currently have any bindings for hjkl, so it'd be awesome to see these added as arrow-key alternatives.

Is your feature request related to a problem? Please describe.
My muscle memory is programmed for hjkl rather than left-down-up-right

Describe the solution you'd like
Adding new keybindings for h = left, j = down, k = up, and l = right

Describe the bug
A clear and concise description of what the bug is.

I see Error from network dispatch channel closed when I launch kdash, this is printed repeatedly on the screen.
Is this because of configuration?
I'm running Kubernetes using Azure Kubernetes Service.

To Reproduce
Steps to reproduce the behavior or a screencast

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS and OS version: [e.g. macOS 10.1 / Fedora 34 / WIndows 10]
• Terminal name and version [e.g. Tilix, Yakuake, Gnome Terminal, Konsole, iTerm, Windows CMD]
• Shell name and version [e.g. bash, zsh, fish, powershell]
• Kubectl Client Version [e.g. 1.19]
• Kubectl Server Version [e.g. 1.19]
• KDash version [e.g. 0.0.8]

Additional context
Add any other context about the problem here.

Implement the deployments block for overview page

Is your feature request related to a problem? Please describe.
Add a tab to support Jobs (Tab 8)

Currently when pod is running but Ready checks are not complete, normal status color is shown. It should be red instead

Describe the bug
Application crashes when exiting via the ESC key.

To Reproduce
Steps to reproduce the behavior or a screencast

1. Open application
2. Hit the ESC key
3. Crash

Expected behavior
Gracefully exit the application

Desktop (please complete the following information):

• OS and OS version: RHEL 8.4
• Terminal name and version: kitty
• Shell name and version: bash 4.4.20
• Kubectl Client Version: 1.20.5
• Kubectl Server Version: 1.20.5
• KDash version: 0.2.0

As suggested here kube-rs/kube#492

Add support for Roles

When streaming container logs, the network thread gets blocked for any subsequent calls (when going back and selecting a new container). Seems like when the try_next on the logs stream waits for a server response (incase of a container that doesn't produce next line of log yet) the thread gets blocked

log_streaming_method: https://github.com/kdash-rs/kdash/blob/main/src/network/kube_api.rs#L394

Describe the bug

Report a crash report as it's asked when it happens.

To Reproduce
Steps to reproduce the behavior or a screencast

Perhaps I did something but I cannot reproduce the crash again doing what I remember that I did when it crashed.

I was in the utilization tab and I have several context configured.

Desktop (please complete the following information):

• OS and OS version Ubuntu 20.04 docker container with several tools installed
• Terminal name and version tmux 3.0a
• Shell name and version zsh 5.8 (x86_64-ubuntu-linux-gnu)
• Kubectl Client Version 1.17.14
• Kubectl Server Version 1.18.17-gke.1901
• KDash version 0.1.2

Additional context

Crash report content:

name = 'kdash'
operating_system = 'unix:Ubuntu'
crate_version = '0.1.2'
explanation = '''
Panic occurred in file '/home/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/tui-0.15.0/src/widgets/table.rs' at line 359
'''
cause = 'index out of bounds: the len is 72 but the index is 127'
method = 'Panic'
backtrace = '''

   0: 0x7f1102848c82 - <unresolved>
   1: 0x7f1102aeccae - <unresolved>
   2: 0x7f11029b9e03 - <unresolved>
   3: 0x7f1102a9e1d2 - <unresolved>
   4: 0x7f110299b548 - <unresolved>
   5: 0x7f110293d092 - <unresolved>
   6: 0x7f11029ae629 - <unresolved>
   7: 0x7f1102a90a14 - <unresolved>
   8: 0x7f1102a1f9ea - <unresolved>
   9: 0x7f11028fe8c3 - <unresolved>
  10: 0x7f1102a00f0d - <unresolved>
  11: 0x7f1102f3bfa9 - <unresolved>
  12: 0x7f1102a200e2 - <unresolved>'''

Is your feature request related to a problem? Please describe.
When I send a request to a service backed by a replicaset that has more than one pod, I cannot know in advance which pod will execute the request. I end up switching between all the pod backing the replicaset to find the one with the right logs. Or, if that is possible, I scale down the replicaset.

Describe the solution you'd like
For a replicaset, see the containers defined in the pod template. When one of those containers is selected, the merged logs for all the pods that run that container are shown in a single view, ordered by timestamp, with the pod name as a prefix.

Describe alternatives you've considered

• A quicker way to switch between logs of similar containers in a replicaset.
• Not having to select a container in a pod when I want to see its log. In a lot of cases a pod runs just a single (main) container.

Additional context
None.

Add support for Storage classes

Add support for cron jobs

• Stream logs/events
  • select/copy output
  • Containers
  • Services
  • Deployments
  • StatefulSets

Describe the bug
Running given docker command will fail to execute because no image is available for latest tag.

To Reproduce

$ docker run --rm -it -v ~/.kube/config:/root/.kube/config deepu105/kdash

docker: Error response from daemon: manifest for deepu105/kdash:latest not found: manifest unknown: manifest unknown.

Expected behavior
Being able to get the latest version without tag.

Add support for custom keymap using a config file

Describe the bug
Executing cargo install kdash to install the v0.2.3 crate fails during compilation

To Reproduce
Steps to reproduce the behavior:

1. Execute cargo install kdash

Expected behavior
Installation of the crate

Screenshots
The following is output during the install:

error: failed to run custom build command for `k8s-openapi v0.13.0`

Caused by:
  process didn't exit successfully: `/tmp/cargo-installJLFrYi/release/build/k8s-openapi-405af67896caa110/build-script-build` (exit status: 101)
  --- stderr
  thread 'main' panicked at '
  None of the v1_* features are enabled on the k8s-openapi crate.

  The k8s-openapi crate requires a feature to be enabled to indicate which version of Kubernetes it should support.

  If you're using k8s-openapi in a binary crate, enable the feature corresponding to the minimum version of API server that you want to support. It may be possible that your binary crate does not directly depend on k8s-openapi. In this case, add a dependency on k8s-openapi, then enable the corresponding feature.

  If you're using k8s-openapi in a library crate, add a dev-dependency on k8s-openapi and enable one of the features there. This way the feature will be enabled when buildings tests and examples of your library, but not when building the library itself. It may be possible that your library crate does not directly depend on k8s-openapi. In this case, add a dev-dependency on k8s-openapi, then enable the corresponding feature.

  Library crates *must not* enable any features in their direct dependency on k8s-openapi, only in their dev-dependency. The choice of Kubernetes version to support should be left to the final binary crate, so only the binary crate should enable a specific feature. If library crates also enable features, it can cause multiple features to be enabled simultaneously, which k8s-openapi does not support.

  If you want to restrict your library crate to support only a single specific version or range of versions of Kubernetes, please use the k8s_* version-specific macros to emit different code based on which feature gets enabled in the end.', /home/matt/.cargo/registry/src/github.com-1ecc6299db9ec823/k8s-openapi-0.13.0/build.rs:9:42
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish...
error: failed to compile `kdash v0.2.3`, intermediate artifacts can be found at `/tmp/cargo-installJLFrYi`

Desktop (please complete the following information):

• OS and OS version: Ubuntu 20.04
• Terminal name and version: Kitty
• Shell name and version: bash
• KDash version: v0.2.3

Additional context
Cargo looks to be retrieving a new version of the k8s-openapi crate than what kdash states via the Cargo.toml file. Which looks to be due to other dependencies requiring the newer version of the crate.

Describe the bug
If a file or path in KUBECONFIG env var is missing or kubeconfig file is blank, kdash exits with a crash report. It would be better if the missing kubeconfigs are either ignored or a cleaner error message is presented.

To Reproduce

1. Add a non-existing path, a path without a kubeconfig or a blank kubeconfig file in KUBECONFIG environment variable
2. Start kdash

Expected behavior

• Either: invalid config is ignored and kdash functions normally
• Or: clean error output stating missing kubeconfig path, instead of crash report

Desktop (please complete the following information):

• MacOS 11.5
• iTerm2 3.4.8
• Bash 5.1.8
• Kubectl Client Version 1.21.0
• Kubectl Server Version 1.19
• KDash version 0.2.3
• Installed from homebrew

After running for a while, the dashboard stuck inexplicably.

Add support for Cluster role bindings

Describe the bug
I use k3d to bootstrap a k8s cluster locally. When I now open kdash, the error
HyperError: error trying to connect: tcp connect error: Die angeforderte Adresse ist in diesem Kontext ungültig. (os error 10049)
appears after some seconds and I'm not able to see the resource overview. With other tools (kubectl, k9s) I can connect to the cluster without any problems.

Also, sometimes when I press Ctrl-C to close kdash after the previous mentioned error appeared, I get the following error in the cmd:

Traceback (most recent call last):
  File "<string>", line 1, in <module>
OSError: [Errno 22] Invalid argument
Exception ignored in: <_io.TextIOWrapper name='<stdout>' mode='w' encoding='cp1252'>
OSError: [Errno 22] Invalid argument

To Reproduce

1. Create a local k8s cluster using k3d cluster create
2. Start kdash using the kdash command
3. Wait a few seconds
4. See error

Expected behavior
The resource overview loads.

Screenshots

Desktop (please complete the following information):

• OS and OS version: Windows 10
• Terminal name and version: Windows CMD
• Shell name and version: -
• Kubectl Client Version: v1.21.0
• Kubectl Server Version: v1.20.5+k3s1
• KDash version: 0.0.8

Additional context

kubectl version
Client Version: version.Info{Major:"1", Minor:"21", GitVersion:"v1.21.0", GitCommit:"cb303e613a121a29364f75cc67d3d580833a7479", GitTreeState:"clean", BuildDate:"2021-04-08T16:31:21Z", GoVersion:"go1.16.1", Compiler:"gc", Platform:"windows/amd64"}
Server Version: version.Info{Major:"1", Minor:"20", GitVersion:"v1.20.5+k3s1", GitCommit:"355fff3017b06cde44dbd879408a3a6826fa7125", GitTreeState:"clean", BuildDate:"2021-03-31T06:21:52Z", GoVersion:"go1.15.10", Compiler:"gc", Platform:"linux/amd64"}

k3d version
k3d version v4.4.1
k3s version v1.20.5-k3s1 (default)

Is your feature request related to a problem? Please describe.
Add a tab to support DeamonSets (Tab 9)

Describe the bug
If the user of the active context does not have permission to enumerate other namespaces, etc., errors will be shown and no pods are listed in the current namespace even though it's permitted for the user

To Reproduce
Steps to reproduce the behavior or a screencast

• select a context with permission restrictions

Expected behavior

• resources that the user have permission to view will be shown
• resources that the user does not have permission to view will not be shown (perhaps a 'no permission' message be presented)

Desktop (please complete the following information):
MacOS 11.5
iTerm2 3.4.8
Bash 5.1.8
Kubectl Client Version 1.21.0
Kubectl Server Version 1.19
KDash version 0.2.3
Installed from homebrew

Add support for Service accounts

Add support for custom theme using a config file

Describe the bug
Node are missing for EKS

Desktop (please complete the following information):

• OS and OS version: Fedora 32
• Terminal name and version: Yakuake
• Shell name and version: zsh
• Kubectl Client Version: v1.17.17
• Kubectl Server Version [v1.20.7-eks]
• KDash version [0.2.3]

Additional context
Metrics are also not captured. Look for unhandled errors

Add support for replication controllers

Container logs are streamed now, but its not perfect, there are some issues that needs to be fixed

• Due to timeout and re-poll, there might be some random missing log lines. May be this can be fixed by recording last update time and sending the elapsed duration as since_seconds in LogParams
• The first 10 lines tailed may be can be buffered to show up immediately
• Randomly the wrong log appears, even though there is explicit check for id and container id is sent in LogParams. Need to investigate
• Repetitive logging on some workloads like wasm binaries and so on

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
Yes. cargo install kdash will fail on a fresh install of Ubuntu Desktop, with xorg-dev installed as per the README, because of missing dependencies

Describe the solution you'd like
A clear and concise description of what you want to happen.
The solution to the issue is to install libxcb-xfixes0-dev and libxcb-shape0-dev, the non--dev packages are not enough. The proposed solution is to add the following to the README for Ubuntu/Debian:

sudo apt install -y libxcb-xfixes0-dev and libxcb-shape0-dev

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
N.A.

Additional context
Add any other context or screenshots about the feature request here.

Output from rustc:

   Compiling kdash v0.2.4
error: linking with `cc` failed: exit status: 1
  |
  = note: "cc" "-m64" "/tmp/cargo-installGcVkvt/release/deps/kdash-3cd074a07c9a7e61.kdash.d81f41e3-cgu.0.rcgu.o" "-Wl,--as-needed" "-L" "/tmp/cargo-installGcVkvt/release/deps" "-L" "/tmp/cargo-installGcVkvt/release/build/openssl-sys-8b6d1c8eda31ec5e/out/openssl-build/install/lib" "-L" "/tmp/cargo-installGcVkvt/release/build/ring-7cd5715780f3a214/out" "-L" "/home/tobias/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-Wl,-Bstatic" "/tmp/rustciKrNKZ/libopenssl_sys-91ac39aed5aff684.rlib" "/tmp/rustciKrNKZ/libring-e3238ae251d7e213.rlib" "-Wl,--start-group" "-Wl,--end-group" "/home/tobias/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcompiler_builtins-dd7db1bec6909f24.rlib" "-Wl,-Bdynamic" "-lxcb" "-lxcb-render" "-lxcb-shape" "-lxcb-xfixes" "-lgcc_s" "-lutil" "-lrt" "-lpthread" "-lm" "-ldl" "-lc" "-Wl,--eh-frame-hdr" "-Wl,-znoexecstack" "-L" "/home/tobias/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-o" "/tmp/cargo-installGcVkvt/release/deps/kdash-3cd074a07c9a7e61" "-Wl,--gc-sections" "-pie" "-Wl,-zrelro" "-Wl,-znow" "-Wl,-O1" "-nodefaultlibs"
  = note: /usr/bin/ld: cannot find -lxcb-shape
          /usr/bin/ld: cannot find -lxcb-xfixes
          collect2: error: ld returned 1 exit status

Add support for Network policies

Add support for Cluster roles

The ready state count seems to be wrong when the pod is in pending status

Workloads

• Pods
• Deployments
• Replica sets
• Stateful sets
• Jobs #35
• Cron Jobs #45
• Daemon sets #34
• Replication Controllers #46

Service

• Services
• Ingresses #47

Config/Storage

• Config Maps
• Secrets #48
• Persistent Volume Claims #49
• Storage classes #50

Cluster

• Nodes
• Namespaces
• Cluster roles #51
• Cluster role bindings #52
• Network policies #53
• Persistent volumes #54
• Role bindings #55
• Roles #56
• Service accounts #57