Conversation
|
Containers are by design ephemeral, and mostly useful for concurrency-based licensing models, rather than long-lived node-locked based models, simply because the underlying machines can change very often during autoscaling/rotation. Regardless, I don't think using the hostname is the right solution here, especially since your implementation doesn't only run in k8s, i.e. it'll break the proceeding powershell line. The hostname is also easily changed. Maybe it'd be a better idea in k8s to use the Downward API to put the pod's UID metadata into a known file such as volumes:
- name: podinfo
downwardAPI:
items:
- path: /etc/machine-id
fieldRef:
fieldPath: metadata.uidIf overwriting |
|
Thanks for the valuable feedback, @ezekg. In our use case, we don’t have control over the configuration that users run with, but we still need to detect a unique ID when our program runs. If you feel the Kubernetes case doesn’t require special handling in the code itself, adding a note in the README could be a good way to help others who might encounter the same issue. |
|
I want to support k8s, but I'm not sure the hostname here works as a fallback for everything outside of k8s. |
we found that in the case of containers running in kubernetes the library raised
MachineIdNotFound. There the regex used for docker doesn't return anything. Instead we used the/etc/hostnamethat contains the pod name.Not a kubernetes expert but seems that the containers inside the pod can be regenerated and using the container id is not very reliable as they are much more ephemeral.
https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/