istio

ServiceMesh

Service Mesh

服务网格(Service Mesh) 这个术语通常用于描述构成这些应用程序的微服务网络以及应用之间的交互。

随着规模和复杂性的增长,服务网格越来越难以理解和管理。 它的需求包括服务发现、负载均衡、故障恢复、指标收集和监控以及通常更加复杂的运维需求,例如A/B 测试、金丝雀发布、限流、访问控制和端到端认证等。

可以理解为服务调用链路上的所有能力, 加起来组成的网格状的结构

1700527201495

1700526427912

serviceMesh (sidecar模式)工作原理

1700526398414

SD:服务发现

CB: 熔断

LB:负载均衡

AU:认证鉴权

为什么用Service Mesh

1700526522161

  • Http、Grpc 和TCP流量的自动负载均衡。

  • 通过丰富的路由规则、重试、故障转移和故障注入,可以对流量进行细粒度的控制。

  • 可插入的策略层和配置API,支持访问控制、速率限制和配额。

  • 对出入集群入口和出口中所有流量的自动度量指标、日志记录和跟踪。

  • 通过强大的基于身份验证和授权,在集群中实现安全的服务间通信。

    Service Mesh 的优劣

1700526755366

Istio 功能概览

1700527609633

流量管理

1700527662962

安全

1700527977466

可观察性

1700528019329

Istio 架构

Istio 架构演进

  • 数据平面: SideCar 方式部署的 Proxy, 负责网络通信(上面介绍的服务网格, 其实是通过数据面实现的);
  • 控制平面: 负责管理和配置代理来进行路由流量,就是负责控制数据面的部署和配置;

1700528361306

watch api service, 监控state信息: Service 、 Pod、 Endpoint 等信息, 将Istio 配置和 State 信息结合后下发给Envoy, 作为各Pod的Proxy。

数据面的-Envoy

主流七层代理的比较

1700528954131

Envoy 的优势

1700529227250

Istio 的原理

部署istio 后会有三个pod

  • istiod: 负责监听集群所有service 、pod、 endpoint 、secret、以及istio自身对象的变化,并负责将集群的信息push给envoy实例
  • istio-ingressgateway:进入网络的所有流量都会通过ingress-envoy进行传输
  • istio-egressgateway :离开网络的所有流量都会通过egress-envoy进行传输
  • 1700616123027

Istio 流量劫持是如何实现

  • 先为pod注入sidecar, 注入Istio side car 的结果是会有 istio-init 和 istio-proxy 两个pod
  • 通过istio-init, 修改iptable, 将应用容器的所有流量都转发哦到Envoy的容器中
  • 通过istio-proxy, 实际为envoy容器, 用来进行虚拟路由, 将流量转发给实际的endpoint。

Istio 流量管理如何实现

  • 通过比例分流
  • 通过请求header 分流

1700785487127

  • 服务的客户端不知道服务不同版本之间的差异。他们可以使用服务的主机名或者ip地址继续访问服务。Envoy sidecar 代理拦截并转发客户端和服务器之间的所有请求。

  • istio还为统一服务版本的多个实例提供流量的负载均衡。可以在服务发现和负载均衡中找到更多信息

  • istio不提供DNS。应用程序可以尝试使用底层平台(kube-dns、mesos-dns等)中存在的DNS服务来解析FQDN。

    Ingress 和Egress介绍

通过将Envoy 代理部署在服务之前, 运维人员可以针对面向用户的服务进行A/测试、部署金丝雀服务等。

类似的, 通过使用Envoy将流量路由到外部的web服务,例如, 方位Maps API 或者视频服务API的方式, 运维人员可以为这些服务添加超时控制、重试、断路器等功能,同时还能从服务连接中获取各种细节指标。

服务发现和负载均衡

1700786815224

故障处理

1700786847659

Istio 的规则配置

名词解释

  • VirtualService: 在Istio 服务网络中定义路由规则, 控制路由如何路由到服务上
  • DestinationRule VirtualService 路由生效后, 配置应用与请求的策略集
  • ServiceEntry 是通常用于在Istio服务网格之外启动对服务的请求
  • Gateway 为Http/Tcp 流量配置负载均衡器,最常见的是在网格边缘的操作,以启用应用程序的入口流量。

VirtualService

是在Istio 服务网格内对服务的请求如何进行路由进行控制。

规则的目标描述

image-20231125084057152

在服务之间流量拆分

image-20231125084230503

超时和重试

image-20231125084254833

匹配规则条件

image-20231125084345693

流量镜像

image-20231125084438621

规则委托

用于将代理规则的分机, 分组治理

image-20231125084510866

匹配规则优先级

当对同一目标有多个规则时,会按照在VirtualService 中的顺序进行应用,换句话中, 列表中的第一条规则具有最高的优先级。

DestinationRule

用来管理流量从envoy流量离开envoy到对端的时候, 的流量管理规则, 需要被VirtualService引用。

示例

image-20231125090701989

连接池和断路器(熔断器)

image-20231125090732131

ServiceEntry

用于将流量转发到在服务网格之外的服务

image-20231125091158293

WorkloadEntry

用来给ServiceEntry提供一种发现外部cluster的集群endpoint信息的方式

image-20231125091355721

Gateway

用来将服务网格内部的服务, 可以代理到外部访问, 核心还是通过istio-ingress 组件

注意:如果在配置VirtualService的时候, 指定了gateways, 那规则将只会下发给gateway节点, 否则适用于所有envoy节点。

image-20231125091638566

小结

微服务架构是当前业界普遍认可的架构模式,容器的封装性, 隔离性为微服务架构的兴盛提供了有力的保障。

Kubenetes 作为声明式集群管理系统,代表了分布式系统架构的大方向:

  • kube-proxy 本身提供了基于iptable/ipvs 的四层 Service Mesh 方案;
  • Istio/linked 作为基于Kubernetes 的七层 Service Mesh 方案, 近期会有比较多的部署案例;

生产系统需要考虑的,除了Service Mesh 架构带来的便利性,还需要考虑:

  • 配置一致性检查;
  • endpoint的健康检查;
  • 海量转发规则情况下的scalability;
刘小恺(Kyle) wechat
如有疑问可联系博主