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 immediately gives us a number of benefits:
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.
To learn more about namerd, its setup, and its operation, check out Buoyant’s blog post on dynamic routing.
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.