我们在使用k8s集群的时候, k8s虽然强大, 但是也有弱点, 比如我们要是想控制灰度发布, 需要进行大量的配置, 徒手硬敲金丝雀, 流量控制, 权限控制, 这种事情还是留给年轻人吧…
我们要是想控制通信重试, 限流, 熔断, 倾斜的负载均衡, 以往还是用代码强侵入性的 springcloud那一套, 现在我认为我们应该是有了更好的选择了!
虽然 istio 还算年轻，但是它作为集群基础设施通用网络层的地位已经开始显露，相信在未来的发展中接受度会越来越大，并逐渐巩固自己的地位。
另外，基于 istio 构建自己的 serverless 服务，也符合目前软件行业不要重复造轮子的工作。istio 在集群的网络管理方面非常优秀（智能路由、负载均衡、蓝绿发布等）
作为service mesh 的最佳实现(起码在我眼里), 也顺理成章的秉承了service mesh设计思想的优势, 通过istio的pod注入, 实现在会话层(网络通信)的解耦, 让开发人员更专注于业务本身, 挎斗模式就是香! 业务pod不用思考, 上车就走.
- gateway 简称gw, 本身不存在网关实体, 本质上就是ingress gateway的一条配置
- virtual service 简称vs, 本身也不存在实体, 是ingress gateway里的一条配置
- destination rule 简称dr, 本身也不存在实体, 也是ingress gateway里的一条配置
- service entry
- peer authentication
- authorization policy
- request authentication
在想变得更强吗? 5分钟带你了解云原生核心 – Istio (下) 别点了大佬, 我正在写中我会对上述的每一项, 进行细致的讲解.
别慌, 一听到注入就觉得是耦合, 其实这个耦合(严格上都不算是耦合), 影响很小, 最多就是在namespace 层面配置一下 需要全局pod注入.
service mesh 服务网格拓扑图
下章连接
===>
想变得更强吗? 5分钟带你了解云原生核心 – Istio (下)
