Hook into kubectl commandline as extension

[surajssd]

kubectl now has a way to allow any third party binary to hook into it to do advanced stuff. Using this we will have an ability to do conversion which is cluster aware.

For e.g. places where someone is referring to a secret or configMap we can check if it already exists in the cluster. Here we can also create secrets like passwords which is some random string and everyone wanted to use it refer to the same thing.
Related discussion around this can be found in this issue redhat-developer/opencompose#161

Another use case could be when someone wants to expose a kubernetes service we could simply look at the cluster and do our best possible thing to expose an app with least information given by user.
Related discussion around this can be found in this comment #22 (comment)

And tons of benefits that we get from being cluster aware as opposed to be a static convertor.

• K8s community meeting where this was discussed: video
• Meeting notes from above meeting: doc link
• Extension proposal in upstream:
  • old PR: Add a proposal for kubectl extension kubernetes/kubernetes#30086
  • new pr: Proposal: kubectl extension kubernetes/community#122
• Work on this is here:
  • kubectl binary plugins #37499
• Also helm has added support for plugin model: https://github.com/technosophos/helm-plugins

[concaf]

First off, @surajssd the issue is very detailed and has all the relevant links, it saved me a lot of time, thanks for that 👍

---

So, this behavior has no documentation, and reading through various PRs and commits, I figured out that kubectl kedge is not how the plugins work (for now), they work as kubectl plugin kedge.

Doing the following on kubectl >= v1.7.0 works -

$ cat ~/.kube/plugins/kedge/plugin.yaml 
name: "kedge"
shortDesc: "Concise Application Definition for Kubernetes"
command: "./kedge"

$ kubectl plugin kedge 
Define Kubernetes applications using Kubernetes constructs

Usage:
  kedge [command]

Available Commands:
  apply       Apply a configuration to a resource on the Kubernetes cluster. This resource will be created if it doesn't exist yet.
  create      Create the resource on the Kubernetes cluster
  delete      Delete the resource from the Kubernetes cluster
  generate    Generate Kubernetes resources from App definition
  version     Print the version of Kedge

Flags:
  -h, --help      help for kedge
  -v, --verbose   verbose output

Use "kedge [command] --help" for more information about a command.

But now what? Using kedge as part of a plugin, we can run some scripts before executing the kedge commands and make informed decisions, but we need to decide on the behavior that we want.

e.g. -

• check if secret exists in the cluster, if it does, populate it in the kedge file and then run "kedge generate"
• check if service with the same name exists, and if it does, then don't create the service

These are just random examples to give an idea on the sort of behavior we need to define.

So, what behavior do we want? ping @kedgeproject/maintainers

[surajssd]

First off: kedge generate should remain static, and do all the plugin magic/talk to cluster only when we are doing create, apply, delete.

WDYT ?

[concaf]

@surajssd yeah, I put in generate in there just to try it out. We need to decide on the input that we want from the cluster, parse it and then execute relevant commands.

[surajssd]

Use cases for kubernetes plugin:

• Yes we can now add support of envFrom for secrets as well, but it will only work when it is used as plugin: see issue Add support for envFrom for secrets #85 for more details

• You don't need to define a volume in volumeClaims if you are referring in pod, so here we check if the pvc is there in cluster already defined; but we will have to make sure that the root level volumes is written by user, since with volumeClaims we do auto population.

• If you are referring to a configMap from a env or envFrom we don't need the user to define it in file, we check in the cluster if this is already defined

If you look at these use-cases most of them are referring to things from other resources, here it becomes easy for user since she does not define bunch of things assuming it will exist in cluster with certain name, and we do checks.

[concaf]

Let's wait for this to become more stable and figure out the exact use cases for the plugin behavior. Lowering priority and unassigned myself for now.

[concaf]

We do not have a use case for this, yet.
priority--