Remove Kubernetes UIDs and use Name instead

[silvin-lubecki]

As Kubernetes names are unique, we should only display them and avoid Kubernetes UIDs which are also unique but not commonly used in Kubernetes world (only for debug purpose I presume).

This impacts two commands:

• docker stack ps
• docker stack services

Docker stack ps

$ DOCKER_ORCHESTRATOR=kubernetes docker stack ps mystack
ID                  NAME                             IMAGE                   NODE                 DESIRED STATE       CURRENT STATE           ERROR               PORTS
85d44891-5da        mystack_db-664ccb47c8-tczq7      dockerdemos/lab-db      docker-for-desktop   Running             Running 2 minutes ago
85d768f1-5da        mystack_web-cb4868b76-qs5pp      dockerdemos/lab-web     docker-for-desktop   Running             Running 2 minutes ago                       *:0->80/tcp
8c6da80e-5da        mystack_words-6954ccfd5b-6kph5   dockerdemos/lab-words   docker-for-desktop   Running             Running 2 minutes ago
85e5c1c6-5da        mystack_words-6954ccfd5b-dtc5l   dockerdemos/lab-words   docker-for-desktop   Running             Running 2 minutes ago
85e41d2e-5da        mystack_words-6954ccfd5b-ph9m2   dockerdemos/lab-words   docker-for-desktop   Running             Running 2 minutes ago
8ac68c76-5da        mystack_words-6954ccfd5b-rbj2c   dockerdemos/lab-words   docker-for-desktop   Running             Running 2 minutes ago
85f0343f-5da        mystack_words-6954ccfd5b-z6vrb   dockerdemos/lab-words   docker-for-desktop   Running             Running 2 minutes ago

Here we have the node name column, which can be replaced by the Kubernetes Node UID using the --no-resolve flag (btw we have to resolve the UID, which can be counter-intuitive regarding the flag name... see code here)

$ DOCKER_ORCHESTRATOR=kubernetes docker stack ps mystack --no-resolve
ID                  NAME                             IMAGE                   NODE                                   DESIRED STATE       CURRENT STATE            ERROR               PORTS
85d44891-5da        mystack_db-664ccb47c8-tczq7      dockerdemos/lab-db      d0e2dcd7-4474-11e8-b8ab-025000000001   Running             Running 15 minutes ago
85d768f1-5da        mystack_web-cb4868b76-qs5pp      dockerdemos/lab-web     d0e2dcd7-4474-11e8-b8ab-025000000001   Running             Running 15 minutes ago                       *:0->80/tcp
8c6da80e-5da        mystack_words-6954ccfd5b-6kph5   dockerdemos/lab-words   d0e2dcd7-4474-11e8-b8ab-025000000001   Running             Running 14 minutes ago
85e5c1c6-5da        mystack_words-6954ccfd5b-dtc5l   dockerdemos/lab-words   d0e2dcd7-4474-11e8-b8ab-025000000001   Running             Running 15 minutes ago
85e41d2e-5da        mystack_words-6954ccfd5b-ph9m2   dockerdemos/lab-words   d0e2dcd7-4474-11e8-b8ab-025000000001   Running             Running 15 minutes ago
8ac68c76-5da        mystack_words-6954ccfd5b-rbj2c   dockerdemos/lab-words   d0e2dcd7-4474-11e8-b8ab-025000000001   Running             Running 14 minutes ago
85f0343f-5da        mystack_words-6954ccfd5b-z6vrb   dockerdemos/lab-words   d0e2dcd7-4474-11e8-b8ab-025000000001   Running             Running 15 minutes ago

Question 1: Do we keep the --no-resolve flag for backward compatibility with swarm scripts, but always output node name?

Question 2: About the ID column vs the Name column for Kubernetes. We output both of them in Kubernetes, but ID is kind of useless.

Question 3: Another thing is the task name is not the real Kubernetes Pod name. It is arbitrary prefixed be the stack name (here mystack_) to match Swarm UX. Do we keep this feature?

The output could be like the following:

$ DOCKER_ORCHESTRATOR=kubernetes docker stack ps mystack --no-resolve
NAME                     IMAGE                   NODE                 DESIRED STATE       CURRENT STATE            ERROR               PORTS
db-664ccb47c8-tczq7      dockerdemos/lab-db      docker-for-desktop   Running             Running 15 minutes ago
web-cb4868b76-qs5pp      dockerdemos/lab-web     docker-for-desktop   Running             Running 15 minutes ago                       *:0->80/tcp
words-6954ccfd5b-6kph5   dockerdemos/lab-words   docker-for-desktop   Running             Running 14 minutes ago
words-6954ccfd5b-dtc5l   dockerdemos/lab-words   docker-for-desktop   Running             Running 15 minutes ago
words-6954ccfd5b-ph9m2   dockerdemos/lab-words   docker-for-desktop   Running             Running 15 minutes ago
words-6954ccfd5b-rbj2c   dockerdemos/lab-words   docker-for-desktop   Running             Running 14 minutes ago
words-6954ccfd5b-z6vrb   dockerdemos/lab-words   docker-for-desktop   Running             Running 15 minutes ago

Docker stack services

$ DOCKER_ORCHESTRATOR=kubernetes docker stack services mystack
ID                  NAME                MODE                REPLICAS            IMAGE                               PORTS
85d43ffe-5da        mystack_db          replicated          1/1                 dockerdemos/lab-db
85d9f971-5da        mystack_web         replicated          1/1                 dockerdemos/lab-web                 *:80->80/tcp
d74ed7f1-47c        mystack_words       replicated          5/5                 dockerdemos/lab-words

Question 4: Same as question 2 here, do we need to keep the ID column?

The output could be like the following:

$ DOCKER_ORCHESTRATOR=kubernetes docker stack services mystack
NAME                MODE                REPLICAS            IMAGE                               PORTS
mystack_db          replicated          1/1                 dockerdemos/lab-db
mystack_web         replicated          1/1                 dockerdemos/lab-web                 *:80->80/tcp
mystack_words       replicated          5/5                 dockerdemos/lab-words

[chris-crone]

While users may only ever use object names in Kubernetes, UIDs might be useful for debugging. Names are unique across space while UIDs are unique across space and time (see: ref). It appears that there can be races caused by this.

Q1: In Swarm we literally do a DNS resolve of the hostname of the node. For Kubernetes we're not really resolving the name or UID as they're in the node metadata. I'm OK with keeping the flag for backwards compatibility.

Q2: As stated before, the IDs may be useful for debugging even if they're not useful for manipulating objects.

Q3: I'm not sure if we can interact with tasks by name in Swarm. If we can then we should try to match this behaviour for Kubernetes. If not, this is cosmetic so matching Swarm is OK.

Q4: This is tricky. A Swarm service maps to a Kubernetes Deployment/StatefulSet/... (for the containers) plus one or more Kubernetes Services (Headless/NodePort/LoadBalancer) for networking. Here we're only showing the Kubernetes Headless service UID. I don't know what we could do better here.

@wsong WDYT?

[wsong]

Debugging info is fine, but I think that docker stack ps should optimize for showing info that's useful for the customer. In the case of Swarm, we need to show IDs because they're the only unique identifier, but in Kube, the UIDs are just spam 99% of the time.

[thaJeztah]

For containers, both ID and Name are unique as well, so I don't see the situation that different

I wonder though how many people would use the --no-resolve in general, so if it's a big issue

[wsong]

Name isn't actually unique for containers, though, because if you're using UCP, you can have two containers with the same name on different nodes.

[thediveo]

Over time, two different containers might have the same name, yet two different IDs, so it is crucial to detect that the same name references different container instances over time.