关于开放式服务网格（Open Service Mesh (OSM)）

服务网格

经过之前几年的发展，对于基于 Kubernetes 的容器化应用来说，微服务架构已经成为了最流行的框架。通过按照松耦合和独立的组件（服务）来构建应用，组织们能够加快开发进程，规模化独立服务，增强可观测性并且按照技术栈来提供灵活性。在这样的一个架构下，服务到服务的通信能够很典型地被合并到这些不同的组件里。然而，当这些通信规则变得越来越复杂时，实现监视，网络和安全功能将会变得笨拙臃肿。

服务网格允许开发者从应用基础架构中抽象出负责服务到服务通信的逻辑到一个单独的层面。相对于在微服务之间直接使用请求路由，一个服务网格在服务之间通过“sidecar”代理路由流量，这些代理就被部署在服务的旁边。使用服务网格会提供诸多好处，包括更加可靠和安全的通信，服务发现，还有负载均衡。更有甚者，通过让所有流量被代理所监视，可以使服务网格显示更多的高级矩阵。另一个关键好处就是组织可以升级他们的注意力到如何增强业务特性而不用再担心网络和服务这些基础能力。

什么是开放式服务网格（Open Service Mesh (OSM)）？

开放式服务网格（OSM）一个简单的，完备的并且独立的服务网格。OSM 提供了开箱即用的方案——包含了全部必要的组件来部署一个完整的服务网格。

OSM 提供一个全功能的 Control Plane。OSM 利用了基于 Envoy 反向代理作为 sidecar 的架构，通过注入一个 Envoy 代理来作为一个 sidecar 容器，跟随在应用实例旁边工作。

OSM 能够通过 SMI APIs 来配置；在这种情况下，OSM 仰仗于 SMI Spec 来引用将参与网格服务的服务。

作为一个轻量级的和 SMI 兼容的服务网格，OSM 被设计成是直观并且可扩展的。该项目遵守如下的核心原则：

  • 易于理解和分发。
  • 易于安装，维护和操作。
  • 无痛排障。
  • 经由服务网格接口（SMI）易于配置。

OSM 项目已经被捐赠到 云原生计算基金会 (CNCF) 并由其监管。该项目持续秉承围绕特性的社区导向协作机制，鼓励并欢迎对该项目的贡献。请参阅我们的 贡献阶梯 指南来获取如何参与的信息。

特性

  • 显而易见，简单易学地配置流量转移来完成部署
  • 通过启用双向 TLS 实现安全的服务到服务通信
  • 为服务们定义并执行精确调整的访问控制策略
  • 针对应用矩阵的可观测性和洞察力，用来调试和监视服务
  • 通过一个可插入的接口来集成外部认证管理服务或解决方案
  • 通过启用自动的 Envoy 代理 sidecar 注入来接驳应用到网格

用例

作为一个基于 Kubernetes 的服务运维，我需要一个开源的解决方案，并且该方案是动态的:

  • 应用策略来监管对等应用之间的流量访问
  • 在应用之间，利用 mTLS 和带定制 CA 的短期证书来加密流量
  • 必要的尽可能经常地轮换证书来使证书短期化，从而移除对证书撤销管理的需要
  • 收集追踪和矩阵来为服务的健康和操作提供可视性
  • 在多种版本的服务之间实现流量拆分，这些服务被按照 SMI Spec 的定义来部署

快速入门

遵循快速入门指南来尝试一下带一个微服务拓扑示例的 OSM 吧。