stable-2.14.10

NOTE about 2.15 and beyond: As of February 2024, the Linkerd project is no longer producing open source stable release artifacts. Please read the 2.15 announcement for details.

See the full list of Linkerd releases for ways to get Linkerd.

stable-2.14.10

This stable release back-ports bugfixes and improvements from recent edge
releases.

• Introduced support for arbitrary labels in the podMonitors field in the
  control plane Helm chart (thanks @jseiser!) (#11222; fixes #11175)
• Added a prometheusUrl field for the heartbeat job in the control plane Helm
  chart (thanks @david972!) (#11343; fixes #11342)
• Updated the Destination controller to return INVALID_ARGUMENT status codes
  properly when a ServiceProfile is requested for a service that does not
  exist. (#11980)
• Reduced the load on the Destination controller by only processing Server
  updates on workloads affected by the Server (#12017)
• Changed how updates to a Server selector are handled in the destination
  service. When a Server that marks a port as opaque no longer selects a
  resource, the resource's opaqueness will reverted to default settings
  (#12031; fixes #11995)
• Fixed a race condition in the destination service that could cause panics
  under very specific conditions (#12022; fixes #12010)
• Fixed an issue where inbound policy could be incorrect after certain policy
  resources are deleted (#12088)

edge-24.2.4

This edge release corresponds to Linkerd version 2.15.

edge-24.2.4

• Updated the ExternalWorkload CRD to v1beta1, renaming the meshTls field to
  meshTLS (#12098)
• Updated the proxy to address some logging and metrics inconsistencies
  (#12099)

edge-24.2.3

edge-24.2.3

• Allowed the MutatingWebhookConfig timeout value to be configured (#12028)
  (thanks @mikebell90)
• Added a counter for items dropped from destination controller workqueue
  (#12079)
• Fixed a spurious linkerd check error when using container images with
  digests (#12059)
• Fixed an issue where inbound policy could be incorrect after certain policy
  resources are deleted (#12088)

edge-24.2.2

edge-24.2.2

This release addresses some issues in the destination service that could cause
it to behave unexpectedly when processing updates.

• Fixed a race condition in the destination service that could cause panics
  under very specific conditions (#12022; fixes #12010)
• Changed how updates to a Server selector are handled in the destination
  service. When a Server that marks a port as opaque no longer selects a
  resource, the resource's opaqueness will reverted to default settings
  (#12031; fixes #11995)
• Introduced Helm configuration values for liveness and readiness probe
  timeouts and delays (#11458; fixes #11453) (thanks @jan-kantert!)

edge-24.2.1

edge-24.2.1

This edge release contains performance and stability improvements to the
Destination controller, and continues stabilizing support for ExternalWorkloads.

• Reduced the load on the Destination controller by only processing Server
  updates on workloads affected by the Server (#12017)
• Changed how the Destination controller reacts to target clusters (in
  multicluster pod-to-pod mode) whose Server CRD is outdated: skip them and log
  an error instead of panicking (#12008)
• Improved the leader election of the ExternalWorkloads Endpoints controller to
  avoid missing events (#12021)
• Improved naming of EndpointSlices generated by ExternWorkloads (#12016)
• Restriced the number of IPs an ExternalWorkload can have (#12026)

edge-24.1.3

edge-24.1.3

This release continues support for ExternalWorkload resources throughout the
control and data planes.

• Updated the proxy to use SPIRE to instrument identity outside of Kubernetes.
• Updated the Destination controller to return INVALID_ARGUMENT status codes
  properly when a ServiceProfile is requested for a service that does not
  exist. (#11980)
• An ExternalWorkload EndpointSlice controller has been added to the
  Destination controller.
• Added a createNamespaceMetadataJob Helm value to control whether the
  namespace-metadata job is run during install (#11782)

stable-2.14.9

stable-2.14.9

This stable release adds a cni-repair-controller which fixes the issue of
injected pods that cannot acquire proper network config because linkerd-cni
and/or the cluster's network CNI haven't fully started (#11699). It also
fixes a bug in the destination controller where having a large number of
Server resources could cause the destination controller to use an excessive
amount of CPU (#11907). Finally, it fixes a conflict with tap resource
shortnames which was causing warnings from kubectl v1.29.0+ (#11816).

edge-24.1.2

edge-24.1.2

This edge release incrementally improves support for ExternalWorkload resources
throughout the control plane.

edge-24.1.1

edge-24.1.1

This edge release introduces a number of different fixes and improvements. More
notably, it introduces a new cni-repair-controller binary to the CNI plugin
image. The controller will automatically restart pods that have not received
their iptables configuration.

• Removed shortnames from Tap API resources to avoid colliding with existing
  Kubernetes resources (#11816; fixes #11784)
• Introduced a new ExternalWorkload CRD to support upcoming mesh expansion
  feature (#11805)
• Changed MeshTLSAuthentication resource validation to allow SPIFFE URI
  identities (#11882)
• Introduced a new cni-repair-controller to the linkerd-cni DaemonSet to
  automatically restart misconfigured pods that are missing iptables rules
  (#11699; fixes #11073)
• Fixed a "duplicate metrics" warning in the multicluster service-mirror
  component (#11875; fixes #11839)
• Added metric labels and weights to linkerd diagnostics endpoints json
  output (#11889)
• Changed how Server updates are handled in the destination service. The
  change will ensure that during a cluster resync, consumers won't be
  overloaded by redundant updates (#11907)
• Changed linkerd install error output to add a newline when a Kubernetes
  client cannot be successfully initialised (#11917)

stable-2.14.8

stable-2.14.8

This stable release fixes an issue in the control plane where discovery for pod
IP addresses could hang indefinitely (#11815).