微服务之间调用观测,
 istio的版本是对k8s 版本有要求的,案例中 istioshi 1.15.2 版本的
 
一、下载 Istio

 
二、部署

 
 egressgateway 和 ingressgateway 分别控制进出
istio 通过 Envoy proxy,也就是pod加边车的方式来控制用户对svc的访问

 这样做后,新生的pod自动带代理
三、示例 Bookinfo

四、对外开放应用
 

安装metallb,
还得配置下ipvs和 strict ARP
 
为了获取 ingressgateway的 EXTERNAL-IP
 

 
 
 
 
 这个地址在集群内可以访问,但是集群外ping不通,需要配置二层转发才可以用
 
 
 设置ingress host ip 和 port
 
 设置 gateway_url
 
 
五、service mesh
做架构选型的时候你需要知道原来架构的缺点,才能知道应该选择什么来弥补缺点
 集中式代理,需要对nginx 做keepalived
 嵌入式代理,需要额外的基础架构组开发组件,而且语言只能用java
 代码写得多了,就会被沉淀下去,变成公共库。写的太多了,就变成了一个独立的进程,和原来的进程脱钩,就是sidecar
 是sidecar之间做交互的,相互联系成为网格,即为服务网格 service mesh, istio就是service mesh的一种实现
 
 用户量没那么多,就没必要复杂,用nginx也行。
 用了servicemesh 开发工作量减少了
bookinfo 架构

istio

 istio服务间http,grpc,tcp 调用都通过边车
 
 所有日志间调用都得通过mixer,可以用日志收集,链路追踪来理解他,他会记录下这个过程。A调B 合法不合法也是通过mixer判断
istio 1.0的架构,过时了,为了后面便于理解新的架构
所有的东西都要过mixer,它重启全都得停摆一下,太耗费性能了
 
1.5版本后就是这样了,复杂是万恶之源

istio把网络通信之间的关系下沉到和微服务没有关系,解耦了
istio要给命名空间注入的
 
 
 demo是顶配的套餐,什么功能都有
 
 把demo套餐打个明细出来
 
 kiali调用链路
 
注入
就是在pod里注入sidecar
手动注入

 注入前端口只有80,注入后端口多了几个(监控,通信,流量控制,链路追踪),istio-init 这个开始执行完任务就死掉的哥们做了这件事,它还统一了应用容器和istio-proxy的ip
 
 一个pod里面两个container的端口是一样的。envoy就是sidecar. pilot-agent就是 控制面板pilot的代理,和pilot 做通信用
 
 可以看到死去哥们做的环境变量,端口设置等等
 
 
 pilot 监听k8s api server变化 pilot-agent 从pilot 拿配置给sidecar,然后给nginx
 
 docker insepct proxy镜像
 
 
六、流量管理(就是负载均衡和灰度发布这类)
svc根据标签可以选择两个不同的pod作为后端负载的点
通过VirtualService 控制 流量分发到两个svc,每个svc对应一个pod. 这些deployment和client的 yaml文件都被注入了istio。以此实现了流量分发. svc是不能被注入的

 
istio virtual service 满足的条件,去的目的地

 
 exact: msb的意思是完全等于 msb,走 httpd1-svc
 
 
bookinfo
先需要执行这个
 
 再执行这个就总是v1版本
 
让用户是xiaodi的走v2,不是的随便走
这个命令能查版本号
 
 
 没有改变一行代码,就让他实现了路由
 在官网找到 Virtual Service,还有很多条件可用
 
 
蓝绿发布 保证服务不间断提供服务
比如8点之后的流量就不要去老服务了
 
故障注入:超时

 
 
 timeout就是多久超时,这里一秒就超时
 
 
 前面只等待一秒,没出来就报错了
重试
七、
八、
比如一个程序已经有别人写好的,提供服务,调一万次只要5毛钱,那还要这个开发程序员干什么?没事想想






![NSS [SWPUCTF 2022 新生赛]funny_php](https://img-blog.csdnimg.cn/img_convert/f54cf5d1ba054f39dca63a4e1b6493a8.png)












