一文带你玩转云原生技术之Istio【与云原生的故事】

举报
nukinsan 发表于 2022/05/08 00:45:18 2022/05/08
【摘要】 Istio是一种云原生的、应用层的网络技术,用于解决组成应用的组件之间的连接、 安全、策略、可观察性等问题。Istio是服务网格技术云原生Cloud Native时代的产物,是云原生应用的新型架构模式。同时Istio也是一个与Kubernetes紧密结合的适用于云原生场景的Service Mesh形态的用于服务治理的开放平台。

本文主要内容:

1、Istio介绍

2、Istio发展

3、Istio核心特性

4、Istio整体架构

5、Istio服务网格实现原理

6、总结


1、Istio介绍


Istio是一种云原生的、应用层的网络技术,用于解决组成应用的组件之间的连接、 安全、策略、可观察性等问题。Istio是服务网格技术云原生Cloud Native时代的产物,是云原生应用的新型架构模式。同时Istio是一个与Kubernetes紧密结合的适用于云原生场景的Service Mesh形态的用于服务治理的开放平台。


2、Istio发展


GoogleIBMRedHat等开源巨头成熟的项目运作与社区治理机制下快速发展,Istio 作为第二代 Service Mesh 技术,通过基于K8s标准扩展的控制面带来了前所未有的灵活性及扩展能力,影响力远超更早出现的 LinkerdIstio背负巨大的使命,Google希望在继Kubernetes成为容器编排的事实标准之后,打造另一杀手锏级别的技术,成为服务网格的事实标准,GoogleIBM大厂的加持,在资源及影响力层面远非Buoyant可比拟的。众多厂商参与Istio社区,共同推进繁荣,从企业级可用的1.1版本之后,社区每隔3个月发布一个大版本。同时成立了Steering Committee,使社区的运作、治理更加透明。


3、Istio核心特性


3.1、流量管理

​微服务应用的最大的痛点就是处理服务间的通信, 而这一问题的核心其实就是 流量的管理

传统的微服务在金丝雀发布的路由功能在不借助于第三方框架,最简单的实现方法,就是在服务期间添加一个负载均衡(比如nginx)做代理, 通过修改配置的权重分配流量。

  • 缺点: 对流量的管理和基础设施绑定在一起, 难以维护

而使用 Istio就可以轻松的实现各种维度的流量控制。下图是典型的金丝雀发布策略:根据权重把 5% 的流量路由给新版本,如果服务正常,再逐渐转移更多的流量到新版本。

 


Istio 的流量控制功能主要分为三个方面:

  • 请求路由和流量的转移
  • 弹性功能, 包括熔断,超时, 重试
  • 调试能力, 包括故障注入和流量镜像

3.2、安全

Istio的安全特性解放了开发人员,使其只需要专注于应用程序级别的安全。istio提供了底层的安全通信通道,并为大规模的服务通信管理认证、授权和加密。有了istio,服务通信在默认情况下就是受保护的,可以让你在跨不同协议和运行时的情况下实施一致的策略,而所有这些都只需要很少甚至不需要修改应用程序。istio是独立于平台的,可以与Kubernetes(或基础设施)的网络策略一起使用。但它更强大,能够在网络和应用层面保护podpod或者服务到服务之间的通信。

Istio 中的安全架构是由多个组件协同完成的。

  • Citadel 是负责安全的主要组件,用于密钥和整数的管理
  • Pilot 会将安全策略配置发送给Envoy代理
  • Envoy执行安全策略来实现访问控制

安全策略架构和运作流程如下:


3.3、可观察性

​可观察性的作用

  1. 及时反馈异常或者风险使得开发人员可以及时关注、修复和解决问题(告警);
  2. 出现问题时,能够帮助快速定位问题根源并解决问题,以减少服务损失(减损);
  3. 收集并分析数据,以帮助开发人员不断调整和改善服务(持续优化)

Istio一共提供了三种不同类型的数据从不同的角度支撑起其可观察性:

  • 指标(Metrics:可以用于查看某一段时间范围内系统状态的变化情况, 甚至可以预测未来一段时间系统的行为。Istio中有四类不同的监控标识(响应延迟、流量大小、错误数量、饱和度)生成了一系列观测不同服务的监控指标,用于记录和展示网格中服务状态。
  • 日志(Access Logs:日志是软件系统中记录软件执行状态及内部事件最为常用也最为有效的工具。日志包含了系统状态更多的细节部分。在分布式系统中,日志是定位复杂问题的关键手段;同时,由于每个事件都会产生一条对应的日志,所以日志也往往被用于计费系统,作为数据源。对接 ELK 等日志分析系统后,可以快速的筛选出具有特定特征的日志以分析系统中某些特定的或者需要关注的事件
  • 分布式追踪(Distributed Traces:通过额外数据(Span ID等特殊标记)记录不同组件中事件之间的关联,并由外部数据分析系统重新构造出事件的完整事件链路以及因果关系。在服务网格的一次请求之中,Istio会为途径的所有服务生成分布式追踪数据并上报,通过 Zipkin 等追踪系统重构服务调用链,开发人员可以借此了解网格内服务的依赖和调用流程,构建整个网格的服务拓扑。

3.4、平台支持

Istio独立于平台,被设计为可以在各种环境中运行,包括跨云、内部环境、kubernetesMesos等等。你可以在Kubernetes或是装有ConsulNomad环境上部署Istioistio 目前支持:

  • Kubernetes上的服务部署
  • 基于Consul的服务注册
  • 服务运行在独立的虚拟机上

3.5、整合和定制

Istio的策略实施组件可以扩展和定制,与现有的ACL、日志、监控、配额、审查等解决方案集成。

4、Istio整体架构


Istio架构分层来看主要分为

控制面Istiod(PilotCitadelGalleySidecar-lnjector)

控制平面管理并配置代理来进行流量路由。此外,控制平面配置 Mixer 来执行策略和收集遥测数据。

数据面(EnvoyPilot-Agent)

数据平面由一组智能代理(Envoy)组成,被部署为 sidecar。这些代理通过一个通用的策略和遥测中心(Mixer)传递和控制微服务之间的所有网络通信。

 

4.1、Istiod控制面组成

控制面主要分为以下4部分:

  • Pilot:xDS服务器,为数据面代理提供各种配置
  • Citadel:为数据面签发证书
  • Galley:Admission Webhook,校验Istio API配置
  • Sidecar-lnjector:自动注入Sidecar


4.2、Pliot基本架构

Pilot基本架构:

  • 原生支持KubernetesList-Watch ServiceEndpointPodNodeetc
  • 扩展支持其他注册中心,以MCP协议的方式
  • xDS服务器向下对所有的数据面Sidecar提供xDS配置
  • 中间内核层负责生成xDS配置,每一种xDS对应有一种生成器,xDS Generator深入理解Istio APIEnvoy API之间的转换


服务列表中的istio-pilotistio的控制中枢Pilot服务。如果把数据面的envoy也看作一种agent,则Pilot类似传统C/S架构中的服务端Master,下发指令控制客户端完成业务功能。和传统的微服务架构对比,Pilot至少涵盖服务注册中心和Config Server等管理组件的功能。pilot可以直接从kubernetesconsul提取数据并将其构造和转换成istio的服务发现模型,因此pilot只有服务发现功能,无须进行服务注册。这种抽象模型解耦Pilot和底层平台的不同实现,可支持kubernetesconsul等平台。


4.3、Citadel基本架构

Citadel基本架构:

  • Citadel是服务网格的安全组件与NodeAgent一起为工作复杂提供证书的签发、轮换。
  • Citadel对下处理来自NodeAgentCSR请求
  • Citadel内部签发证书主要有两种形式:
  • 本身作为CA自己签发
  • 作为RA代理CSR请求


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


4.4、Galley基本架构

Galley负责配置管理相关的工作。
Galley
基本架构:

  • Admission Webhook提供配置校验
  • MCP Sink提供配置的摄取


5、Istio服务网格实现原理


5.1、流量治理基本API

API

意义

ServiceEntry

定义Kubernetes集群外部服务,提供非K8s服务发现或者跨集群的服务发现

VirtualService

定义一些路由匹配、灰度、故障注入等功能

DestinationRule

提供目标服务的负载均衡策略以及连接管理,熔断等策略

Gateway

为服务网格边缘提供基本的流量转发策略

5.2、流量治理基本原理


5.3、Istio流量治理的基本流程

在控制面会经过如下流程:
1)管理员通过命令行或者API创建流量规则;
2Pilot将流量规则转换为Envoy的标准格式;
3Pilot将规则下发给Envoy

在数据面会经过如下流程:
1Envoy拦截Pod上本地容器的Inbound流量和Outbound流量;
2)在流量经过Envoy时执行对应的流量规则,对流量进行治理。

5.4、Istio服务发现的基本流程

服务发现与负载均衡,只是一个种策略实施的特例:

1)提供服务的SvcB新增一个Pod(标号1);

2)在Pilot后台修改SvcB的集群配置(标号2);

3PilotSvcB的最新信息同步给该配置的订阅方(标号3),即SvcB的调用方SvcA对应的Proxy

4SvcA对应的Proxy增加到SvcB的链接(标号4),并实施负载均衡;

5.5、路由匹配


6、总结


随着云计算的发展,使用云平台的组织的确享受到了很多好处,但是,不可否认的是,采用云平台对DevOps团队有一定的压力,因为开发人员必须使用微服务架构来构建具有可移植性的服务,同时运营商也需要管理超大型的混合和多云的服务部署。

Istio可以连接、保护、控制和观察这些服务。从较高的角度来看,Istio有助于降低这些部署的复杂性,并减轻开发团队的负担。Istio是一个完全开源的服务网格,可以透明的集成到现有的分布式应用程序上。它也是一个平台,通过API可以将其集成到任何日志记录平台,监控和策略系统。Istio的功能多样性使得可以成功、高效运行分布式微服务架构,并提供一种统一的方式来保护、连接和监视微服务。


【与云原生的故事】有奖征文火热进行中:https://bbs.huaweicloud.com/blogs/345260

【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息, 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。