Shulou(Shulou.com)06/02 Report--

This article is compiled by Huawei Cloud BU technical experts on K8S Technology Society.

Sharing about the Istio call chain.

Preface

Hello, everyone. I'm idouba from Huawei Cloud BU. I'm currently working on the production of Istio Services Grid in Huawei Cloud Container Service. The topic I share with you today is about the Istio call chain. By analyzing the architectural mechanism of Istio and how the call chain works in Istio, we often ask a question: is Istio completely non-invasive to the business code as advertised in its official documents, and can complete all the governance capabilities, including the location of the call chain, without making any changes?

With regard to this question, it can be explained in advance that the answer is a little frustrating and needs to be changed. In Isito, you don't have to use all kinds of SDK in your code to do the logic of burying points, but you must have appropriate modifications.

Why does the original non-intrusive Service Mesh technology require us developers to modify some code and what changes should be made? How exactly does the call chain work in Istio? These questions will be answered one by one in the following content.

The topic of this sharing consists of two parts: the first part serves as the background and foundation to introduce the architecture and mechanism of Istio; the second part will focus on the relevant content of the Istio call chain to answer the previous questions.

The structure and Mechanism of Isito

Service Mesh

As officially introduced, Istio is an open platform for connecting, controlling, protecting and observing services. That is, intelligent control of inter-service traffic and API calls; provision of authorization, authentication and communication encryption mechanisms to automatically protect the security of services; and use various policies to control callers' access to services; in addition, rich call chain, monitoring, logging and other means can be expanded to observe the service and performance.

Istio is another important project of Google after Kubernetes, which provides a complete solution of Service Mesh service governance. The first version 0.1 was released in May 2017, and version 0.8 was released on June 1, 2018. The first version of LTS, currently in use, was released on July 31 this year, which is advertised for production. The latest version 1.1 will be released recently in mid-2018.11 (planning was actually delayed at that time, author's note).

Istio is an implementation of Service Mesh. Learn about Service Mesh through a typical picture. As shown in the figure, the dark color is Proxy, the light color is the service, and all inflows and outflows of services are through Proxy. Service Mesh is made up of this set of lightweight agents, deployed with the application, but the application is not aware of its presence. Especially for cloud native applications, the application access topologies between services are relatively complex, and Service Mesh can be used to ensure the reliable and secure delivery of invocation requests between services. In the implementation, there is generally a unified control plane, there is a unified management of these agents, and all agents are connected to a control plane. The life cycle management of agents and the configuration of unified governance rules.

Here is a general description of the characteristics of Service Mesh. Later, combined with the architecture and mechanism of Isito, we can take a look at the corresponding implementation in Istio.

You can see that the core feature of Service Mesh is the implementation of governance logic in Proxy so that the application is not aware of it. In fact, this form has also gone through a process of evolution:

The earliest governance logic was directly designed and implemented by business code developers to manage access between services. In fact, there is no distinction between governance and business in the code. Governance itself is a part of the business. The obvious drawback of this form is the coupling of business code and governance, while there is a lot of duplication of common governance logic.

It's easy to think of encapsulating a common library, called SDK, that uses a specific SDK to develop a business, and all governance capabilities are built in. Spring Cloud and Netflix are such tools, which are widely used. In addition to governance capabilities, SDK itself is a development framework. It is very easy to develop new projects based on a unified language and style development framework. But this kind of morphological language is related, and there are more SDK in the current version of Java. In addition, there is a certain learning cost for developers, you must be familiar with this SDK in order to develop based on him. The most important thing is that it is not easy to drive mature systems that are already in use to rewrite using SDK. For example, our customers have systems developed in C, which run stably and are basically impossible to rewrite. The governance of such services requires a way of governance outside the service.

So consider whether you can continue to encapsulate and bring governance capabilities outside the process as an independent process. That is, the Sidecar way, that is, the widely concerned Service Mesh. It is really possible to invade the business code and process 0, which does not need to be modified for the original system, but directly uses Sidecar for governance.

The evolution of the above form is represented by a piece of pseudo code:

You can see that as the encapsulation gets stronger and stronger, from the common library level to the process level. The intrusion into the business is less and less, the common library of SDK is decoupled from the business code, and the Sidecar mode is decoupled directly from the business process. The corresponding governance position is getting lower and lower, that is, the effective position is more basic. In particular, the Service Mesh mode accesses governance through Proxy, so the Service Mesh approach has been called an application infrastructure layer, just like the TCP/IP protocol stack. TCP/IP is responsible for the reliable transmission of byte flow between network nodes, while the application infrastructure ensures that requests between services are delivered securely, reliably and controllably. This also corresponds to the previous positioning of Istio as an implementation of Service Mesh.

Key capabilities of Istio

Istio officially introduces its key capabilities as shown above, and I divide it into two parts: one is the functionality, and the other is the extensibility provided.

Features include traffic management, policy enforcement, security and observability. It also deals with the four major functions of the home page: connection, protection, control and observation.

Traffic management: is the most commonly used function in Istio. You can control traffic and API calls between services by configuring rules and access routing. Thus, the service governance functions such as load balancing, circuit breaker, fault injection, retry and redirection can be realized, and the grayscale publishing process can be realized by configuring traffic rules to split the traffic into different versions.

Policy enforcement: the ability of Istio to support access control, rate limit, and quota management. These capabilities are implemented through the back-end of policy control that can be dynamically inserted.

Security: Istio provides the underlying secure channel and manages the authentication and authorization of service communications, so that the development task only needs to pay attention to the security related in the business code.

Observability: compared with other systems and platforms, one of the obvious features of Istio is that the monitoring data of service operation can be obtained and output dynamically, providing a strong ability to call chain, monitor and call log collection and output. With visualization tools, operators can easily see the operation of the system, and find the problem and then solve the problem. The theme call chain we share this time is also a core competence of Isito observability.

The following analysis shows that the above four features correspond to the three important components of Istio from a management point of view.

Expansibility: mainly refers to the Istio from the system design to the running platform, interactive related systems are decoupled as much as possible, scalable. The features listed here:

Platform support: Istio can be deployed in various environments, supporting services deployed on Kubernetes, Consul, etc., and Service registered on Eureka is also supported in the previous version. The support for Eureka in the new version has been removed.

Integration and customization: the Istio can dynamically interface with various objective backends such as access control, quota management, and log monitoring. Support users to easily integrate their own backend according to the template according to their needs.

In fact, these two extensibility capabilities also correspond to the two core components of Istio, Pilot and Mixer, which we will look at together when we look at the Isito architecture.

Overall architecture of Istio

The above is the overall architecture of Isito. The upper part is the data plane, and the lower part is the control plane.

Envoy on the data side is a lightweight proxy written by C++. You can see that all traffic flowing into and out of the service is forwarded and processed by Proxy. All the governance logic listed in the previous Istio is executed on the Envoy, and all kinds of governance can be carried out only when the traffic between service accesses is blocked. In addition, you can see that Sidecar is connected to a unified control plane.

Istio actually refers to several service components of the control plane:

Pilot:Pilot does two things: one is configuration, that is, the intelligent routing and traffic management functions introduced in the previous features are configured through Pilot and sent to Sidecar for execution; the other is service discovery, which can be docked with different service discovery platforms to maintain the relationship between service name and instance address and dynamically provide it to Sidecar for use in service requests. The detailed functions and mechanisms of Pilot are described in the following components.

Mixer:Mixer is a special and even controversial component of Istio. The two major features of telemetry and policy enforcement described in the previous Isito core functions are provided by Mixer. The integration and customization that Istio officially emphasizes are also provided by Mixer. That is, the back-end of strategy execution and telemetry can be dynamically configured and developed to achieve the corresponding functions. The detailed functions and mechanisms of Mixer are described in the following components.

Citadel: mainly corresponds to the security part of the core functions of Istio. Cooperate with Pilot and Mixer to manage keys and certificates, manage authorization and audit, ensure secure communication between clients and servers, provide authentication between services through built-in identities and credentials, and then implement policies based on service representation.

Isito main component Pilot

As introduced in Istio architecture, Pilot implements the functions of service discovery and configuration management.

As a service discovery, Pilot defines an abstract service model, including service, service instance, version and so on. And only the interface of service discovery is defined, which does not realize the function of service discovery, but integrates a variety of different service discovery in an extensible way through Adapter mechanism, and is transformed into a general abstract model of Istio. For example, in Kubernetes, the Kubernetes adapter in Pilot gets the corresponding resource information in Kubernetes through the Kube-APIServer server. For a service registry such as Eureka, it is a cluster that uses an Eureka HTTP Client to access Eureka's name service to get a list of service instances. Either way is eventually converted to Pilot's standard service discovery definition, which is then provided to Sidecar through a standard interface.

Configuration management defines and maintains various traffic rules to achieve load balancing, circuit breaker, fault injection, traffic splitting and other functions. And convert it to the standard format in Envoy and push it to Envoy, thus realizing the governance function. Users do not need to modify the code interface to complete all these functions. The detailed configuration method can be defined by the rules in Istio Traffic Routing. Focus on: VirtualService, DestinationRule, Gateway and other rule definitions. For example, you can use traffic rules to configure various grayscale publishing, or you can test fault scenarios by injecting a fault; you can configure circuit breakers for fault recovery; and you can redirect, rewrite and retry HTTP requests according to our needs.

Istio main component Mixer

Mixer is a unique component of Isito. Mainly do two functions Check and Report, corresponding to the two major features of Istio official publicity, policy enforcement and telemetry functions. Logically, it is understood that each request between services will be processed through the proxy connection Mixer, and the Mixer will dispatch the request to the corresponding backend for processing. Enhance the capabilities of Mixer by extending different backends. For example, access control and quota control can be done, and different monitoring backends can also be connected to collect monitoring data, so as to provide the observability of grid operation.

Mixer implements the docking of different backends using a common plug-in model, which avoids the need for proxy to dock different backends in order to accomplish different functions. Each plug-in is called Adapter. For each request, Sidecar collects relevant information from each request, such as request path, time, source IP, destination service, tracing header, log, etc., and asks these attributes to be reported to Mixer. The connection between the Mixer and the back-end service is through an adapter, and the Mixer sends the content reported by the Sidecar to the back-end service through the adapter. You can dynamically switch background services without stopping the application service.

In addition to being able to access different backends through the adapter mechanism, mixer also supports defining the collected metric and how to handle the metric as needed. As shown in the example, you can customize monitoring metrics.

We will see later that the data of the call chain in Istio can also be collected through Mixer.

Natural combination of Istio and Kubernetes

Although Isito emphasizes that the important point of its extensibility is that it can adapt to a variety of different platforms, in practice, even if you look at the current code and design of Istio, you can find that all its important capabilities are based on Kubernetes. Istio is so closely integrated with Kubernetes that it is even described as being developed by a team. That is, Istio is based on Kubernetes, the completion of Kubernetes capabilities.

From the perspective of functional scenarios, Kubernetes provides deployment, upgrade and limited running traffic management capabilities; use the mechanism of Service to register, discover and forward services, and have certain forwarding and load balancing capabilities through Kubeproxy. But upward, such as circuit breaker, current limit demotion, call chain and other governance capabilities are not available. The previous functional introduction can find that Istio is a good complement to this part of Kubernetes's ability in service governance. That is, Kubernetes provides the ability to run basic services, while Istio provides the ability to govern Kubernetes services based on its ability to provide services.

In addition to complementary functions, Istio is also built on Kubernetes from a morphological point of view. Including: Sicecar runs in Kubernetes Pod, deployed as a Proxy and business container, and the deployment process is transparent to users. Mesh requires that the operation of business programs is not aware of the existence of Sidecar, the design of pod based on Kubernetes is more thorough and transparent to users, and users are not even aware of the process of deploying Sidecar through the automatic injection of Isito, which is no different from deploying a general Deployment. Imagine that it would not be so convenient to deploy an Agent on VM.

In addition, Istio's service discovery is also perfect to build a domain name access mechanism based on Kubernetes. The service in Isito is the service of Kubernetes, which avoids the confusion and confusion of two sets of name services when running on Kubernetes using a separate micro-service framework. In mechanism, Pilot listens for events by registering a controller in kubernetes, thus obtains the relationship between Service and Kubernetes's Endpoint and Pod, and transforms these mapping relations into a unified abstract model of Istio and sends them to Envoy for forwarding.

Istio all the routing rules and control policies that we are familiar with are expressed through Kubernetes CRD and do not require a separate APIserver and back-end configuration management. So Istio APIServer is the KubeAPIServer of Kubernetes, and the data is of course stored in the ETCD of the corresponding Kubernetes.

Even Istio's command-line tool Istioctl is a Kubectl-style feature that provides command-line-based configuration.

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.