3.9 KiB
PLEASE NOTE: This document applies to the HEAD of the source tree
If you are using a released version of Kubernetes, you should refer to the docs that go with that version.
The latest release of this document can be found [here](http://releases.k8s.io/release-1.3/docs/proposals/kubectl-extension.md).Documentation for other releases can be found at releases.k8s.io.
Kubectl Extension
Abstract
Allow kubectl to be extended to include other commands that can provide new functionality without recompiling Kubectl
Motivation and Background
Kubernetes is designed to be a composable and extensible system, with the ability to add new APIs and features via Third Party Resources
or API federation, by making the server provide functionality that eases writing generic clients, and by supporting other authentication
systems. Given that kubectl is the primary method for interacting with the server, some new extensions are difficult to make usable
for end users without recompiling that command. In addition, it is difficult to prototype new functionality for kubectl outside of the
Kubernetes source tree.
Ecosystem tools like OpenShift, Deis, and Helm add additional workflow around kubectl targeted at the end user. It is beneficial to encourage workflows to develop around Kubernetes without requiring them to be part of Kubernetes to both the end user community and the Kubernetes developer community.
There are many tools that currently offer CLI extension for the same reasons - Git and Heroku are two relevant examples in the space.
Proposal
Define a system for kubectl that allows new subcommands and subcommand trees to be added by placing an executable in a specific
location on disk, like Git. Allow third parties to extend kubectl by placing their extensions in that directory. Ensure that help
and other logic correctly includes those extensions.
A kubectl command extension would be an executable located in EXEC_PATH (an arbitrary directory to be defined that follows similar
conventions in Linux) with a name pattern like kubectl-COMMAND[-SUBCOMMAND[...]] with one or many sub parts. The presence of
a command extension overrides any built in command.
A key requirement is that the lookup be fast (since it would be invoked on every execution of kubectl) and so some true extension
behavior (such as complex inference of commands) may not be supported in order to reduce the complexity of the lookup.
Kubectl would lazily include the appropriate commands in preference to the internal command structure if detected (a user asking for
kubectl a b c would first check for kubectl-a-b-c, kubectl-a-b, or kubectl-a before loading the internal command).
All kubectl command extensions MUST:
- Support the
-hand--helpflags to display a help page - Respect the semantics of KUBECONFIG lookup (to be further specified)
All kubectl command extensions SHOULD:
- Follow the display and output conventions of normal kubectl commands.