微服务之间调用观测,
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毛钱,那还要这个开发程序员干什么?没事想想