In 2020, Bilgin Ibryam proposed the concept of Multi-Runtime (Multi-Runtime), and made a practical summary and theoretical sublimation of various product forms based on the Sidecar model. So what exactly is multi-runtime? First of all, we have to start with the four basic requirements of distributed applications. Simply put, there are four basic requirements in any distributed application:
1. Life cycle: including deployment, health check, horizontal expansion, configuration management, etc. Currently, the best practices for these requirements have been implemented on kubernetes.
2. Network: Network requirements are the main battlefield of service mesh. For example, istio can meet most of the requirements here, except for pub/sub.
3. State: including data reading and writing, the state is actually very difficult to manage, involving idempotence, caching, data flow, etc.
4. Binding: mainly refers to the interaction with external resources of the system.
In the era of traditional software, it was coupled in the application code, but nowadays, more and more distributed capabilities are stripped from the application, and the way of stripping is gradually changing. From the earliest days, these capabilities were stripped from the business code into the dependency library, and then some features are stripped to the platform layer (kubernetes). Now, more non-business capabilities will be stripped into sidecar. The author predicts: In theory, each microservice can have multiple runtimes: a business runtime, and multiple distributed capability runtimes, but the ideal situation is, or the most likely situation is: running outside the business When combined into one, all distributed capabilities are provided to the business in a highly modular, standardized and configurable manner. Dapr has completed the integration of istio a long time ago. In theory, we can provide distributed capabilities by running two sidecars. istio focuses on the network side, including not limited to service registration discovery, A/B testing, and canary Deployment, traffic mirroring, monitoring links, etc. Of course, there is a certain overlap in dapr, but it is not as detailed as istio, and the two can complement each other. Dapr can provide network functions that istio does not have, such as subscription/publishing, state management, including state idempotency, consistency, actors, etc., as well as binding, which interacts with external systems through binding.
Table of contents:
1. Implement a simple .net-based microservice e-commerce system through Dapr
2. Realize a simple .net-based microservice e-commerce system through Dapr (2)——Communication framework explanation
3. Implement a simple .net-based microservice e-commerce system through Dapr (3) - teach you how to use Dapr step by step
4. Realize a simple .net-based microservice e-commerce system through Dapr (4) - step by step to teach you how to subscribe and publish Dapr
Realize a simple .net-based microservice e-commerce system through Dapr (5) - teach you how to use Dapr's state management step by step
Realize a simple .net-based microservice e-commerce system through Dapr (6) - teach you how to use Dapr's Actor service step by step
Realize a simple .net-based microservice e-commerce system through Dapr (7) - teach you step by step how to limit the service flow of Dapr
Realize a simple .net-based microservice e-commerce system through Dapr (8) - teach you how to follow Dapr's link tracking step by step
Realize a simple .net-based microservice e-commerce system through Dapr (9) - teach you how to use Dapr's OAuth2 authorization step by step
Realize a simple .net-based microservice e-commerce system through Dapr (9)-step by step to teach you how to use Dapr's OAuth2 authorization-Baidu version
Realize a simple .net-based microservice e-commerce system through Dapr (10) - teach you how to bind Dapr step by step
Realize a simple .net-based microservice e-commerce system through Dapr (13)—istio+dapr builds a multi-runtime service grid for production environment deployment
Appendix: (If you think it is useful to you, please give a star)
1. E-commerce Demo address: https://github.com/sd797994/Oxygen-Dapr.EshopSample
2. Communication framework address: https://github.com/sd797994/Oxygen-Dapr
What is istio? To put it simply, istio is a service mesh, similar in structure to dapr, which provides distributed capabilities by inserting sidecars on top of the application, and at the same time performs specific scheduling and control of these sidecars through the control plane, but istio prefers To provide network capabilities, the one-sentence description on its official website can be summed up: "Simplifies observability, traffic management, security and policy through leading service mesh." Its functions include the following:
1. Secure service-to-service communication within the cluster using TLS encryption, strong authentication and authorization
2. Automatic load balancing of HTTP, gRPC, WebSocket, and TCP traffic
3. Fine-grained control of traffic behavior through rich routing rules, retry, failover and fault injection
4. A pluggable policy layer and configuration API that supports access control, rate limiting and quotas
5. Automatically measure, log and track all traffic in the cluster (including cluster ingress and egress)
Having said so much, let's talk about how to integrate multiple runtimes for our e-commerce demo through dapr+istio. The first is installation. You can refer to the official Chinese documentation of istio for installation. The default installation profile=demo will help us install istiod+ingressgateway+egressgateway. istiod is the core of our control plane, which is different from dapr’s method of dispersing the control plane in multiple containers. After the version 1.5 iteration, all the functions have been merged into one container. The ingressgateway is used to replace the ingress-controller, and the egress is the egress gateway. Since istio controls the ingress and egress traffic by default, we do not need to restrict the egress traffic here, so it is set to ALLOW_ANY. At the same time, there is no need to pull the sidecar image every time.
istioctl install --set profile=demo --set meshConfig.outboundTrafficPolicy.mode=ALLOW_ANY --set values.global.imagePullPolicy=IfNotPresentSimilarly, we need to point the ingressgateway as nodeport to our 30882. Remember that we need to modify the 30882 of the svc of the previously installed ingress-controller to other ports, otherwise there will be conflicts.
kubectl edit svc istio-ingressgateway -n istio-system
-> 文件内容改动如下：...- name: http2 #只需要修改http2即可nodePort: 30882port: 80protocol: TCP...type: NodePort #改成NodePort,下面的部分删除
status:loadBalancer:ingress:- hostname: localhostThen we look at kubectl get po -n istio-system to ensure that all three pods are running. Then we need to install some dashboards to observe istio through these, enter the installed istio root directory, find \samples\addons, and execute kubectl apply -f . You can install Kiali and other plugins. Kiali is the official dashboard of istio. After the installation is complete, you can start kiali through istioctl dashboard kiali. Of course, you can also modify kubectl edit svc kiali -n istio -system Set nodeport to permanently expose the kiali panel, so I won't go into details here. It can be seen that the current state of all pods in our dapreshop is missing sidecar, indicating that the sidecar has not been injected yet.
Next, let's inject istio's sidecar into our e-commerce demo. It's very simple, just execute kubectl label ns dapreshop istio-injection=enabled to label the namespace of our dapreshop for automatic injection, and then we can run kubectl delete po --all -n dapreshop to restart all pods and all the pods under the space will be Automatic injection of sidecar. If you don't need some pods to inject sidecar, just disable it:
template:
metadata:labels: app: accountserviceversion: v1annotations:sidecar.istio.io/inject: "false" If everything goes well, after waiting for a while, we can see that each pod will be correctly injected into istio's sidcar, and the working principle of istio sidecar is different from that of dapr. It is forced to intercept by modifying the ip rule to forward traffic, traffic model as follows:
Then we need to write the ingress traffic, let our traffic take over through the istio gateway, the yaml is as follows:
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:name: dapreshop-gatewaynamespace: dapreshop
spec:selector:istio: ingressgatewayservers:- port:number: 80name: httpprotocol: HTTPhosts:- "*"
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:name: apigatewaynamespace: dapreshop
spec:hosts:- "api.dapreshop.com"gateways:- dapreshop-gatewayhttp:- route:- destination:port:number: 80host: apigateway
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:name: mobiledapreshopnamespace: dapreshop
spec:hosts:- "m.dapreshop.com"gateways:- dapreshop-gatewayhttp:- match:- uri:prefix: /route:- destination:port:number: 80host: mobilefrontend
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:name: admindapreshopnamespace: dapreshop
spec:hosts:- "admin.dapreshop.com"gateways:- dapreshop-gatewayhttp:- match:- uri:prefix: /route:- destination:port:number: 80host: adminfrontend
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:name: oauthdapreshopnamespace: dapreshop
spec:hosts:- "oauth.dapreshop.com"gateways:- dapreshop-gatewayhttp:- match:- uri:prefix: /route:- destination:port:number: 80host: oauthservice-daprAfter apply, we can use kugectl get gw,vs -n dapreshop. You can see that the relevant resources have been injected successfully, and then you can visit our http://admin.dapreshop.com:30882/, and you can see that the page has been opened correctly, indicating that the traffic has been correctly forwarded through istio. Then we operate the platform, and then log in to kiali to see the correct link call
That’s all for today’s sharing. This is just a simple demo-level demonstration. Others need to be explored by yourself. Welcome to fork+star as usual~
istio vs dapr comparison point
According to the latest annual survey [3] of the CNCF [2], it is clear that a lot of people are showing great interest in using service meshes in their projects, and many are already using them in production. Nearly 69% are evaluating Istio and 64% are looking at Linkerd. Linkerd was the first service mesh on the market, but Istio's service mesh is more popular. Both programs are cutting edge and highly competitive, so which one to choose is a tough choice. In this blog post, we'll learn more about the architecture of Istio and Linkerd, their components, and compare their features to help you make an informed decision.
Introduction to Service Mesh
Over the past few years, microservice architecture has become a popular style for designing software applications. In this architecture, we decompose the application into independently deployable services. These services are typically lightweight, multilingual, and often managed by various functional teams. This architectural style works well until the number of these services becomes large and unmanageable. Suddenly, they're not simple anymore. This creates challenges in managing aspects such as security, network traffic control, and observability. A service mesh can help address these challenges.
The term service mesh is used to describe the network of microservices that make up such applications and the interactions between them. As services increase in number and complexity, scaling and managing them becomes increasingly difficult. Services typically provide service discovery, load balancing, failure recovery, metrics, and monitoring. Service meshes also typically have more complex operational requirements such as A/B testing, canary rollouts, throttling, access control, and end-to-end authentication. A service mesh provides an easy way to create a network of services for load balancing, service-to-service authentication, monitoring, and more, with little or no changes to the service code.
Let's look at the architecture of Istio and Linkerd. Note that both projects are rapidly evolving, and this article is based on Istio version 1.6 and Linkerd version 2.7.
To that
Istio is an open source platform that provides a complete solution as a service mesh, providing a unified approach to secure, connect and monitor microservices. It's backed by industry leaders like IBM, Google, and Lyft. Istio is one of the most popular and complete solutions with advanced features suitable for enterprises of all sizes. It is a first-class citizen of Kubernetes and is designed to be a modular, platform-independent system. For a quick demo of Istio, please refer to our previous article [4].
architecture
Istio architecture
Istio architecture source: istio.io[5]
components
Envoy[6] is a high-performance proxy written in C++ by Lyft that coordinates all inbound and outbound traffic for all services in the service mesh. It is deployed with the service as a sidecar proxy.
Envoy provides the following features:
• Dynamic Service Discovery • Load Balancing • TLS Termination • HTTP/2 and gRPC Proxy • Circuit Breaker • Health Check • Staged Rollout with Percentage Distribution of Traffic • Fault Injection • Rich Metrics
In newer Istio versions, the sidecar proxy has taken on additional responsibility for Mixer's work. In earlier versions of Istio (<1.6), Mixer was used to collect telemetry from the mesh.
Pilot provides service discovery, traffic management capabilities, and resiliency for sidecar proxies. It translates high-level routing rules that control traffic behavior into Envoy-specific configurations.
Citadel enables strong service-to-service and end-user authentication with built-in identity and credential management. It enables authorization and zero-trust security in the grid.
Galley is the Istio configuration validation, extraction, processing and distribution component.
Core functions
• Traffic Management —Management of intelligent traffic routing rules, traffic control, and service-level attributes such as circuit breakers, timeouts, and retries. It allows us to easily set up A/B tests, canary rollouts, and staged rollouts that distribute traffic proportionally. • Security —Provides secure communication channels between services and manages authentication, authorization, and encryption at scale. • Observability —Powerful link tracking, monitoring, and logging capabilities provide deep insights and visibility. It helps to detect and solve problems effectively.
Istio also has an add-on infrastructure service that enables monitoring of microservices. Istio integrates with applications like Prometheus, Grafana, Jaeger, and the service mesh dashboard Kiali.
Left
Linkerd is an open source ultra-lightweight service mesh designed by Buoyant for Kubernetes. Completely rewritten in Rust to make it ultra-lightweight and performant, it provides runtime debugging, observability, reliability, and security without requiring code changes in distributed applications.
architecture
Linkerd has three components — UI, data plane, and control plane. It works by installing a lightweight transparent proxy next to each service instance.
control plane
Linkerd's control plane is a set of services that provide the core functionality of a service mesh. It aggregates telemetry data, provides a user-facing API, and provides control data to data plane proxies. Following are the components of the control plane:
• Controller —It contains a public API container that provides APIs for the CLI and Dashboard. • Destination – Every proxy in the data plane will visit this component to find out where to send the request. It has service description information for each route metrics, retries and timeouts. • Identity — It provides a certificate authority that accepts a CSR from the proxy and returns a certificate signed with the correct identity. It provides mTLS functionality. • Proxy Injector — It is an admission controller that looks for annotations ( linkerd.io/inject: enabled) and changes the pod spec to add initContainer and include the sidecar of the proxy itself. • Service Profile Validator – This is also an admission controller that validates new service descriptions before saving them [7]. • Tap – It receives commands to monitor requests and responses in real time from the CLI or dashboard to provide observability within the application. • Web —Provides a web dashboard. • Grafana — Linkerd provides out-of-the-box dashboards through Grafana. • Prometheus - /metrics Collects and stores all Linkerd metrics through a breakpoint proxied on port 4191.
data plane
The Linkerd data plane consists of lightweight proxies that are deployed as sidecar containers alongside each instance of the service container. A proxy is injected during the initialization phase of a Pod with a specific annotation (see Proxy Injector above). The proxy has been very lightweight and performant since 2.x, when it was completely rewritten in Rust. These proxies intercept communication to and from each Pod to provide instrumentation and encryption (TLS) without requiring application code changes.
Proxy function:
• Transparent, zero-configuration proxy for HTTP, HTTP/2, and arbitrary TCP protocols. • Automatically export Prometheus metrics for HTTP and TCP traffic. • Transparent zero-configuration WebSocket proxy. • Automatic, latency-aware Layer 7 load balancing. • Automatic Layer 4 load balancing of non-HTTP traffic. • On-demand diagnostics of tap APIs.
Compare
in conclusion
Service meshes are becoming an integral part of cloud-native solutions and microservices architectures. It does all the heavy lifting such as traffic management, resiliency, and observability, letting developers focus on business logic. Both Istio and Linkerd are mature and used in production by several enterprises. Planning and analysis of requirements is critical to choosing which service mesh to use. Please invest enough time in the analysis phase, as migrating from one to the other later in the game is complicated.
When choosing a technology as complex and critical as a service mesh, it is important to consider not only the technology, but also the context in which it is used. Without context, it's hard to say whether A is better than B, since the answer really is "it depends". I like the simplicity of Linkerd, both getting started and managing the service mesh later. Additionally, Linkerd has been enhanced over the years with users from enterprise companies.
There may be some features in one that look good, but make sure to check out the other if it's planned for release in the near future, and based on not only theoretical evaluation, but also trying them out in a proof-of-concept sandbox, do make wise decisions. This proof of concept should focus on ease of use, feature fit, and more importantly, operation of the technology. Bringing in technology is relatively easy, the hardest part is running and managing it through its lifecycle.