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

This article mainly explains "what are the basic functions of istio". Interested friends may wish to have a look. The method introduced in this paper is simple, fast and practical. Let's let Xiaobian take you to learn "what are the basic functions of istio"!

I. Background

As monolithic applications transition to distributed microservices architecture, especially with topologically complex relationships between services, service mesh is proposed to simplify the management of communication between microservices. In order to implement the microservice Mesh pattern and many ideas, Google , IBM and Lyft collaborated on the development and released the first release of Istio-Istio version 0.1 on June 8, 2017 (according to the last submission time of Github).

Second, the istio architecture

istio is divided into control plane and data plane

Data plane: consists of a group of sidecars, corresponding to the specific component envoy; by starting a lightweight network agent for each application to perform control and adjustment of network communication, sidecars and peripheral agents to achieve secure communication between clients and servers;

Control plane: Responsible for managing and configuring proxy traffic. Specifically, the mixer component delivers the policy to envoy, executes the policy, and collects data from each sidecar. Citadel is used for key and certificate management;pilot distributes authentication policies and security naming information to agents;mixer manages authorization and auditing.

III. Core Functions

Traffic Management:

The following figure shows the service discovery process for pilot.

After istio discovers and registers services based on Kubernetes adapters, traffic rules will be parsed by pilot into formats understood by envoy and sent to Sidecar to control traffic and API calls between services. Istio simplifies configuration of service level attributes such as circuit breakers, timeouts, and retries, and makes it easy to set up important tasks such as A/B testing, canary deployment, and phased deployment of percentage based traffic splitting.

Security:

Istio provides an underlying secure communication channel that allows developers to focus on application-level security and provides authentication, authorization, and encryption for large-scale management service communications. With Istio, service communication is secure by default and policies can be enforced consistently across different protocols and runtimes, all with little or no application changes.

Several components and architectures involved in security are shown below:

Citadel: Used for key and certificate management.

Sidecar and Peripheral Proxy: Enable secure communication between client and server.

pilot: Distributes authentication policies and security naming information to agents.

Mixer: Used to manage authorizations and audits.

Policy customization: Configure custom policies for applications to enforce rules at runtime, such as dynamically restricting traffic to services, restricting access to services through lists, or creating your own policy adapters to add custom authorization behavior.

Observability: Istio's powerful tracing, monitoring, and logging capabilities provide insight into service grid deployments. Istio's monitoring capabilities allow you to truly understand the upstream and downstream impact of service performance, while its custom dashboards allow you to view the performance of all services and understand how that performance affects other processes.

IV. Basic function verification

This environment is validated against Kubernets 1.14 and istio 1.13. The following examples are in the official linked samples directory, official links [1]istio official examples

1. Traffic management:

To populate its own service registry, Istio connects to the service discovery system, and Istio is installed on the Kubernetes cluster, Istio automatically detects the services and endpoints in the cluster, and using this service registry, the proxy can direct traffic to the relevant services. By default, traffic is distributed evenly across multiple instances of the same workload, but as part of A/B testing, a specific percentage of traffic can be directed to a new version of the service, or different load balancing policies can be applied to traffic for a particular subset of service instances. You can also apply special rules to traffic in and out of Mesh, or add external dependencies of Mesh to the service registry.

Take the official bookinfo as an example, using traffic management for multiple versions of the same program, the specific configuration is as follows:

self-injection enable

kubectl label namespace default istio-injection=enabled

Deploy bookinfo to default namespaces. The default invocation relationship between bookinfo services is as follows:

You can create virtualService to direct all traffic to reviews-v1. In the yaml file, host points to reviews service, and only v1 version is specified, so all traffic is directed to reviews v1.

virtualService yaml is as follows:

apiVersion: networking.istio.io/v1alpha3kind: VirtualServicemetadata: name: reviewsspec: hosts: - reviews http: - route: - destination: host: reviews subset: v1

Security, mainly to provide secure access between service grids, here to enable TLS as an example.

Create meshPolicy global enable tls

kubectl apply -f -

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.