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。如果超过，需要增加计算资源，否则会卡顿。
• 完成了将网络策略与应用程序的分离。

还有一个是

smi-spec/traffic-access.md at main · servicemeshinterface/smi-spec · GitHub

转载至https://blog.csdn.net/ryanlll3/article/details/113733717