Istio 核心组件介绍
Istio 核心组件介绍
目录
Istio 是什么？
lstio架构
Istio核心组件
目录
Istio 是什么？
lstio架构
Istio核心组件
1、Pilot
2、Mixer
3、Citadel
4、Galley
5、Istio-sidecar-injector
6、Istio-ingressgateway
1、Sidecar ( 在 Istio 中，默认的 Sidecar 是 Envoy )：
数据平面组件：
控制平面组件：
回到顶部
Istio 是什么？
云平台令使用它们的公司受益匪浅。但不可否认的是，上云会给 DevOps 团队带来压力。为了可移植性，开发人员必须使用微服务来构建应用，同时运维人员也正在管理着极端庞大的混合云和多云的部署环境。 Istio 允许您连接、保护、控制和观察服务。
从较高的层面来说，Istio 有助于降低这些部署的复杂性，并减轻开发团队的压力。它是一个完全开源的服务网格，作为透明的一层接入到现有的分布式应用程序里。它也是一个平台，拥有可以集成任何日志、遥测和策略系统的 API 接口。Istio 多样化的特性使您能够成功且高效地运行分布式微服务架构，并提供保护、连接和监控微服务的统一方法。《摘抄于官方文档》
回到顶部
lstio架构
Istio 服务网格从逻辑上分为数据平面和控制平面
DataPlane（数据平面）：
由一组智能代理（Envoy）组成，被部署为 sidecar。这些代理负责协调和控制微服务之间的所有网络通信。他们还收集和报告所有网格流量的遥测数据
ControlPlane（控制平面）
控制平面通过管理和配置 Envoy 来管理流量。此外，控制平面pilot下发xds规则来实施路由策略，mixer收集检测到的监控数据。
回到顶部
Istio核心组件
数据平面组件：
1、Sidecar ( 在 Istio 中，默认的 Sidecar 是 Envoy )：
Envoy 是使用 C++ 开发的高性能代理，用于调解服务网格中所有服务的入站和出站流量。在 Istio 中，Envoy 被用于 Sidecar ，和对应的应用服务部署在同一个 Kubernetes 的 Pod 中。
Envoy 调解所有出入应用服务的流量。所有经过 Envoy 的流量行为都会调用 Mixer（只是report功能，check功能可以通过配置关闭），为Mixer 提供一组描述请求和请求周围环境的 Attribute 。根据 Envoy 的配置和 Attribute，Mixer 会调用各种后台的基础设施资源。而这些 Attribute 又可以在 Mixer 中用于决策使用何种策略，并发送给监控系统，以提供整个网格行为的信息。
控制平面组件：
1、Pilot
Pilot 为 Sidecar 提供“服务发现”功能，并管理高级路由( 如 A/B 测试和金丝雀部署 )和故障处理( 超时、重试、熔断器等 )的流量。Pilot 将这些“高级”的流量行为转换为详尽的 Sidecar (即 Envoy) 配置项，并在运行时将它们配置到 Sidecar 中。
Pilot 将服务发现机制提炼为供数据面使用的 API ，即任何 Sidecar 都可以使用的标准格式。这种松耦合的设计模式使 Istio 能在多种环境( Kubernetes、Consul 和 Nomad )下运行，同时保持用于流量管理操作的相同。
除了服务发现， Pilot 更重要的一个功能是向数据面下发规则，包括VirtualService 、DestinationRule 、Gateway 、ServiceEntry 等流量治理规则，也包括认证授权等安全规则。Pilot 负责将各种规则转换成Envoy 可识别的格式，通过标准的XDS 协议发送给Envoy,指导Envoy 完成功作。在通信上， Envoy 通过gRPC 流式订阅Pilot 的配置资源。如下图所示， Pilot 将VirtualService 表达的路由规则分发到Evnoy 上， Envoy 根据该路由规则进行流量转发。
2、Mixer
Mixer 是一个独立于平台的组件，通过从 Sidecar 和一些其他服务处收集数据，进而在整个 Service Mesh 上控制访问和执行策略。Sidecar 请求级别的 Attribute 被发送到 Mixer 进行评估。
Mixer 中包括一个灵活的插件模型，使其能够接入到各种主机环境和后端基础设施，从这些细节中抽象出 Envoy 代理和 Istio 管理的服务。利用 Mixer，可以精细控制网格和后端基础设施后端之间的所有交互。
Mixer 的设计具有以下特点：
无状态：Mixer 本身是无状态的，它没有持久化存储的管理功能。
高可用：Mixer 被设计成高度可用的组件，任何单独的 Mixer 实例实现 > 99.999% 的正常运行时间。
缓存和缓冲：Mixer 能够积累大量短暂的瞬间状态。Mixer 是Istio 独有的一种设计,不同于Pilot ，在其他平台上总能找到类似功能的服务组件。从调用时机上来说，Pilot 管理的是配置数据，在配置改变时和数据面交互即可；然而，对于Mixer 来说，在服务间交互时Envoy 都会对Mixer 进行一次调用，因此这是一种实时管理。当然，在实现上通过在Mixer 和Proxy 上使用缓存机制，可保证不用每次进行数据面请求时都和Mixer 交互。
Istio-telemetry：
Istio-telemetry是专门用于收集遥测数据的Mixer服务组件;如下图所示 所示，当网格中的两个服务间有调用发生时，服务的代理Envoy 就会上报遥测数据给Istio-telemetry服务组件，Istio-telemetry 服务组件则根据配置将生成访问Metric等数据分发给后端的遥测服务。数据面代理通过Report 接口上报数据时访问数据会被批量上报。
stio-policy：
stio-policy 是另外一个Mixer 服务，和Istio-telemetry 基本上是完全相同的机制和流程。如图所示，数据面在转发服务的请求前调用Istio-policy 的Check接口检查是否允许访问， Mixer 根据配置将请求转发到对应的Adapter 做对应检查，给代理返回允许访问还是拒绝。可以对接如配额、授权、黑白名单等不同的控制后端，对服务间的访问进行可扩展的控制。
3、Citadel
Istio Citadel 安全功能提供强大的身份验证功能、强大的策略、透明的 TLS 加密以及用于保护服务和数据的身份验证、授权和审计（AAA）工具，Envoy 可以终止或向网格中的服务发起 TLS 流量。为此，Citadel 需要支持创建、签署和轮换证书。Istio Citadel 提供特定于应用程序的证书，可用于建立双向 TLS 以保护服务之间的流量。
Citadel 一直监听Kube-apiserver ，以Secret 的形式为每个服务都生成证书密钥，并在Pod 创建时挂载到Pod 上，代理容器使用这些文件来做服务身份认证，进而代理两端服务实现双向TLS认证、通道加密、访问授权等安全功能，这样用户就不用在代码里面维护证书密钥了。如下图所示，frontend 服务对forecast 服务的访问用到了HTTP 方式，通过配置即可对服务增加认证功能， 双方的Envoy 会建立双向认证的TLS 通道，从而在服务间启用双向认证的HTTPS 。
4、Galley
Istio-galley 并不直接向数据面提供业务能力，而是在控制面上向其他组件提供支持。Galley 作为负责配置管理的组件，验证配置信息的格式和内容的正确性，并将这些配置信息提供给管理面的Pilot和Mixer服务使用，这样其他管理面组件只用和Galley 打交道，从而与底层平台解耦。它负责将其他的 Istio 组件与从底层平台（例如 Kubernetes）获取用户配置的细节中隔离开来，在新的版本中Galley的作用越来越核心。
5、Istio-sidecar-injector
Istio-sidecar-injector 是负责向动注入的组件，只要开启了自动注入，在Pod 创建时就会自动调用Istio-sidecar-injector 向Pod 中注入Sidecar 容器。
在Kubernetes环境下，根据自动注入配置， Kube-apiserver 在拦截到Pod 创建的请求时，会调用自动注入服务Istio-sidecar-injector生成Sidecar 容器的描述并将其插入原Pod的定义中，这样，在创建的Pod 内除了包括业务容器，还包括Sidecar 容器。这个注入过程对用户透明，用户使用原方式创建工作负载。
6、Istio-ingressgateway
Istio-ingressgateway 就是入口处的Gateway ，从网格外访问网格内的服务就是通过这个Gateway 进行的。Istio-ingressgateway 比较特别，是一个Loadbalancer 类型的Service,不同于其他服务组件只有一两个端口, Istio-ingressgateway 开放了一组端口，这些就是网格内服务的外部访问端口
如下图 所示，网格入口网关Istio-ingressgateway 的负载和网格内的Sidecar 是同样的执行体，也和网格内的其他Sidecar 一样从Pilot处接收流量规则并执行。。Istio 通过一个特有的资源对象Gateway 来配置对外的协议、端口等。
来源：https://www.cnblogs.com/Mr-Axin/p/14752458.html