服务网格规模化应用下的Istio Sidecar配置管理挑战与实践｜IstioCon 2022

最新推荐文章于 2022-06-25 23:14:21 发布

阿里巴巴中间件

最新推荐文章于 2022-06-25 23:14:21 发布

阅读量682

点赞数

文章标签：大数据分布式编程语言数据库 python

本文链接：https://blog.csdn.net/weixin_39860915/article/details/124743377

版权

本文探讨了在服务网格Istio规模化应用中面临的Sidecar配置管理挑战，介绍了阿里云ASM如何通过灵活配置方案解决这些问题。文章分析了社区Istio Sidecar配置现状，指出配置粒度问题，提出阿里云服务网格ASM的架构和Sidecar代理配置能力，包括命名空间和工作负载标签范围的配置管理。同时，分享了ASM如何实现Sidecar代理生命周期管理和TLS加速，并对比了ASM与Istio社区ProxyConfig的异同。文章最后展望了未来的发展方向。

摘要由CSDN通过智能技术生成

服务网格是服务间通信的基础设施层，服务网格 Istio 近期已经宣布了加入云原生计算基金会（CNCF）的意向，今后会得到更多开发者的信任和应用。阿里云内部很早就开始调研并实践 ServiceMesh 技术，通过总结业务场景落地经验，持续驱动技术发展，积累一系列服务网格核心技术，并将其沉淀成为业界首个兼容 Istio 的托管式服务网格平台 ASM（ Alibaba Cloud Service Mesh，简称 ASM）。

阿里云服务网格 ASM 在帮助客户落地实践过程中发现，随着集群管理的规模增长和配置复杂度的提升，对于不同的工作负载，目前 Sidecar 代理配置不够灵活。希望通过本次分享，能帮助大家在不同的业务场景下灵活配置 Sidecar 代理的配置来满足个性化需求、优化系统性能。

Istio Sidecar代理配置现状

Aliware

社区Istio Sidecar代理配置

在 Istio 社区方案中，修改 Sidecar 代理配置的方法有很多种。

1）最细粒度的方式，通过逐个修改 Deployment 等 workload 的 templateAnnotation，从而对注入到 Pod 中的 Sidecar 代理配置生效。

2）服务网格全局配置，可以在 Global Mesh Options 中配置 ProxyConfig 内容，这种方式对服务网格中所有注入了 Sidecar 的 Pod 全部生效，但生效优先级低于前者。前 2 种配置完成后，需要重新创建 Pod。

3）通过 EnvoyFilter 的方式，与前面 2 种方式配置的角度不同，它提供了一种来定制 Istiod 下发给 Envoy 的配置的机制，类似于插件的能力。使用 EnvoyFilter 可以修改下发配置字段的值、添加特定 cluster、listener。通常不需要重新创建 Pod。

EnvoyFilter 与 Istio 的内部实现和 envoy 的 XDS API 相关，虽然 EnvoyFilterAPI 本身保持向后兼容性，但 EnvoyFilter 配置中的内容在 Sidecar 代理版本升级过程中有不兼容的风险。不正确或者不兼容的 EnvoyFilter 配置内容可能会破坏整个服务网格的稳定性。阿里云服务网格 ASM 将 EnvoyFilter 抽象为插件市场的能力，提供了更好的升级兼容性，优化了作用范围。

管理Sidecar代理配置的难点

随着服务网格中管理的 Pod 规模的增长，现有的 Sidecar 代理配置管理方案，配置范围的粒度过粗或者过细。以下 2 个场景为例。

命名空间范围

对于中小型企业，只有单个 Kubernetes 集群，通过命名空间的划分，将不同的环境或者开发组进行划分。例如，开发环境和测试环境分别对应命名空间 Dev 和 Prod。需要在开发环境的命名空间中使用较小的 Istio-proxy 资源配置，在生产环境的命名空间中，配置更大的 Istio-proxy 资源限制。按照目前的方式，就必须使用 Pod Annotation 的方式为它们逐个添加注解。

当资源配置需要变更或者有新的 Deployment 需要部署时，也容易造成配置遗漏。同一命名空间下的 Sidecar 代理配置存在共性，但是目前缺少为整个命名空间进行 Sidecar 资源配置的手段。

工作负载标签范围

ServiceA/B/C 分别表示视频/文字/图片转换的 AI 服务。对应的 Pod 都标有 performancesensitive 的标签来标识为性能敏感的业务。用户希望配置来使指定 Port 的入流量不经过 Sidecar 代理，提升系统性能。这里使用到的配置参数为 IncludeOutboundPorts 来设置端口使出口流量经过 Sidecar 代理，同时 excludeInboundPorts 来设置端口使入口流量免于经过 Sidecar 代理。由于服务网格中其它业务的 Pod 不需要此配置，所以无法使用全局配置。目前也只能逐个为这一类 workload 添加 Annotation。当 Port 端口变更时，也需要逐一修改。从这两种用户场景中我们总结发现，目前 Sidecar 代理配置不够灵活和覆盖全面，难以管理。

阿里云服务网格ASM架构

Aliware

阿里云服务网格 ASM 提供一个全托管式的服务网格平台，兼容 Istio 开源社区。在产品能力方面，用于简化服务的治理，包括服务调用之间的流量路由与拆分管理、服务间通信的认证安全以及网格可观测性能力，减轻开发与运维的工作负担。同时 ASM 增强了多协议支持以及动态扩展能力，提供精细化服务治理，完善零信任安全体系，大规模集群支持能力，并集成了 Multi-Buffer 等技术来持续提升性能。

阿里云服务网格 ASM 定位于混合云、多云、多集群、非容器应用迁移等核心场景中，构建托管式统一的服务网格能力。使用一致的方式来管理运行于 ACK 托管 Kubernetes 集群、专有 Kubernetes 集群、Serverless Kubernetes 集群、混合云或多云场景下的接入集群上的应用服务，从而提供一致的可观测性和流量控制。托管控制平面的核心组件，最大限度地降低用户资源开销和运维成本，助力客户在生产环境中进行大规模落地。