We’re very excited to announce Linkerd version 1.2.0! This is a huge release with a lot of new features, fixes, and performance improvements, especially for our users running Linkerd with Kubernetes, HTTP/2, or gRPC. There are also a handful of breaking changes in 1.2.0 , so we’ve included a migration guide below to help make the transition as easy as possible.
We’d like to take a moment to highlight contributions from the Linkerd community members in this release.
- Christopher Taylor (@ccmtaylor): added DNS SRV record support
- Andrew Wright (@blacktoe): improved Consul health checks
- Cyril Ponomaryov (@cponomaryov): fixed an
issue in the
config.jsonadmin endpoint, and made some performance improvements in logging
- Marcin Mejran (@mejran): fixed a memory leak in
In addition to contributions from the community, this release also contains the first contributions from Phil Calçado, the newest member of the Linkerd engineering team.
New Features in 1.2.0
New DNS SRV Record support
Thanks to Christopher Taylor (@ccmtaylor) at
SoundCloud, Linkerd 1.2.0 features a new
io.l5d.dnssrv namer that allows
Linkerd to use DNS SRV records for service discovery.
An example configuration for the DNS SRV namer might look like this:
namers: - kind: io.l5d.dnssrv experimental: true refreshIntervalSeconds: 5 dnsHosts: - ns0.example.org - ns1.example.org
dnsHosts configuration key specifies a list of DNS servers against which
to perform SRV lookups, while the
refreshIntervalSeconds key specifies the
frequency of lookups. Please note that this namer is still considered
experimental: true is required. Once the DNS SRV namer is
configured, it can be referenced in the dtab to use it:
dtab: | /dnssrv => /#/io.l5d.dnssrv /svc/myservice => /dnssrv/myservice.srv.example.org & /dnssrv/myservice2.srv.example.org; /svc/other => /dnssrv/other.srv.example.org;
Please see the DNS SRV namer documentation for more information.
Improved Consul health filtering
Another new feature added by an open-source contributor is support for filtering
by Consul health states, added by Linkerd user Andrew Wright
(@blacktoe). Consul has a concept of
critical health statuses, but the Consul namer previously only
supported filtering nodes by a binary health status. To use this feature, add
the following to the Consul namer configuration:
useHealthCheck: true healthStatuses: - 'passing' - 'warning'
healthStatuses is a list of statuses to filter on. Refer to the
for the Consul namer for more information. In addition, we’ve made the Consul
namer more robust: Consul errors will now cause the namer to fall back to the
last good state observed from Consul, and the log messages on these errors have
been made more informative.
New Kubernetes ConfigMap Interpreter
Users running Linkerd on Kubernetes may be interested in the new
io.l5d.k8s.configMap interpreter (marked experimental for now, until it sees
more production use). This interpreter will interpret names using a dtab stored
in a Kubernetes ConfigMap, and update the dtab if the ConfigMap changes,
allowing users on Kubernetes to implement dynamic routing rule changes without
An example configuration is as follows:
routers: - ... interpreter: kind: io.l5d.k8s.configMap experimental: true namespace: ns name: dtabs filename: my-dtab
namespace configuration key refers to the name of the Kubernetes namespace
where the ConfigMap is stored, while the
name key refers to the name of the
ConfigMap object, and the
filename key refers to the name of the dtab within
the ConfigMap. As this interpreter is still experimental,
must be set for it to be used.
See the ConfigMap namer documentation for more information.
Improved Ingress Identifier Configurability (istio)
For users running Linkerd-powered Istio deployments, Linkerd 1.2.0 allows multiple simultaneous Ingress controllers by configuring which annotation class each Ingress controller uses.
Bug Fixes and Performance Improvements
Improved Kubernetes watches, BUGFIXES, and performance
This release features a major
refactoring of the
io.l5d.k8s.ns namers. We’ve rewritten how these namers watch Kubernetes
API objects. New code should be much more efficient, leading to major
performance improvements. We’ve also fixed issues where Linkerd would continue
routing to Kubernetes services that had been deleted, and some minor routing
problems in the ingress controller. Finally, we’d like to thank community member
Marcin Mejran (@mejran), who fixed a memory leak in
JSON stream parsing which could impact Kubernetes performance.
HTTP/2 and gRPC fixes
For users of the HTTP/2 protocol, we’ve solved an issue where long-running streams would eventually stop receiving new frames, and we’ve fixed a memory leak in long-running streams.
Breaking Changes and Migration
Removed Support for PKCS#1 Keys
Linkerd 1.2.0 removes support for Public Key Cryptography Standard #1 SSL private keys, which were previously deprecated. If you still have keys in PKCS#1 format, you will need to convert your private keys to PKCS#8. Private keys can be converted with the following command:
openssl pkcs8 -topk8 -nocrypt -in $PKCS1.pem -out $PKCS8.pk8
$PKCS8 are the file names of the old PKCS#1 key and the new
key to output, respectively. If you see errors with messages containing “file
does not contain valid private key”, you’ll know you need to do this step. For
example, the message:
WARN 0908 14:03:38.201 CDT finagle/netty4-6: Failed to initialize a channel. Closing: [id: 0xdd6c26dd] java.lang.IllegalArgumentException: File does not contain valid private key: finagle/h2/src/e2e/resources/linkerd-tls-e2e-key-pkcs1.pem
Indicates that the key
linkerd-tls-e2e-key-pkcs1.pem needs to be updated to
Client TLS Configuration
Linkerd now rejects client TLS configurations which contain both
disableValidation: true and a
clientAuth configuration, as disabling
validation will cause Linkerd to use the JDK SSL provider, which does not
support client authorization. These configurations have always been
incompatible, and including both would have previously caused errors at runtime.
Admin and Interpreter Server Configuration
For improved security, by default Linkerd and Namerd 1.2.0 now serve the admin
io.l5d.mesh , and
io.l5d.thriftNameInterpreter only on
127.0.0.1. (Previously, it bound to every available network interface.) This
means that accessing the admin and metrics interfaces from an external IP
address will no longer work. If you need to access the admin or metrics pages
from an external IP address, you will need to add
admin: ip: 0.0.0.0 port: 9990
To your configuration file.
StatsD Telemeter Deprecation
The StatsD telemeter (
io.l5d.statsd) is now
and will log a warning on use. We’ve been considering deprecating this telemeter
for some time, as it doesn’t work the way most users expect and can lead to loss
of data and/or greatly increased Linkerd latency. We recommend that users of
this telemeter migrate to the InfluxDB telemeter in conjunction with Telegraf.
In future releases, we will remove this telemeter.
The complete changelog for this release is available on GitHub, and updated documentation can be found on docs.linkerd.io. And, as always, if you have any questions or just want to chat about Linkerd, join the Linkerd Slack or browse the Discourse community forum for more in-depth discussion.