It's not really true that "users cannot control which nodes their pods run on" -- you can use node selector in your Pod.Spec. The reason why ReplicationController is sub-optimal for this use case is that you can't know what value to set for replicas in the RC spec, since the size of the cluster (or size of the subset of the cluster defined by the node selector) may vary over time.

Will change.

I think that the update needs to be explained a bit more carefully. Will there be a rolling update to limit the number of instances that are changing? The description of the daemon controller's operation doesn't seem to allow for that.

We'd probably describe this in deployment terminology as MaxAvailability:
80% and MaxSurge: 0. The deployment process would need a way to make the
daemon controller "inert" or "inactive", create a new daemon controller,
and then selectively delete old pods.

On Wed, Sep 2, 2015 at 10:12 PM, Kamal Marhubi notifications@github.com
wrote:

In docs/design/daemon.md
#13368 (comment)
:

•      image: kubernetes/sharded
  

•      ports:
  

•        - containerPort: 9042
  

•          name: main
  

  +```
• • commands that get info
• • get (e.g. kubectl get dc)
• • describe
• • Modifiers
• • delete
• • stop: first we turn down all the pods controller by the daemon (by setting the nodeName to a non-existed name). Then we turn down the daemon controller.
• • label
• • update
• • Daemon controllers have labels, so you could, for example, list all daemon controllers with a certain label (the same way you would for a Replication Controller).
• • In general, for all the supported features like get, describe, update, etc, the Daemon Controller works in a similar way to the Replication Controller. However, note that the Daemon Controller and the Replication Controller are different constructs.

I think that the update needs to be explained a bit more carefully. Will
there be a rolling update to limit the number of instances that are
changing? The description of the daemon controller's operation doesn't seem
to allow for that.

—
Reply to this email directly or view it on GitHub
https://github.com/kubernetes/kubernetes/pull/13368/files#r38607531.

Clayton Coleman | Lead Engineer, OpenShift

I agree you should provide some description of a plausible update process. Even if it managed by deployment controller, I assume we need some way deployment controller tweaks daemon controller to accomplish the update? (Or would deployment controller manage the update directly?)

Also, since one of the main purposes of daemon controller is to guarantee one replica per node, you probably want to kill the old pod before starting the new pod (i.e. the application make break if there are two instances running on the same node).

I don't want to rathole on updates in the initial implementation, but I envision Daemon orchestrating the updates, analogous to (but not the same as) Deployment.

For now I just specified which fields can be updated.

Implementation is in progress.

nodeSelector:
https://github.com/kubernetes/kubernetes/blob/master/pkg/api/v1/types.go#L1215

node-selector violates our API conventions:
https://github.com/kubernetes/kubernetes/blob/master/docs/devel/api-conventions.md#naming-conventions