Add ANSI colors to kubectl describe and other outputs

[izelnakri]

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.

[cnfatal]

Maybe a good idea

[seans3]

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

[jglick]

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]

@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]

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]

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]

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

[fejta-bot]

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]

/remove-lifecycle stale

[austinorth]

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

[meltingrobot]

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

[lukjaw]

@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]

Any news on this?

[apemost]

As a work around you can use bat then run:

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

[a0s]

Another weird work around

kubectl get pods | ccze -A -o nolookups

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

[andreazorzetto]

Or in alternative you could try yh for YAML output

$ kubectl get pods -o yaml | yh

[TomaszKlosinski]

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

[gattytto]

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]

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]

/remove-lifecycle stale

[hidetatz]

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

[h3ct0rjs]

/remove-lifecycle rotten

[jainpratik163]

when this feature is coming?

[TomaszKlosinski]

Any updates?

[felipecrs]

Now that kubecolor is archived, I believe this is more important than ever. :)

[h3ct0rjs]

I agree completely with @felipecrs that we need to add support to this, this also helps people who have special eyes 👀 , this will increase the accessibility to kubectl.

[gurpalw]

workaround so far:
https://github.com/itaysk/kubectl-neat

alias in my .zshrc file:

alias kneat="kubectl neat | yq"

Then i pipe my get commands to kneat.

kubectl get nodes -l gitlab=true -o yaml | kneat

[WladyX]

workaround so far: https://github.com/itaysk/kubectl-neat

alias in my .zshrc file:

alias kneat="kubectl neat | yq"

Then i pipe my get commands to kneat.

kubectl get nodes -l gitlab=true -o yaml | kneat

Gold, thanks for sharing.

[h3ct0rjs]

This feature should be built-in. but in any case, is a good hack, thanks @WladyX

Best Regards,
H

[husanu]

/assign

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues 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 as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

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

/lifecycle stale

[ovk]

/remove-lifecycle stale

[abhimanyu003]

Sharing trick based on @spuder comment earlier but using bat: A cat(1) clone with wings.
https://github.com/sharkdp/bat

kubectl get $type $name -oyaml | cat -l yaml --paging=never

Alias

function vml() {
  cat -l yaml --paging=never
}

kubectl get $type $name -oyaml | vml

Output

PS: this is using gruvbox-dark theme from bat.
Also please note that here bat is aliased to cat alias cat='bat --paging=never' from the bat docs.

[felipecrs]

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

For reference, here's the new maintained one: https://github.com/kubecolor/kubecolor

[briantopping]

Maybe the answer we are looking for here is the ability to locally remap kubectl commands. Consider:

• The kubectl command tree is a standard, don't break that
• Local user customizations shouldn't need a different command tree (i.e. kubecolor) to do the same things
• Introducing aspects such as colorization may break environments that have script dependencies on CLI output

The ability to generically override commands as a part of the login context would cover these bases. A service account with no overrides would get raw output, users who had customizations would get their preferred output format without having to use a different command set.

A final tweak on this would be to allow krew to update the override config. So if someone installed kubecolor, existing commands would be automatically remapped upon installation without magic.

[felipecrs]

Honestly, I think that's overengineering. kubectl itself could output colors based on whether it is running in a terminal with color support or not. Like bat itself, which automatically disables color when being executed in things like pipes.

[briantopping]

kubectl itself could output colors based on whether it is running in a terminal with color support or not

Point taken, but one may want a completely different output for the same basic commands.

[bytebeast]

side wish, kinda wished that* kubectl describe *allowed output format, so that it can be piped to a any syntax highlighter

…

On Thu, Apr 18, 2024 at 1:33 PM Brian Topping ***@***.***> wrote: kubectl itself could output colors based on whether it is running in a terminal with color support or not Point taken, but one may want a completely different output for the same basic commands. — Reply to this email directly, view it on GitHub <#524 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AET32OXYPVUKJ7RW2I3A3HLY6AUZDAVCNFSM4FRPBD42U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMBWGUZDMOJQGEYQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues 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 as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

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

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues 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 as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

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

/lifecycle rotten

[ganievs]

/remove-lifecycle rotten