Service Mesh介绍，Istio概述/架构
kubernetes 面对的问题
当访问service的时候，那么会转发给pod1 pod2的，它是通过kube-proxy组件帮我们往下转发的，kube-proxy有两种工作模式，一种是iptables。一种是ipvs。
现在需要对流量进行管控，要往pod1走80%流量，pod2走20%流量。
如果想要对流量进行控制，要怎么做呢，或者说如下有两个svc，要分摊流量到两个svc上面，那么在svc之前还需要负载均衡类似的设备，通过这个设备来转发。
pod之前是svc，相当于负载均衡设备，但是对于svc来说还没有这样一个设备。这样就体现出来的kubernetes的一个弊端，没有对流量的细致管控。
使用kubernetes单独实现金丝雀发布
实现金丝雀发布，就是为了体现出来，在k8s里面配置是有多难使用。
金丝雀发布我们也称为灰度发布，客户端所有的流量都访问在pod v1，然后上线了pod v2版本，现在没有客户端可以访问到pod v2，之后觉得pod v2版本很稳定了，后面想要迁移到v2这边来，但是不想让客户端全部迁移到这边来，但是想要一点点的迁移到这边来。
这样就需要流量的管控95%的流量到v1版本，5%的流量到v2版本，然后根据客户的反馈和体验，逐步扩大流量到v2版本。也就是一边的流量慢慢的变小，一边的流量慢慢变大。（如果客户反馈新版本有问题，那么就改进）
kubernetes网站上提供了一个方案，也就是创建两个deployment，一个svc关联着两个deployment，然后通过扩大缩小副本数达到金丝雀发布。（通过手动的调整副本数来实现）
现在有两个svc，现在要实现testpod往svc1走多少的流量，往svc2走多少的流量。
这样就需要类似与负载均衡的组件来实现，在这个pod里面增加sidecar，这个直接使用haproxy来实现，它后端的两个服务就是svc1和sv2，那么testpod就不直接访问sv1，sv2，而是直接访问sidecar，sidecar指定了后端的sv1，sv2访问的负载比例，这样就实现了往svc1，sv2的流量是可控的。
Haproxy的设置
frontend www-http
bind :80
default_backend www-backend
backend www-backend
server nginx-service1 svc1:80 weight 1
server nginx-service1 svc2:80 weight 1大问题
- 流量管控
- 安全性
- 可观测性
Service Mesh
Service Mesh 的中文译为 “服务网格” ，是一个用于处理服务和服务之间通信的基础设施层，它负责为构建复杂的云原生应用传递可靠的网络请求，并为服务通信实现了微服务所需的基本组件功能，例如服务发现、负载均衡、监控、流量管理、访问控制等。在实践中，
服务网格通常实现为一组和应用程序部署在一起的轻量级的网络代理，但对应用程序来说是透明的。
Sidecar指的是和应用服务部署在一起的一个代理程序，要是访问你的应用要走proxy才能访问到，只能走sidecar去通信，不能走应用和应用之间去通信，因为应用所有的流量都被proxy所接管了。
服务网格的本质是将业务程序给接管起来，然后由自己的proxy代理去负责数据的转发。
上面蓝色的方块都会有一个控制心去统一管理蓝色的方块，比如在控制中心可以给它发送一个配置，让这些proxy去生效。
还可以去做访问控制，指定某个应用不能访问某个应用，这样proxy就不会转发了。
管理员只是负责配置中心，来配置整个服务网格内的一些流量的管控，等等一系列这些功能。
Service Mesh特点
Service Mesh有以下特点：
治理能力独立（Sidecar 去负责应用的流量，它们之间通信也是通过sidecar）
应用程序无感知（以边车的形式与服务绑定的，使用的时候不需要修改应用程序的代码，sidecar可以直接管理到它了）
服务通信的基础设施层（管理服务的通信设施）
解耦应用程序的重试/超时、监控、追踪和服务发现
servicemesh可以看作nginx代理后端的应用之上更为高级的一种模式，这个模式就是增加控制系统，这些控制系统可以将所有的代理统一的去管理起来，就不像传统单体应用的代理。
因为流量都经过sidecar，被它接管了，那么可以做非常多的功能。
service mesh设计的目标和实现的原理其实就是来自于proxy，和一个控制中心去管理。
Istio概述
Isito是Service Mesh的产品化落地，是目前最受欢迎的服务网格，功能丰富、成熟度高。
连接（Connect）
安全（Secure）
控制（Control）
观察（Observe）
Istio版本变化
在Istio1.5版本发生了一个重大变革，彻底推翻原有控制平面的架构，将有原有多个组件整合为单体结构 “istiod”，同时废弃了Mixer 组件，如果你正在使用之前版本，必须了解这些变化。
之前有很多的组件，在部署的时候要部署7，8个组件，但是又不知道组件之间什么关系，怎么去通信的，有些组件可能很容易就挂掉了。
listio是基于kubernetes上面一个服务网格治理平台，早期追求架构的纯粹性，一个控制面很多组件，好多组件从架构来说非常清晰，设计的非常好，后面就陷入了困境，一个控制面很多组件，当你做系统升级的时候，这个升级就陷入了困境，先升级哪个组件，后升级哪个组件，中间是否会有业务中断，这就会造成很多的困扰。
所以做个取舍，比如一些组件是一个团队维护的，那就合并好了，将一些组件变为一个组件了，这样升级的风险降低了，维护成本降低，这里面没有绝对的原则，完全看你的业务场景。
重构之后，服务端控制面板这就有istiod，之前老版本有4个组件，现在只要一个组件。
Istio架构图
istio创建出来的每个pod都会加上一个sidecar，envoy其实也是网络代理，每个pod里面主容器将流量转发给它的代理envoy就行了。
流量转发给envoy是可以设置各种策略的，比如设置流量走向，一边走流量50%，另外一边走50%。
修改策略是不需要重启pod，通过设置一些策略就可以立刻生效，比如Gateway，VirtualService，DestinationRule ，ServiceEntry。这些策略都是通过控制平面应用到代理里面，就不需要重启容器生效。
istio注入
不管你是哪个命名空间的，或者是非kubernetes集群里主机 ，只要你被istio注入了，那么我们就相当于在一个平面里了。
Istio注入
所有的策略生效，前提是你必须得要在网格里，如果没有在网格里的话，策略是不生效的。
Istio架构与组件
Istio服务网格在逻辑上分为数据平面和控制平面。
使用全新的部署模式：istiod，这个组件负责处理Sidecar注入、证书分发、配置管理等功能，替代原有组件，降低复杂度，提高易用性。（将proxy进行管理，对采集的进出流量进行分析，提供监控，日志，链路追踪方面的）（将原有的组件整合到一个组件里面来）
- Pilot：策略配置组件，为Proxy提供服务发现、智能路由、错误处理等。 （管理proxy）
- Citadel：安全组件，提供证书生成下发、加密通信、访问控制。
- Galley：配置管理、验证、分发。
数据平面：由一组Proxy组成，这些Proxy负责所有微服务网络通信，实现高效转发和策略。使用envoy实现， envoy是一个基于C++实现的L4/L7 Proxy转发器，是Istio在数据平面唯一的组件。
（指的是微服务的那一端，就是服务部署的那一端，比如部署一个Pod，这就属于数据平面，他会在数据平面里面植入一个proxy）（proxy负责所有微服务网络通信，微服务之间通信都会走这个proxy，或者微服务访问外部也要走这个proxy，负责转发和配置相关的策略）
可以看到改版之后架构清晰明了，减少了更多的成本。
Istio基本概念
Istio 有 4 个配置资源，落地所有流量管理需求：（各种各样功能是根据这些配置资源实现的）
- VirtualService（虚拟服务）：实现服务请求路由规则的功能。
- DestinationRule（目标规则）：实现目标服务的负载均衡、服务发现、故障处理和故障注入的功能。
- Gateway（网关）：让服务网格内的服务，可以被全世界看到。
- ServiceEntry（服务入口） ：允许管理网格外的服务的流量。（用的较少）