Linkerd a fondo

En esta presentación hablamos de Linkerd, uno de los pioneros en el ámbito de las "arquitecturas Service Mesh". Haremos un repaso por la historia de este producto, conoceremos sus principales funcionalidades y tendremos una parte práctica en la que mostraremos su integración en arquitecturas distribuidas junto a Docker y Kubernetes.

1. Cliente. Nombre proyecto.
Service mesh - Linkerd a fondo
Luis Mora

2. Meetup microservicios - Linkerd a fondo
About me
@luismoramedina
Luis Mora Medina

Arquitecto software @Paradigma

3. Meetup microservicios - Linkerd a fondo
introducción a service mesh
Linkerd a fondo
1

4. Meetup microservicios - Linkerd a fondo
1 Service mesh / Problemáticas de las “nuevas” aplicaciones



Aplicaciones deslocalizadas y distribuidas en numerosos componentes que hablan con numerosos
protocolos de red, arquitecturas complejas, que crecen en número de dependencias
●Service Discovery
●Enrutamiento y balanceo de carga
●Gestión de errores: time-out, reintentos, circuit-breaker
●Securización y control de acceso (autenticación / autorización)
●Comprobación de disponibilidad (Health check)
●Métricas, monitorización, logging y trazabilidad distribuidos
“The Hardest Part of Microservices:
Calling Your Services”
Christian Posta

5. Meetup microservicios - Linkerd a fondo
1 Service mesh / Que es?
“A service mesh is a dedicated infrastructure layer for handling
service-to-service communication. It’s responsible for the reliable
delivery of requests through the complex topology of services that
comprise a modern, cloud native application”

William Morgan, Buoyant CEO
April 2017

6. Meetup microservicios - Linkerd a fondo
Stubby
1 Service mesh / Service mesh “as a library”
●spring-cloud-netflix-hystrix
●spring-cloud-netflix-ribbon
●spring-cloud-netflix-eureka
●spring-cloud-netflix-zuul
●spring-cloud-sleuth
●spring-cloud-zipkin
●vertx-circuit-breaker
●vertx-service-discovery
●vertx-dropwizard-metrics
●vertx-zipkin
de Twitter
¿Es nuevo este concepto?

7. Meetup microservicios - Linkerd a fondo
●A alto nivel, la responsabilidad del service mesh es asegurar que las solicitudes
sean entregadas en las conexiones entre los servicios de nuestra arquitectura
distribuida
●Propicia arquitecturas políglotas
●Permite que los equipos de desarrollo se centren en la funcionalidad de sus
aplicaciones y que la lógica de negocio no se difumine con el código de
instrumentación de las conexiones
1 Service mesh / Que aporta?

8. Meetup microservicios - Linkerd a fondo
1 Service mesh / Patrón sidecar
Aplicación
principal

●Core de la
aplicación
●Tiene la
funcionalidad y
la ofrece por sí
sola
●Corre en un
proceso o
contenedor
diferente
Sidecar

Ofrece ayuda a la
aplicación principal

●Telemetría y
monitorización
●Logging
●Proxy
●Protocol
transformation
●Configuración
●Health
●Auditoría
●...

9. Meetup microservicios - Linkerd a fondo
Pod
1 Service mesh / Patrón sidecar en Kubernetes
POD: Unidad de computación mínima que puede ser desplegada en
Kubernetes
main
sd container 2
sd container 3
Shared

●Network & IP
●Hostname
●Data Volumes
localhost

10. Meetup microservicios - Linkerd a fondo
1 Service mesh / Modos de instalación
Per host
●1 proxy en cada host
●n..1 servicios - proxy
●menor gasto de memoria
●puede llegar a ser un SPOF

11. Meetup microservicios - Linkerd a fondo
1 Service mesh / Modos de instalación
Sidecar
●1 proxy por cada servicio
●1..1 servicios - proxy
●más versátil
●mejor rendimiento

12. Meetup microservicios - Linkerd a fondo
1 Service mesh / Data plane
Los service mesh suelen tener dos partes (1/2):
-El plano de datos (maya de proxies encargados
de gestionar conexiones entre componentes)

13. Meetup microservicios - Linkerd a fondo
1 Service mesh / Control plane
Los service mesh suelen tener dos partes (2/2):
-El plano de control (políticas, gestión,
configuración, monitorización del data plane)

14. Meetup microservicios - Linkerd a fondo
qué es Linkerd?
Linkerd a fondo
2

15. Meetup microservicios - Linkerd a fondo
2 Linkerd / Qué es?
What is Linkerd?
“Linkerd is an open source network proxy designed to be deployed
as a service mesh: a dedicated layer for managing, controlling,
and monitoring service-to-service communication within an
application.”
/linkerd-DEE/

16. Meetup microservicios - Linkerd a fondo
2 Linkerd / Producto
●Linkerd (l5d) aparece en 2016
●Open-source con Soporte comercial (Bouyant)
●Desarrollado en scala y ejecutado en la JVM
●Basado en Finagle y Netty
●Soporte a múltiples clouds, herramientas y protocolos
●“Performante” p99 (99% peticiones) < 1 milisegundo
●Extensible
●Dentro de la iniciativa CNCF
●Nuevo producto Linkerd2 (f.k.a. Conduit)

17. Meetup microservicios - Linkerd a fondo
2 Linkerd / Funcionalidades
●Enrutamiento dinámico
○Blue green
○Canary

●Balanceo de carga avanzado
○Least loaded
○Round robin, etc.

●Gestión de errores
○Circuit breaking
○Reintentos para llamadas fallidas
○Límite de carga
●Autodescubrimiento
●Seguridad de red
service-to-service (TLS)
●Trazabilidad distribuida
●Monitorización y métricas
●Sidecar o proxy por host
●Multi protocolo
○Http1
○Http2 (Grpc)
○Thrift

18. Meetup microservicios - Linkerd a fondo
2 Linkerd / Arquitecturas
https://linkerd.io/1/advanced/deployment/
Per host
●1 Linkerd en cada host
●n..1 servicios - linkerd
●menor gasto de memoria
●puede llegar a ser un SPOF

Sidecar
●1 Linkerd por cada servicio
●1..1 servicios - linkerd
●más versátil
●mejor rendimiento

19. Meetup microservicios - Linkerd a fondo
2 Linkerd / Plano de control
¿Tiene Linkerd un plano de
control?

20. Meetup microservicios - Linkerd a fondo
2 Linkerd / Namers, namerd y dtab
●Los “namers” son los encargados de resolver nombres lógicos
de servicios y transformarlos en una dirección “física”

●Delegation tabs (dtabs) son las reglas de enrutado para
resolver los path lógicos

●Existen numerosos namers: k8s, marathon, consul, filesystem,
zookeeper, etc.

●Toda esta configuración puede estar en cada proxy o puede
estar en un servicio llamado “namerd”, que permite cambios en
caliente

21. Meetup microservicios - Linkerd a fondo
2 Linkerd / Enrutado
/meetup/goto
/kschool/goto
/madrid/magallanes/1/goto
/spain/madrid/magallanes/1/goto
/meetup => /kschool;
/kschool => /madrid/magallanes/1;
/madrid => /spain/madrid;

/meetup/goto

Finagle
delegation table
Logical path
Physical name

22. Meetup microservicios - Linkerd a fondo
2 Linkerd / Enrutado avanzado
/meetup => /kschool;
/kschool => /madrid/magallanes/1 * 0.9 & /madrid/sol/5 * 0.1;
/madrid => /spain/madrid;
Canary or AB
deployments
/svc/local => /$/inet/127.0.0.1/8080

/$/inet namer
/svc => /#/io.l5d.fs
file system
namer (not for
production)
192.0.2.220 8080
192.0.2.210 8080 * 2.0
/$ a classpath
namer
A configurable
namer

23. Meetup microservicios - Linkerd a fondo
2 Linkerd / Integraciones

24. Meetup microservicios - Linkerd a fondo
playground
Linkerd a fondo
3

25. Meetup microservicios - Linkerd a fondo
3 Playground / Configuración básica
admin:
port: 9990
ip: 0.0.0.0

routers:
- protocol: http
dtab: /svc/* => /$/inet/python/8080;
servers:
- port: 4140
ip: 0.0.0.0
4140
client
linkerd
python
8080

26. Meetup microservicios - Linkerd a fondo
3 Playground / Configuración balanceo
●Round Robin

●P2C (Power of two choices) Least loaded: coge 2 nodos del pool de
manera aleatoria y envía la petición al menos cargado de la tupla (el que
menos peticiones pendientes tiene). Por defecto.

●P2C (Power of two choices) Peak EWMA: variación del anterior pero que
tiene en cuenta los servidores con mayores latencias para dejarles
tiempo para su recuperación

●Aperture Least Loaded

●Heap Least Loaded

27. Meetup microservicios - Linkerd a fondo
3 Playground / Configuración balanceo
namers:
- kind: io.l5d.fs
rootDir: disco

routers:
- protocol: http
dtab: /svc => /#/io.l5d.fs/nginx;
servers:
- port: 4140
ip: 0.0.0.0
4140
client
linkerd
nginx1
8080
nginx2
8080
httpbin.org

28. Meetup microservicios - Linkerd a fondo
3 Playground / Configuración circuit breaking
●Linkerd elimina nodos del pool de balanceo cuando no están “sanos”
○A nivel de conexión (failFast)
○Basado en fallos (failureAccrual)
■Número de fallos consecutivos
■Porcentaje de peticiones erróneas (contabilizando las últimas peticiones o usando
una ventana de tiempo)

●Existe una política de reinserción en el pool
○tiempo constante
○jittered (tiempo incremental)

●El pool de nodos no se puede quedar vacío, se siguen enviando peticiones a alguno de los
nodos aunque todos hayan sobrepasado el umbral de “retirada”

●Por defecto se eliminará del pool un nodo a los 5 fallos consecutivos

29. Meetup microservicios - Linkerd a fondo
3 Playground / Configuración circuit breaking
routers:
- protocol: http
...
client:
failureAccrual:
kind: io.l5d.consecutiveFailures
# remove from the pool on 2 FAILs
failures: 2
backoff:
kind: constant
# wait 15s after reinserting
ms: 15000
4140
client
linkerd
nginx1 nginx2
httpbin.org
2x

30. Meetup microservicios - Linkerd a fondo
3 Playground / Configuración reintentos
service:
responseClassifier:
kind: io.l5d.http.retryableRead5XX
retries:
budget:
minRetriesPerSec: 0
# every failure is retried twice
percentCanRetry: 2
backoff:
kind: constant
ms: 300
4140
client
linkerd
nginx1 nginx2
httpbin.org
2x
retry

31. Meetup microservicios - Linkerd a fondo
3 Playground / Configuración telemetría
telemetry:
- kind: io.l5d.recentRequests
sampleRate: 1.0
- kind: io.l5d.prometheus
- kind: io.l5d.zipkin
host: zipkin
port: 9410
sampleRate: 1.0
linkerd
4140 client
nginx1 nginx2
httpbin.org
prometheus
zipkin .

32. Meetup microservicios - Linkerd a fondo
3 Playground / Instalación en Kubernetes
Kubernetes
4141
client
8081
4141
8081
http://books
Pod
linkerd
books
Pod
linkerd
stars
/svc/stars
3
4140
2
4
5
1
Modo Sidecar

33. Meetup microservicios - Linkerd a fondo
3 Playground / Instalación en Kubernetes
Modo Proxy
por host
Kubernetes
4141
client
stars
books
8081
4140
4141
8081
/svc/stars
http://books
linkerd
1
3
2
4
5

34. Meetup microservicios - Linkerd a fondo
3 Playground / Adaptando tus aplicaciones
Y todo esto... ¿sin modificar nuestras
aplicaciones?

●Nuestros clientes http deben usar Linkerd como proxy* (HTTP_PROXY,
http.proxyHost, http.proxyPort)

●Se deben propagar, en las llamadas a otros servicios upstream, las
cabeceras de Linkerd (l5d-ctx-*)
* Linkerd puede actuar como proxy transparente en
k8s, modificando las iptables en un init container

35. Meetup microservicios - Linkerd a fondo
conclusiones
Linkerd a fondo
4

36. Meetup microservicios - Linkerd a fondo
4 Conclusiones / Pros y contras
Tiene soporte comercial
Soporte a múltiples entornos y clouds
Instalación en arquitectura sidecar o nodo por host
Integración con múltiples productos
Producto robusto, sólido y rápido
Abierto a la implementación de plugins con los
lenguajes de la JVM

No tiene un plano de control avanzado
El elevado footprint del proxy dificulta su instalación en
modo sidecar
La funcionalidad de circuit breaker tiene algunas
deficiencias
Se echan de menos funcionalidades extra de seguridad
CONTRASPROS

37. Meetup microservicios - Linkerd a fondo
4 Conclusiones / Linkerd VS Linkerd2
Linkerd 1 Linkerd 2
No tiene un plano de control diferenciado, se queda en
el plano de datos Tiene un plano de control
Diferentes modos de instalación (Sidecar proxy/Proxy
per host) Instalación en Sidecar dentro de pods
Proxy con footprint medio (JVM) ~150 megas Proxy ultraligero (Rust)
Múltiples integraciones con productos de terceros
Es un producto relativamente nuevo, menos integraciones
y menos funcionalidad (no circuit breaker, no routing, etc.)
Instalación y configuración es artesanal
Cuenta con un cli para realizar instalación y configuración
del sistema
Soporte a múltiples plataformas (AWS, DC/OS,
Kubernetes, Docker, On-Premise)
Diseñado inicialmente para funcionar en Kubernetes
(>=1.9)

38. Meetup microservicios - Linkerd a fondo
¿Preguntas?

https://github.com/luismoramedina/linkerd-playground
https://github.com/luismoramedina/linkerd-microservices