Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

Example Analysis of Istio in kubernetes

2025-01-16 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Servers >

Share

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

This article mainly introduces the example analysis of Istio in kubernetes, which is very detailed and has certain reference value. Friends who are interested must finish it!

One: brief introduction

With the popularity of micro-service architecture, more and more applications have been split into micro-service architecture. One of the difficulties of micro-service architecture is how to make stable communication between services and services.

After the deployment of micro-services, how to do load balancing, fault tolerance, service monitoring, log tracking and circuit breakers and other functions need to be carefully considered.

In order to get the business team back to basics and focus all its efforts on business code rather than writing a large number of non-functional requirements with micro-service components, Istio came into being.

Istio is an open source Service Mesh component contributed by Google, IBM, Lyft and other companies. Its goal is to make business development no longer focus on how to invoke, manage, monitor and other non-functional requirements between micro-services, but let Istio deal with these problems. Istio and Kubernetes have natural support.

Istio can easily solve the problems of blue-green release and canary release.

Istio can do this:

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

two。 Fine-grained control of traffic behavior through rich routing rules, retry, failover, and fault injection.

3. Pluggable policy layer and configuration API that support access control, rate limit, and quotas.

4. Automatic metrics, logs, and tracking of all traffic within the cluster, including cluster ingress and egress.

5. The authentication between services is realized through strong identity assertions between services in the cluster.

By deploying a special sidecar agent (secondary container) throughout the environment, you can add Istio support to the service. After the sidecar agent is installed, all network communication between (micro) services passes through this agent. In addition, all network communications are configured and managed using the control plane function of Istio.

Second, main functions

1. Traffic Management (Pilot). Control the flow between services and the flow of API calls, making calls more flexible and reliable, and making the network more robust in bad situations.

two。 Observability. By integrating services such as zipkin, you can quickly understand the dependencies between services, as well as the nature and flow of traffic between them, thus providing the ability to quickly identify problems.

3. Policy enforcement (mixer). Apply organizational policies to the interaction between services to ensure that access policies are implemented and resources are well allocated among consumers. Policy changes are made by configuring the grid rather than modifying the application code.

4. Service identity and Security (Istio-auth). Provide services in the grid with verifiable identity and the ability to protect service traffic so that it can flow over networks with different trustworthiness.

In addition, Istio is designed for scalability to meet different deployment needs:

1. Platform support. Istio is designed to run in a variety of environments, including cross-cloud, provisioned environments, Kubernetes, Mesos, and so on. Initially focus on Kubernetes, but will soon support other environments.

two。 Integration and customization. Policy enforcement components can be extended and customized to integrate with existing ACL, logging, monitoring, quotas, auditing, and other solutions.

Third: overall structure

Divided into two parts: control plane and data plane:

Control plane: Pilot, Mixer, Istio-Auth, respectively configure traffic management, policy configuration, security communication and other rules for the services in Istio.

Data plane: Envoy on all pod, responsible for the enforcement of all rules

The main components:

1.Envoy: used to mediate all inbound and outbound traffic for all services in the service grid. Support functions such as dynamic service discovery, load balancing, fault injection, traffic management and so on. Envoy is deployed as sidecar in the Pod of the associated service.

2.Pilot:Pilot is responsible for collecting and verifying the configuration and propagating it to various Istio components.

3.Mixer: responsible for enforcing access control and usage policies on the service grid and collecting telemetry data from Envoy agents and other services.

4.Istio-Auth: provides strong inter-service authentication and end-user authentication.

Fourth: the implementation principle of Istio distributed tracking

The core of Istio service grid is Envoy, which is a high-performance open source L7 agent and communication bus. In Istio, each microservice is injected with Envoy Sidecar, and this instance handles all incoming and outgoing network traffic. Therefore, each Envoy Sidecar can monitor all inter-service API calls and record the time required for each service call and whether it completed successfully.

Whenever the microservice makes an external call, the client Envoy creates a new span. A span represents the complete interaction between a set of microservices, from the time the requester (client) sends the request to the response from the server.

During the service interaction, the client will record the initiation time of the request and the receiving time of the response, and the server-side Envoy will record the receiving time of the request and the return time of the response.

Each Envoy publishes its own span view information to a distributed tracking system. When a microservice processes a request, other microservices may need to be invoked, resulting in the creation of a causal span, forming a complete trace. This requires the application to collect and forward the following Header from the request message.

The above is all the content of the article "sample Analysis of Istio in kubernetes". Thank you for reading! Hope to share the content to help you, more related knowledge, welcome to follow the industry information channel!

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.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Servers

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report