LinkMesh can now onboard a Kubernetes cluster from the UI: one install brings the agent and the collector fleet up under a cluster name you choose, names the platform, adds a cluster collector for cluster-wide metrics and events, and lets you pick metrics and map ownership. This release carries 21 breaking changes, most of them to the attributes Kubernetes telemetry carries and to how licence seats are handled, so read every upgrade note before you upgrade.
Breaking changes
This release contains breaking changes. Read the upgrade notes below before upgrading.
Read the marker, not the version number. Version numbers do not carry a semver major warning: a breaking change can ship in a minor release. Rely on the breaking-change marker, not on the version number.
On a Kubernetes Cluster Metrics source with a saved metric selection, optional metrics you did not tick stop arriving after the next config push.
Detected in the release
Before you upgrade
WHO IS AFFECTED. Only Kubernetes Cluster Metrics sources that have a saved metric selection. Sources without a selection are unchanged.
BEFORE YOU UPGRADE:
- Note which of these you rely on: k8s.container.status.reason, k8s.pod.status_reason, k8s.service.endpoint.count, k8s.service.load_balancer.ingress.count, k8s.persistentvolumeclaim.status.phase, and the k8s.node.condition_* and k8s.node.allocatable_* metrics.
AFTER YOU UPGRADE:
- Open the source's metric picker, tick the metrics you noted (or choose Everything) and save. The next config push keeps them.
While the managed remove list is on (the default), pod resources from the Cluster Metrics source no longer carry an OTLP entity reference of type k8s.pod.
Detected in the release
Before you upgrade
WHO IS AFFECTED. Only backends that read pod entities from OTLP entity references. The k8s.pod.name, k8s.namespace.name and k8s.node.name attributes on these records are unchanged, so queries on attributes keep working.
IF YOU NEED THE ENTITY REFERENCE:
- On the Kubernetes group's Kubernetes tab, turn off "Drop these attributes" (the managed remove list). Note that this also keeps the churning and sensitive attributes the list removes.
With the ownership mapping on, cluster metrics about Deployments, StatefulSets, ReplicaSets, Jobs and namespaces now carry service.name=cluster-state instead of the object's name.
Detected in the release
Before you upgrade
WHO IS AFFECTED. Kubernetes groups with the ownership mapping on. Cluster metrics about objects without a pod (a Deployment's, StatefulSet's or ReplicaSet's replica counts, a Job, the namespace itself) now carry service.name=cluster-state, and service.namespace comes from the namespace map or the Kubernetes namespace.
BEFORE YOU UPGRADE:
- Find dashboards and alerts that select k8s.deployment.* (or ReplicaSet, StatefulSet, Job or namespace) metrics by service.name.
- Change them to select by the object's own attribute, for example k8s.deployment.name.
External labels on a Prometheus Remote Write destination are now added to every series it sends (they were silently ignored before), and invalid labels are refused on save.
Detected in the release
Before you upgrade
WHO IS AFFECTED. Prometheus Remote Write destinations that have external labels set. Until now those labels were stored but never sent.
BEFORE YOU UPGRADE:
- Review the external labels on every Prometheus Remote Write destination. On the first config push after the upgrade they are added to every series, which changes series identity at your backend: recording rules, alerts and dashboards keyed on the old label set see new series.
- Remove any label you did not mean to send.
- Fix or remove any label with an empty value or a name that is not a valid Prometheus label name (letters, digits and underscores, starting with a letter, not starting with "__"). Otherwise saving that destination is refused after the upgrade.
Cluster Metrics records of pods and containers now carry the owner workload names, and with the ownership mapping on their service.name becomes the workload name instead of the container name.
Detected in the release
Before you upgrade
WHO IS AFFECTED. Kubernetes groups that collect Cluster Metrics. Pod and container records gain k8s.deployment.name, k8s.statefulset.name, k8s.daemonset.name, k8s.replicaset.name, k8s.job.name, k8s.cronjob.name, container.image.name/tag and the k8s.pod.label.* app labels. Where the ownership mapping is on, their service.name changes from the container name to the owning workload's name, matching what kubelet metrics and pod logs of the same pod already report.
BEFORE YOU UPGRADE:
- Find queries, dashboards and alerts that filter Cluster Metrics on service.name = <container name>.
- Change them to the workload name, or to k8s.container.name if you meant the container.
A gone Kubernetes node collector now gives up its licence seat about 75 seconds after its last contact, or sooner when another node's pod is waiting at a full cap.
Detected in the release
Before you upgrade
WHO IS AFFECTED. Kubernetes node collectors on a licence with a collector cap. A node pod that is gone now releases its seat within about 75 seconds of its last contact, and at a full cap a pod of the same node group on another node may take it. No action is needed below the cap.
AT THE CAP:
- A node pod that returns after its seat was released re-takes the licence cap check, so at the cap it waits until a seat is free. Before rolling or resizing node pools, check your licence headroom so that returning pods are not left waiting.
A Kubernetes node collector replaced by a new pod on the same node now releases its licence seat as soon as the replacement enrols; if the old pod returns it re-takes the licence cap check.
Detected in the release
Before you upgrade
WHO IS AFFECTED. Kubernetes node collectors on a licence with a collector cap. A node collector replaced by a new pod on the same node now releases its seat as soon as the replacement enrols, instead of after the fleet reap interval. A collector refused at the cap now retries on its own. No action is needed below the cap.
AT THE CAP:
- If a replaced pod comes back, it re-takes the licence cap check and waits for a free seat. Check your licence headroom before rolling upgrades of the node collector DaemonSet.
Sources created from the Kubernetes tab or from Data Onboarding are now local to the group or collector they were created on, and the source list API leaves local sources out by default.
Detected in the release
Before you upgrade
UPGRADING CHANGES NOTHING ABOUT YOUR EXISTING SOURCES. They stay in the library and stay attached where they were, shown as "from library" on a group's Sources tab, and every collector keeps the config it runs. No action is needed for them.
WHAT CHANGES FOR NEW SOURCES. A source created from the Kubernetes tab or from Data Onboarding is now local to the group or collector it was created on, like one made with "Add source": it is not listed in the source library, cannot be attached elsewhere, and removing it from that group or collector deletes it. Use "Save to library" to share one.
IF YOU SCRIPT AGAINST THE API:
- GET /api/v1/sources now leaves local sources out. Add includeLocal=true if your script needs every source.
- The discovery approve endpoints now refuse, with the reason (4xx), a source that "Add source" would refuse; they used to store it. Handle that response in any automation that approves discovered sources.
Saving a destination is refused (422 invalid_label_promotion) when it turns promote_resource_attributes on for a type other than Prometheus Remote Write, or carries promoted_attributes while promotion is off.
Detected in the release
Before you upgrade
WHO IS AFFECTED. Only destinations whose configuration carries promote_resource_attributes on a type other than Prometheus Remote Write, or a promoted_attributes list while promotion is off. Neither key had any effect before.
BEFORE YOU UPGRADE (or before you next save such a destination):
- Remove the key, or turn promotion on for a Prometheus Remote Write destination. Saving is otherwise refused with 422, code invalid_label_promotion. Existing destinations keep working until they are saved.
On a Kubernetes group with the ownership mapping on, application telemetry now gets service.namespace (the Kubernetes namespace) and service.name (the owning workload) where it set none.
Detected in the release
Before you upgrade
WHO IS AFFECTED. Kubernetes groups where the ownership mapping is on (a platform service namespace is set on the node group). Application telemetry now gets service.namespace (default: the Kubernetes namespace) and service.name (default: the owning Deployment, StatefulSet, DaemonSet, CronJob or Job, else the container), unless the record already has them from an SDK, OTEL_RESOURCE_ATTRIBUTES or the pod annotation. Backends that index these (Grafana Cloud Loki promotes service.name to service_name) see the new values on new data.
BEFORE YOU UPGRADE, if you do not want this:
- To keep only the platform mapping: PATCH /api/v1/collector-groups/{nodeGroupId} with {"ownership": {..., "workload": {"serviceNamespace": [], "serviceName": []}}}.
- To turn the whole mapping off: PATCH the node group with {"ownership": {"enabled": false}}.
Note: opting into label keys also exports the label values it reads as k8s.pod.label.<key>, k8s.deployment.label.<key> and k8s.statefulset.label.<key>.
On Kubernetes node groups, OTLP received from apps on the collector's own node now carries the pod's Kubernetes metadata (namespace, pod, node, owner workload, image, app labels).
Detected in the release
Before you upgrade
WHO IS AFFECTED. Kubernetes node groups with an OTLP source. Records from a sender on the collector's own node now carry k8s.namespace.name, k8s.pod.name, k8s.node.name, the owner names (k8s.deployment.name, k8s.replicaset.name, k8s.statefulset.name, k8s.daemonset.name, k8s.job.name, k8s.cronjob.name), container.image.name, container.image.tag and the app.kubernetes.io/* pod labels as k8s.pod.label.*. Values the application already sets are kept. With the ownership mapping on, OTLP from platform namespaces is classified as platform and gets the platform service.namespace where it set none.
BEFORE YOU UPGRADE:
- Check whether your backend indexes any of these attributes (for example Loki promoting k8s.namespace.name to a stream label). If it does, expect new streams for that traffic and budget for the extra cardinality.
Every record exported by a Kubernetes collector group now carries k8s.cluster.name, set to the node group's name unless already present.
Detected in the release
Before you upgrade
WHO IS AFFECTED. Every Kubernetes collector group (node and cluster collector). Every exported record gains the resource attribute k8s.cluster.name, set to the node group's name unless a value is already present. Backends that index it (Grafana Cloud Loki promotes it to a stream label) see a new label on new data. Once you set a platform service namespace, platform resources also gain service.namespace and service.name (never overwriting a value already set), and a tenant value adds linkmesh.tenant.id (or the key you configure).
BEFORE YOU UPGRADE:
- Decide the cluster name you want. To change it, set it on the node group's Kubernetes tab after the upgrade.
- To send no cluster name, clear the field on the Kubernetes tab, or PATCH /api/v1/collector-groups/{nodeGroupId} with {"clusterName": ""}.
- To turn the platform mapping off, untick "Map platform telemetry" on the Kubernetes tab, or PATCH the node group with {"ownership": {"enabled": false}}.
The enabled_metrics key of a Kubernetes Cluster Metrics source is now applied, and a save that names anything other than the five optional metrics (or one twice) is refused.
Detected in the release
Before you upgrade
WHO IS AFFECTED. Only Kubernetes Cluster Metrics sources whose configuration carries an enabled_metrics key. Before, the key was stored and ignored; now each listed metric is switched on in the collector.
BEFORE YOU UPGRADE:
- Check the key on each such source. It may list only these five optional metrics, each once: k8s.container.status.reason, k8s.pod.status_reason, k8s.service.endpoint.count, k8s.service.load_balancer.ingress.count, k8s.persistentvolumeclaim.status.phase.
- Remove the key, or reduce it to those names. A save that names anything else is refused with 422, because an unknown metric name would stop the collector from loading its config.
The Kubernetes OpAMP install manifests now limit the collector container to 500m CPU / 512Mi memory and request 100m / 256Mi.
Detected in the release
Before you upgrade
WHO IS AFFECTED. Kubernetes clusters where you re-apply the OpAMP install manifests (node collector DaemonSet and cluster collector Deployment) from the wizard or a group's rendered upgrade. Collectors already running are untouched until you re-apply. Where no LimitRange applied, collectors were unbounded before.
BEFORE YOU RE-APPLY:
- Run kubectl top pod -n linkmesh and compare each collector's usage with the new limits (500m CPU, 512Mi memory) and requests (100m, 256Mi).
- If a collector uses more than 512Mi it would now be OOM-killed: raise the limits in the manifest before applying.
- If a node does not have 100m CPU and 256Mi memory free, its pod stays Pending: free capacity or lower the requests.
Kubernetes collector groups no longer export churning and sensitive resource attributes such as process.pid, process.command_line, host.ip, host.mac, k8s.pod.uid and container.image.id.
Detected in the release
Before you upgrade
WHO IS AFFECTED. Every Kubernetes collector group (node and cluster collector), for every source on the group, including OTLP. These resource attributes are no longer exported: process.pid, process.parent_pid, process.executable.path, process.command_line, process.command_args, process.owner, process.runtime.version, process.runtime.description, host.ip, host.mac, k8s.pod.start_time, k8s.pod.uid, container.image.id, container.image.repo_digests, os.description and os.build_id.
BEFORE YOU UPGRADE:
- Search your queries, dashboards and alerts for these attributes. Anything that uses them stops matching new data.
- To keep them, turn off "Drop these attributes" on the node group's Kubernetes tab, or PATCH /api/v1/collector-groups/{nodeGroupId} with {"managedRemoveList": false}. The setting covers both halves of the cluster.
A Docker Compose install without LINKMESH_TAG now pulls linkmesh-server:latest instead of 1.160.0, and 1.160.0 is no longer on Docker Hub.
Detected in the release
Before you upgrade
WHO IS AFFECTED. Docker Compose installs that do not set LINKMESH_TAG. They now pull docker.io/opensight/linkmesh-server:latest instead of 1.160.0, and 1.160.0 has been removed from Docker Hub.
BEFORE YOU UPGRADE:
- If you want to stay on a fixed version, set LINKMESH_TAG in .env to a published version (for example 1.442.0) before your next docker compose pull.
- If you want to follow releases, leave it unset: you get :latest, which only ever points at a published release.
Activating Cluster metrics or Cluster events on a Kubernetes node group is now refused; they run on the group's cluster collector instead.
Detected in the release
Before you upgrade
WHO IS AFFECTED. Anyone who activates Cluster metrics (k8s_cluster) or Cluster events (k8s_events) on a Kubernetes node group. That is now refused with 400 cluster_source_on_node_group, whatever the group's member count, because on a node group the cluster was collected once per node. Activations that already exist are left as they are. Likewise, Node metrics or Pod logs on a cluster collector group are refused (node_source_on_cluster_group).
WHAT TO DO:
- Add the cluster collector from the node group's Kubernetes tab (one click) and activate Cluster metrics and Cluster events there.
- Then remove the old activations from the node group, so the cluster is not collected twice.
- If you automate group creation: the role, pairedGroupId and clusterInstanceUid group fields are set by the server only; a create or update that sets them is refused with 422.
docker.io/opensight/linkmesh-server:edge stops updating; only released versions appear on Docker Hub.
Detected in the release
Before you upgrade
WHO IS AFFECTED. Anyone pulling docker.io/opensight/linkmesh-server:edge or an unreleased version number from Docker Hub. :edge stops updating, and new versions appear on Docker Hub only when they are released.
WHAT TO DO:
- Switch to :latest, or pin a released version such as 1.442.0.
PII masking rules whose salt contains a backslash now hash with the stored salt, so their hash values change at upgrade.
Detected in the release
Before you upgrade
WHO IS AFFECTED. Only PII masking rules whose salt contains a backslash (for example \a or \" inside the value). Until now such a salt was read as an escape, so values were hashed with a different salt than the one stored in the vault. From this release they are hashed with the stored salt, so the hashes for those rules change at upgrade, exactly as on a salt rotation. Salts without a backslash, quote or control character are not affected.
BEFORE YOU UPGRADE:
- Check whether any masking salt contains a backslash.
- If one does and you join masked records on the hash, plan for a break at the upgrade: records masked before and after cannot be joined. Treat it like a salt rotation.
On a licence without single sign-on, SSO sessions issued before the upgrade stop working on their next request instead of at token expiry.
Detected in the release
Before you upgrade
WHO IS AFFECTED. Servers that use single sign-on and whose licence does not include it (Community, Read-only, or a registered Community licence). Mostly relevant if you upgrade from a version older than 1.399: an SSO session issued before that upgrade now stops on its next request with 403 license_sso_required instead of running until its token expires. The same applies to a refreshed session of a user who has no local password.
BEFORE YOU UPGRADE, if you are affected:
- Make sure you can sign in with a local password (at least the local administrator).
- To keep single sign-on, upload an Enterprise licence. It takes effect without a restart.
The Kubernetes node collector now also runs on control-plane nodes, so re-applying the install on a self-managed cluster (kubeadm, kind, k3s, RKE2) adds one collector per control-plane node, and each takes a licence seat.
Written by us
Before you upgrade
WHO IS AFFECTED. Self-managed clusters (kubeadm, kind, k3s servers, RKE2) when you re-apply the Kubernetes install or a group's rendered upgrade. Managed control planes (GKE, EKS, AKS) are unaffected because they expose no control-plane nodes. Collectors already running change nothing until you re-apply. Both runtimes are covered: the OpenTelemetry Collector DaemonSet and the Grafana Alloy chart values now tolerate the node-role.kubernetes.io/control-plane taint.
BEFORE YOU RE-APPLY:
- Count your control-plane nodes. Each one gets a node collector that enrols and takes a licence seat like any other node collector. Check your licence headroom first; at the cap, the new pods wait for a free seat.
- If you do not want the control-plane nodes covered, remove the control-plane toleration from the manifest (or the Alloy chart values) before applying.
Security updates
This release includes 2 security updates in shipped dependencies. Severity not stated by the advisory source.
2 of these carry no published severity, so the highest severity above does not describe them.
Which packages, and which advisories
| Package | To | Severity | Advisory |
|---|---|---|---|
golang.org/x/text | v0.41.0 | not published | CVE-2026-56852 |
golang.org/x/net | v0.60.0 | not published | CVE-2026-78659 |
Fixes
- S-5504Existing groups named agent-enroll-k8s, created by earlier Kubernetes enrollments, are left as they are; rename them by hand if you want the cluster name.
- S-5420The Kubernetes node collector now also runs on control-plane nodes of self-managed clusters, which previously got no node metrics and no pod logs.
- S-5500 S-5507 S-5563 S-5208Kubernetes installs start under restricted Pod Security and on OpenShift's default security constraints, including the cluster collector, and declare their resource requests and limits.
- S-5422 S-5531Licence seats of replaced or vanished Kubernetes node pods are released promptly, and a collector refused at the cap retries on its own.
- S-5537 S-5499 S-5548 S-5423 S-5538 S-5501 S-5503The collector list, the Members tab and the Kubernetes tab say why a collector is in error, why none enrolled, or why the Kubernetes API is unreachable, and keep that cause across retries.
- S-5438 S-5565 S-5149Grafana Alloy groups refuse or flag sources that Alloy never collects, such as node metrics, HTTP checks and TCP checks, instead of showing them as healthy.
- S-5564A collector's Sources tab reads live from the last delivery, so a delivering source no longer shows "No data".
- S-5496 S-5497The routing page loads in milliseconds instead of more than 30 seconds on large installs.
- S-4758 S-4759Windows collectors install over OpAMP from the wizard, start delayed after boot, and keep send queues and checkpoints under ProgramData.
- S-4876 S-4689A TCP Port Check renders a configuration every supported OpenTelemetry Collector loads, and no generated configuration needs an empty-pipeline exception to start.
- S-5087A PII masking salt of any value is carried into the collector configuration safely.
- S-5242 S-5372 S-5062A VM collector gets 30 seconds to start a pushed configuration before it counts as rejected, and after a rollback the restored configuration is reported correctly.
- S-5118 S-5117 S-5119Deploy to Fleet reports refused attaches as failures with real counts, and a custom source or destination reads misconfigured when its body names a missing file.
- S-4832 S-5400 S-5401 S-5494 S-5495 S-5566 S-5402 S-5498Error and confirmation messages now appear on screen, and status badges, muted text and buttons reach accessible contrast in both themes.
- S-5260 S-5114A Git remote can be connected to an install that already has a local repository, and a remote without an access token is mirrored too.
- S-5113On a licence without single sign-on, single sign-on sessions from before the upgrade end at once.
- S-5148 S-4482Docker Compose and Helm installs default to the latest released image, and only released versions are published to Docker Hub.
- S-5128Live Capture on a group-scoped route resolves the group again.
Features and improvements
- S-5504 S-5506 S-5418 S-5419 S-5505 S-5436Kubernetes enrollment asks for a cluster name, installs the agent and the complete collector fleet with one apply, and tells you which group the cluster landed in, with a link to it.
- S-5121A one-click cluster collector on a node group's Kubernetes tab collects cluster metrics and cluster events once per cluster instead of once per node.
- S-5136 S-5270 S-5123 S-5312Install presets for OpenShift, GKE Autopilot and EKS Fargate, and LinkMesh names EKS, RKE2, k3s and kubeadm clusters and detects an existing monitoring stack.
- S-5125 S-5126 S-5127 S-5130 S-5133 S-5417 S-5437 S-5439Kubernetes telemetry is enriched and owned: every record carries the cluster name, workload owner and app labels, OTLP from in-cluster apps gets pod metadata, platform and workload telemetry get service.namespace and service.name, and churning or sensitive attributes are dropped by default.
- S-5140 S-5141 S-5142 S-5143 S-5144 S-5134 S-5472A metric picker for Kubernetes sources with Minimum, Extended and Everything presets, per-runtime metric catalogs, and a preview of the attributes each metric carries at your backend.
- S-5129 S-5135Kubelet and cAdvisor scrape templates, and annotation autodiscovery for Prometheus sources on Kubernetes with a default sample limit.
- S-5394 S-5478 S-5479 S-5122 S-5138 S-5139 S-5463 S-5467 S-5395 S-5404The Kubernetes tab is reorganised into summary, inventory, setup and data quality, with a stack view that shows each layer's coverage by metrics, logs and traces and offers the one-click action that closes each gap.
- S-5128 S-5323An enrichment and ownership check on the Kubernetes tab, optionally run after each publish to a node group.
- S-5196An upgrade view per Kubernetes group shows version drift and the ready-to-apply manifest or helm command for the upgrade.
- S-5480 S-5481 S-5483 S-5484 S-5570Add a source directly on a group or collector in one step; reuse through the library is optional with "Add existing from library" and "Save to library", and Sources, Destinations and Pipelines share one Library menu.
- S-5482Upgrading changes nothing about your existing sources: they stay in the library and stay attached where they were, shown as "from library" on a group's Sources tab, and every collector keeps the config it runs.
- S-5131 S-5435Prometheus Remote Write destinations can promote selected resource attributes to labels, and their external labels are now actually sent.
24 further changes — build and test work, internal refactoring, and changes with no effect you could observe — were reviewed and deliberately left out.