Istio
最后更新于
最后更新于
Istio is the brainchild of tech giants Google, IBM, and Lyft. It's an open-source service mesh framework designed to take the complexity out of managing the discoverability, connectivity, administration, surveillance, and security of a multitude of microservices. The magic of Istio is that it's invisible to applications and performs its myriad of services without requiring any modifications to the service code.
Here are some of the superpowers Istio possesses:
Automatic load balancing for HTTP, gRPC, WebSocket, and TCP networking traffic
Fine-tuned control over networking traffic behaviors like sophisticated routing rules, retries, fault transfers, and fault injections
Optional policy layers and configuration APIs for access control, rate limiting, and quota management
Auto metrics, logging, and tracking for all inbound and outbound traffic
Robust authentication and authorization system that lets services talk to each other in a safe and secure manner
Logically, Istio divides and conquers by splitting itself into data and control planes:
The data plane is made up of a slew of smart proxies—defaulting to Envoy—that handle network communications among the microservices
The control plane manages and configures these proxies for traffic routing and configures a Mixer for policy enforcement and telemetry data gathering
Istio's architecture looks something like this:
It consists mainly of the following elements:
Envoy: An efficient, open-source proxy created by Lyft, Envoy mediates inbound and outbound traffic for all services within the service mesh. It comes with a rich toolbox filled with features like dynamic service discovery, load balancing, TLS termination, HTTP/2 and gRPC proxy, circuit breaker, health check, fault injection, and performance metrics. Built as a sidecar, it gets deployed alongside the related service's Pod, eliminating the need for code rewrites or redesigns.
Mixer: Enforces access control and policies while also collecting telemetry data from Envoy proxies. It comes with a flexible plugin model for expandability, which accommodates various backends including GCP, AWS, Prometheus, Heapster, and more.
Pilot: Responsible for managing the lifecycle of Envoy instances dynamically, providing service discovery, smart routing, and managing traffic resilience such as timeouts and retries. It translates traffic management strategies into configurations for the Envoy data plane and distributes them to the sidecars.
Pilot also provides service discovery for Envoy sidecars, offering traffic management functions for smart routing (e.g., A/B testing, canary releases) and resilience (timeouts, retries, circuit breakers). It hyperbolizes complex routing rules for traffic control into Envoy-specific configurations and propagates them to the sidecars during runtime. Pilot also abstracts service discovery mechanisms into a format compatible with the Envoy data plane API, permitting operation in various environments while maintaining the same operational interfaces for traffic management.
Citadel: Strengthens inter-service and end-user authentication via built-in identity and credential management. Supports role-based access control and policy execution based on service identity.
In the data plane, besides Envoy, there are other options such as nginxmesh and linkerd as network proxies. When utilizing nginxmesh, the control plane of Istio (Pilot, Mixer, Auth) remains intact, only the Nginx Sidecar replaces Envoy:
For step-by-step installation instructions of Istio, please refer to this page.
Pods must meet certain criteria before getting injected with a Sidecar container and, in turn, becoming part of the service mesh. Istio requires Pods to:
Be associated with and uniquely belong to a single service—multi-service Pods aren't supported
Have named ports, conforming to the <protocol>[-<suffix>] format, where the protocol can be http, http2, grpc, mongo, or redis. Unnamed ports are treated as TCP traffic
It's recommended to include an app label in all Deployments to add context information to distributed traces
The following steps assume that the terminal is in the
istio-${ISTIO_VERSION}directory, which was downloaded during the installation deployment.
During application deployment, the istioctl kube-inject can be used to manually insert an Envoy sidecar container into the Pod:
The initial app appears as follows:
istioctl kube-inject inserts an Envoy container into each Pod of the original application:
Once the service is running, you can access the BookInfo app via the Gateway address http://<gateway-address>/productpage:
By default, the three versions of reviews services go through rounds in a load-balanced way.
First, verify that the admissionregistration API has been turned on:
Then, make sure the istio-sidecar-injector is properly running:
Next, add the label istio-injection=enabled to the namespace that needs automatic sidecar injection:
After doing so, any newly created Pods in the default namespace will automatically have the istio sidecar container attached.
