They basically serve the same purpose, but Deployments move more of the "state" into the Kubernetes API controller. For example, the standard way to do a rolli

They basically serve the same purpose, but Deployments move more of the "state" into the Kubernetes API controller. For example, the standard way to do a rolling update using RCs is to create a new RC that is responsible for the updated pods, and then gradually increase/decrease the replica counts to reach the desired state. This is conceptually simple, but the downside is that the Kubernetes API doesn't know anything about the relationship between the old and new controllers. All the responsibility is pushed to the client. With Deployments, both the old and new configurations are first-class objects. So you can view the history of previous configurations, and you can query the progress of a rolling update. You also get better-defined behavior when multiple clients are trying to concurrently make changes, because Kubernetes can arbitrate between them at a higher level.