Kops: Kops Plugin Library

[kris-nova]

What is a plugin?

A plugin would be any arbitrary executable path a user could implement. The two big use cases I see are

• Shell executable code
• Library implementation in go

Basically, we would offer avenues into the kops deployment lifecycle via controlled entry points.

Entry Points

• Before nodeup on instance (sync/async)
• After nodeup on instance (sync/async)
• After deploy on host (sync)

The user could define custom logic either through a controlled go interface implementation, or even through raw shell executable code.

All kops would have to do is execute the code, and recover if anything went wrong. In the case of sync vs async we could define if we want kops to wait for the plugin to finish running (and succeed) before moving on.

Plugin manifests

Keeping in the nature of k8s, we could abstract everything out into a plugin manifest for kops

Example 1 - shell commands

Say a user wants to execute a shell command on the server after nodeup has ran. They would have a snippet in their plugin manifest. Note that sync-enforce would tell us to run the plugin synchronously, and enforce any failures.

name: ex1
type: shell-exec
behavior: sync-enforce
command: "sudo apt-get update -y"

Example 2 - shell script

So a basic shell command wasn't enough. Let's just dump all of our post nodeup logic into a shell script, and see what happens. In this example we run the shell script asynchronously, and we tell kops not to worry if it fails or not.

Note: Notice how we could build in support for a few ways of getting a shell script. Either locally, from a repo, S3, etc..

name: ex2
type: shell-exec
behavior: async-bypass
script: "s3://path/to/your/script.sh"
#script: "https://rawgit.com/org/repo/branch/path/script.sh"
#script: "/path/on/local/filesystem/script.sh"

Example 3 - go interfaces

Okay, so we really need some custom logic here, that would be easy to turn on/off and potentially pass around as a vendored plugin. You realize that you will have to role your own kops binary, and frankly you don't care. You just wan't this to be easy, and to work.

In this example we pull some data out of kops, and use it for our own use case to write a custom tag on some resources in AWS. We have a little bit of plugin code, that we could vendor into kops.

type Plugin interface {
    Exec() error
}

type CustomTags struct {}
func (p *CustomTags) Exec(){
     tag := buildCustomTagFromKops() // Will use values found in-memory in kops at runtime to build a tag
     tagCluster(tag) // Will actually hit the AWS API with our custom tag
}

And of course we would need to update our manifest with

type: plugin # <-- This will tell kops to look for a plugin 
name: CustomTags # <-- This will tell kops that the plugin is called "CustomTags", we will need a struct defined.
behavior: sync-enforce

Bells and Whistles

Of course we could start to add features like timing out, and conditional logic.. but for a version 1.0 this makes it easy for the user to interface with kops. And makes it easier for users to share their work.

Imagine a world where we could pass plugins around in the community :)

Disclaimer

This is actually completely wrong to do in kops, and we of course (As supporters and maintainers) could offer little to no support on plugins.. This would be dependent on the community, and has a risk of becoming messy.

[aledbf]

@kris-nova the plugin feature of Go 1.8 look promising https://github.com/campoy/golang-plugins

[kris-nova]

@aledbf I have been watching that closely.. last I checked it only runs on Linux.. but yes ideally Plugins here would be fabulous ;)

[kris-nova]

Also might be worth looking into how helm has handled this:

https://github.com/kubernetes/helm/blob/master/docs/plugins.md

[mirague]

We would also love to see this feature available. It'd make it easier to install for example, monitoring agents on the machines.

[kris-nova]

I am currently working on coming up with a prototype using the avenues mentioned above and native Go plugins.. also trying to get plugins working on Darwin but there is a bug in the Go standard library bug preventing this in 1.8.. if I can find time I will try to contribute to getting this into 1.9 but we can always suggest containerizing everything for the time being (might be easier with plugins TBH)

https://github.com/golang/go/issues/18104

[igorvpcleao]

Hi @kris-nova,

Is Kops Plugin Library already available?
If so how can I use it?

Thanks in advance!

[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.

Prevent issues from auto-closing with an /lifecycle frozen comment.

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

[chrislovecnm]

Nobody has picked up this issue. Please submit a POC PR if you are interested

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

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 rotten
/remove-lifecycle stale

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close