feat: Enable kubetai logs CLI as krew plugin

[rxinui]

Description

Enable kubetail logs CLI to be used as a kubectl plugin using krew

Why

Lazyness is a well known traits among nerds. As a result, duplicating commands such as kubetail and kubectl that does similar thing might discourage devs/ops to try out kubetail. Therefore, integrating kubetail logs to kubectl as a pluging could improve the ADOPTION of kubetail.

Note: installation of kubetail logs should be done using

krew install kubetail

Benefits

kubetail logs can be seen as a kubectl logs on steroids. It enable more options and filters to the logs command.

[bavarianbidi]

👋 i can work on this - as i've done that already few times. Should be straight forward

[amorey]

I just had one quick thought on this. I think @rxinui has thought about it more.

Rather than adding a kubectl kubetail sub-command I thought it might be better to add separate kubectl head and kubectl tail commands so it works similar to head and tail in linux.

[bavarianbidi]

To get a plugin accepted as an official krew-plugin, we have to be sure to fulfill the krew naming guide

ATM i see the following issues:

• head and tail are not super specific (see Be specific in the naming guide)
• kubetail is repeating kube (see Avoid repeating kube[rnetes] in the naming guide)

[bavarianbidi]

• from a technical POV:
  As long as a binary in your $PATH is prefixed with kubectl- it will be executed as kubectl plugin.
  I've renamed the kubetail binary to kubectl-kubetail and with that i'm able to run k kubetail serve without any code-modifications.
• from a user POV:
  i've started using kubetail one week ago. And most of the time i just used the serve subcommand. For viewing logs on my terminal i mostly use stern or the built-in logs implementation. Personally i would be happy if i can have the power of all kubetail subcommands by installing kubetail via krew

[bavarianbidi]

Do krew plugins have an upgrade path?

short: yes

long:

The plugin description is done in a yaml file.
All official plugins are defined in the krew-index repo.
Whenever you publish a new version of your plugin, you can automatically raise a PR in that repo (for that case there is a dedicated github-action: https://github.com/rajatjindal/krew-release-bot?tab=readme-ov-file#example-when-using-go-releaser ).

Version-Bump PRs are merged automatically. Once the version-bump is merged, you can run kubectl krew upgrade (Update the local copy of the plugin index). With kubectl krew upgrade the new binary version will be installed.

more technical details can be found here: https://github.com/kubernetes-sigs/krew?tab=readme-ov-file#contributor-documentation

[bavarianbidi]

From the user POV what's the benefit of calling kubetail from kubectl kubetail instead of just kubetail?

Keeping kubetail updated is much more easier if it's a krew plugin. kubectl krew upgrade will upgrade all my plugins

[amorey]

Sounds good, at the very least this sounds like a good way make it easier for people to keep kubetail up-to-date.

[rxinui]

What would be the final command run then?

1. kubectl kubetail {cmd}
2. something else?

[bavarianbidi]

regarding the name: see my comments and the link to the krew naming scheme - https://github.com/orgs/kubetail-org/discussions/282#discussioncomment-13114781

[amorey]

kubetail is now available as a krew plugin kubernetes-sigs/krew-index#4892