Brian Grant

Yeah, Deployments originated in OpenShift and were ported to upstream, from my understanding.

The story I heard (and this was back in 2016ish, secondhand and in passing, so take however many grains of salt), was:

When the community decided to rework replica management, DeploymentConfig managing ReplicationControllers was proposed by the folks from Red Hat, but the community eventually went with a different proposal of Deployment managing a new resource called a ReplicaSet.

The key issue seems to be kubernetes/kubernetes#1743, which almost five years later reads as @smarterclayton proposing the adoption of DeploymentConfig as a result of existing discussion and @bgrant0607 taking off from there, paring it down and bending it into a different shape.

The OpenShift doc text makes it sound like Kubernetes Deployment is a lineal descendant of OpenShift DeploymentConfig.

Deployment was inspired by DeploymentConfig, but I wanted to make updates continuous and the rollout constraints intent-oriented. Rather than the typical rate limit and max-in-flight, I proposed minReadySeconds and maxUnavailable. It was a big effort to get it to beta in 1.2

I remember that, I was new to Kubernetes then and was going “aw man, I just learned this and they’re changing it already?” Little did I know...

I think the end result of deployments is the right model for most flows (try to keep forcing a rollout forever) - some DC mindset was colored by more conservative rollout mindsets in large enterprise deployment where trying forever felt too radical