1 Istio介绍
1.1 Istio介绍
官方文档:https://istio.io/docs/concepts/what-is-istio/ 中文官方文档:https://istio.io/zh/docs/concepts/what-is-istio/ Github地址:https://github.com/istio/istio/releases
官当解释:
An open platform to connect, secure, control and observe services.
翻译过来,就是连接、安全加固、控制和观察服务的开放平台 。 开放平台就是指它本身是开源的,服务对应的是微服务,也可以粗略地理解为单个应用。
-
连接( Connect ):智能控制服务之间的调用流量,能够实现灰度升级、 AB 测试和 蓝绿 部署等功能
-
安全加固( Secure ):自动为服务之间的调用提供认证、授权和加密。
-
控制( Control ):应用用户定义的 policy ,保证资源在消费者中公平分配。
-
观察( Observe ):查看服务运行期间的各种数据,比如日志、监控和 tracing ,了解服务的运行情况。
Istio是 ServiceMesh 的产品化落地, 可以通过在现有 的 服务器新增部署边车代理 (sidecar-proxy),应用程序不用改代码 或者只需要改很少的代码,就能实现 如下 基础功能
-
帮助微服务之间建立连接,帮助研发团队更好的管理与监控微服务,并使得系统架构更加安全
-
帮助微服务分层解耦,解耦后的 proxy 层能够更加专注于提供基础架构能力,例如:
-
服务发现 (discovery)
-
负载均衡 (load balancing)
-
故障恢复 (failure recovery)
-
服务度量 (metrics)
-
服务监控 (monitoring)
-
A/B 测试 (A/B testing)
-
灰度发布 (canary limiting)
-
限流限速 (rate limiting)
-
访问控制 (access control)
-
身份认证 (end-to-end authentication)
-
1)服务注册和发现
RPC:RPC Remote Procedure Call )远程过程调用,简单的理解是一个节点请求另一个节点提供的服务
2)负载均衡
把前端的请求分发到后台多个服务器
3)故障恢复
出现故障具备自恢复的能力
4)服务度量
对于HTTP HTTP/2 和 GRPC 流量, Istio 生成以下指标:
-
请求计数( istio_requests_total ):这是一个用于累加每个由 Istio 代理所处理请求的COUNTER 指标。
-
请求持续时间( istio_request_duration_seconds ):这是一个用于测量请求的持续时间的
-
DISTRIBUTION指标。
-
请求大小( istio_request_bytes ):这是一个用于测量 HTTP 请求 body 大小的 DISTRIBUTION指标。
-
响应大小( istio_response_bytes ):这是一个用于测量 HTTP 响应 body 大小的 DISTRIBUTION指标。
对于TCP 流量, Istio 生成以下指标:
-
Tcp 发送字节数( istio_tcp_sent_bytes_total ):这是一个用于测量在 TCP 连接下响应期间发送的总字节数的 COUNTER 指标。
-
Tcp 接收字 节数( istio_tcp_received_bytes_total ):这是一个用于测量在 TCP 连接下请求期间接收的总字节数的 COUNTER 指标。
-
Tcp 打开连接数( istio_tcp_connections_opened_total ):这是一个用于累加每个打开连接的COUNTER 指标。
-
Tcp 关闭连接数 (istio_tcp_connections_closed_total) : 这是一个用于累加每个关闭连接的COUNTER 指标。
5)灰度发布
灰度发布也叫金丝雀发布,起源是,矿井工人发现,金丝雀对瓦斯气体很敏感,矿工会在下井之 前,先放一只金丝雀到井中,如果金丝雀不叫了,就代表瓦斯浓度高。
在灰度发布开始后,先启动一个新版本应用,但是并不直接将流量切过来,而是测试人员对新版本进行线上测试,启动的这个新版本应用,就是我们的金丝雀。如果没有问题,那么可以将少量的用户流量导入到新版本上,然后再对新版本做运行状态观察,收集各种运行时数据,如果此时对新旧版本做各种数据对比,就是所谓的 A/B 测试。
当确认新版本运行良好后,再逐步将更多的流量导入到新版本 上,在此期间,还可以不断地调整新旧两个版本的运行的服务器副本数量,以使得新版本能够承受越来越大的流量压力。直到将 100% 的流量都切换到新版本上,最后关闭剩下的老版本服务,完成灰度发布。
如果在灰度发布过程中(灰度期)发现了新版本有问题,就应该立即将流量切回老版本上,这样,就会将负面影响控制在最小范围内。
1.2 Istio核心特性
-
流控 (traffic management) 断路器(circuit breakers)、超时、重试、多路由规则、 AB 测试、灰度发布、按照百分比分配流量等。
-
安全 (security) 加密、身份认证、服务到服务的权限控制、K8S 里容器到容器的权限控制等。
-
可观察 (observability) 追踪、监控、数据收集,通过控制后台全面了解上行下行流量,服务链路情况,服务运行情况,系统性能情况,国内微服务架构体系,这一块做得比较缺乏。
-
平台无关系 (platform support) K8s,物理机,自己的虚机都没问题。
-
集成与定制 (integration and customization) 可定制化扩展功能。
1)断路器
示例1:举个生活中的例子 解释断路器
当电路发生故障或异常时,伴随着电流不断升高,并且升高的电流有可能能损坏电路中的某些重要器件,也有可能烧毁电路甚至造成火灾。若电路中正确地安置了保险丝,那么保险丝就会在电流异常升高到一定的高度和热度的时候,自身熔断切断电流,从而起到保护电路安全运行的作用。
断路器也称为 服务熔断,在多个服务调用的时候,服务 A 依赖服务 B ,服务 B 依赖服务 C ,如果服务C 响应时间过长或者不可用,则会让服务 B 占用太多系统资源,而服务 A 也依赖服 B ,同时也在占用大量的系统资源,造成系统雪崩的情况出现。 Istio 断路器通过网格中的边车对流量进行拦截判断处理,避免了在代码中侵入控制逻辑,非常方便的就实服务熔断的能力。
在微服务架构中,在高并发情况下,如果请求数量达到一定极限(可以自己设置阈值),超出了设置的阈值,断路器会自动开启服务保护功能,然后通过服务降级的方式返回一个友好的提示给客户端。假设当10个请求中,有10%失败时,熔断器就会打开,此时再调用此服务,将会直接返回失败,不再调远程服务。直到10s钟之后,重新检测该触发条件,判断是否把熔断器关闭,或者继续打开。
示例2:服务降级(提高用户体验效果)
比如电商平台,在针对618、双11的时候会有一些秒杀场景,秒杀的时候请求量大,可能会返回报错标志“当前请求人数多,请稍后重试”等,如果使用服务降级,无法提供服务的时候,消费者会调用降级的操作,返回服务不可用等信息,或者返回提前准备好的静态页面写好的信息。
2)超时
什么时候需要用到超时?
在生产环境中经常会碰到由于调用方等待下游的响应过长,堆积大量的请求阻塞了自身服务,造成雪崩的情况,通过超时处理来避免由于无限期等待造成的故障,进而增强服务的可用性。
示例:
-
nginx服务设置了超时时间为 3 秒,如果超出这个时间就不在等待,返回超时错误
-
httpd服务设置了响应时间延迟 5 秒,任何请求都需要等待 5 秒后才能返回
-
client通过访问 nginx 服务去反向代理 httpd 服务,由于 httpd 服务需要 5 秒后才能返回,但nginx 服务只等待 3 秒,所以客户端会提示超时错误。
3)重试
istio 重试机制就是如果调用服务失败, Envoy 代理尝试连接服务的最大次数。而默认情况下,Envoy 代理在失败后并不会尝试重新连接服务 。
示例:
客户端调用nginx,nginx 将请求转发给 tomcat 。 tomcat 通过故障注入而中止对外服务, nginx设置如果访问 tomcat 失败则会重试 3 次。
4)多路由规则
-
HTTP 重定向(HTTPRedirect)
-
HTTP 重写(HTTPRewrite)
-
HTTP 重试(HTTPRetry)
-
HTTP 故障注入(HTTPFaultInjection)
-
HTTP 跨域资源共享(CorsPolicy)
2 Istio架构
istio服务网格从逻辑上分为数据平面和控制平面。
数据平面由一组以Sidecar方式部署的智能代理(Envoy+Polit-agent)组成。这些代理承载并控制微服务之间的所有网络通信,管理入口和出口流量,类似于一线员工。 Sidecar 一般和业务容器绑定在一起(在Kubernets中以自动注入的方式注入到到业务pod中),来劫持业务应用容器的流量,并接受控制面组件的控制,同时会向控制面输出日志、跟踪及监控数据。
Envoy 和 pilot-agent 打在同一个镜像中,即sidecar Proxy。
控制平面负责管理和配置代理来路由流量。istio1.5+中使用了一个全新的部署模式,重建了控制平面,将原有的多个组件整合为一个单体结构istiod,这个组件是控制平面的核心,管理Istio的所有功能,主要包括Pilot、Mixer、Citadel等服务组件。
istiod是新版本中最大的变化,以一个单体组件替代了原有的架构,降低了复杂度和维护难度,但原有的多组件并不是被完全移除,而是在重构后以模块的形式整合在一起组成了istiod。
结合下图我们来理解Istio的各组件的功能及相互之间的协作方式。
1)自动注入:在创建应用程序时自动注入 Sidecar代理Envoy程序。在 Kubernetes中创建 Pod时,Kube-apiserver调用控制面组件的 Sidecar-Injector服务,自动修改应用程序的描述信息并注入Sidecar。在真正创建Pod时,在创建业务容器的Pod中同时创建Sidecar容器。
2)流量拦截:在Pod初始化时设置iptables 规则,基于配置的iptables规则拦截业务容器的Inbound流量和Outbound流量到Sidecar上。而应用程序感知不到Sidecar的存在,还以原本的方式 进行互相访问。上图中,流出frontend服务的流量会被 frontend服务侧的 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上执行。
3 Istio组件详解
Istio服务组件 有很多 ,从上面的流程中基本能看出每个组件如何协作的,下面具体讲解每个组件的具体用途和功能。
3.1Pilot
Pilot是 Istio 的主要控制组件,下发指令控制客户端。在整个系统中, Pilot 完成以下任务:
-
从 Kubernetes 或者其他平台的注册中心获取服务信息,完成服务发现过程。
-
读取 Istio 的各项控制配置,在进行转换之后,将其发给数据面进行实施。
Pilot 将配置内容下发给数据面的 Envoy,Envoy 根据 Pilot 指令,将路由、服务、监听、集群等定义信息转换为本地配置,完成控制行为的落地。
-
Pilot为Envoy提供服务发现
-
提供流量管理功能(例如,A/B 测试、金丝雀发布等)以及弹性功能(超时、重试、熔断器等);
-
生成envoy配置
-
启动envoy
-
监控并管理envoy的运行状况,比如envoy出错时pilot-agent负责重启envoy,或者envoy配置变更后reload envoy
3.2 Envoy
Envoy是用 C++ 开发的高性能代理,用于协调服务网格中所有服务的入站和出站流量。
Envoy有许多强大的功能,例如:
-
动态服务发现
-
负载均衡
-
TLS终端
-
HTTP/2与gRPC代理
-
断路器
-
健康检查
-
流量拆分
-
灰度发布
-
1)Istio中 Envoy 与服务关系
为了便于理解Istio 中 Envoy 与服务的关系,下图为 Envoy 的拓扑图,如图所示:
Envoy和 Service A 同属于一个 Pod ,共享网络和命名空间 Envoy 代理进出 Pod A 的流量,并将流量按照外部请求的规则作用于 Service A 中。
2)Pilot-agent介绍
-
Envoy不直接跟k8s交互,通过 pilot-agent管理的
-
Pilot-agent进程根据K8S APIserver中的配置信息生成Envoy的配置文件,并负责启动Envoy进程。
-
Envoy由Pilot-agent进程启动,启动后,Envoy读取Pilot-agent为它生成的配置文件,然后根据该文件的配置获取到Pilot的地址,通过数据面从pilot拉取动态配置信息,包括路由(route),监听器(listener),服务集群(cluster)和服务端点(endpoint)。
3.3 Citadel
负责处理系统上不同服务之间的TLS通信。 Citadel充当证书颁发机构(CA),并生成证书以允许在数据平面中进行安全的mTLS通信。
Citadel是 Istio的核心安全组件,提供了自动生 成、分发、轮换与撤销密钥和证书功能。Citadel一直监听 Kube- apiserver,以 Secret的形式为每个服务都生成证书密钥,并在Pod创建时挂载到Pod上,代理容器使用这些文件来做服务身份认证,进而代 理两端服务实现双向TLS认证、通道加密、访问授权等安全功能。如图 所示,frontend 服 务对 forecast 服务的访问用到了HTTP方式,通过配置即可对服务增加认证功能,双方的Envoy会建立双向认证的TLS通道,从而在服务间启用双向认证的HTTPS。
3.4 Galley
Galley是istio的配置验证、提取、处理和分发的组件。Galley是提供配置管理的服务。实现原理是通过k8s提供的ValidatingWebhook对配置进行验证。
Galley使Istio可以与Kubernetes之外的其他环境一起工作,因为它可以将不同的配置数据转换为Istio可以理解的通用格式。
3.5 Ingressgateway
Ingressgateway 就是入口处的 Gateway,从网格外访问网格内的服务就是通过这个Gateway进行的。istio-ingressgateway是一个Loadbalancer类型的Service,不同于其他服务组件只有一两个端 口,istio-ingressgateway 开放了一组端口。
这些就是网格内服务的外部访问端口。如下图所示,网格入口网关istio-ingressgateway的负载和网格内的Sidecar是同样的执行流程,也和网格内的其他 Sidecar一样从 Pilot处接收流量规则并执行。
3.6 Sidecar injector
Sidecar-injector是负责自动注入的组件,只要开启了自动注 入,在Pod创建时就会自动调用istio-sidecar-injector向Pod中注入Sidecar 容器。
在 Kubernetes环境下,根据自动注入配置,Kube-apiserver在拦截到 Pod创建的请求时,会调用自动注入服务 istio-sidecar-injector 生成 Sidecar 容器的描述并将其插入原 Pod的定义中,这样,在创建的 Pod 内除了包括业务容器,还包括 Sidecar容器,这个注入过程对用户透明。
3.7 其他组件
除了以”istio“ 为前缀的 Istio 自有组件,在集群中一般还安装 Jaeger agent 、 Jaeger-collector 、 Jaeger-query 、 Kiali 、 Prometheus 、 Grafana 、 Tracing 、 Zipkin 等组件,这些组件提供了 Istio 的调用链、监控等功能,可以选择安装来完成完整的服务监控管理功能。
4 在Kubernetes集群中安装Istio
4.1 准备部署环境
1)下载
cd /root/ && wget https://github.com/istio/istio/releases/download/1.11.4/istio-1.11.4-linux-amd64.tar.gz
2)解压
tar -zxvf istio-1.11.4-linux-amd64.tar.gz && mv istio-1.11.4 /usr/local/kubernetes/
3)添加环境变量
export PATH=/usr/local/kubernetes/istio-1.11.4/bin:$PATH
4)移动客户端文件
cp -ar /usr/local/kubernetes/istio-1.11.4/bin/istioctl /usr/local/bin/
4.2 安装Istio
1)执行安装
istioctl install --set profile=demo -y
注意:执行安装过程中出现失败情况,一般都是由于网络拉取不到镜像 拉取到镜像后服务无法启动,一般是和K8S环境有关,建议使用kubeadm方式安装实验
2)查看部署情况
kubectl get pods -n istio-system -o wide
3)卸载Istio集群(需要时才操作)
istioctl manifest generate --set profile=demo | kubectl delete -f -
5 Istio部署演示demo-bookinfo
5.1 功能介绍
该应用由四个单独的微服务构成,这个应用模仿在线书店的一个分类,显示一本书的信息,页面上会显示一本书的描述,书籍的细节(ISBN、页数等),以及关于这本书的一些评论。
Bookinfo应用分为四个单独的微服务
-
productpage这个微服务会调用details和reviews两个微服务,用来生成页面;
-
details这个微服务中包含了书籍的信息;
-
reviews这个微服务中包含了书籍相关的评论,它还会调用ratings微服务;
-
ratings这个微服务中包含了由书籍评价组成的评级信息。
reviews微服务有3个版本
-
v1版本不会调用ratings服务;
-
v2版本会调用ratings服务,并使用1到5个黑色星形图标来显示评分信息;
-
v3版本会调用ratings服务,并使用1到5个红色星形图标来显示评分信息。
Bookinfo应用中的几个微服务是由不同的语言编写的。这些服务对istio并无依赖,但是构成了一个有代表性的服务网格的例子:它由多个服务、多个语言构成,并且reviews服务具有多个版本。
5.2 部署应用
要在Istio中运行这一应用,无需对应用自身做出任何改变。 只要简单的在 Istio 环境中对服务进行配置和运行,具体一点说就是把 Envoy sidecar 注入到每个服务之中。 最终的部署结果将如下图所示:
所有的微服务都和Envoy sidecar集成在一起,被集成服务所有的出入流量都被envoy sidecar 所劫持,这样就为外部控制准备了所需的 Hook,然后就可以利用Istio控制平面为应用提供服务路由、遥测数据收集以及策略实施等功能。
1)创建标签绑定命名空间
kubectl label namespace default istio-injection=enabled
2)部署应用
因为属于istio的demo实例,所以在istio文件夹中可以找到对应的yaml文件
kubectl apply -f /usr/local/kubernetes/istio-1.11.4/samples/bookinfo/platform/kube/bookinfo.yaml
查看部署情况
kubectl get deploy,pods,svc -o wide
确认 Bookinfo 应用是否正在运行,在某个Pod中用curl命令对应用发送请求,例如ratings:
kubectl exec -it $(kubectl get pod -l app=ratings -o jsonpath='{.items[0].metadata.name}') -c ratings -- curl productpage:9080/productpage | grep -o "<title>.*</title>"
3)部署网关
kubectl apply -f /usr/local/kubernetes/istio-1.11.4/samples/bookinfo/networking/bookinfo-gateway.yaml
查询网关
kubectl get virtualservices,gateway
4)查询ingress IP和端口
执行如下指令,明确自身 Kubernetes 集群环境支持外部负载均衡:
kubectl get svc istio-ingressgateway -n istio-system
如果EXTERNAL-IP值已设置,说明环境正在使用外部负载均衡,可以用其为ingress gateway 提供服务。 如果EXTERNAL-IP值为<none>(或持续显示<pending>), 说明环境没有提供外部负载均衡,无法使用ingress gateway。在这种情况下,可以使用服务的NodePort访问网关。
5)访问测试
http://NodeIP:port/productpage
6)扩展外部IP-extertal-IP
修改svc配置
kubectl edit svc istio-ingressgateway -n istio-system
增加以下字段
查看istio-ingressgateway的svc
kubectl get svc istio-ingressgateway -n istio-system
访问测试
http://NodeIP/productpage
5.3 卸载应用
可以使用下面的命令来完成应用的删除和清理了:
-
删除路由规则,并销毁应用的 Pod
sh /usr/local/kubernetes/istio-1.11.4/samples/bookinfo/platform/kube/cleanup.sh
-
确认应用已经关闭
kubectl get virtualservices,destinationrules,gateway,pods,svc
6 Istio实现灰度发布
6.1 灰度发布介绍
灰度发布也叫金丝雀部署,是指通过控制流量的比例,实现新老版本的逐步更替。比如对于服务 A 有 version1 、 version2 两个版本 当前两个版本同时部署,但是 version1 比例90% version2 比例 10% ,看运行效果,如果效果好逐步调整流量占比 80 20 7030 ·····10 90 0 100 ,最终 version1 版本下线。
灰度发布的特点
-
新老版本共存
-
可以实时根据反馈动态调整占比
-
理论上不存在服务完全宕机的情况
-
适合于服务的平滑升级与动态更新
6.2 实现灰度发布
1)创建演示环境
mkdir -p /opt/k8s-cfg/istio/
1)创建Deploy文件
cat <<EOF> /opt/k8s-cfg/istio/canary-deploy.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: appv1
labels:
app: v1
spec:
replicas: 1
selector:
matchLabels:
app: v1
apply: canary
template:
metadata:
labels:
app: v1
apply: canary
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: appv2
labels:
app: v2
spec:
replicas: 1
selector:
matchLabels:
app: v2
apply: canary
template:
metadata:
labels:
app: v2
apply: canary
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
EOF
kubectl apply -f /opt/k8s-cfg/istio/canary-deploy.yaml
登录到容器内修改下index.html访问文件,以便后续测试
kubectl exec -it appv1-6bcc5579f7-9smts -c nginx -- /bin/bash
echo v1 > /usr/share/nginx/html/index.html
cat /usr/share/nginx/html/index.html
2)创建Service文件
cat <<EOF> /opt/k8s-cfg/istio/canary-service.yaml
apiVersion: v1
kind: Service
metadata:
name: canary
labels:
apply: canary
spec:
selector:
apply: canary
ports:
- protocol: TCP
port: 80
targetPort: 80
EOF
kubectl apply -f /opt/k8s-cfg/istio/canary-service.yaml
3)创建Gateway
cat <<EOF> /opt/k8s-cfg/istio/canary-gateway.yaml
apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
name: canary-gateway
spec:
selector:
istio: ingressgateway
servers:
- port:
number: 80
name: http
protocol: HTTP
hosts:
- "*"
EOF
kubectl apply -f /opt/k8s-cfg/istio/canary-gateway.yaml
4)创建Virtualservice
cat <<EOF> /opt/k8s-cfg/istio/canary-virtual.yaml
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: canary
spec:
hosts:
- "*"
gateways:
- canary-gateway
http:
- route:
- destination:
host: canary.default.svc.cluster.local
subset: v1
weight: 90
- destination:
host: canary.default.svc.cluster.local
subset: v2
weight: 10
---
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
name: canary
spec:
host: canary.default.svc.cluster.local
subsets:
- name: v1
labels:
app: v1
- name: v2
labels:
app: v2
EOF
kubectl apply -f /opt/k8s-cfg/istio/canary-virtual.yaml
5)查看部署情况
kubectl get virtualservices,destinationrules,gateway,pods,svc
6)查看演示效果
查看istio-ingressgateway的svc
kubectl get svc istio-ingressgateway -n istio-system
for i in `seq 1 100`; do curl 192.168.5.3:31817 ;done > 1.txt
7 Istio核心资源解读
7.1 Gateway
在Kubernetes 环境中, Ingress controller 用于管理进入集群的流量。在 Istio 服务网格中 Istio Ingress Gateway 承担相应的角色,它使用新的配置模型( Gateway 和 VirtualServices )完成流量管理的功能。通过下图做一个总的描述。
-
用户向某端口发出请求
-
负载均衡器监听端口,并将请求转发到集群中的某个节点上。 Istio Ingress Gateway Service会监听集群节点端口的请求
-
Istio Ingress Gateway Service 将请求交给 Istio Ingress Gateway Pod 处理。IngressGateway Pod 通过 Gateway 和 VirtualService 配置规则处理请求。其中, Gateway 用来配置端口、协议和证书; VirtualService 用来配置一些路由信息(找到请求对应处理的服务 App Service
-
Istio Ingress Gateway Pod 将请求转给 App Service
-
最终的请求会交给 App Service 关联的 App Deployment 处理
apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
name: canary-gateway
spec:
selector:
istio: ingressgateway
servers:
- port:
number: 80
name: http
protocol: HTTP
hosts:
- "*"
EOF
网关是一个运行在网格边缘的负载均衡器,用于接收传入或传出的 HTTP/TCP 连接。 主要工作是接受外部请求, 把请求 转发到内部服务 。 网格边缘的 Ingress 流量,会通过对应的 Istio IngressGateway Controller 进入 到集群内部 。
在上面 这个 yaml 里我们配置了一个监听 80 端口的入口网关,它会将 80 端口的 http 流量导入到集群内对应的 Virtual Service 上 。
注意:
hosts:
- "*"
表示通配符, 通过任何域名都可以访问
7.2 VirtualService
VirtualService是 Istio 流量治理的一个核心配置,可以说是 Istio 流量治理中最重要、最复杂的。VirtualService 在形式上表示一个虚拟服务,将满足条件的流量都转发到对应的服务后端,这个服务后端可以是一个服务,也可以是在 DestinationRule 中定义的服务的子集。
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: canary
spec:
hosts:
- "*"
gateways:
- canary-gateway
http:
- route:
- destination:
host: canary.default.svc.cluster.local
subset: v1
weight: 90
- destination:
host: canary.default.svc.cluster.local
subset: v2
weight: 10
这个虚拟服务会收到上一个gateway 中所有 80 端口来的 http 流量。
VirtualService主要由以下部分组成:
-
hosts
-
Gateway
-
路由
hosts字段列出了 virtual service 的 虚拟 主机。它是客户端向服务发送请求时使用的一个或多个地址,通过该字段提供的地址访问 virtual service ,进而访问后端服务。在集群内部 网格内 使用时通常与 kubernetes 的 Service 同 名 ;当需要在集群外部 网格外 访问时,该字段为 gateway 请求的地址,即与 gateway 的 hosts 字段相同。
hosts:
- reviews
virtual service的主机名可以是 IP 地址、 DNS 名称,也可以是短名称 (例如 Kubernetes 服务短名称),该名称会被隐式或显式解析为全限定域名(FQDN),具体取决于 istio 依赖的平台。可以使用前缀通配符("*")为所有匹配的服务创建一组路由规则。 virtual service 的 hosts 不一定是 Istio 服务注册表的一部分,它们只是虚拟目的地,允许用户为网格无法路由到的虚拟主机建立流量模型。
virtual service 的 hosts 短域名在解析为完整的域名时,补齐的 namespace 是 VirtualService 所在的命名空间,而非 Service 所在的命名空间。如上例的 hosts 会被解析为:reviews.default.svc.cluster.l ocal 。
hosts:
- "*"
# *表示通配符,任何域名都可以
7.3 virtualservice 配置路由规则
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: reviews
spec:
hosts:
- reviews
http:
- match:
- headers:
end user:
exact: jason
route:
- destination:
host: reviews
subset: v2
- route:
- destination:
host: reviews
subset: v3
在http 字段包含了虚拟服务的路由规则,用来描述匹配条件和路由行为,它们把 HTTP/1.1 、HTTP2 和 gRPC 等流量发送到 hosts 字段指定的目标 。
示例中的第一个路由规则有一个条件,以match 字段开始 。 此路由 接收 来自 ”jason“ 用户的所有请求 ,把请求发送到 destination 指定 的 v 2 子集 。
1)路由规则优先级:
在上面例子中,不满足第一个路由规则的流量均流向一个默认的目标,该目标在第二条规则中指定。因此,第二条规则没有 match 条件,直接将流量导向 v3 子集。
2)多路由规则解读:
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: bookinfo
spec:
hosts:
- bookinfo.com
http:
- match:
- uri:
prefix: /reviews
route:
- destination:
host: reviews
- match:
- uri:
prefix: /ratings
route:
- destination:
host: ratings
路由规则是将特定流量子集路由到指定目标地址的工具。可以在流量端口、header 字段、 URI 等内容上设置匹配条件。例如, 上面 这个 虚拟服务让用户发送请求到两个独立的服务: ratings 和reviews 相当于访问 http://bookinfo.com/ ratings 和 http://bookinfo.com/reviews 虚拟服务规则根据请求的 URI 把请求路由到特定的目标地址。
路由的destination 字段指定了匹配条件的流量的实际地址。与 virtual service 的主机不同,该host 必须是存在于 istio 的服务注册表 如 kubernetes services consul services 等 中的真实目的地或由 ServiceEntries 声明的 hosts ,否则 Envoy 不知道应该将流量发送到哪里。它可以是一个带代理的网格服务或使用 s ervice entry 添加的非网格服务。在 kubernetes 作为平台的情况下, host 表示名为kubernetes 的 service 名称:
- destination:
host: canary.default.svc.cluster.local
subset: v1
weight: 90
7.4 DestinationRule
destinationrule 是 istio 流量路由功能的重要组成部分。一个 virtual service 可以看作是如何将流量分发给特定的目的地,然后调用 destination rule 来配置分发到该目的地的流量。 destinationrule 在 virtual service 的路由规则之后起作用 即在 virtual service 的 math -->route destination 之后起作用,此时流量已经分发到真实的service 上 ),应用于真实的目的地。
可以使用destination rule 来指定命名的服务子集,例如根据版本对 服务的实例进行分组,然后通过 virtual service 的路由规则中的服务子集将控制流量分发到不同服务的实例中。
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
name: canary
spec:
host: canary.default.svc.cluster.local
subsets:
- name: v1
labels:
app: v1
- name: v2
labels:
app: v2
在虚拟服务中使用Hosts 配置默认绑定的路由地址,用 http.route 字段,设置 http 进入的路由地址,可以看到, 上面 导入到了目标规则为 v 1 和 v 2 的子集 。
v1 子集对应的是 具有如下标签的 pod
selector:
matchLabels:
app: v1
流量控制流程:
Gateway-->VirtaulService -->TCP/HTTP Router -->DestinationWeight -->Subset:Port
8 Istio核心功能演示
8.1 断路器
官网介绍:https://istio.io/latest/zh/docs/tasks/traffic-management/circuit-breaking/
断路器是创建弹性微服务应用程序的重要模式。断路器使应用程序可以适应网络故障和延迟等网络不良影响。
1)创建熔断器后端服务器
kubectl apply -f /usr/local/kubernetes/istio-1.11.4/samples/httpbin/httpbin.yaml
查看
kubectl get pods,svc,sa
2)创建DestinationRule规则
cat <<EOF> httpbin-DR.yaml
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
name: httpbin
spec:
host: httpbin
trafficPolicy:
connectionPool:
# 连接池( TCP | HTTP )配置,例如:连接数、并发请求等
tcp:
maxConnections: 1
# TCP 连接池中的最大连接请求数,当超过这个值,会返回 503 代码 。如两个请求过来,就会有一个请求返回 503
http:
http1MaxPendingRequests: 1
# 连接到目标主机的最大挂起请求数 ,也就是待处理请求数 。 这里的目标指的是 virtualservice 路由规则中配置的destination 。
maxRequestsPerConnection: 1
# 连接池中每个连接最多处理 1 个请求后就关闭,并根据需要重新创建连接池中的连接
outlierDetection:
# 异常检测配置,传统意义上的熔断配置,即对规定时间内服务错误数的监测
consecutiveGatewayErrors: 1
# 连续错误数 1 ,即连续返回 502-504 状态码的 Http 请求错误数
interval: 1s
# 错误异常的扫描间隔 1s ,即在 interval 1s )内连续发生 consecutiveGatewayErrors 1 )个错误,则触发服务熔断
baseEjectionTime: 3m
# 基本驱逐时间 3 分钟,实际驱逐时间为 baseEjectionTime* 驱逐次数
maxEjectionPercent: 100
# 最大驱逐百分比 100%
EOF
kubectl apply -f httpbin-DR.yaml
查看
kubectl get destinationrule
3)添加客户端访问 httpbin 服务
创建一个客户端以将流量发送给httpbin 服务。该客户端是一个简单的负载测试客户端, Fortio 可以控制连接数,并发数和 HTTP 调用延迟。使用此客户端来 跳闸 在 DestinationRule 中设置的断路器策略。
kubectl apply -f /usr/local/kubernetes/istio-1.11.4/samples/httpbin/sample-client/fortio-deploy.yaml
测试访问:
kubectl exec -it fortio-deploy-5bb66f84-xtwsn -c fortio -- /usr/bin/fortio curl http://httpbin:8000/get
4)触发断路器
在DestinationRule 设置中,指定了 maxConnect ions: 1 和 http1MaxPendingRequests: 1 。这些规则表明,如果超过一个以上的连接并发请求,则 istio proxy 在为进一步的请求和连接打开路由时,应该会看到下面的情况 。
以两个并发连接(-c 2 )和发送 20 个请求(-n 20 )调用服务
kubectl exec -it fortio-deploy-5bb66f84-xtwsn -c fortio -- /usr/bin/fortio load -c 2 -qps 0 -n 20 -loglevel Warning http://httpbin:8000/get
8.2 超时
在生产环境中经常会碰到由于调用方等待下游的响应过长,堆积大量的请求阻塞了自身服务,造成雪崩的情况,通过通过超时处理来避免由于无限期等待造成的故障,进而增强服务的可用性 Istio 使用虚拟服务来优雅实现超时处理。
下面例子模拟客户端调用 nginx,nginx 将请求转发给 tomcat 。 nginx 服务设置了超时时间为 2秒,如果超出这个时间就不在等待,返回超时错误 。 tomcat 服务设置了响应时间延迟 10 秒,任何请求都需要等待 10 秒后才能返回 。 client 通过访问 nginx 服务去反向代理 tomcat 服务,由于 tomcat 服务需要 10 秒后才能返回,但 nginx 服务只等待 2 秒,所以客户端会提示超时错误 。
1)创建演示环境
mkdir -p /opt/k8s-cfg/istio/timeout
2)创建后端服务
cat <<EOF> /opt/k8s-cfg/istio/timeout/nginx-tomcat-deploy.yaml
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-tomcat
labels:
server: nginx
app: web
spec:
replicas: 1
selector:
matchLabels:
server: nginx
app: web
template:
metadata:
name: nginx
labels:
server: nginx
app: web
spec:
containers:
- name: nginx
image: nginx:latest
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: tomcat
labels:
server: tomcat
app: web
spec:
replicas: 1
selector:
matchLabels:
server: tomcat
app: web
template:
metadata:
name: tomcat
labels:
server: tomcat
app: web
spec:
containers:
- name: tomcat
image: docker.io/kubeguide/tomcat-app:v1
EOF
kubectl apply -f /opt/k8s-cfg/istio/timeout/nginx-tomcat-deploy.yaml
cat <<EOF> /opt/k8s-cfg/istio/timeout/nginx-tomcat-svc.yaml
---
apiVersion: v1
kind: Service
metadata:
name: nginx-svc
spec:
selector:
server: nginx
ports:
- name: http
port: 80
targetPort: 80
protocol: TCP
---
apiVersion: v1
kind: Service
metadata:
name: tomcat-svc
spec:
selector:
server: tomcat
ports:
- name: http
port: 8080
targetPort: 8080
protocol: TCP
EOF
kubectl apply -f /opt/k8s-cfg/istio/timeout/nginx-tomcat-svc.yaml
kubectl get pods,svc -o wide
3)创建VirtualService路由规则
cat <<EOF> /opt/k8s-cfg/istio/timeout/virtual-nginx-tomcat.yaml
---
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: nginx-vs
spec:
hosts:
- nginx-svc
http:
- route:
- destination:
host: nginx-svc
timeout: 2s
---
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: tomcat-vs
spec:
hosts:
- tomcat-svc
http:
- fault:
delay:
percentage:
value: 100
fixedDelay: 10s
route:
- destination:
host: tomcat-svc
EOF
kubectl apply -f /opt/k8s-cfg/istio/timeout/virtual-nginx-tomcat.yaml
4 )设置反向代理
登录到pod容器内
kubectl exec -it nginx-tomcat-c9d66cc79-hk6sp -c nginx -- /bin/bash
# 安装vim编辑器
apt-get update
apt-get -y install vim
vim /etc/nginx/conf.d/default.conf
proxy_pass http://tomcat-svc:8080;
proxy_http_version 1.1;
# 更新配置文件
nginx -s reload
5)验证超时
创建测试容器
kubectl run busybox --image busybox:1.28 --restart=Never --rm -it busybox -- sh
time wget -q -O - http://nginx-svc
while true;do wget -q -O - http://nginx-svc; done
每隔2 秒,由于 nginx 服务的超时时间到了而 tomcat 未有响应,则提示返回超时错误。
验证故障注入效果,执行如下语句: