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

This article focuses on "what are the core functions of Istio". Interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn what are the core functions of Istio.

What is Istio?

The use of cloud platforms can provide rich benefits for organizations. However, it is undeniable that adopting the cloud can put pressure on the DevOps team. Developers must use micro-services to meet the portability of applications, while operators manage extremely large hybrid and multi-cloud deployments. Istio allows you to connect, protect, control, and observe services.

At a high level, Istio helps to reduce the complexity of these deployments and reduce the pressure on the development team. It is a completely open source service grid that can be transparently layered into existing distributed applications. It is also a platform, including API that allows it to be integrated into any logging platform, telemetry, or policy system. Istio's diverse feature set enables you to run the distributed microservice architecture successfully and efficiently and provides a unified way to protect, connect, and monitor microservices.

What is a service grid?

In the transition from a single application to a distributed micro-service architecture, developers and operators face many challenges that can be solved by using Istio.

The term service grid (Service Mesh) is commonly used to describe the micro-service networks that make up these applications and the interactions between applications. With the growth of scale and complexity, service grid becomes more and more difficult to understand and manage. Its requirements include service discovery, load balancing, fault recovery, metrics collection and monitoring, and often more complex operation and maintenance requirements, such as Aash B testing, canary release, current limiting, access control, and end-to-end authentication.

Istio provides a complete solution to meet the diverse needs of micro-service applications by providing behavioral insight and operational control for the entire service grid.

Why use Istio?

Automatic load balancing of HTTP, gRPC, WebSocket, and TCP traffic.

Through rich routing rules, retry, failover and fault injection, traffic behavior can be finely controlled.

Pluggable policy layer and configuration API to support access control, rate limiting, and quotas.

Automatic metrics, logging and tracking of all traffic in and out of the cluster entrances and exits.

Secure communication between services in a cluster is achieved through powerful identity-based authentication and authorization.

Istio is designed to be scalable to meet a variety of deployment needs.

Core function

Istio provides many key functions uniformly in the service network:

Traffic management

With simple rule configuration and traffic routing, you can control traffic and API calls between services. Istio simplifies the configuration of service-level attributes such as circuit breakers, timeouts, and retries, and makes it easy to set up important tasks such as A _ hand B testing, canary deployment, and phased deployment of percentage-based traffic segmentation.

Safety

Istio's security features allow developers to focus on application-level security. Istio provides the underlying secure communication channel and manages the authentication, authorization and encryption of service communications on a large scale. With Istio, service communication is secure by default, allowing you to enforce policies consistently across multiple protocols and runtimes-all of which require little or no application change.

Although Istio is platform-independent, it has greater advantages when combined with Kubernetes (or infrastructure) network policies, including the ability to secure communication between pod or services at the network and application layers.

Observability

Istio's powerful tracking, monitoring, and logging give you an in-depth understanding of service grid deployment. Through Istio's monitoring capabilities, you can truly understand how service performance affects upstream and downstream functions, while its custom dashboard provides visibility into the performance of all services and allows you to understand how that performance affects your other processes.

The Mixer component of Istio is responsible for policy control and telemetry collection. It provides back-end abstraction and mediation, isolates the rest of the Istio from the implementation details of each infrastructure back-end, and provides operations and maintenance with fine-grained control over all interactions between the grid and the infrastructure back-end.

All of these features allow you to set up, monitor, and implement SLO on services more effectively. Of course, the most important thing is that you can detect and fix problems quickly and effectively.

Platform support

Istio is platform independent and is designed to run in a variety of environments, including cross-cloud, on-premises, Kubernetes, Mesos, and so on. You can deploy Istio on Kubernetes or Nomad with Consul. Istio currently supports:

Services deployed on Kubernetes

Services registered with Consul

Services deployed on virtual machines

Integration and customization

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

Architecture

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

The data plane consists of a set of intelligent agents (Envoy) deployed as sidecar. These agents can regulate and control all network communication between microservices and Mixer.

The control plane is responsible for managing and configuring agents to route traffic. In addition, the control plane configures Mixer to implement policies and collect telemetry data.

The following figure shows the different components that make up each panel:

Istio architecture

Envoy

Istio uses an extended version of the Envoy agent, Envoy, a high-performance proxy developed with C++ to mediate all inbound and outbound traffic for all services in the service grid. Many of the built-in features of Envoy are carried forward by istio, such as:

Dynamic service discovery

Load balancing

TLS termination

HTTP/2 & gRPC Agent

Fuse

Health check, grayscale release based on percentage traffic split

Fault injection

Rich metrics

Envoy is deployed as sidecar, in the same Kubernetes pod as the corresponding service. This allows Istio to extract a large number of signals about traffic behavior as attributes, which in turn can be used in Mixer to execute policy decisions and send them to the monitoring system to provide information about the behavior of the entire grid.

The Sidecar proxy model can also add the functionality of Istio to an existing deployment without having to rebuild or rewrite the code. You can read more about why we choose this approach in our design goals.

Mixer

Mixer is a platform-independent component that enforces access control and usage policies on 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. For more information about attribute extraction and policy evaluation, see Mixer configuration.

Mixer includes a flexible plug-in model that enables it to access a variety of host environments and infrastructure backends, abstracting Envoy proxies and Istio-managed services from these details.

Pilot

Pilot provides service discovery capabilities for Envoy sidecar and traffic management capabilities for intelligent routing (such as A hand B testing, canary deployment, etc.) and resiliency (timeouts, retries, fuses, etc.). It translates advanced routing rules that control traffic behavior into Envoy-specific 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 multiple environments (for example, Kubernetes, Consul, Nomad) while maintaining the same interface for traffic management.

Citadel

Citadel provides powerful inter-service and end-user authentication through 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 service.

Design goal

There are several key goals in the architectural design of Istio, which are critical to enabling the system to cope with large-scale traffic and high-performance service processing.

Maximize transparency: if Istio is to be adopted, operators and developers should be able to benefit from it at a small cost. To do this, Istio automatically injects itself into all network paths between services. Istio uses sidecar proxies to capture traffic and automatically programs the network layer wherever possible 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 writing iptables rules. After injecting the sidecar agent into the pod and modifying the routing rules, Istio can mediate all traffic. This principle also applies to performance. When Istio is applied to deployment, operators can find that the additional resource overhead to provide these capabilities is small. All components and API must be designed with performance and scale in mind.

Increment: as operators and developers become more and more dependent on the functionality provided by Istio, the system is bound to grow with their requirements. The policy runtime supports standard extension mechanisms for insertion into other services. In addition, it allows you to expand the vocabulary to allow policy enforcement based on new signals generated by the grid.

Portability: ecosystems that use Istio will differ in many dimensions. Istio must be able to run in any cloud or provisioned environment with minimal cost. Porting Istio-based services to a new environment should be easy, and using Istio to deploy a service to multiple environments at the same time (for example, redundant deployment on multiple clouds).

Policy consistency: in API calls between services, the application of policies makes it possible to fully control the behavior between grids, but for resources that do not need to be expressed at the API level, it is also important to apply policies to resources. For example, applying a quota to the number of CPU consumed by a ML training task is more useful than applying a quota to a call that initiates the work. Therefore, the policy system is maintained as a unique service, with its own API rather than placed in an agent / sidecar, which allows the service to integrate directly with it as needed.

At this point, I believe you have a deeper understanding of "what are the core functions 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.