ADR: optional upgrade-responder support

[l-mb]

Proposed Changes

The ADR describes a proposal to include an upgrade-responder client in k3s and downstream distributions for optional metric insights for the project.

Types of Changes

New Feature

Verification

After acceptance of the ADR and the implementation of the described features, k3s maintainers will gain more insights into the deployment footprint of k3s as well as the version breakdown.

User-Facing Change

The ADR itself doesn't, but the implementation will introduce new configuration options and be described there.

[brandond]

@l-mb can you cover the gap between what this proposes, and what users (and project maintainers) get when the administrator deploys the system-upgrade-controller to poll a channel? It feels like there is a lot of overlap here. In particular, the SUC already sends the cluster ID and current version in headers, the only thing we don't get is node counts.

[l-mb]

@brandond Thanks for asking!

I admit I didn't see that field, and even knowing the code I couldn't find documentation for them. Are those logs available somewhere?

A challenge with the system-upgrade-controller seemed to be that we don't have easy access to those logs (including the origin IP address); that may be an incorrect assumption.

More relevant seems to be that it isn't deployed by default, and that it's actively conflicting with Rancher Manager.

It also seems to be somewhat more heavy-weight to deploy and configure.

I see the overlap, but it felt like a small, privacy-preserving telemetry client (which is what upgrade-responder really does) drop-in was an easier lift than resolving the above.

I'm more than happy if we can indeed leverage existing infrastructure though!

[l-mb]

For reference, kubewarden (another CNCF project) just merged a similar RFC: kubewarden/rfc#51 (comment)

[OrlinVasilev]

@l-mb , can you join our community meeting next week , and can we bring that for discussion?

[brandond]

We should also be wary of doing what other projects like k0s are doing with their telemetry - it is on by default, and their docs do not cover what they collect, where it is sent, what they do with the data (how identifiable is it, can it be used for marketing, etc), or how the data is shared with the community.

I think the team definitely wants to err on the side of transparency if we do move forward with this, and these are the sorts of questions we should address well in advance.