Kubernetes Service Mesh (服务网格)
Kubernetes 服务网格
- 什么是服务网格
- Kubernetes vs Service Mesh
- Nginx Controller vs Istio Gateway
- Envoy 开源服务
- Istio原理分析 - 控制平面
- Istio原理分析 - 数据平面
- Istio原理分析 - Sidecar注入（Injection）
- Istio服务优势 - 流量管理
Ref.
Istio服务网格
什么是服务网格
服务网格提供了一种透明且独立于语言的方式，可以灵活，轻松的自动化运维应用程序的网络功能。
Service Mesh通过Sidecar(从容器)的模式，对于服务本身时没有侵入式的。开发人员只需要关注微服务本身的代码逻辑。不需要去管理service mesh的sidecar是怎么实现的，所以说它是透明的方式。
Service Mesh不是跟任何开发语言绑定的，是一种平台框架。
自动化运维是通过sidecar来实现的。
服务网格的3个特性：
- 安全性：必须是安全可靠，比如TLS认证与加密，服务间的相互认证，都是可以通过sidecar来实现的。
- 可观察性：可以观察到服务与服务之间通讯的延迟，谁发起了调用请求，谁拒绝了调用请求。
- 可运维性：Sidecar可以帮助添加健康检查，做服务间调用的熔断，重试，如果一个用户请求10秒钟，还没有收到响应，可以把用户请求终止，重新发起请求，而不是让用户一直等待超时链接。
Kubernetes vs Service Mesh
K8S模式中，微服务是以Pod+Container的方式在运行的，我们会用到service(cluster ip, nodeport)把后面的pod代理成一个集群。比如在发布一个微服务镜像的时候，replicas设置为3，同时发布了一个cluster IP的服务。这样就是表示一个cluster IP service后面挂着3个pod。服务间的通讯，是通过work node上kube-proxy做流量转发。所有的请求是基于kubernetes API server上的数据来路由的。这是传统的K8S内部服务网络的管理。参照之前文档。Kubernetes网络之Service网络（2）
Service Mesh基于service的概念，做到了更多的拓展。K8S的原生服务，如上面所讲，是对后面的POD集群做了一个代理，通过round-robin的方式，将你的请求转发到后面的pod。但是Service Mesh做到了更多的拓展，比如 retry, 熔断，流量转发控制。
Kube-proxy是全局模式的，以daemonset的方式在每一个节点上运行的。kube-proxy的配置是全局的，只能做到针对的node级别的管控。然而Service Mesh，每次你运行一个容器，它都会在旁边跑一个sidecar(从容器)，所以它可以支持到一个服务粒度的管控。
Nginx Controller vs Istio Gateway
一般情况下，K8S集群服务暴露是用Ingress Controller 或者 Nginx Controller的方法。
Istio是基于envoy服务来实现Istio本身的gateway功能。接口更加丰富，原生支持与很多中间件的通信。（如图）。还支持流量转发的管控，白名单， 调用重试，超时，健康检查等机制。
Envoy 开源服务
它的定位是中间的service proxy的服务。跑在Istio sidecar容器里的服务。
Istio原理分析 - 控制平面
Service Mesh理念对微服务是非常有价值的。Istio是当前社区流行的service mesh的实现方式。
Istio分为两个面，控制平面，数据平面。
控制平面（Control Plane）：类似于K8S的API Server, Scheduler，etcd这些组件。Istio也需要有自己的控制组件。
- Mixer: 负责配置文件的发放，一致性校对，采集envoy，sidecar上报的数据。
- Galley: 监控，展现是有galley组件负责。
- Citadel: TLS加密，证书。
- Pilot: Sidercar与Pilot交互。Pilot负责把对应的Sidecar从容器的规则部署下去。
- Istio控制平面是以pod的形式运行在K8S中的。
Istio原理分析 - 数据平面
数据平面：
- 自己部署的服务所运行的平面。可以理解你的微服务和sidecar的一个组合。
- Sidecar proxy(Envoy)是以从容器的方式运行在你部署的容器旁边，管控你服务的流量进出，接收与拒绝。
Istio原理分析 - Sidecar注入（Injection）
如果部署一个微服务，只需要发布一个传统的deployment和一个service。那如果开启了Istio的Auto sidecar injection的功能，最终部署出来的容器是多了两个容器。
- 一个init container: 创建一条新的iptables记录做流量转发。
- 一个sidecar container: 当流量进来的时候，负责管控流量，直接转发给容器，还是drop掉，或者校验reques的认证。
Istio如何注入容器呢？
是基于Kubernetes的mutating webhook。mutating webhook是Admission controller的一个拓展。比如用户通过kubectl apply -f file.yml创建了一个pod，如果没有Istio，它会简单部署为一个pod。一旦开启了Istio Auto sidecar injection，file.yml就会经过k8s的mutating webhook，mutating webhook判断该服务应该被管控，然后基于Istio已经配置好的Istio-sidecar-injector的yaml文件，创建一个资源对象，存到etcd里面。
查看配置文件：
注意：istio-injection开启
matchLabels:
istio-injection: enabled
istio-injection规则：
rules:
- operations: ["CREATE"]
apiGroups: [""]
apiVersions: ["v1"]
resources: ["pods"]
Istio服务优势 - 流量管理
流量管理主要是由pilot组件来实现的。从容器的注入，流量的转发规则，都是pilot组件负责配置，分发到对应的sidecar proxy（envoy）里面。
Pilot组件包含一个envoy API，负责与sidecar proxy（envoy）交互。
Istio的流量管理实现了：
- 了解服务之间的网络交互：谁请求，响应谁。
- 服务间调用是否正常，200,404，延迟etc.
- 流量路由百分比的管控，针对于服务级别的管控。
- 目前版本默认支持1000个service，2000个sidecar和70000请求的自动策略执行。默认配置就可以实现。不需要增加Istio的CPU, Memory。如果超过，需要增加计算资源，否则会卡顿。
- 完成了将网络策略与应用程序的分离。