Istio 配置安全：如何避免错误配置
探索常见的 Istio 配置错误及其解决方法，提高服务网格的安全性和稳定性。阅读原文请转到：https://jimmysong.io/blog/istio-configuration-safety-common-misconfigurations/Istio 是一个功能强大的服务网格解决方案，提供零
Istio 专栏目录
1. istio 虚拟服务 yaml 解释2. istio envoyfilter yaml 解释3. istio 熔断器异常点检测 yam 解释4. istio 熔断器连接池 yaml 解释。
Istio 安全 mTLS认证 PeerAuthentication
mTLS (mutual TLS，双向TLS)： 让客户端和服务器端通信的时候都必须进行TLS认证默认情况下，在网格内部默认启用了mTLS了。在网格里面所有的pod， 不管是istio使用到的pod，还是普通创建的pod1 pod2，都会通过mtls来进行通信，也就是互相认证。上面其实就演示了网格之
【云原生 | 从零开始学istio】二、Istio核心特性与架构
关于istio架构和特性的深入讲解，通过现实的例子让大家理解
【云原生 | 从零开始学istio】五、istio灰度发布以及核心资源
灰度发布也叫金丝雀发布 ，是指通过控制流量的比例，实现新老版本的逐步更替。比如对于服务 A 有 version1、 version2 两个版本 ， 当前两个版本同时部署，但是 version1 比例 90% ，version2 比例 10% ，看运行效果，如果效果好逐步调整流量占比 80～20 ，7
基于Istio服务治理网格的SpringCloud大型微服务项目部署流程
用户请求首先到portal前端页面，也就是程序的首页，在首页的各项功能操作都会由Gateway网关服务转发到各自的微服务程序上，比如请求一个订单服务，订单服务会事先注册到Eureka中，由Gateway将请求发送给Eureka，再由Eureka转发给具体的微服务程序，这些微服务程序都有自己单独的数据
Istio服务网格进阶③：基于Istio服务网格实现灰度发布机制
灰度发布的例子：一个应用程序有2个版本，V1版本为线上生产环境的版本的，V2版本为即将上线的版，需要同时将两个版本的应用程序部署，并且全部接入到负载均衡中，通过灰度发布控制，V1版本承担90%的流量，V2版本承担10%的的流量，观察运行效果，循序渐进，最新V1版本下线，V2版本提供线上服务。Kube
【云原生 | 从零开始学istio】二、Istio核心特性与架构
关于istio架构和特性的深入讲解，通过现实的例子让大家理解
Istio服务网格进阶⑤：Istio服务网格的流量管理之服务熔断
应用程序调用之间也是有类似保险丝的概念的，被称为服务熔断，当A服务请求B服务时，如果B服务故障无法提供请求时，A服务还是会一直请求B服务，从而占用很多的资源，请求积压过多就会影响服务器的整体性能，当应用程序设置了服务熔断，当B服务无法处理请求时，就不会让A服务再去请求B服务了，根据设置的时间，一段时
Istio服务网格核心资源YAML编排文件配置清单
VirtualService是Istio流量治理的核心配置资源，所有的流量控制策略都是由VirtualService资源实现的，Gateway资源相当于流量的入口，流量如何管控是由VirtualService资源实现的。流量比例分配如果先写weight再写destination参数就更容易理解了，如
基于Istio服务治理网格的SpringCloud大型微服务项目部署流程
用户请求首先到portal前端页面，也就是程序的首页，在首页的各项功能操作都会由Gateway网关服务转发到各自的微服务程序上，比如请求一个订单服务，订单服务会事先注册到Eureka中，由Gateway将请求发送给Eureka，再由Eureka转发给具体的微服务程序，这些微服务程序都有自己单独的数据
Istio服务网格中的流量复制
在发布新版本前，测试同事会通过很多的测试工具对新版本的程序进行压测，虽然可以模拟出很多的流量，但是也不算是真实的流量请求，上线后还是不能保证其他问题的发生。当需要用真实的线上流量进行新版本的测试，但是也不能真的让测试中的版本为线上用户提供服务，基于这种情况，Istio可以通过VirtualServi
