"Kubernetes provides a first-class, native API object type in OpenShift Container Platform called Deployments. Deployments serve as a descendant of the OpenShift Container Platform-specific DeploymentConfig."
-
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
- Show replies
New conversation -
-
-
To be fair, DC was taking most of our early discussions about what deployments *might* look like and then prototyping them. I do think more workload controllers would be better than fewer - it’s super hard to do that correctly still. We’re still finding bugs in replicasets.
-
The learnings from Openshift were definitely valuable. Original upstream issue: http://issues.k8s.io/503 . And, yes, there are still known bugs in ReplicaSet, such ashttp://issues.k8s.io/22061
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.