![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.](https://image.slidesharecdn.com/containers-170727145532/85/Linkerd-Service-mesh-with-service-Discovery-backend-13-320.jpg)
![Zipkin integration
Config:
telemetry:
- kind: io.l5d.zipkin
host: [zipkin-host]
port: 9410
sampleRate: 1.0](https://image.slidesharecdn.com/containers-170727145532/85/Linkerd-Service-mesh-with-service-Discovery-backend-14-320.jpg)
Linkerd – Service mesh with service Discovery backend
- 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
- 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