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

What is the concept of each component of istio? in view of this question, this article introduces in detail the corresponding analysis and solutions, hoping to help more partners who want to solve this problem to find a more simple and feasible way.

This document introduces Istio: an open platform for connecting, managing, and protecting microservices. Istio provides an easy way to create a deployed service network through load balancing, service-to-service authentication, monitoring, and so on, without changing the service code. You can add Istio support for services by deploying a special side car agent throughout the environment, which intercepts all network traffic between micro services and uses the control plane features of Istio for configuration and management.

Istio currently supports service deployment on Kubernetes, as well as services registered with Consul or Eureka, and services running on individual VM.

For more conceptual information about Istio components, see our other concept guides.

Why use Istio?

With the transition from monolithic applications to a distributed microservice architecture, Istio addresses many of the challenges faced by developers and operators. The term service grid is often used to describe the micro-service networks that make up such applications and the interactions between them. As the size and complexity of the service grid increases, it becomes more difficult to understand and manage. Its requirements can include discovery, load balancing, fault recovery, metrics and monitoring, and often more complex operational requirements such as A / B testing, gold chip release, rate limiting, access control, and end-to-end authentication.

By providing behavioral insight and operational control of the overall service grid, Istio provides a complete solution to meet the needs of micro-service applications. It provides many key functions uniformly in the service network:

traffic control. 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 identity and security. Provide authenticated services in the grid and provide the ability to protect service traffic as it flows through networks of different trustworthiness.

Policy implementation. Apply organizational policies to interactions between services, ensure that access policies are enforced, and distribute resources fairly among consumers. Policy changes are made by configuring the grid rather than by changing the application code.

Telemetry. Understand the dependencies between services and the nature and traffic of the traffic between them, and provide the ability to quickly identify problems.

In addition to these behaviors, Istio can be extended to meet different deployment needs:

Platform support. Istio is designed to run in a variety of environments, including cloud, on-premises, Kubernetes,Mesos, etc. We initially focused on Kubernetes, but will soon try to support other environments.

Integration and customization. Policy enforcement components can be extended and customized to integrate with existing ACL, logging, monitoring, quota, audit, and other solutions.

These features greatly reduce the coupling between application code, underlying platforms, and policies. This reduced coupling not only makes services easier to implement, but also makes it easier for operators to move application deployments or new policy solutions between environments. Therefore, the application itself is more portable.

Architecture

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

The data plane is deployed by a group to mediate and control all network communications between microservices, with common strategies and telemetry hubs (mixers) along the side cabinet intelligent agents (special envoys).

The control plane is responsible for managing and configuring proxy server routing traffic, and configuring mixers during policy enforcement and collection telemetry.

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

Istio architecture

Emissary

Istio uses 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 deployment based on% traffic distribution, fault injection, and rich metrics.

The Special Envoy is deployed as a side car for related services in the same Kubernetes pod. This allows Istio to extract a large number of signals about traffic behavior as attributes, which in turn can be used to implement policy decisions in Mixer and sent to the monitoring system to provide information about the behavior of the grid as a whole. The sidecar proxy model also allows you to add Istio functionality to an existing deployment without having to rearchitecture or rewrite code. You can learn 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 across service grids 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 this attribute extraction and policy evaluation, see Mixer configuration. Mixer includes a flexible plug-in model that enables it to interact with various host environments and infrastructure backends, abstracting Envoy proxies and Istio-managed services from these details.

Pilot

Pilot provides service discovery for Envoy side cars, traffic management capabilities for intelligent routing (for example, A / B testing, canary deployment, etc.), and resilience (timeouts, retries, circuit breakers, etc.). It translates advanced routing rules that control traffic behavior into Envoy-specific configurations and propagates them to sidecars at run time. Pilot abstracts the platform-specific service discovery mechanism and synthesizes it into a standard format consumed by any side cars that conform to the Envoy data plane API. This loose coupling allows Istio to run on multiple environments (for example, Kubernetes,Consul / Nomad) while maintaining the same operator interface for traffic management.

Fortress

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 enable operators 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.

Official website address: https://istio.io/docs/concepts/what-is-istio/overview/

According to the personal understanding of the official website documents:

Envoy: (it can be understood as a pod gateway) there is an envoy proxy in each pod (equivalent to a dynamic gateway for pod). Block all inbound and outbound traffic for all services in pod. Many built-in features of Envoy, such as dynamic service discovery, load balancing, TLS termination, HTTP / 2 and gRPC agents, circuit breakers, health checks, metrics reporting.

Mixer: (it can be understood as an indicator collector, which collects indicators. Docking external components to store and display indicators. Such as: Prometheus,Fluentd,Jaeger)

Collect telemetry data from Envoy agents and other services. The agent extracts the request-level attributes and sends them to Mixer for evaluation.

Demonstrates how to collect telemetry information from a grid.

Distributed tracking. How to configure an agent to send trace requests to Zipkin or Jaeger

Collect metrics and logs. This task explains how to configure Istio to collect metrics and logs.

Collect metrics for TCP services. This task explains how to configure Istio to collect metrics for TCP services.

Check Prometheus's indicators. This task explains how to use Prometheus to query Istio metrics.

Use the Grafana visualization metric. This task explains how to set up and use the Istio dashboard to monitor grid traffic.

Generate a service diagram. This task shows how to generate a service graph in an Istio grid.

Use fluent logging. This task explains how to configure Istio to log to the Fluentd daemon

Pilot:

Features:

The registry (zk,ectd) obtains relevant service information from K8s api

Configuration Center (spring cloud config,Apollo). Dynamically convert to envoy configuration by configuring api

Citadel:

Security center

In short:

Envoy: dynamic service acquisition, load balancing, routing, circuit breaker, timeout, indicator reporting.

Mixer: metrics collection, docking external components (Prometheus,Fluentd,Jaeger)

Pilot: registry, configuration center

Citadel: security Center

The answer to the question about the concept of each component of istio is shared here. I hope the above content can be of some help to you. If you still have a lot of doubts to be solved, you can follow the industry information channel for more related knowledge.

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.