Shulou(Shulou.com)05/31 Report--

This article introduces the relevant knowledge of "how to configure AWS App Mesh and Istio". In the operation of actual cases, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

Conceptual product positioning

According to the official introduction, both Istio and App Mesh make it clear that they are a service grid product. Istio emphasizes its capabilities in connectivity, security, control and visualization, while App Mesh emphasizes consistent visibility and flow control, as well as the benefits of being a product on a cloud platform: managed services that do not need to be maintained on their own.

To some extent, Istio is a relatively heavy solution, providing capabilities that are not limited to all aspects of traffic management, while App Mesh is a more pure service for applications running on AWS and providing flow control functions. The author believes that this is related to the imperfection of its current product form (which will be specifically mentioned later). From the communication with AWS internal developers, it can be sensed that App Mesh should be a big chess game, and it is only in the early stages.

Core terminology

Like many products in AWS, App Mesh is not original, but based on Envoy. Closed-loop ecology like AWS is bound to be improved and integrated. At the same time, in order to encapsulate it into an external service and provide an appropriate API interface, the following important technical terms are put forward in the product App Mesh, which we will introduce one by one.

Service Grid (Service mesh): the logical boundary of network traffic between services. This concept is easy to understand, which is a virtual boundary for the service circle using App mesh.

Virtual service (Virtual services): an abstraction of a real service. A real service can be a service deployed on an abstract node or indirectly pointed to through a route.

Virtual nodes (Virtual nodes): virtual nodes are logical pointers to special working groups (task group). For example, AWS's ECS service, or Kubernetes's Deployment. It can be simply understood as an abstraction of physical nodes or logical nodes.

Envoy:AWS modified Envoy (which will be merged into the official version of Envoy in the future) as a data plane in App Mesh, Sidecar proxy.

Virtual router (Virtual routers): used to handle traffic from virtual services. It can be understood as the encapsulation of a set of routing rules.

Routes: a routing rule that is used to distribute requests according to this rule.

The figure above shows the relationship between these concepts: when a user requests a virtual service, the router configured by the service directs the request to the corresponding virtual node according to the routing policy, which is essentially a node of EKS or ECS in AWS.

So can these App Mesh-coined terms find similar or even the same objects in Istio? I summarized the following table to make a comparison:

App MeshIstio Services Grid (Service mesh) Istio does not show the definition of this concept, we can think that in a cluster, the collection of services managed by Istio, the network topology they form is the service grid. Virtual service (Virtual services) Istio also has the concept of virtual service. Its main function is to define routing rules so that requests can be distributed to the corresponding service according to these rules. From this point of view, it is basically consistent with App Mesh's concept of virtual services. Virtual node (Virtual nodes) Istio has no concept of virtual node and can be thought of as similar to Deployment in Kubernetes. Virtual Router (Virtual routers) Istio also does not have the concept of virtual router. The target rule (DestinationRule) in the Routes Istio is similar to the concept of routing, setting some policies for routing. From the configuration level, the subset (subset) corresponds to the target selected in the App Mesh route, that is, the virtual node. However, the target rules of Istio are more flexible and support more routing policies.

From the above comparison, we can see that App Mesh has basically achieved the most important flow control (routing) functions, but some advanced functions such as overtime retry, circuit breaker and traffic replication have not yet been provided and need to be further improved.

Architecture

AWS App Mesh is a commercial product, and the technical details of the architecture have not been found yet, but we can still find some useful information in existing and public documents or introductions.

As can be seen from the structure diagram of the official website, the orange part of each service is the Sidecar proxy: Envoy. The middle AWS App Mesh is actually the control plane, which is used to control the interaction between services. So what is the specific function of this control plane? We can see the following words in a PPT article in AWS Summit this year:

The control plane is used to convert logical intentions into proxy configurations and distribute them.

Do friends who are familiar with Istio architecture feel deja vu? Yes, the responsibilities of this control plane are basically the same as those of Pilot. Thus it can be seen that no matter what product's control plane, it must also have these core functions.

What about support for the platform? The following figure shows that App Mesh can be run in the following infrastructure, including EKS, ECS, EC2, and so on. Of course, all these must exist in the closed-loop ecology of AWS.

Istio is relatively weak in this respect. Although Istio claims to support multiple platforms, it is still strongly dependent on Kubernetes for now. However, it is not limited to a single cloud platform, which has a big advantage.

From the perspective of observability, App Mesh still gives full play to its own ecological advantages, and can easily access CloudWatch and X-Ray to observe services. In addition, App Mesh also provides more flexibility to configure service backends (which can be virtual services or ARN) in virtual nodes, and traffic can be outbound to these configured services. At this point, it is similar to Istio's Mixer. Mixer provides great extensibility for Istio through plug-ins, and App Mesh is not at a disadvantage at this point.

Everyone is very familiar with the structure of Istio, so I won't repeat it here. Students who are interested can check it out directly on the official website.

Deployment of functions and implementations

After Istio deployment, it is attached to your Kubernetes cluster like a network, and the control plane will use the resources you set, while App Mesh is hosted and only uses Envoy proxies. The fully installed Istio needs to add about 50 CRD, while App Mesh only adds 3 CRD:meshes.appmesh.k8s.aws,virtualnodes.appmesh.k8s.aws and virtualservices.appmesh.k8s.aws. This also reflects the difference in function.

Flow control

Although the data planes of both are based on Envoy, there is still a big gap in the flow control capabilities they provide. In terms of routing settings, App Mesh provides relatively rich matching strategies, which can basically meet most of the usage scenarios. The following is a screenshot of the routing configuration in the App Mesh console. You can see that the matching of request headers is also supported in addition to the basic URI prefixes, HTTP Method and Scheme.

Istio's matching strategy is more perfect, including HTTP Authority, port matching, request parameter matching and so on. Details can be found in the virtual service settings of the official document. The following two yaml paragraphs show the differences between the two products in the configuration of virtual services.

App Mesh configuration:

ApiVersion: appmesh.k8s.aws/v1beta1kind: VirtualServicemetadata: name: my-svc-a namespace: my-namespacespec: meshName: my-mesh routes:-name: route-to-svc-a http: match: prefix: / action: weightedTargets:-virtualNodeName: my-app-a weight: 1

Istio configuration:

ApiVersion: networking.istio.io/v1alpha3kind: VirtualServicemetadata: name: ratings-routespec: hosts:-ratings.prod.svc.cluster.local http:-match:-headers: end-user: exact: jason uri: prefix: "/ ratings/v2/" ignoreUriCase: true route:-destination: host: ratings.prod.svc.cluster.local

Another big difference is that App Mesh requires you to define different versions of services separately (that is, to define different virtual services), while Istio is associated with routing configuration through a subset of subsets in the target rule DestinationRule. There is not much difference between them in essence.

In addition to the routing function, App Mesh appears to be stretched. At the time of this writing, AWS has just added retry functionality. With the help of powerful Envoy, Istio provides comprehensive flow control capabilities, such as overtime retry, fault injection, fuse, flow mirroring and so on.

Safety

In terms of security, the implementation methods of the two are quite different. By default, a user cannot directly access App Mesh resources and needs to be authorized through AWS's IAM policy. For example, the following configuration allows the user to manipulate any resource in the grid with arbitrary behavior:

{"Version": "2012-10-17", "Statement": [{"Effect": "Allow", "Action": ["appmesh:*"], "Resource": "*"}]}

In terms of authorization between virtual nodes, App Mesh is only supported by TLS access, and only the preview version (Preview) has not been officially released. The following configuration shows that a virtual node allows access only in tls mode:

{"meshName": "app1", "spec": {"listeners": [{"portMapping": {"port": 80, "protocol": "http"}, "tls": {"mode": "STRICT" "certificate": {"acm": {"certificateArn": "arn:aws:acm:us-west-2:123456789012:certificate/12345678-1234-1234-1234-123456789012"}] ServiceDiscovery: {"dns": {"hostname": "serviceBv1.mesh.local"}}, "virtualNodeName": "serviceBv1"}

The end-to-end authentication in Istio supports mTLS as well as user authentication of JWT. The following configuration shows these two authentication methods:

ApiVersion: "authentication.istio.io/v1alpha1" kind: "Policy" metadata: name: "reviews" spec: targets:-name: reviews peers:-mtls: {} origins:- jwt: issuer: "https://accounts.google.com" jwksUri:" https://www.googleapis.com/oauth3/v3/certs" trigger_rules:-excluded_paths:-exact: / health

Istio authorization is implemented through RBAC and provides access control based on namespace, service, and HTTP method levels. There is no specific display here, you can check it through the official website documents.

Observability

In general, you can observe your application in three ways: metric data, distributed tracking, and logging. Istio has relatively complete support in these three aspects. In terms of indicators, the data related to the request can be obtained through Envoy, and the indicators of service level and control plane are also provided to detect the operation of each component. Collect metrics through the built-in Prometheus and display them using Grafana. Distributed tracking also supports a variety of mainstream OpenTracing tools, such as Jaeger, Zipkin and so on. Access logs are generally collected, analyzed and displayed through ELK. In addition, Istio also has visualization tools such as Kiali, which provide you with a topological view of the entire grid and micro-service applications. Overall, the observability of Istio is very powerful, mainly because of the great flexibility brought by the plug-in features of Mixer components.

App Mesh has also done a good job in this respect. As you can see in the configuration of the virtual node in the figure below, you can configure the back-end infrastructure of the services so that traffic can be outbound to these services. At the same time, in terms of log collection, it can also be configured to local logs or other log systems.

On the other hand, AWS once again gives full play to the advantages of its closed-loop ecology, providing the integration of App Mesh with its own CloudWatch and X-Ray monitoring tools. Overall, App Mesh is not losing ground on observability.

That's all for "how to configure AWS App Mesh and Istio". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.