当前位置: 代码迷 >> 综合 >> Kubernetes Service Mesh (服务网格)
  详细解决方案

Kubernetes Service Mesh (服务网格)

热度:63   发布时间:2024-01-06 05:23:07.0

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