我们尝试用迭代方式来说明:
首先来看下Istio在服务访问过程中做了什么。一个简单的Client访问Server,对两者使用开发语言没有任何要求,可以是Client采用node.js编写,server采用java编写。在Client中访问服务server,在两个程序中不用包含任何服务访问管理的逻辑。
来看看Istio在其中做了什么:
…
所有这些功能,都不用用户修改代码,用户只需要在Istio 的控制面做些配置即可,并且动态生效。以灰度测试为例,在Istio中通过简单配置实现灰度发布,核心是实现两个版本同时在线,并通过一定的流量策略将部分流量引流到新版本上。无须改动代码,只需要简单的一个配置即可:
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: server
spec:
hoste:
- server
http:
- match:
- headers:
cookie:
exact: "group=dev"
route:
- destination:
name: v2
- route:
- destination:
name: va
将group为dev的流量转发到server的v2版本,其他用户访问的还是v1,从而实现灰度发布。整个过程中除了Istio配置需要修改,其他不需要做任何事情。
在集群中通过“kubectl get svc -n istio-system” 获取isto 的各组件
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
grafana ClusterIP 10.109.18.105 3000/TCP 46h
istio-citadel ClusterIP 10.97.247.24 8060/TCP,15014/TCP 46h
istio-egressgateway ClusterIP 10.106.34.148 80/TCP,443/TCP,15443/TCP 46h
istio-galley ClusterIP 10.103.74.254 443/TCP,15014/TCP,9901/TCP,15019/TCP 46h
istio-ingressgateway LoadBalancer 10.99.94.178 localhost 15020:30397/TCP,80:32621/TCP,443:32749/TCP,15029:31666/TCP,15030:32662/TCP,15031:30400/TCP,15032:32139/TCP,15443:32435/TCP 46h
istio-pilot ClusterIP 10.98.146.59 15010/TCP,15011/TCP,8080/TCP,15014/TCP 46h
istio-policy ClusterIP 10.109.93.7 9091/TCP,15004/TCP,15014/TCP 46h
istio-sidecar-injector ClusterIP 10.100.143.27 443/TCP 46h
istio-telemetry ClusterIP 10.110.99.43 9091/TCP,15004/TCP,15014/TCP,42422/TCP 46h
jaeger-agent ClusterIP None 5775/UDP,6831/UDP,6832/UDP 46h
jaeger-collector ClusterIP 10.108.7.167 14267/TCP,14268/TCP,14250/TCP 46h
jaeger-query ClusterIP 10.107.85.181 16686/TCP 46h
kiali ClusterIP 10.103.150.239 20001/TCP 46h
prometheus ClusterIP 10.110.122.226 9090/TCP 46h
tracing ClusterIP 10.105.32.84 80/TCP 46h
zipkin ClusterIP 10.107.56.80 9411/TCP 46h
pilot 是Istio 的控制中心,下发指令控制完成作业。Pilot 直接从平台提取数据并将构建和转换成Istio 的服务发现模型。因此Pilot只有服务发现功能,而无服务注册功能。这种抽象框架解耦了Pilot和底层平台的不同实现,可支持kubernetes、Consul等平台。
除了服务发现,Pilot更重要的一个功能是向数据面下发规则,包括VirtualService、DestinationRule、Gateway、ServiceEntry等流量治理规则,也包括认证授权等安全机制。Pilot负责将各种规则转换成Envoy可识别的格式,通过标准的xDS协议发送给Envoy,指导Envoy完成动作。在通信上Envoy通过gRPC流式订阅Pilot的配置资源。例如Pilot将VirtualService表达的路由规则分发到Envoy上,Envoy将根据该路由规则进行流量转发。
telemetry是专门用于收集遥测数据的Mixer服务组件,如服务列表所示,在部署上,Istio 控制面部署了两个Mixer组件:telemetry和policy,分别处理遥测数据的收集和策略的执行。查看两个组件的Pod镜像会发现,容器的镜像是一样的,都是“/istio/mixer”。
Mixer 是Istio独有的一种设计,不同于Pilot,在其他平台上总能找到类似功能的服务组件。从调用时机来说,Pilot管理的是配置数据,在配置改变时和数据面交互即可;然而,对于Mixer来说,在服务间交互时Envoy都会对Mixer进行一次调用,因此这是一种实时管理。当然,通过在Mixer和Proxy上使用缓存机制,可保证不用每次进行数据请求时都和Mixer交互。
当网络中的两个服务间有交互发生时,服务的代理Envoy就会上报遥测数据给telemetry 服务组件。telemetry服务组件根据配置将生成访问Mixer等数据分发给后端的遥测服务。数据面代理通过report 接口上报数据时访问数据会被批量上报。
在架构上,Mixer 作为中介来解耦数据面和不同后端的对接,以提供灵活性和扩展能力。运维人员可以动态配置各种遥测后端,来收集指定的服务运行数据。
policy 时另外一个Mixer服务,和telemetry基本上是完全相同的机制和流程。数据面在转发服务的请求前,调用policy的Check接口检查是否允许访问。Mixer根据配置将请求转发到对应的Adapter做对应检查,给代理返回允许访问还是拒绝。可以对接如 配额、授权、黑白名单等不同的控制后端,对服务间的访问进行可扩展的控制。
citadel是Istio的核心安全组件,提供了自动生成、分发、轮换与撤销秘钥和证书功能。Citadel一直监听kube-apiserver。以secret的形式对每个服务都生成证书秘钥,并在Pod创建时挂载到Pod上,代理容器使用这些文件来做服务身份认证,进而代替两端服务的双向TLS认证、通道加密、访问授权等安全问题功能,这样用户就不用再代码里面维护证书秘钥了。例如两个服务之间采用HTTP进行通信,通过配置即可对服务增加认证功能,双方的Envoy会建立双向认证的TLS通道,从而在服务间启用双向认证的HTTPS。
galley并不直接向数据面提供业务能力,而是在控制面上向其他组件提供支持。galley作为负责配置管理的组件,验证配置信息的格式和内容的正确性,并将这些配置信息提供给管理面的Pilot和Mixer服务使用,这样其他的管理组件只用和galley打交道,从而与底层平台解耦。在新的版本中galley的作用越来越重要。
sidecar-injector 是负责自动自动注入的组件,只要开启自动注入,在Pod创建时就会自动调用istio-sidecar-injector 向Pod中注入Sidecar 容器。
在kubernetes环境中,根据自动注入配置,Kube-apiserver 在拦截到Pod创建的请求时,会调用自动注入服务istio-sidecar-injector 生成Sidecar容器描述并将其插入原Pod的定义中,这样,在创建的Pod内除了包括业务容器,还包括Sidecar容器。这个注入过程对用户透明,用户使用原始的方式创建工作负载。
在很多和Istio相关的地方,会将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代理、熔断器、健康检查、流量拆分、灰度发布、故障注入等功能,istio描述的大部分自治能力最终都落实到Envoy的实现上。
在Istio中,规则被描述的对象都是被访问者,但是真正的规则执行位置,对于不同的类型的动作可能不同,可能在被访问服务的Sidecar拦截到Inbound流量时,或是在访问者的Sidecar拦截到outbound流量时执行,一般后者居多。当给一个服务定义流量规则时,所有访问该服务的Sidecar都收到规则,并且执行相同的治理逻辑,从而对目标服务执行一致的治理。下面列出常用的服务治理规则和其执行位置。
治理规则 | 治理位置:服务发起方 | 治理位置:服务发起方 |
---|---|---|
路由管理 | * | |
负载均衡 | * | |
调用链分析 | * | * |
服务认证 | * | * |
遥测数据 | * | * |
重试 | * | |
重写 | * | |
重定向 | * | |
鉴权 | * |
ingressgateway 就是入口处的Gateway,从网络外访问网格内的服务就是通过这个Gateway进行的。ingressgateway比较特别的是,是一个LoadBalance类型的Service,不同于其他服务组件只有一两个端口,ingressgateway开发了一组端口,这些就是网格内服务的外部访问端口。网格入口网关ingressgateway的负载和网格内的Sidecar是同样的执行体,也和网格内的其他Sidecar一样从Pilot接收流量规则并执行。因为入口处的流量都走这个服务,会有较大的并发可能出现流量峰值,所有需要评估流量来规划和实例数。Istio通过一个特有的资源对象Gateway来配置和对外的协议、端口等。
除了以“Istio” 为前缀的以上几个Istio自有组件,在集群中一般还安装了jaeger-agent、jaeger-collector、jaeger-query、Kiail、Prometheus、Tracing、ZIPkin组件,这些组件提供了Istio调用链、监控等功能,可以选择安装来完成完整的服务监控管理功能。