第二十节 Istio的试用建议

前面已经展示了istio的大多数功能，在无须对程序进行修改（分布式跟踪除外)的情况下，能对应用提供如此之多的功能支持，可以证明Istio是非常有吸引力的。

Istio的功能集完全可以说是服务网格技术的典范。 然而，作为一个新生事物，Istio还很初级的。虽然前面讲了很多功能，但笔者认为对于选型决策来说，更重要的是：

该系统具有什么样的缺点，我们能否接受， 对于无法接受的问题是否可以规避。下面仅就笔者个人的认知，列出Istio的一些问题，同时结合以往的经验，谈谈试用Istio时的一些建议和注意事项。

结合Istio的现状，以及多数企业的运行状态，个人浅见：Istio的应用在现阶段只能小范围试探性地进行，在进行过程中要严格定义试用范围，严控各个流程。

按照个人经验，笔者将试用过程分为如下4个阶段。

• 范围定义：选择进入试用的服务，确定受影响的范围，并根据Istio项目现状决定预备使用的Istio相关功能。围绕这些需要，制定试用需求。
• 方案部署：根据范围定义的决策，制定和执行相关的部署工作。其中包含Istio自身的部署和业务服务、后备服务的部署工作。
• 测试验证：根据既有业务目标对部署结果进行测试。
• 切换演练：防御措施，用于在业务失败时切回到原有的稳定环境。下面会根据这几点内容，逐一展开讨论）

1、Istio自身的突出问题

API稳定性可能是最严重的一个问题。目前最成熟的功能组别应该是流量控制，其版本号也仅是v1alpha 3。一般来说，alpha阶段的产品，不会提供向后兼容的承诺，流量控制API在从v1alpha 2升级为v1alpha 3的过程中，API几乎全部改写，使得很多早期用户的精力投入付诸东流。核心功能尚且如此，更别提相对比较"边缘”的Mixer,Citadel及Galley组件的相关内容。

Istio的发布节奏和发布质量方面的问题也相当严重。在Istio并不算长的历史中出现了多次版本撤回、大版本严重延期、发布质量低下无法使用及Bug反复等状况，这无疑会让每次升级尝试都充满了不确定性，会极大影响生产过程的连续性。

• Mixer：是一个问题焦点，其数据模型较为复杂，并且将所有应用的流量集一点，虽然在其中加入了各种缓存等技术来减少延迟，但是其独特地位决定了Mixer始终处于一个高风险的位置。

• Pilot在性能方面也经常被人垢病，虽然经过几次升级，但仍在1.0版本之后，出现了Pilot在集群中服务或Pod过多的情况下会超量消耗资源的两次状况。

安全、物理机和虚拟机的支持及网格边缘通信这二组功能。目前用户较少，质量尚不明确。

最后就是Istio sidecar注人模式，这种模式一定会增加服务间调用的网络延迟，目前是一个顽疾, Sidecar的固定延迟和Mixer的不确定行为相结合，有可能会产生严重后果。

这里提出的只是被反复提及或者经常出现在Issue列表中的问题，从发布的问题来看，面临的风险可能远不止这些。

2、确定功能范围

在Istio中包含了非常多的功能点，从原则上来说，各种功能都是有其实际作用的然而，Istio 作为一个新产品，本身也有很多不足.

Istio提供的众多功能对每个公司或者项目，都会有不同价值。我们在采用一个 新系统时，首先要考虑的就是性价比问题，这里的“价" 对业务应用的影响，还包括可能出现的服务停机等问题 代表着Istio带来的风险、

笔者曾经做出这样一个性价比的降序排列，如下所述。

1. 服务监控和跟踪：对存量应用提供服务质量可视化支持，并且可以通过自定义实现指标和日志的定制，有效地根据服务质量的变化提供告警和分析支持。
2. 路由管理：能有效地支持版本更新和回滚、金丝雀测试等发布相关的功能；并且其中的重试控制、超时控制对应对网络波动非常具有实际意义；同时，故障注入和流量复制功能对测试来说也是很有帮助的。
3. 限流和黑白名单功能：能有效地提高服务的健壮性；但是从这里开始，风险已经开始提高了。
4. mTLS和RBAC功能：大幅提高安全性，带来的代价是因为配置错误或者证书轮转等问题，造成服务中断的风险。

当然，每个不同的组织都可能会有自己的评判方法，这里的排列仅供参考。

在制定了优先级列表之后，就可以根据这一列表，结合项目的实际需求，按照效果明显、功能稳定、部署成本低、少改造或者不改造的标准来进行选择，最终确定待测试的功能点。

在选定功能点之后，应该遵循目前已有的Istio文档，对各个功能点进行单项测试和验证，以确保其有效性。并通过官方GitHub的Issue列表及讨论组内容，了解现有功能是否存在待解决的问题，以及相关的注意事项等。

3、选择试用业务

在试用功能点确定之后，就要选择用于试用的业务应用了。Istio作为一个相对底层的系统，其部署和调试过程必然会对业务产生一定的影响，在运行阶段又有Sidecar和各个组件造成的损耗，如下所述。

• 所有网格之间的通信都要经过Sidecar的中转，会造成大约10毫秒的延迟。
• Pilot对集群规模敏感，集群中的服务数量、Pod数量都可能对Pilot造成较大影响，也会影响到Istio各种规则向Pod的传输过程。
• 所有流量都会经由Mixer处理，也有造成瓶颈的可能。
• 安全功能设置不当同样会造成服务中断。

如上所述还只是个概要，对业务来说，对这些风险都是必须正视并做好预案的。

为了避免引起过大损失，建议将如下标准作为选择试用服务的依据。

• 能够容忍一定的中断时间：不管是Istio还是其他新技术的采用，都可能会造成服务中断，应该避免选择使用关键业务进行试点
• 对延迟不敏感：对于高频度、低延迟的服务类型，Sidecar造成的固定延迟总体来看会非常可观，因此不建议采用这种负载类型的业务作为试用服务。
• 调用深度较浅：一个试用服务如果包含太多层次，则每个层次之间都会因为Sidecar的延迟变慢少许，但是叠加起来会使得整个业务产生比较明显的延迟。
• 能够方便地回滚和切换：应该在前端负载均衡器、反向代理方而做好切换准备，在服务发生中断时，能够迅速切回原有环境。
• 具备成熟完善的功能、性能和疲劳测试方案：试用服务的上线必须有一个明确的标准，并以符合标准的测试结果来对标准进行验证。

4、调用过程

在选择了Istio功能这方面的建议。能范围和试用服务之后，就应该开始试用了，这里分享笔者在

4-1 制度目标

首先按分析类似， 照现有业务的实际需要，对试用服务进行功能分析。和传统的需求功能要在该过程中明确一些具体的需求内容。

• 环境需求：

说明Istio部署所需的Kubernetes部署需求，的系统资源需求，并根据实际的组织运行流程进行申请、以及整体功能所需分配，建立环境需求说明书供后续步骤核对。

• 功能性需求：

在Istio的功能中选择需要Istio为试用服务提供支撑的功能应形成功能测试案例。

• 服务质量需求：

根据现有业务的运行状况，对服务质量提出具体要求，例如并发数量、响应时间、成功率等，应形成性能测试案例。

• 故障处理需求：

对于试点应用发生故障时，如何在网格和非网格版本的试用服务之间进行切换以降低故障影响，应形成故障预案。

这里需要重视的一点是，在试用过程中，非常不建议"借机会"对现有试点应用进行业务或者负载方面的改动，以免试用过程造成干扰，混淆试用结果。

另外，建议形成一份关联服务列表, 用于评估试用服务的影响范围，尤其是关网格外服务的引用会影响注人行为，有需要额外关注。

4-2 方案部署

试用方案的部署过程可以分为以下儿步。

1. Istio部署首先是基本环境的准备，按照在上节中制定的环境需求，复查集群环境。 如果是内网部署，则应该部署内网可达的私有镜像库，推送全部所需的镜像，并利 用He In：变量设置合理的镜像地址。 接

下来根据试用需求，利用Helm对Istio部署进行调整，这方面的调整主要分为两类：资源调度和功能裁剪，如下所述。

先说功能调度，Istio的默认配置是非常保守的，申请的CPU和内存资源都很低， 并且残留了一部分调试信息，这是为了让测试用户在尽量少消耗资源的前提下，尽可能多地体验Istio的功能而设计的，而我们的目的是为生产服务，自然就应该根据实际应用进行调节了。

目前可以通过values.yaml进行调整的资源项目如下。

• proxy.resources：负责指定Sidecar的资源分配。
• defaultResources：负责Istio各个控制面组件的默认资源分配。
• gateway.resources：负责Istio Gateway Controller的资源分配。
• pilot.resources：负责Pilot组件的资源分配。

在试用过程中，建议详细调整各个组件及Sidecar的资源设置，并启用HPA.

Istio官方给出的一些资源分配建议如下。

• 在每秒有1000个请求并打开日志的情况下，Sidecar需要1 vCPU。
• Mixer预检功能在每秒有1000请求的情况下，如果缓存达到80%的命中率，则需要0.5 vCPU。
• 服务间的延迟通常会增加10毫秒。

笔者给出如下补充建议。

• 在试用过程中，尤其是在压力测试或业务高峰场景下，建议利用节点亲和性及Pod亲和性设置，将控制面和数据面分离，以备在出现性能问题时迅速排查。
• 在默认情况下，多个组件都开启了访问日志（可能来自各进程本身，也有可能来自stdio适配器），这而可能会严重影响性能，需要检查并进行设置。
• 部分组件开启了跟踪功能，也可能会对性能有所影响。
• 对服务器节点的I/O要严密关注，也应随时注意Istio控制面各应用的资源占用和HPA工作情况。

在设置好资源及相关选项之后，还应根据试用目标来对Istio组件功能进行裁剪，例如:

• 增删Ingress Gateway Controller; Prometheus, Grafana这些第三方组件是否启动；
• Galley校验
• Mixer预检是否使用等。

还需要对Istio进行一些个性化配置，例如开放端口、Ingress资源等。 上

述这些内容都可以在values.yarml中进行配置。

1. 后备服务部署

在进行试用应用的注入之前，首先应该部署一组备份服务，这组服务需要和整体服务网格进行隔离。这一组备份服务应处于待机模式，以备网格版本的应用在出现故障时，进行整体切换。

基于这一点考虑，负载均衡等前端控制设施也应备齐。

1. 试用服务部署

接下来要把试用服务部署到网格中，同其他Kubernetes一样，网格应用的部署也是从YAML代码开始的。原有应用的部署代码需要根据Istio标准进行复核，检查其中的端口命名、标签设置。

除了待注人的应用清单文件，还应该为每个部署单元都提供默认的 VirtualService和Destination Rule，建立基本的路由关系，提供一个路由基准，方便 在路由调整过程中进对比。

制定的具体网格需求列表，逐个编写所需的路由、规则等方面的配置内容。

在这些都完成之后，就可以按照顺序逐个提交部署了。

4. 监控告警部署

在试用服务部署之后，就有更多的项目可以监测了，这里建议将其自带的Prometheus进行变更，连接到能够有效发出告警的Alertmanager组件上，并为以下几组目标进行监测和告警。

• Pilot的内存和Cpu占用：Pilot的资源消耗问题反复出现多次，需要重点关注。
• Mixer的内存占用：Mixer的缓存到目前为止还尚未完善，有风险。
• 业务应用的成功率：尤其是启用了mTLS的Istio服务网格，应该着重关注。
• 业务应用的响应时长：响应时长有可能受到Envoy Sidecar和Mixer/Adapter的多重影响，需要重点关注。
• 关联服务列表：应根据在上节中制定的关联服务列表，提高对影响范围内的服务的监控级别。

4-3 测试验证

根据在20.4.1中制定的功能需求对试用服务进行功能测试，在测试通过之进行性能和疲劳测试，观察各方面的性能指标是否符合，如果性能出现下降，则可以尝试扩容，提高资源分配率。关键组件可能是Istio自身的问题, 应检查社区Issue或提出新的Issue。

此处是一个关键步骤， 如果测试方案不符合实际情况或者预期目标无法达到，则强烈建议放弃试用。

4-4 切换演练

在功能 和性能测试全部通过之后，就应该进行试用服务和后备服务之间的双向，在双方切换之后都应该重复进行在20.4.3节提到的验证过程，防止故障反复。

切换演练是试点应用的最后一道保险，在网格严重故障之后能否迅速恢复业务，全靠这一步的支持。

4-5 试点上线

在通过测试验证和切换演练的过程之后，就可以将试用的网格应用上线到生产环境开始试运行了。和所有其他上线活动一样，在上线之后需要提高监控级别，关注试用服务自身和试用服务影响范围内的相关功能的健康情况。