namerd

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.