Linkerd – Service mesh withservice Discovery backend

Leandro Totino Pereira – System Engineer

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 andqemu 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

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

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/

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

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

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

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

Linkerd – architecture I

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_namevariable.

4 - Containers must connect to linkerd in your own host/hypervisor.

5 – Linkerd balance or forward connection to another linkerd.

Namerd

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.

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.

Zipkin integration

Config:

telemetry:

- kind: io.l5d.zipkin

host: [zipkin-host]

port: 9410

sampleRate: 1.0

Thank you!

Question?

More information:

Linkedin

https://www.linkedin.com/in/leandro-totino-pereira-

06726227

Facebook:

https://www.facebook.com/leandro.totinopereira