istio详解_istio架构和原理「建议收藏」

istio详解_istio架构和原理「建议收藏」1.1Istio是什么我们尝试用迭代方式来说明:Istio是用于服务治理的开放平台Istio是ServiceMash形态的用于服务治理的开放平台Istio是一个与Kubernetes紧密结合的适用

istio详解_istio架构和原理「建议收藏」"

1.1 Istio 是什么

我们尝试用迭代方式来说明:

  • Istio 是 用于服务治理 的开放平台
  • Istio 是 Service Mash形态 的用于服务治理的开放平台
  • Istio 是一个与 Kubernetes紧密结合 的 适用于云原生场景的 Service Mash 形态的 用于服务治理的开放平台。这里的治理 不局限于微服务治理,任何服务,只要服务间有访问,如果需要对服务间的访问进行管理,就可以使用Istio。根据Isio官方介绍,服务治理及连接(connect)、安全(secret)、策略执行(control)和可观察性(observe)。
  • 连接:Istio 通过集中配置的流量规则控制服务间的流量和调用,实现负载均衡、熔断、故障注入、重试、定向等服务治理功能。
  • 安全:Istio 通过透明的认证机制、通道加密、服务访问权限等安全能力,可增强服务访问的安全性。
  • 策略执行:Istio 通过可动态插拔、可扩展的策略实现访问控制、速率限制、额配管理、服务计费等能力。
  • 可观察性:动态获取服务运行数据和输出,提供强大的调用链、监控和调用日志收集输出的能力。配合可视化工具,可方便运维人员了解服务的运行状态,发现并解决问题。

1.2 Istio 提供的重要能力:

  • 服务运行可观察性:监控应用及网络相关数据,将相关指标与日志记录发生至任意收集、聚合与查询系统中意实现功能扩展,追踪分析性能热点并对分布式故障模式进行诊断。
  • 弹性效率:提供了统一的方法配置重试、负载均衡、流量控制和断路器等来解决网络可靠性低所造成的各类常见故障,更轻松地运维高弹性服务网格。
  • 研发人员生产力:确保研发人员专注于基于已选择的编程语言构建业务能力,不用在代码中处理分布式系统问题,从而极大地提升生产能力。
  • 策略驱动型运营:解耦开放和运维团队的工作,在无须更改代码的前提下提升安全性、监控能力、扩展性与服务拓扑水平。运营人员能够不依赖开发提供的能力精确控制生产水平。
  • 默认安全:允许运维人员配置TLS双向认证,并保护各服务之间的所有通信,并且开发人员与运维人员不用维护证书,以应对分布式计算中经常存在的大量网络安全问题。
  • 增量适用:考虑到在网络内运行的各类服务的透明性,允许团队按照自己的节奏和需求逐步使用各项功能,例如先观察服务运行情况再进行服务治理等。

1.3 通过示例看看Istio 做了什么

首先来看下Istio在服务访问过程中做了什么。一个简单的Client访问Server,对两者使用开发语言没有任何要求,可以是Client采用node.js编写,server采用java编写。在Client中访问服务server,在两个程序中不用包含任何服务访问管理的逻辑。

来看看Istio在其中做了什么:

  • 自动通过服务发现获取server服务实例的列表,并根据负载均衡策略选择一个服务实例。
  • 对服务双方启用双向认证和通道加密。
  • 如果某个服务实例连续访问出错,则可以自动将该实例隔离一段时间,以提高访问质量。
  • 设置最大连接数、最大请求数、访问超时等对服务进行保护。
  • 限流。
  • 对请求进行重试。
  • 修改请求中的内容。
  • 将一定特征的服务重定向。
  • 灰度发布
  • 自动记录服务访问信息。
  • 记录调用链,进行分布式追踪。
  • 根据访问数据形成完整的应用访问拓扑。

所有这些功能,都不用用户修改代码,用户只需要在Istio 的控制面做些配置即可,并且动态生效。以灰度测试为例,在Istio中通过简单配置实现灰度发布,核心是实现两个版本同时在线,并通过一定的流量策略将部分流量引流到新版本上。无须改动代码,只需要简单的一个配置即可:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: server
spec:
  hoste:
  - server
  http:
  - match:
    - headers:
      cookie:
        exact: "group=dev"
    route:
    - destination:
      name: v2
  - route:
    - destination:
      name: va    

将group为dev的流量转发到server的v2版本,其他用户访问的还是v1,从而实现灰度发布。整个过程中除了Istio配置需要修改,其他不需要做任何事情。

1.4 组件介绍

在集群中通过“kubectl get svc -n istio-system” 获取isto 的各组件

NAME                     TYPE           CLUSTER-IP       EXTERNAL-IP   PORT(S)                                                                                                                      AGE
grafana                  ClusterIP      10.109.18.105    <none>        3000/TCP                                                                                                                     46h
istio-citadel            ClusterIP      10.97.247.24     <none>        8060/TCP,15014/TCP                                                                                                           46h
istio-egressgateway      ClusterIP      10.106.34.148    <none>        80/TCP,443/TCP,15443/TCP                                                                                                     46h
istio-galley             ClusterIP      10.103.74.254    <none>        443/TCP,15014/TCP,9901/TCP,15019/TCP                                                                                         46h
istio-ingressgateway     LoadBalancer   10.99.94.178     localhost     15020:30397/TCP,80:32621/TCP,443:32749/TCP,15029:31666/TCP,15030:32662/TCP,15031:30400/TCP,15032:32139/TCP,15443:32435/TCP   46h
istio-pilot              ClusterIP      10.98.146.59     <none>        15010/TCP,15011/TCP,8080/TCP,15014/TCP                                                                                       46h
istio-policy             ClusterIP      10.109.93.7      <none>        9091/TCP,15004/TCP,15014/TCP                                                                                                 46h
istio-sidecar-injector   ClusterIP      10.100.143.27    <none>        443/TCP                                                                                                                      46h
istio-telemetry          ClusterIP      10.110.99.43     <none>        9091/TCP,15004/TCP,15014/TCP,42422/TCP                                                                                       46h
jaeger-agent             ClusterIP      None             <none>        5775/UDP,6831/UDP,6832/UDP                                                                                                   46h
jaeger-collector         ClusterIP      10.108.7.167     <none>        14267/TCP,14268/TCP,14250/TCP                                                                                                46h
jaeger-query             ClusterIP      10.107.85.181    <none>        16686/TCP                                                                                                                    46h
kiali                    ClusterIP      10.103.150.239   <none>        20001/TCP                                                                                                                    46h
prometheus               ClusterIP      10.110.122.226   <none>        9090/TCP                                                                                                                     46h
tracing                  ClusterIP      10.105.32.84     <none>        80/TCP                                                                                                                       46h
zipkin                   ClusterIP      10.107.56.80     <none>        9411/TCP                                                                                                                     46h

1、istio-pilot

pilot 是Istio 的控制中心,下发指令控制完成作业。Pilot 直接从平台提取数据并将构建和转换成Istio 的服务发现模型。因此Pilot只有服务发现功能,而无服务注册功能。这种抽象框架解耦了Pilot和底层平台的不同实现,可支持kubernetes、Consul等平台。
除了服务发现,Pilot更重要的一个功能是向数据面下发规则,包括VirtualService、DestinationRule、Gateway、ServiceEntry等流量治理规则,也包括认证授权等安全机制。Pilot负责将各种规则转换成Envoy可识别的格式,通过标准的xDS协议发送给Envoy,指导Envoy完成动作。在通信上Envoy通过gRPC流式订阅Pilot的配置资源。例如Pilot将VirtualService表达的路由规则分发到Envoy上,Envoy将根据该路由规则进行流量转发。

2、telemetry

telemetry是专门用于收集遥测数据的Mixer服务组件,如服务列表所示,在部署上,Istio 控制面部署了两个Mixer组件:telemetry和policy,分别处理遥测数据的收集和策略的执行。查看两个组件的Pod镜像会发现,容器的镜像是一样的,都是“/istio/mixer”。
Mixer 是Istio独有的一种设计,不同于Pilot,在其他平台上总能找到类似功能的服务组件。从调用时机来说,Pilot管理的是配置数据,在配置改变时和数据面交互即可;然而,对于Mixer来说,在服务间交互时Envoy都会对Mixer进行一次调用,因此这是一种实时管理。当然,通过在Mixer和Proxy上使用缓存机制,可保证不用每次进行数据请求时都和Mixer交互。
当网络中的两个服务间有交互发生时,服务的代理Envoy就会上报遥测数据给telemetry 服务组件。telemetry服务组件根据配置将生成访问Mixer等数据分发给后端的遥测服务。数据面代理通过report 接口上报数据时访问数据会被批量上报。
在架构上,Mixer 作为中介来解耦数据面和不同后端的对接,以提供灵活性和扩展能力。运维人员可以动态配置各种遥测后端,来收集指定的服务运行数据。

3、policy

policy 时另外一个Mixer服务,和telemetry基本上是完全相同的机制和流程。数据面在转发服务的请求前,调用policy的Check接口检查是否允许访问。Mixer根据配置将请求转发到对应的Adapter做对应检查,给代理返回允许访问还是拒绝。可以对接如 配额、授权、黑白名单等不同的控制后端,对服务间的访问进行可扩展的控制。

4、citadel

citadel是Istio的核心安全组件,提供了自动生成、分发、轮换与撤销秘钥和证书功能。Citadel一直监听kube-apiserver。以secret的形式对每个服务都生成证书秘钥,并在Pod创建时挂载到Pod上,代理容器使用这些文件来做服务身份认证,进而代替两端服务的双向TLS认证、通道加密、访问授权等安全问题功能,这样用户就不用再代码里面维护证书秘钥了。例如两个服务之间采用HTTP进行通信,通过配置即可对服务增加认证功能,双方的Envoy会建立双向认证的TLS通道,从而在服务间启用双向认证的HTTPS。

5、galley

galley并不直接向数据面提供业务能力,而是在控制面上向其他组件提供支持。galley作为负责配置管理的组件,验证配置信息的格式和内容的正确性,并将这些配置信息提供给管理面的Pilot和Mixer服务使用,这样其他的管理组件只用和galley打交道,从而与底层平台解耦。在新的版本中galley的作用越来越重要。

6、sidecar-injector

sidecar-injector 是负责自动自动注入的组件,只要开启自动注入,在Pod创建时就会自动调用istio-sidecar-injector 向Pod中注入Sidecar 容器。
在kubernetes环境中,根据自动注入配置,Kube-apiserver 在拦截到Pod创建的请求时,会调用自动注入服务istio-sidecar-injector 生成Sidecar容器描述并将其插入原Pod的定义中,这样,在创建的Pod内除了包括业务容器,还包括Sidecar容器。这个注入过程对用户透明,用户使用原始的方式创建工作负载。

7、Istio-Proxy

在很多和Istio相关的地方,会将Envoy、Sidecar、Proxy等术语有时是混着用的,都表示Istio数据面的轻量代理。但关注Pod详细信息,会发现这个容器的正式名称是istio-proxy,不是通用的Envoy镜像,而是叠加了Istio的Proxy功能的一个扩展版本。另外,在istio-proxy容器中除了有Envoy外还有一个Pilot-agent的守护进程。未来如果能在istio-proxy 中提供Mixer的部分能力,将会是一个非常紧凑的设计。
Envoy是用C++开发的非常有影响力的轻量级高性能开源服务代理。作为服务网格的数据面,Envoy提供了动态服务发现、负载均衡、TLS、HTTP/2及gRPC代理、熔断器、健康检查、流量拆分、灰度发布、故障注入等功能,istio描述的大部分自治能力最终都落实到Envoy的实现上。
在Istio中,规则被描述的对象都是被访问者,但是真正的规则执行位置,对于不同的类型的动作可能不同,可能在被访问服务的Sidecar拦截到Inbound流量时,或是在访问者的Sidecar拦截到outbound流量时执行,一般后者居多。当给一个服务定义流量规则时,所有访问该服务的Sidecar都收到规则,并且执行相同的治理逻辑,从而对目标服务执行一致的治理。下面列出常用的服务治理规则和其执行位置。

治理规则 治理位置:服务发起方 治理位置:服务发起方
路由管理 *
负载均衡 *
调用链分析 * *
服务认证 * *
遥测数据 * *
重试 *
重写 *
重定向 *
鉴权 *

8、Ingressgateway

ingressgateway 就是入口处的Gateway,从网络外访问网格内的服务就是通过这个Gateway进行的。ingressgateway比较特别的是,是一个LoadBalance类型的Service,不同于其他服务组件只有一两个端口,ingressgateway开发了一组端口,这些就是网格内服务的外部访问端口。网格入口网关ingressgateway的负载和网格内的Sidecar是同样的执行体,也和网格内的其他Sidecar一样从Pilot接收流量规则并执行。因为入口处的流量都走这个服务,会有较大的并发可能出现流量峰值,所有需要评估流量来规划和实例数。Istio通过一个特有的资源对象Gateway来配置和对外的协议、端口等。

9、其他组件

除了以“Istio” 为前缀的以上几个Istio自有组件,在集群中一般还安装了jaeger-agent、jaeger-collector、jaeger-query、Kiail、Prometheus、Tracing、ZIPkin组件,这些组件提供了Istio调用链、监控等功能,可以选择安装来完成完整的服务监控管理功能。

今天的文章istio详解_istio架构和原理「建议收藏」分享到此就结束了,感谢您的阅读。

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。
如需转载请保留出处:https://bianchenghao.cn/65632.html

(0)
编程小号编程小号

相关推荐

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注