[服务网格Istio系列]--Istio架构介绍

上篇文章中介绍了：[服务网格Istio系列]--微服务 Kubernetes Istio关系，这里主要介绍Istio的架构。

Istio的工作机制

Istio主要分为两部分：控制面和数据面；

控制面主要包括Pilot、Mixer、Citadel、Galley等组件；

pilot
英 /ˈpaɪlət/ 美 /ˈpaɪlət/ 全球(英国)
n. 飞行员；领航员
adj. 试点的
v. 驾驶；领航；试用
n. (Pilot)人名；(意、印)皮洛特；(法)皮洛
复数 pilots过去式 piloted过去分词 piloted现在分词 piloting第三人称单数 pilots

mixer
英 /ˈmɪksə(r)/ 美 /ˈmɪksər/ 全球(德国)
n. 混合器；搅拌器；[电子] 混频器

citadel
英 /ˈsɪtədəl; ˈsɪtədel/ 美 /ˈsɪtədəl,ˈsɪtədel/ 全球(美国)
n. 城堡；大本营；避难处
复数 citadels

galley
英 /ˈɡæli/ 美 /ˈɡæli/ 全球(英国)
n. [船] 船上的厨房；单层甲板的大帆船；活版盘，长条校样
n. (Galley)人名；(英)加利；(法、德)加莱
复数 galleys

envoy
英 /ˈenvɔɪ/ 美 /ˈenvɔɪ/ 全球(英国)
n. 使者；全权公使
复数 envoys

数据面由伴随每个应用程序部署的代理程序Envoy组成，执行针对应用程序的治理逻辑。

下面通过动态场景来了解Istio的工作机制，观察frontend服务对forecast服务进行一次访问时，在Istio内部都发生了什么？

1. 自动注入：

指在创建应用程序时自动注入Sidecar代理。在Kubernetes场景下创建Pod时，Kuber-apiserver调用管理面组件的Sidecar-injector服务，自动修改应用程序的描述信息并注入Sidecar。在真正创建Pod时，在创建业务容器的同时在Pod中创建Sidecar容器。

2. 流量拦截

在Pod初始化时设置iptables规则，当有流量到来时，基于配置的iptables规则拦截业务容器的Inbound和Outbound流量到Sidecar容器上，应用程序感知不到Sidecar的存在，还以原本的方式进行相互访问。如上图，流出frontend服务的流量会被frontend服务侧的Sidecar Envoy拦截，而当流量到达forecast服务时，Inbound流量被forecast侧的Envoy拦截。

3. 服务发现

服务发起方的Envoy调用管理面组件Pilot的服务发现接口获取目标服务的实例列表，如上图所示，frontend服务侧的Envoy通过Pilot的服务发现接口得到forecast服务各个实例的地址，为访问做准备。

4. 负载均衡

服务发起方的Envoy根据配置的负载均衡策略选择服务实例，并连接对应的实例地址。如上图所示，数据面的各个Envoy从Pilot中获取forecast服务的负载均衡配置，并执行负载均衡动作。

5. 流量治理

Envoy从Pilot中获取配置的流量规则，在拦截到Inbound和Outbound流量时执行治理逻辑。如上图，frontend侧的Envoy从Pilot中获取流量治理规则，并根据流量治理规则将不通特性的流量分发到forecast服务的v1或v2版本。

6. 访问安全

在服务访问时通过双方的Envoy进行双向认证和通道加密，并基于服务的身份进行授权管理。如图，Pilot下发安全相关的配置，在frontend服务和forecast服务的Envoy上自动加载证书和密钥来实现双向认证，其中的证书和密钥由管理面组件Citadel维护。

7. 服务遥测

在服务间通信时，通信双方的Envoy都会连接管理面组件Mixer，上报访问数据，并通过Mixer将数据转发给对应的监控后端。如图所示，frontend服务对forecast服务的访问监控指标、日志和调用链都可以通过这种方式收集到对应的监控后端。

8. 策略执行

在进行服务访问时，通过Mixer连接后端服务来控制服务间的访问，判断对访问是放行还是拒绝。如上图，Mixer后端可以对接一个限流服务对从frontend服务到forecast服务的访问进行速率控制。

9. 外部访问

在网格的入口处有一个Envoy扮演入口网关的角色。如上图，外部服务通过Gateway访问入口服务frontend，对frontend服务的负载均衡和一些流量治理策略都在这个Gateway上执行。

总结

服务调用双方的Envoy代理拦截流量，并根据管理面的相关配置执行响应的治理动作。

Istio的服务模型

Istio 支持将由服务、服务版本和服务实例构造成的抽象模型映射到不同的平台上。可以认为，Istio的几个资源对象就是基于Kubernetes的相应资源对象构建的，加上部分约束来满足Istio服务模型的要求。

Istio 官方对这几个约束的描述如下：

端口命名：对Istio的服务端口必须进行命名，二期名称只允许是<protocol>[-<suffix>]这种格式：
- <protocol> 可以是tcp、http、http2、https、grpc、tls、mongo、mysql、redis等，Istio根据在端口上定义的协议来提供对应的路由能力。
- [-<suffix>] 后缀，端口名称，可以省略。
- 例如：name: http2-forecast 和 name: http 是合法的端口名，但是name: http2forecast 是非法的端口名。
- 如果端口未命名或者没有基于这种格式进行命名，则端口的流量会被当做TCP流量来处理。
服务关联：Pod需要关联到服务，如果一个Pod属于多个Kubernetes服务（Service），则要求不能再同一个端口上使用不同的协议。
Deployment使用app和version标签：建议Kubernetes Deployment显示的包含app和version标签，每个Deployment都需要有一个有业务意义的app标签和一个表示版本的version标签。在分布式追踪时可以通过app标签来补齐上下文信息，还可以通过app和version标签为遥测数据补齐上下文信息。
应用的UID：确认Pods内运行程序的用户ID（UID）不能是1337。
NET_ADMIN能力：如果集群中配置了Pod Security Policies，则Pods必须拥有NET_ADMIN的能力，如果你使用Istio CNI Plugin，则此要求不再适用。

Istio的服务 Service

从逻辑上看，服务是Istio主要管理的资源对象，是一个抽象概念，主要包含HostName和Ports等属性，并指定了Service的域名和端口列表。每个端口都包含端口名称、端口号和端口协议。

不同的协议有不同的内容，相应的，在Istio中对不同的协议也有不同的治理规则集合。这也是Istio关于端口命名约束的机制层面的原因，具体来讲就是要求将端口的协议通过“-”连接符加在端口名称上。

从物理层面看，Istio服务的存在形式就是Kubernetes的Service，在启用了Istio的集群中创建Kubernetes的Service时只要满足以上约束，就可以转换为Istio的Service并配置规则进行流量治理。

Service是Kubernetes的一个核心资源，用户通过一个域名或者虚拟的IP就能访问到后端Pod，避免像用户暴露Pod地址的问题。

一个简单的Service示例如下：

apiVersion: v1
kind: Service
metadata:
  name: forecast
spec:
  ports:
  - port: 3002
    targetPort: 3002
  selector:
    app: forecast

解释：

创建了一个名为foreca的Service，通过一个ClusterIP的地址就可以访问这个Service，指向拥有“app: forecast”标签的Pods。Kubernetes自动创建一个和Service同名的Endpoints对象，Service的Selector会持续的关注属于Service的Pod，结果会被更新到相应的Endpoints对象。

Istio的Service比较简单，可以看到差别就是要满足Istio服务的约束，并在端口名称上指定协议。在以下实例中指定了forecast的服务的3002端口是HTTP，对这个服务的访问就可以应用HTTP的诸多治理规则：

apiVersion: v1
kind: Service
metadata:
  name: forecast
spec:
  ports:
  - port: 3002
    targetPort: 3002
    name: http # 这里只指定了<protocol>,而省略了-<suffix>
  selector:
    app: forecast

Istio虽然依赖于了Kubernetes的Service定义，但是除了一些约束，在定位上还是有些差别的。在Kubernetes中，一般先通过Deployment创建工作负载，在通过创建Service关联这些工作负载，从而暴露工作负载的接口。因而看上去主体是工作负载，Service只是一种访问方式，某些后台执行的负载若不需要被访问，就不用定义Service。

在Istio中，Service是治理的对象，是Istio中的核心管理实体，所以在Istio中，Service是一个提供了对外访问能力的执行体，可以将其理解为一个定义了服务的工作负载，没有访问方式的工作负载不是Istio的管理对象，Kubernetes的Service定义就是Istio服务的元数据。

Istio的服务版本

在Istio的应用场景中，灰度发布是一个重要的场景，即要求一个Service有多个不同版本的实现。而Kubernetes在语法上不支持一个Deployment上定义多个版本，在Istio中多个版本的定义是将一个Service关联到多个Deployment，每个Deployment都对应服务的一个版本：

如下示例：forecast-v1和forecast-v2这两个Deployment分别对应服务的两个版本：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: forecast-v1
  labels:
    app: forecast
    version: v1
spec:
  replicas: 3
  selector:
    matchLabels:
      app: forecast
      version: v1
  template:
    metadata:
      labels:
        app: forecast
        version: v1
    spec:
      containers:
      - name: forecast
        image: istioweather/forecast:v1
        ports:
        - containerPort: 3002
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: forecast-v2
  labels:
    app: forecast
    version: v2
spec:
  replicas: 2
  selector:
    matchLabels:
      app: forecast
      version: v2
  template:
    metadata:
      labels:
        app: forecast
        version: v2
    spec:
      containers:
      - name: forecast
        image: istioweather/forecast:v2
        ports:
        - containerPort: 3002

观察和比较这两个Deployment的描述文件，可以看到：

这两个Deployment都有相同的app: forecast 标签，正式这个标签和Service的标签选择器一致(参考上面的：[Istio的服务 Service](#Istio的服务 Service))，才保证了Service能关联到两个Deployment对应的Pod。
都有不同的镜像版本，因此各自创建的Pod也不同；两个Deployment的version标签也不同，分别为v1和v2，表示这是服务的不同版本，这个不同的版本标签用来定义不同的Destination，进行执行不同的路由规则。

下面根据对Service和两个Deployment的如上定义分别创建3个Pod和两个Pod，假设5个Pod都运行在两个不同的Node上。在对Service进行访问时，根据配置的流量规则，可以将不同的流量转发到不同版本的Pod上：

Istio的服务实例 ServiceInstance

服务实例是真正处理服务请求的后端，就是监听在相同端口上的具有相同行为的对等后端。服务访问时由代理根据负载均衡策略将流量转发到其中一个后端处理。Istio的ServiceInstance主要包括Endpoint，Service，Labels，AvailabilityZone和ServiceAccount等属性，Endpoint是其中最主要的属性，表示这个实力对应的网络后端(IP: Port)，Service表示这个服务实例归属的服务。

Istio的服务发现基于Kubernetes构建，Istio的Service对应Kubernetes的Service，Istio的服务实例ServiceInstance对应Kubernetes的Endpoints：

Kubernetes提供了一个Endpoints对象，这个Endpoints对象的名称和Service的名称相同，它是一个<Pod IP>: <targetPort>列表，负责维护Service后端Pod的变化。上面的例子中，forecast服务对应如下Endpoints对象，包含两个后端Pod，后端地址分别是172.16.0.16和172.16.0.19，当实例数量发生变化时，对应的Subsets列表的后端数量会动态更新；同样，当某个Pod迁移时，Endpoints对象中的后端IP地址也会更新：

apiVersion: v1
kind: Endpoints
metadata:
  labels:
    app: forecast
  name: forecast
  namespace: weather
subsets:
- addresses:
  - ip: 172.16.0.16
    nodeName: 192.168.0.133
    targetRef:
      kind: Pod
      name: forecast-v1-47df577w9d-9sl3
      namespace: weather
  - ip: 172.16.0.19
    nodeName: 192.168.0.133
    targetRef:
      kind: Pod
      name: forecast-v1-89dd2j92jh-3dg3
      namespace: weather
  ports:
  - name: http
    port: 3002

Istio的主要组件

官方参考：https://istio.io/docs/ops/deployment/architecture/

如图所示：是Istio1.1在典型环境下完整组件列表：

Istio架构：

来自官方的架构说明：

An Istio service mesh is logically split into a data plane and a control plane.

The data plane is composed of a set of intelligent proxies (Envoy) deployed as sidecars. These proxies mediate and control all network communication between microservices along with Mixer, a general-purpose policy and telemetry hub.数据平面由一组部署为边车的智能代理(Envoy)组成。这些代理负责协调和控制微服务和Mixer之间的所有网络通信，以及一个通用策略和遥测中心。
The control plane manages and configures the proxies to route traffic. Additionally, the control plane configures Mixers to enforce policies and collect telemetry.控制平面管理并将代理配置为路由流量。此外，控制平面配置Mixer来执行策略和收集遥测数据。

istio-pilot

官方描述：

Pilot provides service discovery for the Envoy sidecars, traffic management capabilities for intelligent routing (e.g., A/B tests, canary rollouts, etc.), and resiliency (timeouts, retries, circuit breakers, etc.).

Pilot converts high level routing rules that control traffic behavior into Envoy-specific configurations, and propagates them to the sidecars at runtime. Pilot abstracts platform-specific service discovery mechanisms and synthesizes them into a standard format that any sidecar conforming with the Envoy API can consume.

服务列表中的istio-pilot是Istio的控制中枢Pilot服务。如果把数据面的Envoy也看做一种Agent，则Pilot类似传统C/S架构中的服务端Master，下发指令控制客户端完成业务功能。和传统的微服务架构对比，Pilot至少涵盖服务注册中心和Config Server等管理组件的功能。

如下图，Pilot直接从运行平台提取数据并将其构造或转换成Istio的服务发现模型，因此Pilot只有服务发现功能，无需进行服务注册。这种抽象模型解耦了Pilot和底层平台的不同实现，可支持Kubernetes、Consul等平台。

出了服务发现，Pilot更重要的一个功能是向数据面下发规则，包括VirtualService、DestinationRule、Gateway、ServiceEntry等流量治理规则，也包括认证授权等安全规则。Pilot负责将各种规则转换成Envoy可识别的格式，通过标准的xDS协议发给Envoy，指导Envoy完成动作。在通信上，Envoy通过gRPC流式订阅Pilot的配置资源，如下，Pilot将VirtualService表达的路由规则分发到Envoy上，Envoy根据该路由规则进行流量转发。

The platform starts a new instance of a service which notifies its platform adapter.
The platform adapter registers the instance with the Pilot abstract model.
Pilot distributes traffic rules and configurations to the Envoy proxies to account for the change.

istio-telemetry

telemetry
英 /təˈlemətri/ 美 /təˈlemətri/ 全球(美国)
n. [自] 遥测技术；遥感勘测；自动测量记录传导

istio-telemetry是专门用于手机遥测数据的Mixer服务组件。在部署上，Istio控制面部署了两个Mixer组件：istio-telemery和istio-policy，分别处理遥测数据的收集和策略的执行，两个组件的镜像时相同的，都是：“/istio/mixer”。

Mixer是Istio独有的一种设计，不同于Pilot，在其他平台上总能找到类似功能的服务组件。从调用实机上来说，Pilot管理的是配置数据，在配置改变时和数据面交互即可；然而，对于Mixer来说，在服务间交互时Envoy都会对Mixer进行一次调用，因此这是一种实时管理。当然，在实现上通过Mixer和Proxy上使用缓存机制，可保证不用每次进行数据面请求时都和Mixer交互。

如下图：当网格中的两个服务间有调用发生时，服务的代理Envoy就会上报遥测数据给istio-telemetry服务组件，istio-telemetry服务组件则根据配置将生成访问Metric等数据分发给后端的遥测服务。数据面代理通过Report接口上报数据时访问数据会被批量上报。

在架构上，Mixer作为中介来解耦数据面和不同后端的对接，已提供灵活性和扩展能力。运维人员可以动态配置各种遥测后端，来收集指定的服务运行数据。

istio-policy

istio-topicy是另一个Mixer服务，和istio-telemetry基本上是完全相同的机制和流程，如下图，数据面在转发服务的请求前，调用istio-policy的Check接口检查是否允许访问，Mixer根据配置将请求转发到对应的Adapter做对应检查，给代理返回允许还是拒绝访问。可以对接如配额、授权、黑白名单等不同的控制后端，对服务间的访问进行可扩展的控制。

Mixer组件官方介绍：

Mixer is a platform-independent component. Mixer enforces access control and usage policies across the service mesh, and collects telemetry data from the Envoy proxy and other services. The proxy extracts request level attributes, and sends them to Mixer for evaluation. You can find more information on this attribute extraction and policy evaluation in our Mixer Configuration documentation.

Mixer includes a flexible plugin model. This model enables Istio to interface with a variety of host environments and infrastructure backends. Thus, Istio abstracts the Envoy proxy and Istio-managed services from these details.

所有的上报属性，参考：https://istio.io/docs/reference/config/policy-and-telemetry/attribute-vocabulary/

这些属性可以作为流量治理的条件使用。


Name	Type	Description	Kubernetes Example
`source.uid`	string	Platform-specific unique identifier for the source workload instance.	`kubernetes://redis-master-2353460263-1ecey.my-namespace`
`source.ip`	ip_address	Source workload instance IP address.	`10.0.0.117`
`source.labels`	map[string, string]	A map of key-value pairs attached to the source instance.	version => v1
`source.name`	string	Source workload instance name.	`redis-master-2353460263-1ecey`
`source.namespace`	string	Source workload instance namespace.	`my-namespace`
`source.principal`	string	Authority under which the source workload instance is running.	`service-account-foo`
`source.owner`	string	Reference to the workload controlling the source workload instance.	`kubernetes://apis/extensions/v1beta1/namespaces/istio-system/deployments/istio-policy`
`source.workload.uid`	string	Unique identifier of the source workload.	`istio://istio-system/workloads/istio-policy`
`source.workload.name`	string	Source workload name.	`istio-policy`
`source.workload.namespace`	string	Source workload namespace.	`istio-system`
`destination.uid`	string	Platform-specific unique identifier for the server instance.	`kubernetes://my-svc-234443-5sffe.my-namespace`
`destination.ip`	ip_address	Server IP address.	`10.0.0.104`
`destination.port`	int64	The recipient port on the server IP address.	`8080`
`destination.labels`	map[string, string]	A map of key-value pairs attached to the server instance.	version => v2
`destination.name`	string	Destination workload instance name.	`istio-telemetry-2359333`
`destination.namespace`	string	Destination workload instance namespace.	`istio-system`
`destination.principal`	string	Authority under which the destination workload instance is running.	`service-account`
`destination.owner`	string	Reference to the workload controlling the destination workload instance.	`kubernetes://apis/extensions/v1beta1/namespaces/istio-system/deployments/istio-telemetry`
`destination.workload.uid`	string	Unique identifier of the destination workload.	`istio://istio-system/workloads/istio-telemetry`
`destination.workload.name`	string	Destination workload name.	`istio-telemetry`
`destination.workload.namespace`	string	Destination workload namespace.	`istio-system`
`destination.container.name`	string	Name of the destination workload instance’s container.	`mixer`
`destination.container.image`	string	Image of the destination workload instance’s container.	`gcr.io/istio-testing/mixer:0.8.0`
`destination.service.host`	string	Destination host address.	`istio-telemetry.istio-system.svc.cluster.local`
`destination.service.uid`	string	Unique identifier of the destination service.	`istio://istio-system/services/istio-telemetry`
`destination.service.name`	string	Destination service name.	`istio-telemetry`
`destination.service.namespace`	string	Destination service namespace.	`istio-system`
`origin.ip`	ip_address	IP address of the proxy client, e.g. origin for the ingress proxies.	`127.0.0.1`
`request.headers`	map[string, string]	HTTP request headers with lowercase keys. For gRPC, its metadata will be here.
`request.id`	string	An ID for the request with statistically low probability of collision.
`request.path`	string	The HTTP URL path including query string
`request.url_path`	string	The path part of HTTP URL, with query string being stripped
`request.query_params`	map[string, string]	A map of query parameters extracted from the HTTP URL.
`request.host`	string	HTTP/1.x host header or HTTP/2 authority header.	`redis-master:3337`
`request.method`	string	The HTTP method.
`request.reason`	string	The request reason used by auditing systems.
`request.referer`	string	The HTTP referer header.
`request.scheme`	string	URI Scheme of the request
`request.size`	int64	Size of the request in bytes. For HTTP requests this is equivalent to the Content-Length header.
`request.total_size`	int64	Total size of HTTP request in bytes, including request headers, body and trailers.
`request.time`	timestamp	The timestamp when the destination receives the request. This should be equivalent to Firebase “now”.
`request.useragent`	string	The HTTP User-Agent header.
`response.headers`	map[string, string]	HTTP response headers with lowercase keys.
`response.size`	int64	Size of the response body in bytes
`response.total_size`	int64	Total size of HTTP response in bytes, including response headers and body.
`response.time`	timestamp	The timestamp when the destination produced the response.
`response.duration`	duration	The amount of time the response took to generate.
`response.code`	int64	The response’s HTTP status code.
`response.grpc_status`	string	The response’s gRPC status.
`response.grpc_message`	string	The response’s gRPC status message.
`connection.id`	string	An ID for a TCP connection with statistically low probability of collision.
`connection.event`	string	Status of a TCP connection, its value is one of “open”, “continue” and “close”.
`connection.received.bytes`	int64	Number of bytes received by a destination service on a connection since the last Report() for a connection.
`connection.received.bytes_total`	int64	Total number of bytes received by a destination service during the lifetime of a connection.
`connection.sent.bytes`	int64	Number of bytes sent by a destination service on a connection since the last Report() for a connection.
`connection.sent.bytes_total`	int64	Total number of bytes sent by a destination service during the lifetime of a connection.
`connection.duration`	duration	The total amount of time a connection has been open.
`connection.mtls`	boolean	Indicates whether a request is received over a mutual TLS enabled downstream connection.
`connection.requested_server_name`	string	The requested server name (SNI) of the connection
`context.protocol`	string	Protocol of the request or connection being proxied.	`tcp`
`context.time`	timestamp	The timestamp of Mixer operation.
`context.reporter.kind`	string	Contextualizes the reported attribute set. Set to `inbound` for the server-side calls from sidecars and `outbound` for the client-side calls from sidecars and gateways	`inbound`
`context.reporter.uid`	string	Platform-specific identifier of the attribute reporter.	`kubernetes://my-svc-234443-5sffe.my-namespace`
`context.proxy_error_code`	string	Additional details about the response or connection from proxy. In case of Envoy, see `%RESPONSE_FLAGS%` in Envoy Access Log for more detail	`UH`
`api.service`	string	The public service name. This is different than the in-mesh service identity and reflects the name of the service exposed to the client.	`my-svc.com`
`api.version`	string	The API version.	`v1alpha1`
`api.operation`	string	Unique string used to identify the operation. The id is unique among all operations described in a specific <service, version>.	`getPetsById`
`api.protocol`	string	The protocol type of the API call. Mainly for monitoring/analytics. Note that this is the frontend protocol exposed to the client, not the protocol implemented by the backend service.	`http`, `https`, or `grpc`
`request.auth.principal`	string	The authenticated principal of the request. This is a string of the issuer (`iss`) and subject (`sub`) claims within a JWT concatenated with “/” with a percent-encoded subject value. This attribute may come from the peer or the origin in the Istio authentication policy, depending on the binding rule defined in the Istio authentication policy.	`issuer@foo.com/sub@foo.com`
`request.auth.audiences`	string	The intended audience(s) for this authentication information. This should reflect the audience (`aud`) claim within a JWT.	`aud1`
`request.auth.presenter`	string	The authorized presenter of the credential. This value should reflect the optional Authorized Presenter (`azp`) claim within a JWT or the OAuth2 client id.	123456789012.my-svc.com
`request.auth.claims`	map[string, string]	all raw string claims from the `origin` JWT	`iss`: `issuer@foo.com`, `sub`: `sub@foo.com`, `aud`: `aud1`
`request.api_key`	string	The API key used for the request.	abcde12345
`check.error_code`	int64	The error code for Mixer Check call.	5
`check.error_message`	string	The error message for Mixer Check call.	Could not find the resource
`check.cache_hit`	boolean	Indicates whether Mixer check call hits local cache.
`quota.cache_hit`	boolean	Indicates whether Mixer quota call hits local cache.

istio-citadel

官方介绍：

Citadel enables strong service-to-service and end-user authentication with built-in identity and credential management. You can use Citadel to upgrade unencrypted traffic in the service mesh. Using Citadel, operators can enforce policies based on service identity rather than on relatively unstable layer 3 or layer 4 network identifiers. Starting from release 0.5, you can use Istio’s authorization feature to control who can access your services.

istio-citadel是Istio核心安全组件，提供了自动生成、分发、转换与撤销密钥和证书功能。Citadel一直监听Kube-apiserver，以Secret的形式为每个服务都生成证书密钥，并在Pod创建时挂载到Pod上，代理容器使用这些文件来做服务身份认证，进而代理两端服务实现双向TLS认证、通道加密、访问授权等安全功能，这样用户就不用在代码里维护证书密钥了。如下图：frontend服务对forecast服务的访问用到了HTTP方式，通过配置即可对服务增加认证功能，双方的Envoy会建立双向认证的TLS通道，从而在服务间启用双认证的HTTPS。

istio-galley

官方介绍：

Galley is Istio’s configuration validation, ingestion, processing and distribution component. It is responsible for insulating the rest of the Istio components from the details of obtaining user configuration from the underlying platform (e.g. Kubernetes).

istio-galley并不直接向数据面提供业务能力，而是在控制面上向其他组件提供支持。Galley作为负责配置管理的组件，验证配置信息的格式和内容的正确性，并将这些配置信息提供给管理面的Pilot和Mixer服务使用，这样其他服务组件只用和Galley打交道，从而与底层平台解耦。在新版本的Galley的作用越来越核心。

istio-sidecar-injector

istio-sidcar-injector是负责自动注入的组件，只要开启了自动注入，在Pod创建时就会自动调用Istio-sidecar-injector向Pod中注入Sidecar容器。

在Kubernetes环境下，根据自动注入配置，Kuber-apiserver在兰街道Pod创建的请求时，会调用自动注入服务istio-sidecar-injector生生Sidecar容器的描述并将其插入原Pod的定义中，这样，在创建Pod内除了包括业务容器，还包括Sidecar容器。这个注入过程对用户是透明的，用户使用原方式创建工作负载。

istio-proxy

Envoy、Sidecar、Proxy等术语有时混着用，都表示Istio数据面的轻量代理。但关注Pod的详细信息，会发现这个容器的正式名字是istio-proxy，不是通用的Envoy镜像，而是叠加了Istio的Proxy功能的一个扩展版本。另外，在istio-proxy容器中除了有Envoy，还有一个pilot-agent的守护进程。未来如果能在istio-proxy中提供Mixer的部分能力，则将是一个非常紧凑的设计。

Envoy使用C++开发的非常有影响力的轻量级高性能开源服务代理。作为服务网格的数据面，Envoy提供了动态服务发现、负载均衡、TLS、HTTP/2及gRPC代理、熔断器、健康检查、流量拆分、灰度发布、故障注入等功能。大部分治理能力最终都落实到Envoy的实现上。

在Istio中，规则的描述对象都是类似forecast服务的呗访问者，但是真正的规则执行位置对于不同类型的动作可能不同，可能在被访问服务的Sidecar兰街道Inbound流量时执行，也可能在访问者的Sidecar在拦截Outbound流量时执行，一般后者（Outbound）巨多。当给forecast服务定义流量规则时，所有访问forecast服务的Sidecar都收到规则，并且执行相同的治理逻辑，从而对目标服务执行一致的治理。如下图列出常用的服务访问治理规则和其执行位置。

istio-ingressgateway

istio-ingressgateway就是入口处的Gateway，从网格外访问网格内的服务就是通过这个Gateway进行的。istio-ingressgateway比较特别，是一个Loadbalancer类型的Service，不同于其他服务组件只有一两个端口，istio-ingressgateway开放了一组端口，这些就是网格内服务的外部访问端口，如下图，网格入口网关istio-ingressgateway的负载和网格内的Sidecar是同样的执行体，也和网格内的其他Sidecar一样从Pilot处接收流量规则并执行。以为入口处的流量都走这个服务，会有较大的并发，并可能出现流量峰值，所以需要评估流量来规划规格和实例数。Istio通过一个特有的资源对象Gateway来配置对外的协议、端口等。

其他组件

除了以Istio为前缀的以上几个Istio自由的组件，在集群中一般还安装Jaeger-agent、Jaeger-collector、Jaeger-query、Kiali、Prometheus、Tracing、Zipkin组件，这些组件提供了Istio的调用链、监控等功能，可以选择安装来完成完整的服务监控管理功能。

来自：云原生服务网格Istio：原理、实践、架构与源码解析书籍，本文只作为读书笔记记录，版权属于原作者。

本文到这里就结束了，欢迎期待后面的文章。您可以关注下方的公众号二维码，在第一时间查看新文章。