Proposal: Package kurl as a kubectl plugin

Proposal: Package kURL as a kubectl plugin

Today, for kURL to be useful, the kurl.sh site is required. The site is where anyone can upload a new kURL spec, and this site serves the installs scripts and the handles building and serving airgap packages. This proposal is to explore ways to enhance kURL to be more useful as a standalone tool.

If we package kURL as a kubectl plugin, then it will be possible to use it locally. This would support both online and offline capabilities and create new ways to run kURL.

Installing a new cluster

Given a kURL spec saved locally as a file named my-cluster.yaml, installing on the local machine could be as easy as:

$ kubectl kurl apply -f ./my-cluster.yaml

This will continue to support URLs on remote servers and even the kurl.sh site:

$ kubectl kurl apply -f https://kurl.sh/latest

Upgrading a cluster

Once a kURL cluster is running, if the my-cluster.yaml is updated (version numbers, new add-on, etc), the change could be applied to the cluster with:

$ kubectl kurl apply -f ./my-cluster.yaml

We should also support a dry-run on the upgrade command:

$ kubectl kurl apply -f ./my-cluster.yaml --dry-run

In this mode, the output is printed, but no changes are applied to the cluster. This is useful to detect when there are changes, or to see what these changes are.

Building Airgap

If you have the kURL plugin installed locally (on your workstation), you could build a new airgap package for server-side installation using:

$ kubectl kurl build -f ./my-cluster.yaml

This will create a file named my-cluster.tar.gz that contains the required packages and artifacts for the cluster described in my-cluster.yaml. Running build will require internet access as it will download and collect the artifacts into a single package. This can be run on a DMZ, in a CI service, or even in-cluster (no root access is needed).

Transfering this file to the server, it can be installed via:

$ kubectl kurl apply -f ./my-cluster.tar.gz

The plugin will detect that this is a tar.gz, not a yaml file, and will extract and run offline. No outbound internet access will be required or attempted.

Implementation

This should be written in go, and packaged as a krew plugin for distribution in the krew index. The build command already exists as a go package in kURL. The apply command would have to be written, since that's currently a shell script. We could use the shell script as times, and interact with the cluster using client-go when needed also.

Questions

• Why kubectl plugin instead of a binary that's installable via brew/snap/etc?
  For ease of distribution across multiple platforms.

• Should the plugin be able to execute client side? For example, if I turn on new EC2 instance, can I run kubectl kURL from my workstation to install?
  Possibly. I think starting with "localhost" as the target is incredibly useful.

• What about Cluster API, doesn't that project handle some of this also?
  There is some overlap between clusterapi and kURL. kURL should support cluster api natively. The big difference is that kURL supports add-ons, while cluster-api provides a declarative way to deploy a cluster.

• What other questions?

Start by reviewing the existing Go package for the build command and the current shell script for apply, which the proposal identifies as the implementation entry points. Clarify the plugin scope, offline and online behavior, dry-run expectations, and krew distribution before work begins; done would require an agreed design and implementation plan.