The workloads API is an important concept to grasp in order to understand how managing objects has stabilized over the course of many releases in Kubernetes. In the early days of Kubernetes, pods and their workloads were tightly coupled with containers that shared the CPU, networking, storage, and life cycle events. Kubernetes introduced concepts such as replication, then deployment, and then labels, and helped manage 12-factor applications. StatefulSets were introduced as Kubernetes operators moved into stateful workloads.
Over time, the concept of the Kubernetes workload became a collective of several parts:
- Pods
- ReplicationController
- ReplicaSet
- Deployment
- DaemonSet
- StatefulSet
These pieces are the current state of the art for orchestrating a reasonable swath of workload types in Kubernetes, but unfortunately the API was spread across many different parts of the Kubernetes codebase. The solution to this was many months of hard work to centralize all of this code, after making many backwards compatibility breaking changes, into apps/v1 API. Several key decisions were made when making the move to apps/v1:
- Default selector behavior: Unspecified label selectors are used to default to an auto-generated selector culled from the template labels
- Immutable selectors: While changing selectors is useful in some cases for deployment, it has always been against Kubernetes recommendations to mutate a selector, so the change was made to enable promoted canary-type deployments and pod relabeling, which is orchestrated by Kubernetes
- Default rolling updates: The Kubernetes programmers wanted RollingUpdate to be the default form, and now it is
- Garbage collection: In 1.9 and apps/v1, garbage collection is more aggressive, and you won't see pods hanging around any more after DaemonSets, ReplicaSets, StatefulSets, or Deployments are deleted
If you'd like more input into these decisions, you can join the Apps Special Interest Group, which can be found here: https://github.com/kubernetes/community/tree/master/sig-apps:
For now, you can consider the workloads API to be stable and backwards compatible.