Skip to content

Latest commit

 

History

History
118 lines (101 loc) · 6.4 KB

roadmap.md

File metadata and controls

118 lines (101 loc) · 6.4 KB

Kubernetes Roadmap

Updated December 6, 2014

This document is intended to capture the set of supported use cases, features, docs, and patterns that we feel are required to call Kubernetes “feature complete” for a 1.0 release candidate.  This list does not emphasize the bug fixes and stabilization that will be required to take it all the way to production ready. This is a living document, and is certainly open for discussion.

Target workloads

Features for 1.0 will be driven by the initial set of workloads we intend to support.

Most realistic examples of production services include a load-balanced web frontend exposed to the public Internet, with a stateful backend, such as a clustered database or key-value store, so we will target such a workload for 1.0.

Which exact stateful applications are TBD. Candidates include:

  • redis
  • memcache
  • mysql (using master/slave replication)
  • mongo
  • cassandra
  • etcd
  • zookeeper

APIs

  1. Consistent v1 API. v1beta3 is being developed as the release candidate for the v1 API.
  2. Deprecation policy: Declare the project’s intentions with regards to expiring and removing features and interfaces, including the minimum amount of time non-beta APIs will be supported.
  3. Input validation: Validate schemas of API requests in the apiserver and, optionally, in the client.
  4. Error propagation: Report problems reliably and consistently, with documented behavior.
  5. Easy to add new controllers, such as per-node controller
  6. Replication controller: Make replication controller a standalone entity in the master stack.
  7. Pod templates: Proposal to make pod templates a first-class API object, rather than an artifact of replica controller #170
  8. Kubelet API should be well defined and versioned.
  9. Cloud provider API for managing nodes, storage, and network resources. #2770

Scheduling and resource isolation

  1. Resource requirements and scheduling: Use knowledge of resources available and resources required to make good enough scheduling decisions such that applications can start and run. #168

Images and registry

  1. Simple out-of-the box registry setup. #1319
  2. Easy to configure .dockercfg.
  3. Easy to deploy new code to Kubernetes (build and push).
  4. Predictable deployment via configuration-time image resolution. #1697

Storage

  1. Durable volumes: Provide a model for data with identity and lifetime independent of pods. #1515, #598, #2609
  2. Pluggable volume sources and devices: Allow new kinds of data sources and/or devices as volumes. #945, #2598

Networking and naming

  1. DNS: Provide DNS for services, internal and external. #2224, #1261
  2. External IPs: Make Kubernetes services externally reachable. #1161
  3. Re-think the network parts of the API: Clean factoring of a la carte networking functionality. #2585
  4. Out-of-the-box, kick-the-tires networking implementation. #1307

Authentication and authorization

  1. Auth[nz] and ACLs: Have a plan for how the API and system will express:
  2. Identity & authentication
  3. Authorization & access control
  4. Cluster subdivision, accounting, & isolation
  5. Support for pluggable authentication implementation and authorization polices
  6. Implemented auth[nz] for:
    1. admin to master and/or kubelet
    2. user to master
    3. master component to component (e.g., controller manager to apiserver): localhost in 1.0
    4. kubelet to master

Usability

Documentation

  1. Documnted reference cluster architecture
  2. Accurate and complete API documentation

Cluster turnup, scaling, management, and upgrades

  1. Easy cluster startup
  2. Automatic node registration
  3. Configuring k8s 1. Move away from flags in master 2. Node configuration distribution
    1. Kubelet configuration
    2. dockercfg
  4. Easy cluster scaling (adding/removing nodes)
  5. Kubernetes can be upgraded
  6. master components
  7. Kubelets
  8. OS + kernel + Docker

Workload deployment and management

  1. Kubectl fully replaces kubecfg #2144
  2. Graceful termination. #1535
  3. Resize. #1629
  4. Config generators integrated into kubectl.
  5. Rolling updates. #1353
  6. Kubectl can perform bulk operations (e.g., delete) on streams of API objects #1905

Productionization

  1. Scalability
  2. 100 nodes for 1.0
  3. 1000 nodes by summer 2015
  4. HA master -- not gating 1.0
  5. Master election
  6. Eliminate global in-memory state 1. IP allocator 2. Operations
  7. Sharding 1. Pod getter
  8. Kubelets need to coast when master down
  9. Don’t blow away pods when master is down
  10. Testing
  11. More/better/easier E2E
  12. E2E integration testing w/ OpenShift
  13. More non-E2E integration tests
  14. Long-term soaking / stress test
  15. Backward compatibility 1. API 2. etcd state
  16. Release cadence and artifacts
  17. Regular stable releases on a frequent timeline (2 weeks).
  18. Automatic generation of necessary deployment artifacts. It is still TBD if this includes deb and RPMs. Also not clear if it includes docker containers.
  19. Export monitoring metrics (instrumentation)
  20. Bounded disk space on master and kubelets
  21. GC of unused images