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.
-
-
Replying to @caffeinepresent @AlexB138
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.1 reply 0 retweets 0 likes -
Replying to @caffeinepresent @AlexB138 and
The OpenShift doc text makes it sound like Kubernetes Deployment is a lineal descendant of OpenShift DeploymentConfig.
2 replies 1 retweet 1 like -
Fair enough! I'm too ignorant on the topic to know for certain either way.
1 reply 0 retweets 0 likes -
Always a ton of nuance here - a lot of DC design was inspired by heroku deployments, but key difference early was deployment tries forever and a DC stops if they can’t rollout.
1 reply 0 retweets 1 like -
Replying to @smarterclayton @AlexB138 and
Over time they both evolved closer - today if you don’t want hooks or custom rollout logic deployments are better. We also haven’t evolved deployments much in the past few years - it’s possible it’s time for some new workload controller experiments in the wild
1 reply 0 retweets 0 likes -
What kinds of things do you think Deployments should handle (or handle better) that they don’t right now? Anything come to mind specifically?
1 reply 0 retweets 0 likes -
Condition summarization is huge - users should not have to look at a pod or RS to diagnose failure reason (stuck because PSP rejected, or quota, or because a secret doesn’t exist).
3 replies 0 retweets 2 likes -
Replying to @smarterclayton @caffeinepresent and
I do not like that deployments reconcile RS (so you can’t have an admission webhook that resolves a tag to a digest on an RS). DCs don’t do that which allows admission to mutate the body.
2 replies 0 retweets 2 likes -
Replying to @smarterclayton @caffeinepresent and
I would like to have the ability to gate deployments on pre and post conditions more easily - whether via a custom controller for specific deployments (deployment strategy “canary with traffic mirroring”) or something innate. Knative does some of this but should be native
2 replies 0 retweets 1 like
One idea that has been floated is more general monitoring inputs, such as with custom metrics, analogous to HPA. For approaches that involve traffic shifting, some approaches are driven entirely by traffic, with autoscaling controlling replicas. Hybrid models are harder.
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.