Home Explore Blog CI



kubernetes

2nd chunk of `content/en/blog/_posts/2018-01-00-Core-Workloads-Api-Ga.md`
2c85ea998cd4f972e55fca12697cde69f72b80863ea8fc500000000100000973
![](https://lh5.googleusercontent.com/0T36knExav8JAr41ict3EVOPOqaIJPMBQrOT2N5jehXw_12jEILD87tKW8BvaK2UCOtCHzS700Oki8Fxja3bF37J3eceanEBjbHpRsATBhC1y3P0mas7DvPeQjt6QmfYuNWDqZVl)  

...Or were we?



## Kubernetes 1.8 and apps/v1beta2
Pod, ReplicationController, ReplicaSet, Deployment, DaemonSet, and StatefulSet came to collectively be known as the core workloads API. We could finally orchestrate all of the things, but the API surface was spread across three groups, had many inconsistencies, and left users wondering about the stability of each of the core workloads kinds. It was time to stop adding new features and focus on consistency and stability.  

Pod and ReplicationController were at GA stability, and even though you can run a workload in a Pod, it’s a nucleus primitive that belongs in core. As Deployments are the recommended way to manage your stateless apps, moving ReplicationController would serve no purpose. In Kubernetes 1.8, we moved all the other core workloads API kinds (Deployment, DaemonSet, ReplicaSet, and StatefulSet) to the apps/v1beta2 group version. This had the benefit of providing a better aggregation across the API surface, and allowing us to break backward compatibility to fix inconsistencies. Our plan was to promote this new surface to GA, wholesale and as is, when we were satisfied with its completeness. The modifications in this release, which are also implemented in apps/v1, are described below.



### Selector Defaulting Deprecated
In prior versions of the apps and extensions groups, label selectors of the core workloads API kinds were, when left unspecified, defaulted to a label selector generated from the kind’s template’s labels.  

This was completely incompatible with strategic merge patch and kubectl apply. Moreover, we’ve found that defaulting the value of a field from the value of another field of the same object is an anti-pattern, in general, and particularly dangerous for the API objects used to orchestrate workloads.



### Immutable Selectors
Selector mutation, while allowing for some use cases like promotable Deployment canaries, is not handled gracefully by our workload controllers, and we have always [strongly cautioned users against it](/docs/concepts/workloads/controllers/deployment/#label-selector-updates). To provide a consistent, usable, and stable API, selectors were made immutable for all kinds in the workloads API.  

Title: Kubernetes 1.8 and apps/v1beta2: Towards Consistency and Stability
Summary
In Kubernetes 1.8, core workloads API kinds (Deployment, DaemonSet, ReplicaSet, and StatefulSet) were moved to the apps/v1beta2 group version to provide a better API aggregation and address inconsistencies. This move aimed to focus on consistency and stability rather than adding new features. The release deprecated selector defaulting, which was incompatible with strategic merge patch and kubectl apply, and introduced immutable selectors to prevent problematic mutations and provide a more consistent and stable API.