@kubernetes/sig-apps-feature-requests

Are you asking for the Pod to have the exact same name as the node? If so you could only have one DeamonSet per namespace that has this property without causing a name collision.

It would also block cases like the first point in #31693 (comment)

It would also block cases like the first point in #31693 (comment)

OTOH, currently we assume we always run at most one replica per node so this would help in that regard.

@kow3ns you are right, that's borked.

My main point is that there should be away how daemonset pods can be addressed per host through DNS.

Considering that skydns is used, then the scheme is (as you probably know) $host.$service.$namespace.cluster.local.
But in the case of daemonsets the $host part i sgenerated, thus you can not directly addressed that specific pod, without out-of-band knowledge about the generated name of the pod.
To fix this, a mechanism is required to fixate the hostname for daemonset pods.

Could be dsname-hostname

Where would you use it, @Kargakis ?

Eventually a flag on the daemonset spec could help to signal that the real hostname shoul dbe used as a pod hostname, i.e. hostsHostname: true.
Once the pod is initiated, the pod's hostname field would be set to the hostname.

Appologies. Wrong button.

Hi,

I tried a naive approach with the following spec:

apiVersion: extensions/v1beta1
kind: DaemonSet
spec:
  template:
    spec:
      hostname:
        valueFrom:
            fieldRef:
              fieldPath: spec.nodeName
      containers:
        - name: test
          image: "ubuntu:16.04"

but when I try to use this spec I get the following error (even if the fieldpath return a string https://github.com/kubernetes/kubernetes/blob/master/pkg/api/types.go#L1275:

error: error validating "test.yaml": error validating data: expected type string, for field spec.template.spec.hostname, got map; if you choose to ignore these errors, turn validation off with --validate=false

Is there a way to tell the downward API to return a string/single value?

Let me rephrase the issue, as it might not be clear from my initial statement.

Whenever a Pod is exposing a service, then the service exposed by a specific pod can be accessed using the fqdn specifc-pod-name.my-service.my-namespace.svc.cluster.local.
For regular pods this is okay, as the name specific-pod-name is known in advance and can be used to reference to specific pod.
However, in the case of daemon sets the name of a pod is not known in advance, and thus we cna not reference a specific pod.
For daemon sets in particular, the host plays an important role, as daemon sets can be considered to be node local services. Any other pod on a node might be interested to access a specific service on it's own node (for several reasons, one is to avoid network latency by accessing a remote pod providing the same service).

Thus to allow a pod to access a specific service on it's own node, it would be helpful if a daemonset pod can be directly addressed using the service, namespace, and - because it's especially interesting in the daemonset case - the hostname.
I.e.: <hostname>.<service>.<namespace>.svc.cluster.local.
With such an address it would be possible for pods to directly access a specific service on a given node.

There could be collisions if a service is bound to more than one pod on a node. I wonder if this could be somehow avoided for the daemonset case.

@fabiand have you looked at the proposal for node-local services?
#28637

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle stale

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle rotten
/remove-lifecycle stale

Would still be important to me.

Might be addressed by #41442

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close