Before going to production
Before you can be ready to deploy Linkerd to production, there are some things you should know and some things you should do to prepare.
All open source Linkerd development happens on GitHub. That’s also the best place to submit bug reports and pull requests. Please star the repo to inflate our vanity metric!
If you need help with Linkerd, you have a couple of channels available to you. Our recommendations are:
- Troubleshooting? Spin up a thread on the Buoyant Linkerd Support Forums.
- Quick one-off question? Start with the Linkerd Slack
- Bug report? File a GitHub issue.
- Need enterprise support (including 24x7 oncall, professional services, and more)? Contact your friends right here at Buoyant.
Of course, open source support is provided by the community on a best-effort basis. And don’t forget to help others—this is often the best way to give back!
(Note that if you are a Linkerd Enterprise customer of Buoyant, you also have other, dedicated support channels available. Please consult the support onboarding instructions you received.)
In the unlikely event that you discover a security vulnerability in Linkerd, please email the private email@example.com list. We’ll send a confirmation email to acknowledge your report, and we’ll send an additional email when we’ve identified the issue positively or negatively. See the project’s official Security Policy for more.
To receive notifications of vulnerabilities and critical updates, please subscribe to the linkerd-announce mailing list.
Linkerd’s code is hosted in the GitHub repo. You may choose to build your own binaries or images from this code, or simply to use one of the published releases.
Open source releases are published in a split fashion: GitHub hosts the CLI binaries, and GitHub Container Registry hosts the container images. These are the canonical binaries and images for Linkerd.
Linkerd follows two versioning schemes: one for stable releases and enterprise releases, and one for “edge” releases.
Open source Linkerd stable releases follow a modified form of semantic
versioning. Version numbers are of the form
stable-2.<major>.[<minor>[.<patch>]]. Breaking changes (typically,
configuration incompatibilities) and significant changes to functionality are
denoted by changes in major version. Non-breaking changes and minor feature
improvements are denoted by changes in minor version. Occasionally, we will
release critical bugfixes to stable releases by incrementing the patch
stable-2.13.3: major version 13, minor version 3
- Moving from
stable-2.12.0: possible breaking changes
- Moving from
stable-2.11.2: no breaking changes
Releases of Linkerd Enterprise follow the same format as the stable releases, with the exception of an optional, additional patch level suffix for hotfixes such as security vulnerabilities.
enterprise-2.13.7-4: major version 13, minor version 7, hotpatch 4
enterprise-2.12.5: major version 12, minor version 5, no hotpatch
Generally speaking, Buoyant Enterprise for Linkerd’s lifecycle automation capabilities should handle even breaking changes between major versions, so upgrading should be painless.
Open source Linkerd is also published in “edge” releases, typically on a weekly
cadence. In contrast to stable open source releases, Linkerd edge releases
follow a flat versioning scheme, of the form
Edge releases are provided to the community as a way of getting early access to
feature work, and may introduce breaking changes at any point. Sometimes, edge
releases are designated informally as a “release candidate” for the upcoming
stable release; this designation also provides no guarantees about feature
edge-23.9.5: the fifth edge release published in September 2023
edge-22.12.1: the first edge release published in December 2022
Sometimes, Linkerd features are denoted as alpha or experimental in the documentation. This designation means that, while we feel confident in the viability of the feature, it hasn’t seen enough production use for us to recommend it unreservedly. Caution should be exercised before using an experimental feature in a production environment. The documentation for each experimental feature will describe why it has been classified this way; for example, “this feature has not been tested on all major cloud providers”.
Sometimes, Linkerd features are denoted as deprecated. This means that, while currently supported, we expect to remove the corresponding configuration in an upcoming release.
The only requirement for Linkerd is a modern, functioning Kubernetes cluster. Regardless of whether the cluster is on-premises or in the cloud, and regardless of Kubernetes distribution or provider, if it’s running Kubernetes, generally speaking, Linkerd should work. (Of course, Linkerd does require specific capabilities and features of the Kubernetes cluster in order to function. See Preparing your environment for more on this topic.)
Generally speaking, open source Linkerd follows the published policy for “supported” Kubernetes releases: effectively, the three most recent minor Kubernetes versions are supported. Of course, earlier Kubernetes versions may still work.
Linkerd Enterprise may offer additional guarantees beyond this including long-term support for specific versions. Contact us for details.