Many network proxies need the same answer to a simple question: where should a request for this service go? Namerd supplied that routing and service-discovery information to Linkerd 1 instances from a shared service. It stored routing rules and consulted systems that knew the current service locations. This reduced the need to configure each proxy independently, but it belongs to Linkerd's older architecture rather than being a required part of Linkerd 2.
Current guidance
The Linkerd 1 repository identifies namerd as its service-discovery subproject and directs current feature development to linkerd2. The recovered record concerns shared routing tables and naming backends used by Linkerd 1 proxies. It should not be described as a required component of a current Linkerd 2 installation.
Before replacing it, export routing tables, namespaces, naming rules and the discovery systems on which they depend. Establish whether applications rely on dynamic route overrides, protocol handling or discovery sources that a proposed mesh does not expose in the same form. A product-name continuation is not an automatic configuration migration.
Test representative destinations and failure cases through an isolated candidate route, including a missing backend and a changed discovery record. Protect administrative routing interfaces, because an authorized change can redirect traffic across many clients. The original repository remains available, but this review does not establish a current support commitment for namerd or a verified direct successor for every feature. Preserve the historical routing contract when evaluating alternatives.
Historical upstream link check · 2026-10-09
The recorded upstream address responded successfully (HTTP 200) on 2026-10-09. GitHub confirms that helm/charts is archived: this is a historical chart distribution, not evidence that the application itself is retired. Link availability does not certify the historical installation instructions or current security support.
Website availability is separate from project, chart and image support. Use the current guidance and primary sources on this page to assess the distribution.
Historical Kubedex content
Original publication: 2018-09-14T14:51:25+00:00. Preserved for context. Commands, versions, prices and results below reflect the original research.
namerd is a service that manages routing for multiple linkerd instances. namerd is a service that manages routing for multiple Linkerd instances. It does this by storing dtabs and using namers for service discovery. namerd supports the same suite of service discovery backends that Linkerd does, which include services like ZooKeeper, Consul, Kubernetes API, and Marathon.
Using namerd, individual Linkerds no longer need to talk directly to service discovery or have dtabs hardcoded into their config files. Instead, they ask namerd for any necessary routing information. This provides a number of benefits, which are outlined below.
Decreased load on service discovery backends
Using namerd means that only a small cluster of namerds need to talk directly to the service discovery backends instead of every Linkerd in the fleet. namerd also utilizes caching to further protect the service discovery backend from excessive load.
Global routing policy
By storing dtabs in namerd instead of hardcoding them in the Linkerd configs, it ensures that routing policy is in sync across the fleet and gives you one central source of truth when you need to make changes.
Dynamic routing policy
The other advantage of storing dtabs in namerd is that these dtabs can be updated dynamically using namerd’s API or command-line tool. This allows you to perform operations like canary, staging, or blue-green deploy, all without needing to restart any Linkerds.
More information
To learn more about namerd, its setup, and its operation, check out Buoyant’s blog post on dynamic routing.
To configure your own namerd, head over to the namerd config documentation. Also check out namerctl, our open source tool for controlling namerd.
For a step-by-step walkthrough of running namerd in Kubernetes to facilitate continuous deployment, check out Buoyant’s blog post Continuous deployment via traffic shifting.
The post Namerd appeared first on kubedex.com.
Sources & further reading
Spotted something that needs another look?
Help improve this page →