Add ANSI colors to kubectl describe and other outputs

izelnakri commented 6 years ago

FEATURE REQUEST:

Currently kubectl outputs are pretty boring without a color:

kubetest_ _-bash_ _181x31

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.

cnfatal commented 6 years ago

Maybe a good idea

seans3 commented 6 years ago

/kind feature /sig cli /area kubectl /priority P2

jglick commented 5 years ago

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 .

bossjones commented 5 years ago

@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 :)

spuder commented 5 years ago

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

geekofalltrades commented 5 years ago

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

mdz commented 5 years ago

It would be great to highlight pods in "kubectl get pods" where # of ready containers < total # of containers

fejta-bot commented 5 years ago

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

izelnakri commented 5 years ago

/remove-lifecycle stale

austinorth commented 5 years ago

This would be so helpful. Anyone working on a PR for this?

meltingrobot commented 5 years ago

Having colorized output for kubectl get nodes would be fantastically helpful.

lukjaw commented 4 years ago

@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

TomaszKlosinski commented 4 years ago

Any news on this?

apemost commented 4 years ago

As a work around you can use bat then run:

$ kubectl get pods -o yaml | bat -l yaml

a0s commented 4 years ago

Another weird work around

kubectl get pods | ccze -A -o nolookups

It would be great if someone writes a "kubernetes plugin" for CCZE :)

andreazorzetto commented 4 years ago

Or in alternative you could try yh for YAML output

$ kubectl get pods -o yaml | yh

Comparison with or without yh

TomaszKlosinski commented 4 years ago

This issue is opened for almost 2 years. Is it on the roadmap?

gattytto commented 4 years ago

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

fejta-bot commented 4 years ago

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

izelnakri commented 4 years ago

/remove-lifecycle stale

hidetatz commented 4 years ago

Just FYI I've made a CLI tool to do this. https://github.com/dty1er/kubecolor

eddiezane commented 4 years ago

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

hidetatz commented 4 years ago

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?

eddiezane commented 3 years ago

@dty1er next meeting will be November 4th. You'll get a calendar invite if you join the mailing list.

hidetatz commented 3 years ago

Will join the next one!

eddiezane commented 3 years ago

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

hidetatz commented 3 years ago

Starting working on writing KEP, will share the one once it's ready here

miton18 commented 3 years ago

Any KEP in progress ? :-)

dougsland commented 3 years ago

/cc dougsland

hidetatz commented 3 years ago

Sorry for the delay of my work. It is not forgotten but I'm just getting busy for my work :(

sviatoslav-somov commented 3 years ago

@dty1er Any updates? 🙏

nickjmv commented 3 years ago

Great job so far, really looking forward to an update!

briantopping commented 3 years ago

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.

reegnz commented 3 years ago

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:

being able to specify what color each column should be
being able to specify how the header looks like
specifying various regexes per column to vary the color (eg. if Status column value is 'Evicted', then color it red, else keep the default)

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.

asymmetric commented 3 years ago

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.

jglick commented 3 years ago

or

kubectl … | yq e -P

brianpursley commented 3 years ago

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.

k8s-triage-robot commented 3 years ago

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:

After 90d of inactivity, lifecycle/stale is applied
After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

Mark this issue or PR as fresh with /remove-lifecycle stale
Mark this issue or PR as rotten with /lifecycle rotten
Close this issue or PR with /close
Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

izelnakri commented 3 years ago

/remove-lifecycle stale

k8s-triage-robot commented 2 years ago

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:

After 90d of inactivity, lifecycle/stale is applied
After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

Mark this issue or PR as fresh with /remove-lifecycle stale
Mark this issue or PR as rotten with /lifecycle rotten
Close this issue or PR with /close
Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

izelnakri commented 2 years ago

/remove-lifecycle stale

sftim commented 2 years ago

reegnz commented 2 years ago

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.

k8s-triage-robot commented 2 years ago

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:

After 90d of inactivity, lifecycle/stale is applied
After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

Mark this issue or PR as fresh with /remove-lifecycle stale
Mark this issue or PR as rotten with /lifecycle rotten
Close this issue or PR with /close
Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

izelnakri commented 2 years ago

/remove-lifecycle stale

k8s-triage-robot commented 2 years ago

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:

After 90d of inactivity, lifecycle/stale is applied
After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can: