This is a creation in Article, where the information may have evolved or changed.
"Editor's note" as businesses evolve to transform traditional monolithic applications into microservices or cloud-native applications, while microservices or cloud-native applications can bring more benefits to businesses, there are challenges, such as how to manage the complexity of inter-service communication from monolithic applications to microservices, How to achieve a safe, efficient, reliable access to microservices, how to meet multi-lingual and multi-environment transparent communication, service discovery, fuse, dynamic traffic migration, canary deployment, cross-data center access and so on. This share introduces you to a new concept service mesh and an introduction to the industry's main service mesh tool, Linkerd.
"3 days Burn brain container Storage Network Training Camp |" This training is themed on container storage and networking, including: Docker Plugin, Docker storage driver, Docker Volume Pulgin, Kubernetes Storage mechanism, container network implementation principle and model, Docker network implementation, network plug-in, Calico, Contiv netplugin, open source enterprise-level image warehouse Harbor principle and implementation.
Before we start introducing linkerd, I don't know how much we know about the concept or noun of service mesh, but I haven't heard a new word before this year (ignorant). Service mesh is actually a buzzword in the current microservices or cloud-native application domain. So, what exactly is Service mesh? What can I do? What are the benefits to microservices or cloud-native applications? Is it necessary to use or deploy service mesh? Well, I'll talk to you about Linkerd tonight and answer these questions by the way.
What is Service Mesh?
- Service Mesh is a dedicated infrastructure layer.
- Lightweight, high-performance network proxy.
- Provide secure, fast, and reliable service-to-Inter communication.
- Together with the actual application deployment, but transparent to the application.
What can Service mesh do?
- Provides a fusing mechanism (circuit-breaking).
- Provides load balancing of perceived latency (latency-awareload balancing).
- Eventually consistent service discovery (discovery).
- Connection retry (retries) and termination (deadlines).
- Manage the complexity of microservices and cloud-native application communications to ensure reliable delivery of application requests.
is Service mesh necessary? This may not be an absolute answer, but:
- Service mesh enables rapid turnaround to microservices or cloud-native applications.
- Service Mesh extends the application load in a natural way, addressing the inevitable partial failure of distributed systems and capturing changes in highly dynamic distributed systems.
- Fully decoupled from the application.
What service mesh products are available in the industry?
- Buoyant's linkerd, based on Twitter's fingle, has long-term practical experience and validation of production lines, supports kubernetes, Dc/os container management platforms, and is one of the CNCF's official support projects.
- Lyft's envoy,7 layer agent and communication bus supports 7 layers of HTTP routing, TLS, GRPC, service discovery, and health monitoring.
- IBM, Google, Lyft supported Istio, an open source microservices connectivity, management platform, and security management for microservices, support Kubernetes, Mesos, and other container management tools, with the underlying dependency on envoy.
What is Linkerd?
- Provides resilient service Mesh for cloud-native applications.
- Transparent high performance network proxy.
- Provides service discovery mechanism, dynamic routing, error handling mechanism and application Runtime visualization.
Features of the Linkerd:
Fast, lightweight, high performance.
- Processing million requests per second with minimal latency and load.
- Easy to scale horizontally.
Support any development language and any environment.
Provides load balancing based on perceived latency.
- Distribute requests through real-time performance data.
- Because Linkerd works at the RPC layer, it is better than traditional heuristic load balancing algorithms such as LRU, TCP activity, and so on, depending on the real-time observed RPC latency and the request queue size to be processed.
- Provides a variety of load balancing algorithms such as: Power of Choices (P2C): Least Loaded, power of the Choices:peak EWMA, Aperture:least Loaded, Heap:least Lo Aded and Round-robin.
Run-time traffic routing.
- Per-request level routing through a specific HTTP header.
- Dynamically modify DTAB rules for traffic migration, blue-green deployment, canary deployment, cross-datacenter failover, and more.
Fusing mechanism.
- Fail fast-session-driven fuse.
- Failure accrual-Request-driven fuses.
Plug-in service discovery.
- Support for various service discovery mechanisms such as file-based (file-based), Zookeeper,consul and Kubernetes.
Supports multiple protocols: http/1.1, HTTP/2, Grpc, Thrift, Mux.- After the production line testing and verification.
Linkerd Terminology:
##################################################################################
# A Basic Service mesh for Internal Linkerd config. This config contains a #
# outgoing router that proxies requests from local applications to the Linkerd #
# running on the destination host and a incoming router that reverse-proxies #
# incoming requests to the application instance running on the local host. #
##################################################################################
Admin
port:9990
Namers:
-Kind:io.l5d.consul
host:127.0.0.1
port:8500
Includetag:false
Sethost:false
-Kind:io.l5d.rewrite
Prefix:/srv
Pattern: "/{service}"
Name: "/srv/{service}"
Routers:
-Protocol:http
Identifier
Kind:io.l5d.path
Segments:1
Label:routera_outgoing
Dtab: |
/srv =/#/IO.L5D.CONSUL/DC;
/svc =/#/srv;
Httpaccesslog:/alloc/logs/access_routera.log
Servers
-port:8080
ip:0.0.0.0
-Protocol:http
Label:outgoing
Dtab: |
/consul =/#/IO.L5D.CONSUL/DC;
/svc =/$/io.buoyant.http.subdomainofpfx/svc.consul/consul;
Httpaccesslog:/alloc/logs/access_outgoing.log
Servers
-PORT:80
ip:0.0.0.0
Interpreter:
Kind:default
Transformers:
# Instead of sending the request directly to the destination and send it to
# The Linkerd (listening on port Bayi) running on the destination host.
-Kind:io.l5d.port
port:81
- Protocol:http
Label:incoming
Dtab: |
/consul =/#/IO.L5D.CONSUL/DC;
/svc =/$/io.buoyant.http.subdomainofpfx/svc.consul/consul;
Servers
- port:81
ip:0.0.0.0
Interpreter:
Kind:default
Transformers:
# Instead of sending the request to a random destination instance, send it
# instances running on localhost. -Kind:io.l5d.localhost
Telemetry
-Kind:io.l5d.recentRequests
samplerate:1.0
-Kind:io.l5d.prometheus
Usage
Enabled:false
- The Router:linkerd configuration must define the Router module, which can define multiple Router, other including protocols used by the service protocol, Identifier, Transformer, Server, Dtab, Client, Service and interpreter.
- Identifier: Used to assign a logical name (logical name) or path (path) to a request, Commonly used identifier such as: Io.l5d.methodandhost,io.l5d.path,io.l5d.header,io.l5d.header.token and io.l5d.static, such as Identifer:io.l5d.header . Token assigns the Get Http://example/hello the logical name/svc/example. Custom Indentifier plugins can be developed. More reference https://linkerd.io/config/1.1. ... iers.
- Namer: Defines how the client name and real address are bound, in essence, how service discovery is performed through service discovery systems, commonly used namer such as: Io.l5d.fs,io.l5d.consul,io.l5d.k8s,io.l5d.marathon and Io.l5d.rewrite, more reference https://linkerd.io/config/1.1. ... amers.
- Interpreter: Decide how to parse namer, commonly used such as: Default, Io.l5d.namerd, Io.l5d.namerd.http, Io.l5d.mesh and Io.l5d.fs, more reference https:// linkerd.io/config/1.1. ... reter.
- Transformer: Based on how interpreter transforms the resolved address, Transformer takes effect in the order in which it appears, such as: Io.l5d.localhost,io.l5d.specifichost,io.l5d.port,io.l5d.k8s.daemonset,io.l5d.k8s.localnode,io.l5d.replace and Io.l5d.const, More reference https://linkerd.io/config/1.1. ... ormer.
- Delegation Table (a.k.a. Dtab): Defines how to convert the service name (the name of the server) to the client name, the client name to the service discovery entry, the service Discovery tool based on how this entry discovers the service, which must be in/$ or/#打头, such as/#/ Io.l5d.consul/dc/product.
Linkerd How do I handle application requests?
Before we talk about Linkerd how to handle application requests, let's take a look at the data processing flowchart that Linkerd officially gives.
We can break down the entire process into 4 main steps:
- Identification: The actual application request such as http://foo.com is actually translated for Get foo.com to the logical name (logical name) or the service name, the specific conversion rule is determined by identifier, Linkerd provides a variety of identifier and chooses to use according to the actual demand, in identifier for Io.l5d.header.token to convert get foo.com to/svc/foo.com.
- Binding: After the completion of the identification, Dtab begins to appear, binding the resulting service name to the client name, how the binding depends on how the Dtab rule is set, the dtab shown, then/svc/foo.com is bound to/#/io.l5d.fs /foo.com.
- Resolution: Even when the binding is complete, Linkerd still fails to forward the request to the backend service, and does not actually know the client name/#/io.l5d.fs/ The foo.com specifically represents what, while resolution converts the client name to the real service address, IP address, and port. The conversion logic is determined by the specified Namer, different namer conversion logic, if Namer for Io.l5d.consul then find the Consul Catalog API to obtain IP address and port information, And the figure Namer for io.l5d.fs,file-based Namer,linkerd will read a local file named Foo.com, the location of the file is determined by the configuration, the file will contain the figure of 2 records 1.1.1.1:8080 and 1.1.1.2 : 8080, then return to the above 2 records.
- Loadbalancing: Once the resolution is completed, the real service address is found, and Linkerd will select a service address based on the load balancing algorithm configured previously.
Now that Linkerd has completed how to handle the application request, here is an example of how an exercise can be translated from the service name to the real address.
Simple Demo
- Deploy Linkerd in host mode.
- Create a service customer and Product,customer communicate with product and return some information, both of which run as containers.
- Register the service customer and product to consul.
- The Linkerd Access Service customer,curl-s-H "Host:customer.svc.consul" 10.xx.xx.199/product outputs the following information:
Q&a
Q: The specific test performance, compared with LVS, Nginx?
A:linkerd Although is a network agent, but with LVS, Nginx still have different, solve the problem also different, for example linkerd common deployment way to sidecar mode deployment. For performance data, a single linkerd is able to handle 20K/SEC requests, p99 latency within 10ms, but more than 20K, in my test environment, is not raised much. And the comparison with the Nginx and LVS, has not been done.
Q: Can you say "fusing mechanism (circuit-breaking)" How to understand?
The A:LINKERD supports 2 ways of fusing, one based on session or link, and the other on request-based fusing. For the session layer of the fuse, linkerd when forwarding the request to the backend application instance, if one of the links is found to have a problem, Linkerd will remove it from the maintenance of a pool, there will be no real request sent to the instance, and in the background, Linkerd will try to connect, once the connection is successful, Linkerd it into the pool again and continues to serve.
And for the request-based fuse, Linkerd will be based on the configuration of Linkerd, such as configured to Io.l5d.consecutiveFailures, Linkerd observed a specified number of consecutive errors, then fuse, other ways to view https:// linkerd.io/config/1.1. ... crual.
How does the q:linkerd achieve horizontal scaling? Does the cluster have a limited number of linkerd compute nodes?
The a:linkerd itself is stateless, so horizontal scaling is easy, and the number of clusters to linkerd depends on how you deploy Linkerd, https://linkerd.io/in-depth/deployment/ This place lists the advantages and disadvantages of various deployment methods.
Q: Looking at the final table seems to be able to implement the display service call chain, showing upstream and downstream relationships? Can we use this to find out the specific service pressure bottleneck in which ring, whether there is performance monitoring?
A:linkerd provides detailed metric, these metric will tell you where the performance occurs, and Linkerd is integrated with Zipkin, so you can trace to the service's access stream, showing the performance of each session.
Q: Can you compare istio?
A: The underlying envoy and linkerd of the corresponding istio essentially achieve similar functionality, Linkerd support Kubernetes, Dc/os, and integration with a variety of service discovery tools, and Istio, as far as I know, currently supports kubernetes, The use of specific istio, has not been used, not very clear.
Q: If the linkd is stateless, how to maintain the internal fuse pool?
A: Here is stateless refers to the linkerd work when the individual instances do not need information synchronization, even if an instance of the problem, the normal work of a whole environment is irrelevant, just restart it, all services found in the information are stored outside, such as consul, ZK, etc., local only cache, There is no persisted data, and the information of the fuse pool is from the service discovery system.
The above content is organized according to the July 04, 2017 night group sharing content. Share people
Yang Zhangxin, Cisco Advanced Systems Engineer. Focus on cloud computing, containers, microservices and other areas, currently in Cisco responsible for the construction of internal PAAs platform related work。 Dockone Weekly will organize the technology to share, welcome interested students add: LIYINGJIESA, into group participation, you want to listen to the topic or want to share the topic can give us a message.
