SpringCloud服务治理（二十四）ISTIO服务治理(下) productpage-gateway，让produc

productpage-gateway，让productpage.bookinfo域名的流量进入网格内部

在这里插入图片描述

现在是建立了一个gw

在这里插入图片描述

这个域名进入网格内部

在这里插入图片描述

建立virtualservice，绑定这个gateway

在这里插入图片描述

现在是有一条规则，允许这个gateway来的流量访问hosts

在这里插入图片描述

如果不想review是随机的，想要只看到review3，那就需要在后面加配置

在这里插入图片描述

现在是product service去访问了review服务

在这里插入图片描述

首先需要建立virtualservice，所有访问reviews的流量都走下面路由

在这里插入图片描述

创建一个destination-rule

在这里插入图片描述

建立vs，访问review服务就转到v3版本

在这里插入图片描述

reviews是没有gateway的

在这里插入图片描述

现在刷新就全部是红星的v3版本了

在这里插入图片描述

不考虑时效性可以这么做

在这里插入图片描述

现在就访问不到v3了

在这里插入图片描述

假如v2版本是多个实例会如何调用

在这里插入图片描述

envoy的lbs，rds，cds，eds，虽然有三个副本，但是eds的时候只选择其中一个

在这里插入图片描述

流量在这里就route里已经分配好了，就跟后面有多少副本就没关系了

在这里插入图片描述

回归到一个副本

在这里插入图片描述

现在要实现下面的常见，bookinfo.com大服务访问review就访问review服务

在这里插入图片描述

首先要允许这个新域名进入服务网格，就需要gateway

在这里插入图片描述

这里其实是一个数组

在这里插入图片描述

两个域名现在都允许进入网格内部

在这里插入图片描述

根据path路径进行转发，还需要定义规则，一般绝大多数规则都是在virtualservice里定义的

在这里插入图片描述

从gateway来的流量，是访问bookinfo.com这个域名的流量按照下面的规则转发

在这里插入图片描述

匹配uri,如果是/productpage开头的就路由到productpage上去，如果要细分还可以转发给哪个版本什么的流量

在这里插入图片描述

从productpage-gateway的转发的bookinfo.com流量转发给bookinfo

在这里插入图片描述

这里就可以访问

在这里插入图片描述

访问ratings的9080 是可以访问到的

在这里插入图片描述

样式访问不到了

在这里插入图片描述

需要加个下划线

在这里插入图片描述

现在就可以了

在这里插入图片描述

访问productpage这个路由会自动帮你拼接到后端对应的service监听端口/路由

在这里插入图片描述

所以这就是为什么要加static

在这里插入图片描述

如果服务只有一个端口其实可以不用写

在这里插入图片描述

如果一个服务有多个端口，可以指向其中的一个

在这里插入图片描述

如果不想ratings区访问ratings，想rate去访问ratings，在原来基础上加个rewrite，匹配路径就换了

在这里插入图片描述

其实即使访问这个

在这里插入图片描述

如果说想要一个用户专门访问一个版本，就可以做灰度发布，登陆里就会在headler里填写一堆数据，kv对

在这里插入图片描述

可以加一个default-route,match匹配不到就走默认路由

在这里插入图片描述

登陆之后会有一个header信息

在这里插入图片描述

先暂时不管灰度发布，先看一下下destination-rule

在这里插入图片描述

之前把v2版本的review换成了三个副本，那么10%的流量到后端后该如何去转发，那么这个策略就是在destination-rule里加的

在这里插入图片描述

默认规则是随机random

在这里插入图片描述

使用https，建议是放在ingress这一层（一般用公有云的lb，比如slb，clb），还可以放在istio侧使用证书

在这里插入图片描述

我们使用istio做灰度发布，也是用header来转发的

在这里插入图片描述

登陆之后，都会去带上这个信息

在这里插入图片描述

访问reviews服务的时候

在这里插入图片描述

假如现在登陆的用户是路飞，想要让他只访问review2，其他的转发到review3上

在这里插入图片描述

那就是要写virtualservice规则。如果headers出现key是end-user里有）exact准确的就是完全等于）路飞的话就匹配到下面的路由上

在这里插入图片描述

否则剩下的就访问下面的

在这里插入图片描述

现在admin就只能分发到v3，是红星

在这里插入图片描述

登陆一下路飞

在这里插入图片描述

只能访问到v2版本

在这里插入图片描述

这里还支持以什么开头，甚至支持正则表达式

在这里插入图片描述

virtualservice的uri看到的，也是用的准确匹配，也可以前缀，或者正则表达式

在这里插入图片描述

还支持scheme，http或者https

在这里插入图片描述

get还是post方法

在这里插入图片描述

这个是httpv2的协议

在这里插入图片描述

headers就是之前用的，也支持正则表达式

在这里插入图片描述

还支持查询参数

在这里插入图片描述

withoutheaders没有这些信息

在这里插入图片描述

不是路飞这个用户的就访问这里，是路飞这个用户的就访问下面

在这里插入图片描述

流量镜像和重试

流量镜像是非常厉害的功能，因为做压力测试的时候很难模拟一套线上的数据。流量镜像，就很大限度的解决了这个问题。是在不影响线上环境的前提下将线上流量持续的镜像到我们的预发布环境中去，让重构的服务结实的收到一波真实的冲击，同时预发布服务也表现出真实的处理能力

在这里插入图片描述

流量进入线上服务，同时发给预发布环境一份

在这里插入图片描述

先建立一个httpv1的服务

在这里插入图片描述

注入

在这里插入图片描述

合理有一个url，headers

在这里插入图片描述

准备v2版本

在这里插入图片描述

注入

在这里插入图片描述

建立一个service

在这里插入图片描述

istio建立规则少不了service，一定要创建service，因为virtualservice全是匹配servicename

在这里插入图片描述

现在httpbin是访问不到的

在这里插入图片描述

需要添加规则

在这里插入图片描述

在default路由前加一下即可

在这里插入图片描述

现在只是创建了服务，还没有创建规则，destinationRule

在这里插入图片描述

现在就访问到了

在这里插入图片描述

headers就访问到这里了

在这里插入图片描述

查看一下日志

在这里插入图片描述

v2现在肯定还没有流量，因为都在v1上

在这里插入图片描述

现在就可以开始做流量镜像

在这里插入图片描述

可以调整多少流量打过去

在这里插入图片描述

istio支持管理多集群，不同集群的服务可以通过这样的一种通用的来管理的

在这里插入图片描述

现在刷新一下页面

在这里插入图片描述

现在就有流量了

在这里插入图片描述

还可以重试，很多都是从代码层面来进行重试逻辑的，重试的本身这种需求，是和业务无关的，是一种通用的需求。istio可以帮你去实现重试的逻辑

在这里插入图片描述

当服务端返回502的时候，可以重试‘

在这里插入图片描述

现在访问，返回的是502

在这里插入图片描述

它自己从代理端就帮你重试了

在这里插入图片描述

5xx的时候进行重试

在这里插入图片描述

访问一次400

在这里插入图片描述

就一条记录

在这里插入图片描述

重试三条

在这里插入图片描述

熔断

过载保护

在这里插入图片描述

istio是通过envoy proxy来实现熔断机制的。envoy强制在网络层面配置熔断策略，这样就不必为了每个应用程序单独配置或重新编程。如果从代码层实现，可以实现一个callback，里面可以写逻辑。istio就没法写逻辑，因为没法进入你的代码。通常来讲istio网络中服务配置链接数和请求数用的是最多的

下面是httpbin去访问java app，可以在中间加一个熔断配置

在这里插入图片描述

先创建服务

在这里插入图片描述

注入一下

在这里插入图片描述

先用一个单线程的进行链接

在这里插入图片描述

现在用client去访问service，里面有get方法，其实就是设置了两个变量去发起请求

在这里插入图片描述

现在发送2个也是请求成功的

在这里插入图片描述

可以进行限制，是放在destinationrule里的

在这里插入图片描述

http2是一个链接去发送多个请求，不像http1，是建立一个链接发送一个请求

在这里插入图片描述

现在线程变成10就绝大多数是会失败的，istio里的熔断更像是限流

在这里插入图片描述

上面的应用的配置其实就是改了envoy的这里，envoy无法触发callback逻辑，因为它不进入代码

在这里插入图片描述

故障注入和超时

在这里插入图片描述

故障注入就是原来你的服务是正常，可以在envoy这层，显式的申明，访问details服务的时候，注入50%的故障，其实就是调试你的程序兼容性。如果100%故障就是服务挂了，它就是为了实现你的程序挂了，整个集群里是否还正常工作

在这里插入图片描述

是通过两类实现，abort是中止，delay是延迟

在这里插入图片描述

现在路飞用户访问到review v2上面

在这里插入图片描述

现在要这样，reviews去访问ratings这一层注入延迟2秒

在这里插入图片描述

建立一个virtualservice是跟ratings整个域名来进行访问的，有一个fault错误类型，也就是把访问rating服务100%流量，注入延迟2秒

在这里插入图片描述

所有访问rating服务的都注入一个延迟访问的故障

在这里插入图片描述

现在就有延迟了

在这里插入图片描述

请求是两秒多

在这里插入图片描述

注入的延迟配置最终体现在envoy里

在这里插入图片描述

可以加超时时间，针对reviews v2的进行1秒超时

在这里插入图片描述

超时针对v2生效，v3无效

在这里插入图片描述

登录路飞用户也是2秒，实际上是timout1秒，但是程序自己加了1秒超时

在这里插入图片描述

这里是1秒，它返回的时候rating还没有返回

在这里插入图片描述

这是一个延迟版的故障注入

在这里插入图片描述

还有状态码，把这个删除了就是故障了

在这里插入图片描述

代表50%纪律是500错误

在这里插入图片描述

这里就50%的几率出错了，也就是不用把服务停了模拟挂的情况

在这里插入图片描述

iptables规则失效排查

在istio网格内，流量请求完全绕过了kube-proxy组件

在这里插入图片描述

但是上次还能访问到

在这里插入图片描述

有几个服务都跑在slave1上，清理掉slave1的规则，也就是kube-proxy清理的规则，去访问通道

在这里插入图片描述

调度到不存在的机器，也就是把kube-proxy清理掉

在这里插入图片描述

在宿主机上清理掉iptables规则

在这里插入图片描述

现在访问不到

在这里插入图片描述

因为dns也是走的service流量，这个是走宿主机iptables规则去解析到的，现在规则没有了就解析不到了billservice了

在这里插入图片描述

直接访问ip可以通，是因为按照istio的走的

在这里插入图片描述

现在访问istio-proxy 是不通的，因为是走的宿主机的iptales

在这里插入图片描述

印证了在istio-proxy（虽然是网格里容器，但是访问外部是一摸一样的），在front-tomcat容器里，是走的envoy流量里去

在这里插入图片描述

把删除的kube-proxy改过来了

在这里插入图片描述

可观察性

在整个istio里提供看的东西就grafana，jaeger（分布式追踪），kiali（专门针对istio做的可视化组件），prometheus

在这里插入图片描述

istio自带了这几个yaml文件，可以直接apply grafana

在这里插入图片描述

jaeger

在这里插入图片描述

需要改两个地址

在这里插入图片描述

这里用的是grafana自带的服务发现地址，默认是在istio名称空间里的

在这里插入图片描述

改成这个

在这里插入图片描述

这几个服务创建到了istio-system空间里

在这里插入图片描述

这些全是istio的

在这里插入图片描述

virtualservice加一个路由就是给服务发现服务路由，istio-proxy用的

在这里插入图片描述

在这里插入图片描述 istio在注入的时候已经帮你实现这个结构了

在这里插入图片描述 这是在pod层面做监控

在这里插入图片描述

建立一个ingress

在这里插入图片描述

获得域名

在这里插入图片描述

数据源都帮你配置好了

在这里插入图片描述

这是istio内部，grafana实现的配置

在这里插入图片描述

发送请求

在这里插入图片描述

成功率百分百

在这里插入图片描述

mesh dashboard，可以监控服务流量，所有服务都在这里

在这里插入图片描述

现在链路追踪是放在sidecar里的

在这里插入图片描述

envoy里已经帮你配置好了

在这里插入图片描述

启动的时候有1个配置文件

在这里插入图片描述

创建jaeger的时候已经看到这个zipkin创建好了

在这里插入图片描述 这两个都是追踪jaeger服务的，envoy虽然配置了zipkin，但是还是访问tracing

在这里插入图片描述

这里有图表展示对于关系

在这里插入图片描述

kiali

可观测性分析服务

在这里插入图片描述

拿的是label里带app的

在这里插入图片描述

istio里做的

在这里插入图片描述

product配置，穿过v1，访问到detail

在这里插入图片描述

点击其他的service也可以看到这些图

在这里插入图片描述

traffic，是inbound和outbound，入站和出站流量

在这里插入图片描述

业务日志和istio-proxy日志

在这里插入图片描述

入站流量

在这里插入图片描述

集成了很多东西，日志，inbound，outbound

在这里插入图片描述

可以看一些service的基础信息

在这里插入图片描述

这个是拿的数据，确定有没有

在这里插入图片描述

小结

istio创建的规则，servicename必须依赖K8S实现的，istio的出现其实是微服务间的通讯的短板

K8S已经称为容器调度编排的事实标准，容器正好可以作为微服务的最小工作单元，从而发挥微服务架Kubernets已经成为了容器调度编排的事实标准，而容器正好可以作为微服务的最小工作单元，从而发挥微服务架构的最大优势。所以我认为未来微服务架构会围绕Kubernetes展开。而lstio和Cnduit这类Service Mesh天生就是为了Kubernetes设计，它们的出现补足了Kubernetes在微服务间服务通讯。上的短板。虽然Dubbo. SpringCloud等都是成熟的微服务框架，但是它们或多或少都会和具体语言或应用场景绑定,并只解决了微服务Dev层面的问题。若想解决Ops问题，它们还需和诸如Cloud Foundry. Mesos、 Docker Swarm或Kubernetes这类资源调度框架做结合:

在这里插入图片描述

laas层面是系统层面的，从这个上面是K8S支持的，springcloud是这么支持，以后很长的时间都是K8S和istio

在这里插入图片描述

总结一下：
第一代为spring cloud为代表的服务治理能力，是和业务代码紧耦合的，没法跨编程语言去使用
为了可以实现通用的服务治理能力，istio会为每个业务pod注入一个sidecar代理容器

提出了server mesh的理念，注入边车去监控业务流量

接管业务pod的流量，因此通过注入的时候引入初始化容器istio=init实现pod内防火墙规则的初始化，分别将出入站流量拦截到pod内的15001和15006端口 在这里插入图片描述还注入了istio-proxy容器，一个是pilot-agent进程，一个是envoy，envoy是pilot-agent拉起来的，pilot-agent是一个info进程，先起来生成配置文件-rev0，生成这个配置文件后把envoy拉起来，启动之后通过xds，再生成pilot，是istiod里的pilot-service这个服务，也就是grpc的server端**** 在这里插入图片描述 virtualservice，destination rule，gateway，转换和曾envoy可以识别的配置片段。通过xds同步到网格的envoy中****服务在productpage去curl这个地址，先给istio-init容器注入iptable规则，（output链转到istio_output链转到istio_redirect链）envoy监听15001端口，出站转到了0.0.0.0_端口这样一个监听上去，listener去读filter chains，经过路由规则，匹配到cluster，转到endpoint，最终转到pod的ip上******** 在这里插入图片描述 进入pod后被15006的envoy拦截，virrtual inbound做处理转到cluster上去，转到最终的endpoint****

在这里插入图片描述 ****

下面是整个过程，创建virtualservice，destination rule，endpoint** 在这里插入图片描述 ******************************

envoy带来的肯定网络上更加复杂，还有额外的开销，是否需要用还要自己考量。灰度发布很简单，创建virtual service，destination rule规则就好了** 在这里插入图片描述 **

rancher安装使用

用rancher还是比较多的，因为用户不需要深入了解K8S 在这里插入图片描述

支持的版本 在这里插入图片描述 安装很简单就一句话stable版本看一下，但是指定的为好v2.5.2需要这样配置，privileged，使用该参数，container内的root拥有真正的root权限。否则，container内的root只是外部的一个普通用户权限。privileged启动的容器，可以看到很多host上的设备，并且可以执行mount。甚至允许你在docker容器中启动docker容器** 在这里插入图片描述 K3S是一个比K8S更轻量级的平台****可以用于物联网边缘计算设计**现在进行访问设置密码选择管理多集群的rancher

现在rancher就是一个K3S集群 在这里插入图片描述 可以理解为在里面启动了一个K3S集群默认起了一个K3S集群同样把这集群放到自己的管理页面去了复制到集群里去执行仪表盘还可以看一些资源的使用可以执行命令行这里也一样可以第一个概念就是项目，项目就是隶属于集群的有几个项目 在这里插入图片描述 这个项目是命名空间上面的一层虚拟概念，这个项目是包含名称空间的default项目下包含一个default命名空间有这么多命名空间不属于任何项目

可以选择添加项目 在这里插入图片描述 可以把命名空间移动到这个项目里可以查看工作负载还有负载均衡service，服务发现里有选择器还可以部署服务挂载卷缩放升级策略，就是灰度更新标签就是加label加标签可以进容器进行curl查看日志事件就是deployment的内容 在这里插入图片描述