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

This article mainly talks about "what is the design goal of Istio". Interested friends may wish to have a look. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn "what is the design goal of Istio"?

Summary

Istio: an open platform for connecting, managing, and protecting micro services. Istio provides a simple way to create a network for deployed services through load balancing, service-to-service authentication, monitoring, etc., without making any changes to the service code. You can deploy a special sidecar agent throughout the environment to intercept all network traffic between microservices, and use the control panel (control plane) function of Istio to configure and manage the Istio function.

Istio currently supports the deployment of services on Kubernetes, as well as services registered through Consul or Eureka, and services running on a single VM.

.

Why use Istio

Istio addresses many of the challenges faced by developers and operators in the transition from a single application to a distributed microservice architecture. The term service mesh (service grid) is often used to describe the micro-service networks that make up these applications and the interactions between them. As the size and complexity of the service grid increases, it may become difficult to understand and manage. Istio provides service discovery, load balancing, failure recovery, measurement and monitoring, as well as more complex operational requirements, such as A / B testing, Canary version, traffic restrictions, access control, and end-to-end authentication.

Istio provides a complete solution to meet the needs of creating micro-service applications by providing behavior analysis and operational control over the entire service grid. It unifies many key functions across the service network:

Traffic management. Control the traffic between services and the flow of API calls to make calls more reliable and make the network more robust in the face of adverse conditions.

Service identification and security. Provide authenticated services in the grid and provide the ability to protect service traffic because traffic flows through varying degrees of trustworthiness networks.

Policy enforcement. The organizational policy is applied to the interaction between services to ensure that the access policy is enforced and resources are fairly distributed among consumers. Policy changes are made by configuring the grid, not by changing the application code.

Telemetry . Understand the dependencies between services and the nature and traffic of data transfer between them to provide the ability to diagnose problems quickly.

In addition to the above features, the Istio extensible design can meet different deployment needs:

Platform support. Istio is designed to run in a variety of environments, including cross-cloud, On-premises deployment, Kubernetes,Mesos, etc. We initially focused on Kubernetes, but are working hard to support other environments.

Integration and customization. Policy enforcement components can be extended and customized to integrate with existing solutions such as ACL, logging, monitoring, quotas, auditing, and so on.

These features greatly reduce the coupling between application code, underlying platforms, and policies. This reduction in coupling not only makes services easier to implement, but also makes it easier for operators to deploy applications between different environments or move between new strategy scenarios. As a result, the application is inherently more portable.

Architecture

Istio service grid is logically divided into data panel and control panel.

The data panel consists of a series of intelligent agents (Envoy) deployed as sidecars (side cars) to mediate and control all network traffic between microservices, as well as a common policy and monitoring log hub (mixer).

The dashboard is responsible for managing and configuring agents to route traffic, and configuring Mixers to enforce policies and collect monitoring log data.

Envoy

Istio is an extended version of the Envoy agent, a high-performance proxy developed in C + + to mediate all inbound and outbound traffic for all services in the service grid. Istio leverages many built-in features of Envoy, such as dynamic service discovery, load balancing, TLS termination, HTTP/2 and gRPC agents, circuit breakers, health checks, phased release based on percentage of traffic, fault injection, and rich metrics.

Envoy is deployed in the same Kubernetes Pod related services in the form of sidecar. This enables Istio to extract a large number of signals about traffic behavior as attributes so that it can be used in Mixer to make policy decisions and send them to the monitoring system to provide information about the behavior of the entire grid. The sidecar proxy model also allows Istio functionality to be added to deployed services without having to rebuild or rewrite code. You can read more about why we chose this approach in our design goals.

Mixer

Mixer is a platform-independent component that enforces access control and usage policies throughout the service grid and collects telemetry data from Envoy agents and other services. The agent extracts the request-level attributes and sends them to Mixer for evaluation. More information about this attribute extraction and policy evaluation can be found in the Mixer configuration. Mixer contains a flexible plug-in model that can interact with a variety of host environments and infrastructure backends, abstracting Envoy agents and Istio-managed services from these details.

Pilot

Pilot provides service discovery for Envoy sidecars and traffic management capabilities for intelligent routing (such as A / B testing, canary deployment, etc.) and resiliency (timeout, retry, circuit breaker, etc.). It translates advanced routing rules that control traffic behavior into specific Envoy configurations and propagates them to sidecar at run time. Pilot abstracts and synthesizes platform-specific service discovery mechanisms into a standard format that any sidecar that conforms to the Envoy data plane API can use. This loose coupling enables Istio to run in a variety of environments (for example, Kubernetes,Consul / Nomad), while the interface operation for traffic management is the same.

Citadel

Citadel provides powerful services to services and end-user authentication, built-in identity and credential management. It can be used to upgrade unencrypted traffic in the service grid and provide operators with the ability to enforce policies based on service identification rather than network control. Starting with version 0.5, Istio supports role-based access control to control who can access your services.

Design goal

The architecture of Istio consists of several key design goals that are critical to enabling the system to handle large-scale and high-performance services.

Maximize transparency. With Istio, operators or developers can reduce their workload as much as possible in order to get more real value from the system. To do this, Istio can automatically inject itself into all network paths between services. Istio uses sidecar agents to capture traffic and, where possible, automatically program the networking layer to route traffic through these proxies without making any changes to the deployed application code. In Kubernetes, agents are injected into pod to capture traffic by programming iptables rules. Once the sidecar agent is injected and the traffic routing rules are programmed, Istio can mediate all traffic. This principle also applies to performance. When applying Istio to deployment, operators should see that Istio requires very few resources to provide these capabilities. Components and API must be designed with performance and scalability in mind.

Gradualness. As operators and developers rely more and more on the functionality provided by Istio, the system must grow according to their needs. While we hope to continue to add new features, we expect that the biggest need is to extend the policy system, integrate with other policy and control sources, and propagate signals about mesh behavior to other systems for analysis. The policy runtime supports standard extension mechanisms for inserting other services. In addition, it allows its vocabulary to be expanded to enforce policies based on new signals generated by the grid.

Portability. The ecosystem that Istio will use is different in many ways. Istio must run in any cloud or internal environment with minimal effort. The effort of porting Istio-based services to the new environment is very small, and you should be able to deploy a service to multiple environments using Istio (for example, redundancy on multiple clouds).

Policy consistency. Applying policies to API calls between services can provide a great deal of control over grid behavior, but it is equally important to apply policies to resources that are not necessarily represented at the API level. For example, the number of CPU consumed by applying quotas to ML training tasks is more useful than applying quotas to calls that initiate work. To this end, the policy system is maintained with its own API as an independent service, rather than being included as an agent / sidecar, thus allowing the service to be directly integrated with it as needed.

At this point, I believe you have a deeper understanding of "what is the design goal of Istio". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

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.