关键概念
微服务:
从结构上:将原有的从技术角度拆分的组件,升级为从业务角度拆分的独立运行的服务,这些服务具备各自实现平台,并且独自占有数据,在服务之间以智能端点和哑管道方式通信。
在工程上:从产品而非项目角度进行设计、强调迭代、自动化和面向故障的设计方法。
服务网格Service Mesh
一代 原始通信时代
最初的时候,服务处理除了需要实现业务功能,还需要处理网络通信面临的丢包、乱序、重试等流控问题。
二代 tcp时代
将流量控制问题下移到网络层实现。
三代 第一代微服务
分布式系统兴起,其特有的通信语义,如熔断策略、负载均衡、服务发现、认证和授权、quota限制,trace和监控等等。服务除了业务逻辑还需要实现这些通信语义
四代 第二代微服务
将分布式通信语义通过面向微服务的开发框架来实现。屏蔽了这些通信细节。
五代 第一代Service Mesh
为了解决微服务框架出现的问题
如框架定位追踪难度大、框架语言限制、框架和服务强关联导致框架升级服务被迫升级等
以Linkerd、Envoy、NginxMesh为代表的代理模式side car出现。将分布式服务通信抽象为单独一层,实现负载均衡、服务发现、认证授权、监控追踪、流量控制等
分布式系统需要的功能,作为服务对等的代理服务和服务部署在一起,接管服务流量,通过代理之间通信完成服务间通信。
六代 第二代Service Mesh
为五代的Service Mesh提供运维管理平台,单机代理通过控制面板交互进行网络拓扑策略更新和单机数据汇报。
主要代表为istio
服务网格:是一个基础设施层,用于处理服务间通信。保证请求在服务拓扑中可靠穿梭。通常是一系列轻量级网络代理,与应用程序部署在一起,但对其透明。
Service Mesh问题:
通过代理模式转发请求,一定程度降低通信系统性能,并增加系统资源开销
Service Mesh接管了网络流量,服务稳定性依赖于Service Mesh,并且运维和管理也是一个挑战
一、服务网格的历史
如上
istio
linkerd
二、服务网格的基本特性
连接:对网格内部服务之间调用所产生的流量进行智能管理,并以此为基础,为微服务部署、测试和升级等操作提供有力保障。
安全:为网格内部服务之间调用提供认证、加密和鉴权支持,在不侵入代码的情况下,加固现有服务,提高安全性
策略:在控制面板定制策略,并在服务中实施。
观察:对服务之间的调用进行跟踪和测量,获取服务状态信息。
三、istio基本介绍
3.1、istio核心组件及其功能
Istio总体来说分为两个部分:控制面和数据面
数据面:称为SideCar,通过注入方式和业务容器共存于一个pod中,劫持业务容器的流量,接受控制面组件管理,并输出日志、跟踪及监控数据。
控制面:管理istio所有功能。
3.1.1、Pilot
Pilot是Istio主要控制点,istio流量就是由Pilot管理的。
任务
从k8s或其他平台的注册中心获取服务信息,完成服务发现过程。
读取istio各项控制配置,进行转换之后,发送给数据面进行实施。
Pilot的配置内容会被转换为数据面能理解的格式,下发给数据面的SideCar。SideCar根据Pilot指令,将路由、服务、监听、集群等定义信息转换为本地配置,
完成控制行为落地。
工作流程
1、用户通过kubectl或istioctl或者api在kubernetes上创建CRD资源,对istio控制平面发出指令。
2、Pilot监听CRD的config、rbac、networking以及authentication资源,在检测到资源对象变更之后,针对其中涉及的服务,发出指令给对应服务Sidecar
3、Sidecar根据指令更新自身配置,根据配置修改通信行为。
3.1.2、Mixer(1.6后废弃)
主要职责:预检和汇报
工作流程
1、用户将Mixer配置发送到Kubernetes中
2、Mixer通过对Kubernetes资源的监听,获知配置变化
3、网格中的服务在每次调用之前,都向Mixer发出预检请求,查看调用是否允许执行。每次调用之后,发出报告,向Mixer汇报调用过程中产生监控跟踪数据。
3.1.3、Citadel
早期版本被称为istio-ca,主要用于证书管理。在集群中启用服务间间后,Citadel负责为集群中各个服务在统一CA的条件下生成证书,并下发给各个服务的SideCar,
服务之间TLS依赖这些证书完成校验过程。
3.1.4、Sidecar(Envoy)
Sidecar就是istio的数据面,负责控制面对网格控制的实际执行
Istio中默认的Sidecar是由Envoy派生出来的,理论上,只要支持Envoy的xDS协议,就可以替代Envoy来担当这一角色。
Istio默认实现中,利用istio-init初始化容器中的iptables指令,对所有pod的流量进行劫持,从而接管pod中应用通信过程。
原来通信方式:源容器-目标容器
现在通信方式:源容器-Sidecar-Sidecar-目标容器
3.2、核心配置对象
Istio在安装过程中会进行CRD初始化,在k8s集群中注册一系列的CRD,在注册成功后,建立一些基础对象,完成istio初始设置。
Istio资源分为三组进行管理,分别是networking.istio.io、config.istio.io以及authentication.istio.io
3.2.1、networking.istio.io
Istio的流量管理就是通过这一组对象完成的
在networking.istio.io的下属资源中,VirtualService是一个控制中心。功能是:定义一组条件,将符合该条件的流量按照在对象中配置的对应策略进行处理,然后
将路由转到匹配目标中
流量访问流程的几个关键对象
Gateway-VirtualService-tcp/tls/http Route-DestinationWeight-Subset:Port
1、Gateway
无论是内部访问还是通过ingress进行网格的外部流量,首先要经过设施都是Gateway。Gateway描述了边缘接入设备的概念,
其中包含对开放端口、主机名以及可能存在的TLS证书的定义。
网络边缘的ingress通过Istio Ingress Gateway Controller进入
网络内部服务互访,通过虚拟的mesh网关进行
Pilot会根据Gateway和主机名进行检索,如果存在对应的VirtualService,则交由VirtualService处理,如果不存在,则尝试调用Kubernetes Service,如果都不存在,
发送404错误。
2、VirtualService
VirtualService主要由以下部分组成
(1)Host:该对象所负责的主机名称,如果在k8s集群,可以是服务名
(2) Gateway:流量的来源网管 默认为mesh
(3) 路由对象:网格中的流量
3、TCP/TLS/HTTP Route
路由对象可以是HTTP、TLS、TCP中的一个,分别针对不同协议进行工作
每个路由对象都至少包含两个部分:匹配条件和目的路由
HTTP Route包含用于匹配的HTTPMatchRequest对象数组,用于描述目标服务的DestinationWeight对象,并且HTTPMatchRequest对象匹配条件
更丰富,还包含专属额外特性,如超时控制、重试、错误注入等。
4、DestinationWeight
指到某个目标的流量权重
5、Destination
目标对象由Subset和Port两个元素组成。Subset就是服务的一个子集,在k8s中代表使用标签选择器区分的不同pod。port代表的是服务的端口
3.2.2、config.istio.io
用于为Mixer组件提供配置。
3.2.2、config.istio.io
3.2.2、config.istio.io
用于为Mixer组件提供配置。
Role
Match
Action->Instance
Handler<- Template
Adapter
1、Rule
Rule对象是Mixer的入口,其中包含一个match成员和一个逻辑表达式,只有符合表达式判断的数据才会被交给Action处理。逻辑表达式的变量被称为
attribute,其中的内容来自Envoy提交的数据
2、Action
负责解决的问题:将符合入口标准的数据,在用什么方式加工之后,交给哪个适配器进行处理。
Action包含两个成员对象,一个是Instance,使用Template对接收到数据进行处理,一个是Handler,代表一个适配器示例,用于接受处理后的数据
3、Instance
主要用于为进入的数据选择一个模板,并在数据中抽取某些字段作为模板参数,传输给模板进行处理。
4、Adapter
Adpater在Istio中只被定义为一个行为规范,而一些必要的实例化数据是需要再次进行初始化的
5、Template
用于对接收到的数据进行再加工,使Envoy提供的原始数据转化为符合适配器输入要求的数据格式
6、Handler
用于对Adapter进行实例化
3.2.3、authentication.istio.io
用于定义认证策略
1、Policy
用于指定服务一级的认证策略,如果命名为default,则默认采用这个认证策略
由两个部分组成:策略目标和认证方法
策略目标包含服务名称(或主机名称)以及服务端口号
认证方法由两个可选部分组成,分别是用于设置服务间认证的peers子对象以及用于设置终端认证的origins子对象
2、MeshPolicy
只能被命名为default,代表所有网格内部应用默认认证策略,其他部分内容和Policy一致
3.2.4、rbac.istio.io
基于角色的访问控制系统,主要对象为ServiceRole和ServiceRoleBinding
1、ServiceRole
由一系列规则组成,每条规则对于一条权限,描述了权限对于服务、服务路径以及方法,还包含一组可以进行自定义的约束
2、ServiceRoleBinding
和Kubernetes的RBAC类似,用于将用户主体和ServiceRole绑定。
四、istio快速入门
部署好服务后,通过istioctl kube-inject -f xxx.yaml|kubectl apply -f
这样就讲istio-proxy注入到服务了,接着就可以进行流量管控了
接着创建目标规则和默认路由
创建DestinationRule对象,将服务分为两个版本v1和v2。提交到k8s集群
创建VirtualService对象,将流量转发到v2。提交到k8s集群
查看流量管理是否生效
五、用helm部署istio
六、istio常用功能
自动注入评估顺序
Pod注解-NeverInjectSelector-AlwaysInjectSelector-命名空间策略
后续基本都是操作配置的操作,就不记录了。
感觉这本书在深入这块还差很多,组件间的运行原理和工作方式等底层的技术都没怎么涉及,希望下一版能加入这些东西吧。