Kubernetes vs Service Mesh
流量转发
K8s集群中的每个节点都部署了一个kube-proxy组件,该组件与K8s API Server 进行通信,获取集群中的服务信息,然后设置iptables规则,将服务请求直接发送到对应的Endpoint(属于同一组服务的pod)
服务发现
istio可以跟踪K8s中的服务注册,也可以在控制平面中通过平台适配器与其他服务发现系统对接;然后生产数据平面的配置(使用CRD,这些配置存储在etcd中),数据平面的透明代理。数据平面的透明代理以sidecar容器的形式部署在每个应用服务的pod中,这些代理都需要请求控制平面同步代理配置。代理之所以 “透明”,是因为应用容器完全不知道代理的存在。过程中的 kube-proxy 组件也需要拦截流量,只不过 kube-proxy 拦截的是进出 Kubernetes 节点的流量,而 sidecar 代理拦截的是进出 pod 的流量。
服务网格的劣势
由于 Kubernetes 的每个节点上都运行着很多 pod,所以在每个 pod 中放入原有的 kube-proxy 路由转发功能,会增加响应延迟——由于 sidecar 拦截流量时跳数更多,消耗更多的资源。为了对流量进行精细化管理,将增加一系列新的抽象功能。这将进一步增加用户的学习成本,但随着技术的普及,这种情况会慢慢得到缓解。
服务网格的优势
kube-proxy 的设置是全局的,无法对每个服务进行细粒度的控制,而 service mesh 通过 sidecar proxy 的方式将 Kubernetes 中的流量控制从服务层中抽离出来–可以实现更大的弹性。
Envoy
Envoy 是 Istio 中默认的 sidecar 代理。Istio 基于 Enovy 的 xDS 协议扩展了其控制平面。在讨论 Envoy 的 xDS 协议之前,我们需要先熟悉 Envoy 的基本术语。
基本术语
下面是您应该了解的 Enovy 里的基本术语:
- Downstream(下游):下游主机连接到 Envoy,发送请求并接收响应,即发送请求的主机。
- Upstream(上游):上游主机接收来自 Envoy 的连接和请求,并返回响应,即接受请求的主机。
- Listener(监听器):监听器是命名网地址(例如,端口、unix domain socket 等),下游客户端可以连接这些监听器。Envoy 暴露一个或者多个监听器给下游主机连接。
- Cluster(集群):集群是指 Envoy 连接的一组逻辑相同的上游主机。Envoy 通过服务发现来发现集群的成员。可以选择通过主动健康检查来确定集群成员的健康状态。Envoy 通过负载均衡策略决定将请求路由到集群的哪个成员。
Istio 中的流量管理
Istio 中定义了以下 CRD 来帮助用户进行流量管理。
- 网关。网关描述了一个运行在网络边缘的负载均衡器,用于接收传入或传出的 HTTP/TCP 连接。
- 虚拟服务(VirtualService)。VirtualService 实际上是将 Kubernetes 服务连接到 Istio 网关。它还可以执行额外的操作,例如定义一组流量路由规则,以便在主机寻址时应用。
- DestinationRule。DestinationRule 定义的策略决定了流量被路由后的访问策略。简单来说,它定义了流量的路由方式。其中,这些策略可以定义为负载均衡配置、连接池大小和外部检测(用于识别和驱逐负载均衡池中不健康的主机)配置。
- EnvoyFilter。EnvoyFilter 对象描述了代理服务的过滤器,可以自定义 Istio Pilot 生成的代理配置。这种配置一般很少被主用户使用。
- ServiceEntry。默认情况下,Istio 服务 Mesh 中的服务无法发现 Mesh 之外的服务。ServiceEntry 可以在 Istio 内部的服务注册表中添加额外的条目,从而允许 Mesh 中自动发现的服务访问并路由到这些手动添加的服务。
核心观点
- Kubernetes 的本质是应用生命周期管理,具体来说就是部署和管理(伸缩、自动恢复、发布)。
- Kubernetes 为微服务提供了一个可扩展、高弹性的部署和管理平台。
- 服务网格是基于透明代理,通过 sidecar 代理拦截服务之间的流量,然后通过控制平面配置管理它们的行为。
- 服务网格将流量管理与 Kubernetes 解耦,不需要 kube-proxy 组件来支持服务网格内的流量;通过提供更接近微服务应用层的抽象来管理服务间的流量、安全性和可观察性。
- xDS 是服务网格的协议标准之一。
- 服务网格是 Kubernetes 中服务的一个更高层次的抽象。
服务网络架构
服务网格中分为控制平面和数据平面,当前流行的两款开源的服务网格 Istio 和 Linkerd 实际上都是这种构造,只不过 Istio 的划分更清晰,而且部署更零散,很多组件都被拆分,控制平面中包括 Mixer、Pilot、Citadel,数据平面默认是用Envoy;而 Linkerd 中只分为 Linkerd 做数据平面,namerd 作为控制平面。
控制平面
控制平面的特点:
- 不直接解析数据包
- 与控制平面中的代理通信,下发策略和配置
- 负责网络行为的可视化
- 通常提供API或者命令行工具可用于配置版本化管理,便于持续集成和部署
数据平面
数据平面的特点:
- 通常是按照无状态目标设计的,但实际上为了提高流量转发性能,需要缓存一些数据,因此无状态也是有争议的
- 直接处理入站和出站数据包,转发、路由、健康检查、负载均衡、认证、鉴权、产生监控数据等
- 对应用来说透明,即可以做到无感知部署
Istio 架构解析
- Istio 可以在虚拟机和容器中运行
- Istio 的组成
- Pilot:服务发现、流量管理
- Mixer:访问控制、遥测
- Citadel:终端用户认证、流量加密
- Service mesh 关注的方面
- 可观察性
- 安全性
- 可运维性
- Istio 是可定制可扩展的,组件是可拔插的
- Istio 作为控制平面,在每个服务中注入一个 Envoy 代理以 Sidecar 形式运行来拦截所有进出服务的流量,同时对流量加以控制
- 应用程序应该关注于业务逻辑(这才能生钱),非功能性需求交给 Service Mesh