mirror of https://github.com/k3s-io/k3s
7.6 KiB
7.6 KiB
Kubernetes CLI/Configuration Roadmap
See also issues with the following labels:
At least the first three issues should block 1.0.
- stop command in kubectl #2144: Gracefully terminate any object(s), to the extent currently possible. We also eventually want first-class support in the API for graceful termination. #1535
- Kind-based filtering on object streams -- only operate on the kinds of objects specified. This would make directory-based kubectl operations much more useful. Users should be able to instantiate the example applications using
kubectl create -f <example-dir> ... - Create services before other objects, or at least before objects that depend upon them. Namespace-relative DNS mitigates this some, but most users are still using service environment variables. #1768
- Pretty printing of endpoints
- Service address/port lookup command(s)
- Multiple objects on command line #3050
- Finish rolling update #1353
- Friendly to auto-scaling #2863
- Rollback (make rollingupdate reversible, and complete an in-progress rolling update by taking 2 replication controller names rather than always taking a file)
- Rollover (replace multiple replication controllers with one, such as to clean up an aborted partial rollout)
- Write a ReplicationController generator to derive the new ReplicationController from an old one (e.g.,
--image-version=newversion, which would apply a name suffix, update a label value, and apply an image tag) - Use readiness #620
- Perhaps factor this in a way that it can be shared with Openshift’s deployment controller
- Rolling update service as a plugin
- List supported API versions
- List supported resources
- Swagger lookups #3060
- --name, --name-suffix applied during creation and updates
- --labels and opinionated label injection: --app=foo, --tier={fe,cache,be,db}, --uservice=redis, --env={dev,test,prod}, --stage={canary,final}, --track={hourly,daily,weekly}, --release=0.4.3c2. Exact ones TBD. We could allow arbitrary values -- the keys are important. The actual label keys would be (optionally?) namespaced with kubectl.kubernetes.io/, or perhaps the user’s namespace.
- --annotations and opinionated annotation injection: --description, --revision
- Bulk updates (similar to get, create, delete)
- Imperative updates. We'll want to optionally make these safe(r) by supporting preconditions based on the current value and resourceVersion.
- label updates: addlabel, rmlabel, changelabel
- annotation updates: addannotation, rmannotation, changeannotation
- more user-friendly on-command-line json for patch
- We also want to support the following flavors of more general updates:
- whichever we don’t support: 1. safe update: update the full resource, guarded by resourceVersion precondition (and perhaps selected value-based preconditions) 1. forced update: update the full resource, blowing away the previous Spec without preconditions; delete and re-create if necessary
- diff/dryrun: Compare new config with current Spec
- submit/apply/reconcile/ensure/merge: Merge user-provided fields with current Spec. Keep track of user-provided fields using an annotation -- see #1702. Delete all objects with deployment-specific labels.
- --dry-run for all commands
- Support full label selection syntax, including support for namespaces.
- Wait on conditions #1899
- Make kubectl scriptable: make output and exit code behavior consistent and useful for wrapping in workflows and piping back into kubectl and/or xargs (e.g., dump full URLs?, distinguish permanent and retry-able failure, identify objects that should be retried)
- Here's an example where multiple objects on the command line and an option to dump object names only (
-q) would be useful in combination. - Easy generation of clean configuration files from existing objects (including containers -- podex) -- remove readonly fields, status
- Export from one namespace, import into another is an important use case
- Derive objects from other objects
- pod clone
- rc from pod
- --labels-from (services from pods or rcs)
- Kind discovery (i.e., operate on objects of all kinds) #3233
- A fairly general-purpose way to specify fields on the command line during creation and update, not just from a config file
- Extensible API-based generator framework (i.e. invoke generators via an API/URL rather than building them into kubectl), so that complex client libraries don’t need to be rewritten in multiple languages, and so that the abstractions are available through all interfaces: API, CLI, UI, logs, ...
- Need schema registry, and some way to invoke generator (e.g., using a container)
- Convert run-container to API-based generator
- Transformation framework
- More intelligent defaulting of fields (e.g., #2643)
- Update preconditions based on the values of arbitrary object fields.
- Deployment manager compatibility on GCP: #3685
TODO:
- watch
- ssh #1513
- attach #1521
- image/registry commands
- do any other server paths make sense? validate? generic curl functionality?
- template parameterization
- dynamic/runtime configuration
Server-side support:
Only finishing v1beta3 is a requirement for 1.0. The others are strong nice-to-haves.