-
Notifications
You must be signed in to change notification settings - Fork 370
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Replace the Machine ID usage with an "Invocation ID" #4230
Conversation
Instead of relying on an externally maintained "machine identity" that may or may not exist on hosts, use a so-called Invocation ID. The Invocation ID is a randomly generated 32-byte hexadecimal string that is created during process startup. The name is inspired by systemd's INVOCATION_ID. K0s doesn't need a unique host identifier that is stable across process invocations. It only needs to have unique identifiers per process. This removes a dependency on the k0s host machine (some machine-id file or registry entry), a Go module dependency, Machine ID related documentation and system probes. It also makes the use of a unique ID obvious. The machine ID has been hard-coded into the guts of the leader election and telemetry components. The invocation ID is passed around instead. Stub out the use of the anonymous ID in telemetry, as the new ID is no longer stable and would be useless for this type of use. Signed-off-by: Tom Wieczorek <[email protected]>
I think at some point kubelet would fail if the machine-id was missing. Is this no longer the case? |
At least the inttests pass, and I removed all machine ID related setup from the bootloose test image. So the Alpine containers shouldn't have a machine ID anymore. I checked the Kubernetes sources, and there are very few traces about machine IDs, as described in #3983 (comment). |
Checked the Kubernetes sources again. On Linux, On Windows, there's even no attempt to read if from the registry, it is simply set to the hostname: https://github.com/kubernetes/kubernetes/blob/v1.30.0-rc.1/pkg/kubelet/winstats/perfcounter_nodestats.go#L162 |
@@ -151,7 +150,7 @@ func (c Component) sendTelemetry(ctx context.Context) { | |||
|
|||
c.log.WithField("data", data).WithField("hostdata", hostData).Info("sending telemetry") | |||
if err := c.analyticsClient.Enqueue(analytics.Track{ | |||
AnonymousId: machineID(), | |||
AnonymousId: "(removed)", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
AnonymousID is the Segment entity: https://segment.com/docs/connections/sources/catalog/libraries/website/javascript/identity/#anonymous-ids
As far as I can see it's not used in our data pipeline now, but are we sure, that we want to remove it completely?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would think the unique cluster id is more important for telemetry than the machine id 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, of course, I was wondering if it could break the pipeline, but we checked with Chen and it should be ok.
Chen suggested testing it a bit, but in general we are fine
Description
Instead of relying on an externally maintained "machine identity" that may or may not exist on hosts, use a so-called Invocation ID. The Invocation ID is a randomly generated 32-byte hexadecimal string that is created during process startup. The name is inspired by systemd's INVOCATION_ID.
K0s doesn't need a unique host identifier that is stable across process invocations. It only needs to have unique identifiers per process. This removes a dependency on the k0s host machine (some machine-id file or registry entry), a Go module dependency, Machine ID related documentation and system probes. It also makes the use of a unique ID obvious. The machine ID has been hard-coded into the guts of the leader election and telemetry components. The invocation ID is passed around instead.
Stub out the use of the anonymous ID in telemetry, as the new ID is no longer stable and would be useless for this type of use.
Resolves #3983.
Type of change
How Has This Been Tested?
Checklist: