Skip to content

Latest commit

 

History

History
78 lines (73 loc) · 7.26 KB

cli-roadmap.md

File metadata and controls

78 lines (73 loc) · 7.26 KB
Raw

Kubernetes CLI/Configuration Roadmap

See also issues with the following labels:

  1. 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
  2. Finish rolling update #1353
  3. Friendly to auto-scaling #2863
  4. Rollback (make rolling-update reversible, and complete an in-progress rolling update by taking 2 replication controller names rather than always taking a file)
  5. Rollover (replace multiple replication controllers with one, such as to clean up an aborted partial rollout)
  6. 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)
  7. Use readiness #620
  8. Perhaps factor this in a way that it can be shared with Openshift’s deployment controller
  9. Rolling update service as a plugin
  10. 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> ...
  11. Improved pretty printing of endpoints, such as in the case that there are more than a few endpoints
  12. Service address/port lookup command(s)
  13. List supported resources
  14. Swagger lookups #3060
  15. --name, --name-suffix applied during creation and updates
  16. --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.
  17. --annotations and opinionated annotation injection: --description, --revision
  18. Imperative updates. We'll want to optionally make these safe(r) by supporting preconditions based on the current value and resourceVersion.
  19. annotation updates similar to label updates
  20. other custom commands for common imperative updates
  21. more user-friendly (but still generic) on-command-line json for patch
  22. We also want to support the following flavors of more general updates:
  23. 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
  24. diff/dryrun: Compare new config with current Spec #6284
  25. 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.
  26. --dry-run for all commands
  27. Support full label selection syntax, including support for namespaces.
  28. Wait on conditions #1899
  29. 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)
  30. 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. #5906
  31. Easy generation of clean configuration files from existing objects (including containers -- podex) -- remove readonly fields, status
  32. Export from one namespace, import into another is an important use case
  33. Derive objects from other objects
  34. pod clone
  35. rc from pod
  36. --labels-from (services from pods or rcs)
  37. Kind discovery (i.e., operate on objects of all kinds) #5278
  38. A fairly general-purpose way to specify fields on the command line during creation and update, not just from a config file
  39. 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, ... #5280
  40. Need schema registry, and some way to invoke generator (e.g., using a container)
  41. Convert run-container to API-based generator
  42. Transformation framework
  43. More intelligent defaulting of fields (e.g., #2643)
  44. Update preconditions based on the values of arbitrary object fields.
  45. Deployment manager compatibility on GCP: #3685
  46. Describe multiple objects, multiple kinds of objects #5905
  47. Support yaml document separator #5840

TODO:

  • watch
  • attach #1521
  • image/registry commands
  • do any other server paths make sense? validate? generic curl functionality?
  • template parameterization
  • dynamic/runtime configuration

Server-side support:

  1. Default selectors from labels #1698
  2. Stop #1535
  3. Deleted objects #2789
  4. Clone #170
  5. Resize #1629
  6. Useful /operations API: wait for finalization/reification
  7. List supported resources #2057
  8. Reverse label lookup #1348
  9. Field selection #1362
  10. Field filtering #1459
  11. Operate on uids