Open izelnakri opened 6 years ago
Maybe a good idea
/kind feature /sig cli /area kubectl /priority P2
Specifically I would expect colorization on get -o yaml
and get -o json
. At least for the latter, you can work around this by
kubectl get -o json $type $name | jq .
@jglick as a work around you can use something like https://www.npmjs.com/package/cli-highlight then run:
kubectl get -o json $type $name | highlight
That's what I do currently :)
You could also use vim -R
to preview the contents with some (limited) color highlighting
kubectl get $type $name | vim -R -c 'set syntax=yaml' -
since that is a lot to type, you may want to wrap that in a bash function
function vaml() {
vim -R -c 'set syntax=yaml' -;
}
then you can simply pipe to the function
kubectl get $type $name | vaml
This would be really helpful to see the difference between "Pending" and "Running" on get pods
. Right now they're hard to distinguish:
Running
Running
Running
Pending
Running
Running
It would be great to highlight pods in "kubectl get pods" where # of ready containers < total # of containers
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale
.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close
.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /lifecycle stale
/remove-lifecycle stale
This would be so helpful. Anyone working on a PR for this?
Having colorized output for kubectl get nodes would be fantastically helpful.
@geekofalltrades I use this:
GREP_COLOR='01;32' egrep --color=always 'Running|$' | GREP_COLOR='01;33' egrep --color=always 'ContainerCreating|$' | GREP_COLOR='01;33' egrep --color=always 'Terminating|$' | GREP_COLOR='01;31' egrep --color=always 'Error|$' | GREP_COLOR='01;31' egrep --color=always 'CrashLoopBackOff|$' | GREP_COLOR='01;31' egrep --color=always 'ImagePullBackOff|$' | GREP_COLOR='01;33' egrep --color=always 'Pending|$'
save it as a file lets say k8s_color
and then:
kubectl get pods | source k8s_color
I know its not elegant solution but it gets the job done
Any news on this?
As a work around you can use bat then run:
$ kubectl get pods -o yaml | bat -l yaml
Another weird work around
kubectl get pods | ccze -A -o nolookups
It would be great if someone writes a "kubernetes plugin" for CCZE :)
Or in alternative you could try yh for YAML output
$ kubectl get pods -o yaml | yh
This issue is opened for almost 2 years. Is it on the roadmap?
I am currently using zsh instead of bash and antigen to manage zsh "plugins", one of them is "antigen bundle c-castillo/ccze" which resides in github.com/c-castillo/ccze
for kubectl get X color I have added the jq plugin to zsh so I use kubectl "-o json" and then press ALT-J and I Can see the colors for the json output of kubectl command, and to stuff with it using jq. maybe yq can be added to the mix @andreazorzetto
I think it would be nice to start from there since handy shortcuts can be made and kubectl can be added to a list of commands ccze can process, thought I haven't checked how it manages the rules for the coloring.
here's my current .zshrc :
source ~/antigen.zsh
antigen bundle zsh-users/zsh-syntax-highlighting
antigen bundle reegnz/jq-zsh-plugin
antigen bundle c-castillo/ccze
export PATH=/snap/bin:$PATH
set -g mouse on
powerline-daemon -q
#tmux new
source /usr/share/powerline/bindings/zsh/powerline.zsh
POWERLINE_CONFIG_COMMAND=powerline-config
#powerline-config tmux setup
# Set up the prompt
source /usr/share/powerlevel9k/powerlevel9k.zsh-theme
autoload -Uz promptinit
promptinit
prompt adam1
setopt histignorealldups sharehistory
# Use emacs keybindings even if our EDITOR is set to vi
bindkey "\033[1~" beginning-of-line
bindkey "\033[4~" end-of-line
# Keep 1000 lines of history within the shell and save it to ~/.zsh_history:
HISTSIZE=1000
SAVEHIST=10000
HISTFILE=~/.zsh_history
# Use modern completion system
autoload -Uz compinit
compinit
zstyle ':completion:*' auto-description 'specify: %d'
zstyle ':completion:*' completer _expand _complete _correct _approximate
zstyle ':completion:*' format 'Completing %d'
zstyle ':completion:*' group-name ''
zstyle ':completion:*' menu select=2
eval "$(dircolors -b)"
zstyle ':completion:*:default' list-colors ${(s.:.)LS_COLORS}
zstyle ':completion:*' list-colors ''
zstyle ':completion:*' list-prompt %SAt %p: Hit TAB for more, or the character to insert%s
zstyle ':completion:*' matcher-list '' 'm:{a-z}={A-Z}' 'm:{a-zA-Z}={A-Za-z}' 'r:|[._-]=* r:|=* l:|=*'
zstyle ':completion:*' menu select=long
zstyle ':completion:*' select-prompt %SScrolling active: current selection at %p%s
zstyle ':completion:*' use-compctl false
zstyle ':completion:*' verbose true
zstyle ':completion:*:*:kill:*:processes' list-colors '=(#b) #([0-9]#)*=0=01;31'
zstyle ':completion:*:kill:*' command 'ps -u $USER -o pid,%cpu,tty,cputime,cmd'
antigen apply
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale
.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close
.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /lifecycle stale
/remove-lifecycle stale
Just FYI I've made a CLI tool to do this. https://github.com/dty1er/kubecolor
Cheers @dty1er and thanks for sharing.
Would be good to have you join us for a future sig-cli meeting to talk potential for getting your work upstream.
https://github.com/kubernetes/community/tree/master/sig-cli#meetings
Hi @eddiezane . Wow nice! I am willing to join the meeting and want to talk about kubecolor with you guys. When will you have a next one?
@dty1er next meeting will be November 4th. You'll get a calendar invite if you join the mailing list.
Will join the next one!
This was discussed today.
Take away is we'll need to create a KEP and then determine the challenge of implementation and maintainer burden. Is this supported server side or client side?
Recording if anyone is interested https://youtu.be/NtmbMqWCbOI?t=1322
Starting working on writing KEP, will share the one once it's ready here
Any KEP in progress ? :-)
/cc dougsland
Sorry for the delay of my work. It is not forgotten but I'm just getting busy for my work :(
@dty1er Any updates? 🙏
Great job so far, really looking forward to an update!
I would like to see the option of the terminal color scheme (background and foreground colors) changing based on a cluster-scoped object that is read when the context is changed. If the object does not exist, nothing happens, if it does exist, the terminal is changed (maybe only a PS1 that flashed the prompt for instance). This would ensure that the user is reminded when their context is set to a critical cluster.
Given that this whole output coloring is a generic problem not specific to kubectl only (since columnar data presentation is also present elsewhere) did anyone think about splitting out this problem and solving it for the generic case?
I did a quick PoC on how to colorize any columnar data, but it's still very basic: https://github.com/reegnz/column-bling
Things I'd like to explore with such a tool are:
Im thinking developing such a generic tool would prove much more value than only embedding this colorizing feature into kubectl, and it shouldn't require all the KEP process and a year to wait until it lands in k8s.
If you're using the fish shell and bat, you can define a function like:
function kat
command kubectl get $argv -o yaml | bat -l yaml
end
You could also use yh
mentioned above instead of bat
, of course.
or
kubectl … | yq e -P
Possibly related, but there appears to be a Colors
property on Config.Preferences
https://github.com/kubernetes/kubernetes/blob/cd83d89ac94c5b61fdd38840098e7223e5af0d34/staging/src/k8s.io/client-go/tools/clientcmd/api/types.go#L58-L60
I can't find anywhere this is actually used though.
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.
This bot triages issues and PRs according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/lifecycle rotten
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
/remove-lifecycle stale
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.
This bot triages issues and PRs according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/lifecycle rotten
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
/remove-lifecycle stale
A related PR: https://github.com/kubernetes/kubernetes/pull/108210
This generic colorizer is also a nice solution for adding some color to kubectl tabular output (and other cli tools as well): https://github.com/garabik/grc
It works with kubectl out of the box, eg. alias kubectl=grc kubectl
It then colors yaml, json and tabular output, and even the help output!
For colorization of json and yaml outputs I usually go straight into vim though:
kubectl get pod pod-name -o yaml | vim -c 'set ft=yaml' -
or
kubectl get pod pod-name -o json | vim -c 'set ft=json' -
I do prefer a more unix-y philosophy with piping and generic tools doing the majority of the work, and maybe most users needs are fully met with such solutions rather than bloating all tools with colorizing code. Although I am totally in favour of built-in colorizing, don't get me wrong. :) But until then, there are some solutions out there.
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.
This bot triages issues and PRs according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/lifecycle rotten
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
/remove-lifecycle stale
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.
This bot triages issues and PRs according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/lifecycle rotten
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
/remove-lifecycle stale
/lifecycle active
is this feature is been included?
currently manually piping to yq
FEATURE REQUEST:
Currently kubectl outputs are pretty boring without a color:
Adding color to them will make them easier to read. Each key could be colored based on its indentation level. Each key/value pair in labels,annotations,taints etc could be colored differently as well.