Linkerd is a service mesh that provides service discovery, routing, failure handling and visibility for microservices applications. It integrates with various container orchestration systems like Kubernetes and Nomad. Linkerd uses Envoy proxies deployed as sidecars next to applications to handle communication between services. It supports features like load balancing, failure handling, canary releases and observability via integrations with tools like Zipkin and Prometheus. Namerd is a companion service to Linkerd that handles service name resolution using delegation tables (dtabs) that map logical names to physical addresses obtained from service registries.

1. Linkerd – Service mesh with
service Discovery backend
Leandro Totino Pereira – System Engineer

2. Orchestration system for containers
Kubernetes – Container system platform based on etcd
Nomad – Container system based on consul
Nomad Kubernetes
Multi-datacenter Native Federation
Multitenancy No Yes
Load Balancing External (consul-templates) Basic Integrated (Services)
Workload Container, java, commands, lxc and
qemu hypervisors based.
Just Containers
Network abstraction Port hypervisor based Port/IP services context based
Multi-Datacenter yes No (federation)
abstrations jobs RC
Load Balancer integration External (consul-template or API) Services (basics load balancer) or API

3. Service Discovery
Itens Consul Etcd
Cluster protocol Raft (Serf) Raft
Datacenter-aware yes No (Kubernetes federation)
auto-configuration DNS yes no
Service Agents yes no
KV store yes yes
Handler and Watches yes no
events yes no

4. Benchmark I Result
Tests send 300,000 requests to key/value stores. One with jsonrpc, the other with gRPC. Both jsonrpc and gRPC code use only one TCP
connection. And another gRPC case with one TCP connection but with multiple clients:
Source: https://blog.gopheracademy.com/advent-2015/etcd-distributed-key-value-store-with-grpc-http2/

5. Benchmark II Result
The output shows that Protocol Buffers outperforms JSON and XML in both marshaling and unmarshaling. The result shows the following
numbers:
:
Protocol Buffers Marshal: 819 ns/op
Protocol Buffers Unmarshal: 1163 ns/op
JSON Marshal: 3316 ns/op
JSON Unmarshal: 7196 ns/op
XML Marshal: 9248 ns/op
XML Unmarshal: 30485 ns/op
Source: https://medium.com/@shijuvar/benchmarking-protocol-buffers-json-and-xml-in-go-57fa89b8525

6. Linkerd
• linkerd is a transparent proxy that adds service discovery, routing, failure handling, and visibility to modern
software applications
• Integration service discovery
• Handles tens of thousands of requests per second per instance with minimal latency overhead. Scales
horizontally with ease
• Provides dynamic, scoped, logical routing rules, enabling blue-green deployments, staging, canarying, failover,
and more.
• Zipkin, Prometheus and statsd integration
• Multi-container orchestration supported
• Cloud Native Computing Foundation
• 918 commit, 30 contributors, 2244 stars, 30 release
• Slack channel really active

7. Linkerd – Integration I
Nomad Integration
JOB Specs:
env { NOMAD_HOST=$HOSTNAME }
Kubernetes Integration
YAML Specs:
env:
- name: NODE_NAME
valueFrom:
fieldRef:
fieldPath: spec.nodeName
- name: POD_IP
valueFrom:
fieldRef:
fieldPath: status.podIP
- name: http_proxy
value: $(NODE_NAME):4140

8. Linkerd Integration II
Container
export http_proxy=$NOMAD_HOST:4140
Test:
For example, if we have a consul servisse named hello, we can resquest passing http header “Host: hello”
curl -sI -H 'Host: hello’ http://
Or if http_proxy is not defined:
curl -sI -H 'Host: hello’ http://$NOMAD_HOST / http://$NODE_NAME

9. Linkerd – architecture I

10. Linkerd – architecture II
1 – Application in containers register to service Discovery as service
2 – Linkerd gets services from services Discovery
3 – Application communicate by linkerd through http_proxy variable or directly by node_name
variable.
4 - Containers must connect to linkerd in your own host/hypervisor.
5 – Linkerd balance or forward connection to another linkerd.

11. Namerd

12. Dtab and Dentries
Dtab or Delegation tables (dtabs for short) are lists of routing rules (dentries) that take a “logical path”
which looks like to rewrite url paths.
Dtabs can (and often do) have more than one dentry. For example, we could list several stores:
3 - /smitten => /USA/CA/SF/Octavia/432;
2 - /iceCreamStore => /smitten;
1 - /iceCreamStore => /humphrys;
When we try to resolve a path that matches more than one prefix, bottom dentries take precedence.
So the path /iceCreamStore/try/allFlavors would resolve first as /humphrys/try/allFlavors. However, if
the address for humphrys is unknown (as in this example), we fall back to /smitten/try/allFlavors,
which ultimately resolves to /USA/CA/SF/Octavia/432/try/allFlavors.

13. Namers– Service discovery
Config Consul/Nomad:
namers:
- kind: io.l5d.consul
host: [ consul server ]
port: 2181
includeTag: true
useHealthCheck: true
Routing:
dtab: |
/svc => /#/io.l5d.consul/dc1/prod;
Config k8s:
namers:
- kind: io.l5d.k8s
host: ip [k8s master]
port: 8001
labelSelector: version
Routing:
dtab: |
/svc => /#/io.l5d.k8s/prod/http;
A namer binds a concrete name to a physical address which is used to setup service discovery backend
access.

14. Zipkin integration
Config:
telemetry:
- kind: io.l5d.zipkin
host: [zipkin-host]
port: 9410
sampleRate: 1.0

15. Thank you!
Question?
More information:
Linkedin
https://www.linkedin.com/in/leandro-totino-pereira-
06726227
Facebook:
https://www.facebook.com/leandro.totinopereira