【华为云】云原生入门级开发者认证学习笔记之服务网格之lstio技术

---

title: 云原生入门级开发者认证学习笔记之服务网格之lstio技术
tags:

• 云原生

写在前面

---

• 嗯，报了考试，整理课堂笔记记忆
• 学习的原因：
  • 虽然考了CKA,了解了一些K8s相关的知识
  • 但是对云原生整个体系一直都很模糊
  • 希望对云原生有一个基本的认识
  • 通过学习实现云原生相关入门
• 博文主要内容涉及：
  • 服务网格概念
  • Istio初识
  • Istio流量规则配置简介
  • istio常用的流量治理策略
  • 流量监控介绍
• 理解不足小伙伴帮忙指正

傍晚时分，你坐在屋檐下，看着天慢慢地黑下去，心里寂寞而凄凉，感到自己的生命被剥夺了。当时我是个年轻人，但我害怕这样生活下去，衰老下去。在我看来，这是比死亡更可怕的事。--------王小波

---

服务网格概念

Service Mesh是承载微服务架构理念的云原生技术形态

• 微服务源自服务化架构设计理念，与敏捷开发DevOps理念的结合：微—>小、快、独
• 经过技术演进，随着云计算发展到云原生阶段，服务网格（service Mesh）则成为承载微服务理念的新一代技术形态。

Serverless将进一步释放云计算的能力，将安全、可靠、可伸缩等需求交由基础设施实现，使用户仅需关注业务逻辑而无需关注具体部署和运行，极大地提高应用开发效率。同时这个方式促进了社会分工协作，云厂商可以进一步通过规模化、集约化实现计算成本大幅优化。

微服务技术演进：

服务治理能力内嵌在业务代码中

• 优点：简单使用依赖少
• 限制：代码耦合,代码重复高,运维复杂,开发要求高

服务治理能力抽象到统一SDK实现

优点：代码重复少,治理逻辑代码和业务代码分开
限制：SDK语言绑定,代码侵入,基于SDK开发学习门槛高,在用系统改造代价大,治理能力升级影响用户业务

服务治理还是和自身业务跑在一块，没有做完全的解耦。当sdk需要升级的时候，但有些服务很久没有编译过了，是一个老代码，sdk版本也老，要去编译重新溯源，更新sdk逻辑的话比较困难。

随着服务框架内功能的日益增多，复用不同编程语言开发的基础功能就显得十分困难，这也意味着微服务的开发人员将被迫绑定在某种特定语言之上，从而违背了微服务的敏捷迭代原则。(springcloud 相关组件)

服务治理能力归一到服务网格

• 优点：独立进程，用户业务非侵入，语言无关，治理逻辑升级业务无感知。已有系统无需改造即可治理，可以渐进的微服务化限制，代理的性能和资源开销
• 限制：代理的性能和资源开销

Service Mesh（服务网格）是什么

Service Mesh又译作服务网格，作为服务间通信的基础设施层。Buoyant公司的CEO Willian Morgan在他的这篇文章 WHAT'S A Service Mesh？AND WHY DOI NEED ONE？中解释了什么是Service Mesh，为什么云原生应用需要Service Mesh

服务网格（Service Mesh）是致力于解决服务间通讯的基础设施层。它负责在现代云原生应用程序的复杂服务拓扑来可靠地传递请求。实际上，Service Mesh通常是通过一组轻量级网络代理（Sidecar proxy），与应用程序代码部署在一起来实现，但对应用程序透明。

服务网格作为单独层的概念与云原生应用程序的兴起息息相关。在云原生模型中，单个应用程序可能包含数百个服务；每个服务可能有数千个实例；并且这些实例中的每一个都可能处于不断变化的状态，因为它们是由像Kubernetes这样的编排器动态调度的。这个世界中的服务通信非常复杂,管理网络对于确保端到端的性能和可靠性至关重要。

服务网格是一种网络模型，位于TCP/IP之上的抽象层。它假定底层L3/L4网络存在并且能够从点到点传送字节。服务网格的明确目标是将服务通信从不可见的、隐含的基础设施领域转移到 生态系统的一流成员 的角色中——可以对其进行监视、管理和控制。

好奇服务网格是不是可以理解为 K8s 中 NetWorkProlicy资源对象的集合？

服务网格的特点

• Service Mesh有如下几个特点：
  • 应用程序间通讯的中间层口
  • 轻量级网络代理
  • 应用程序无感知
  • 解耦应用程序的重试/超时、监控、追踪和服务发现

Service Mesh明星项目

什么是可用的service mesh呢？现在比较知名的项目有：

Istio ：由Lyft、IBM与google联合开发，Istio可以在不修改微服务源代码的情况下，轻松为其加上如负载均衡、身份验证等功能，它可以通过控制Envoy等代理服务来控制所有的流量。此外，Istio提供容错、金丝雀部署、A/B测试、监控等功能，并且支持自定义的组件和集成。 Preview2版本上开始支持lstio，用户可以直接在UI界面中启动Istio并且可以为每个命名空间注入自动sidecar。Rancher内置了一个支持Kiali的仪表盘，简化lstio的安装和配置。这一切让部署和管理Istio变得简单而快速。

Linkerd ：2016年发布，是这些项目中最老的。Linkerd是从Twitter开发的library中分离出来的。在这一领域另一位重量型选手，Conduit，已经进入了Linkerd项目并构成了Linkerd 2.0的基础。

Envoy ：由Lyft创建，为了能够提供完整的service mesh功能，Envoy占据“数据平面”的部分，与其进行匹配。

HashiCorp Consul ：与Consul 1.2一起推出了一项名为Connect的功能，为HashiCorp的分布式系统添加了服务加密和基于身份的授权，可用于服务发现和配置。

服务网格与微服务框架流量治理对比

微服务框架是基于SDK来实现的一些服务治理，需要将微服务框架的SDK嵌入到业务代码中去，从而造成侵入式开发，因此需要开发人员掌握微服务框架。而服务网格由sidecar注入的，就不需要修改业务代码。

Istio初识

Istio 项目发展历程：多个头部云厂商参与，已经商业Ready

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

Istio已日趋成为服务网格标准

Istio是一个提供连接、保护、控制以及观测功能的开放平台，通过提供完整的非侵入式的微服务治理解决方案，能够很好的解决云原生服务的管理、网络连接以及安全管理等服务网络治理问题。

• 连接：智能控制服务之间的流量和APl调用，进行一系列测试，并通过蓝绿部署逐步升级。
• 保护：通过托管身份验证、授权和服务之间通信加密自动保护服务。
• 控制：应用策略并确保其执行，使得资源在消费者之间公平分配。
• 观测：对服务进行多样化、自动化的追踪、监控以及日志记录。

对于云原生应用，采用Kubernetes构建微服务部署和集群管理能力，采用Istio构建服务治理能力，将逐渐成为应用微服务转型的标准配置。

Kubernetes在容器编排领域已经成为无可争辩的事实标准；微服务化的服务与容器在轻量、敏捷、快速部署运维等特征上匹配，这类服务在容器中的运行也正日益流行；

随着Istio的成熟和服务网格技术的流行，使用Istio 进行服务治理的实践也越来越多，正成为服务治理的趋势；而Istio与Kubernetes的天然融合且基于Kubernetes构建，也补齐了Kubernetes的治理能力，提供了端到端的服务运行治理治理平台。这都使得Istio、微服务、容器及Kubernetes形成一个完美的闭环。云原生应用采用Kubernetes构建应用编排能力，采用Istio构建服务治理能力，将逐渐成为企业技术转型的标准配置。

Istio整体架构

Istio采用service mesh（服务网格）设计，逻辑上分为数据平面和控制平面。

• 数据平面以sidecar方式配置代理（基于envoy实现）来管理数据通信。
• 控制平面负责管理和配置来控制数据平面和控制平面本身组件。

Istio 的控制平面本身就是一个现代的云原生应用程序。因此，它从一开始就是作为一组微服务构建的。

Pilot基本架构

概念：Pilot将各类平台的特异性服务发现机制抽象化并合成为符合istio sidecar的标准格式，用来提供服务发现，流量管理功能。

Pilot在方框图中，主要包含三个部分：平台适配层，xds生成器以及xds服务器。

功能：

原生支持Kubernetes，List-Watch Service、Endpoint，Pod，Node，etc XDS服务器向下对所有的数据面Sidecar提供,XDS配置中间内核层负责生成xDS配置，每一种xDS对应有一种生成器，XDS Generator可以实现lstio Al与Envoy API之间的转换。

Pilot是Istio进行流量治理的核心组件，其架构与Istio的设计理念是一致的。Pilot支持从Kubernetes、Consul等多种平台获取服务发现功能。

Citadel基本架构

概念：通过内置身份和凭证管理来实现服务间和最终用户的身份验证。

支持的安全功能：流量加密、身份认证、授权鉴权

我们在istio中，service与service的数据，默认是经过mtls加密之后再两边的envoy之间进行通讯，这样的好处是在零信任网络下打造微服务网络的安全，这个是非常重要的。

交互拆分：

• Citadel是服务网格的安全组件与NodeAgent一起为工作负载提供证书的签发、轮换。

• Citadel处理来自NodeAgent的CSR请求Citadel内部签发证书主要有两种形式：

• 本身作为证书签发机构（CA）自己签发

• 作为RA代理证书签名请求（CSR）请求

Galley基本架构

Galley负责配置管理相关的工作：

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

Galley负责配置校验以及配置摄取，创建Istio api的时候，k8s server会将请求发送给galley，galley会对istio api进行校验，从而判断是否允许创建。

Istio 应用场景

• 灰度发布：版本升级平滑过渡的一种方式，金丝雀发布、蓝绿发布等；
• 流量治理：负载均衡、连接池管理、熔断、故障注入等；
• 访问可视化：监控数据采集、运行指标分析、应用拓扑和调用链展示等；
• 业务场景：电商应用、政企业务、视频业务等。

蓝绿发布

• 蓝绿发布提供了一种零宕机的部署方式。不停老版本，部署新版本进行测试，确认OK，将流量切到新版本，然后老版本同时也升级到新版本。始终有两个版本同时在线，有问题可以快速切换。

• 在部署应用的过程中，应用始终在线。并且新版本上线过程中，不会修改老版本的任何内容，在部署期间老版本状态不受影响·只要老版本的资源不被删除，可以在任何时间回滚到老版本。

金丝雀发布

·
金丝雀发布也叫灰度发布

• 在生产环境上引一部分实际流量对一个新版本进行测试，测试新版本的性能和表现，在保证系统整体稳定运行的前提下，尽早发现新版本在实际环境上的问题。

• 通过在线上运行的服务中，新加入少量的新版本的服务，然后从这少量的新版本中快速获得反馈，根据反馈决定最后的交付形态。

• 基于权重的灰度发布: 可根据需要灵活动态的调整不同服务版本的流量比例

• 基于内容的灰度发布:可根据请求的内容控制其流向的服务版本（Cookie，Header，OS，Browser）

Istio流量规则配置简介

Istio 流量管理资源配置初识

• VirtualService 在 Istio 服务网格中定义路由规则，控制流量路由到服务上的各种行为。

• DestinationRule 是 VirtualService 路由生效后，配置应用与请求的策略集。

• Gateway 为 HTTP/TCP 流量配置负载均衡器，最常见的是在网格边缘的操作，以启用应用程序的入口流量。

• 为了在网格中导流，Istio 需要知道所有的 endpoint 在哪和属于哪个服务。为了定位到service registry(服务注册中心)，Istio 会连接到一个服务发现系统。例如，如果在Kubernetes 集群上安装了 Istio，那么它将自动检测该集群中的服务和 endpoint。

Gateway概述

Gateway为HTTP/TCP流量配置了一个负载均衡，用于启用一个服务的入口流量。和Kubernetes Ingress不同，Istio Gateway只配置四层到六层的功能（例如开放端口或者TLS配置）。绑定一个VirtualService到Gateway上，用户就可以使用标准的Istio规则来控制进入的HTTP和TCP流量。

• L7层的路由能力需要与VirtualService绑定。(路由规则匹配)

• Gateway描述了一个在网格边缘运行的负载均衡器，接收传入或传出的HTTP/TCP连接。该规范描述了一组应该暴露的端口、要使用的协议类型、负载均衡器的SNI配置等。

VirtualService概述

VirtualService（VS）：虚拟服务是lstio重要的资源对象之一。能够将流量路由到网格中的服务。支持基于权重、http header条件等优先级的路由，比Kuberentes service对于流量的管控更加的丰富，颗粒度更加精细。

VirtualService主要配置流量路由。VirtualService定义了一套当主机被寻址时应用的流量路由规则。每个路由规则定义了特定协议流量的匹配标准。如果流量被匹配，那么它将被发送到注册表中定义的指定目标服务（或它的子集/版本）。(类于Ingress的路由匹配)

DestinationRule概述

常常与VS（VirtualService）配合使用，VS定义一些策略将流量路由到某些目标服务，而DestinationRule允许用户针对目标服务配置一些负载均衡，异常检测，连接池以及证书。

DestinationRule还定义了对应目标主机的可路由subset。VirtualService在向特定服务版本发送请求时会用到这些子集。

DestinationRule定义了在路由发生后适用于服务流量的策略。这些规则指定了负载均衡的配置、来自sidecar的连接池大小，以及用于检测和驱逐负载均衡池中不健康主机的离群检测设置。

Istio常用的流量治理策略

流量治理策略：

服务注册&发现

负载均衡

支持的负载均衡算法：

• 加权轮询
• 最少请求
• 环形Hash
• 随机
• 优先级负载均衡
• Locality加权

负载均衡建立在现有网络结构之上，它提供了一种有效透明的方法扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。

默认情况下，lstio使用轮询的负载均衡策略，实例池中的每个实例依次获取请求。lstio同时支持如下的负载均衡模型，可以在DestinationRule中为流向某个特定服务或服务子集的流量指定这些模型。

路由（流量切分、灰度发布）

熔断机制

熔断，是创建弹性微服务应用程序的重要模式。熔断能够使应用程序具备应对来自故障、潜在峰值和其他未知网络因素影响的能力。

故障注入

故障注入可以用来识别系统最薄弱的环节，支持的类型：

• HTTP请求响应延时注入
• HTTP、gRPC错误码注入

在配置了网络，包括故障恢复策略之后，可以使用Istio的故障注入机制来为整个应用程序测试故障恢复能力。

故障注入是一种将错误引入系统以确保系统能够承受并从错误条件中恢复的测试方法。使用故障注入特别有用，能确保故障恢复策略不至于不兼容或者太严格，这会导致关键服务不可用。

可以注入两种故障，它们都使用VirtualService配置：

• Delay：延迟是时间故障。它们模拟增加的网络延迟或一个超载的上游服务。
• Abort：终止是崩溃失败。他们模仿上游服务的失败。终止通常以HTTP错误码或TCP连接失败的形式出现。

限流

Istio支持两种限流方式：

• 1.中心集中式限流
• 2.本地限流

失败重试

Istio支持失败重试HTTPRetry，提高系统的Resilience。

重试设置指定如果初始调用失败，Envoy代理尝试连接服务的最大次数。

通过确保调用不会因为临时过载的服务或网络等问题而永久失败，重试可以提高服务可用性和应用程序的性能。重试之间的间隔（25ms+）是可变的，并由lstio自动确定，从而防止被调用服务被请求淹没。HTTP请求的默认重试行为是在返回错误之前重试两次。

流量监控介绍

服务网格监控-Observability

Istio以非侵入的方式提供了以下遥测类型:

• Metrics：应用流量粒度的监控统计,Istio根据监控的四个“黄金信号”（延迟、流量、错误和饱和度）生成一组服务指标。Istio 还提供了网格控制平面的详细指标。还提供了基于这些指标构建的一组默认网格监控仪表板。

• Distributed Traces：分布式追踪,Istio为每个服务生成分布式跟踪跨度，使操作员能够详细了解网格内的调用流和服务依赖关系。

分布式追踪可以让用户对跨多个分布式服务网格的 1 个请求进行追踪分析。这样进而可以通过可视化的方式更加深入地了解请求的延迟，序列化和并行度。

• Access Logs：访问日志,当流量流入网格内的服务时，Istio可以生成每个请求的完整记录，包括源和目标元数据。此信息使操作员能够审核服务行为，直至单个工作负载实例级别。

Istio最简单的日志类型是Envoy的访问日志。Envoy代理打印访问信息到标准输出。Envoy容器的标准输出能够通过kubectl logs命令打印出来。