组织数字化转型期间向 Kubernetes 和 Linux 基础设施的过渡导致应用程序越来越多地开始基于微服务架构构建,因此经常需要复杂的方案来在服务之间路由请求。
借助红帽 OpenShift Service Mesh,我们超越了传统路由,并提供组件来跟踪和可视化这些请求,从而使服务交互更简单、更可靠。 引入特殊的逻辑控制级别,即所谓的服务网格
Red Hat OpenShift Service Mesh 作为特殊的 Kubernetes Operator 提供,其功能可以在 Red Hat OpenShift 4 中进行测试
改进应用程序和服务级别的通信跟踪、路由和优化
仅使用硬件负载平衡器、专用网络设备和其他已成为现代 IT 环境中常态的类似解决方案,在出现的服务到服务级别上一致且统一地调节和管理通信是非常困难的,有时甚至是不可能的应用程序及其服务之间。 通过添加额外的服务网格管理层,容器化应用程序可以更好地监控、路由和优化与平台核心 Kubernetes 的通信。 服务网格有助于简化跨多个位置的混合工作负载的管理,并提供对数据位置的更精细的控制。 随着 OpenShift Service Mesh 的发布,我们希望微服务技术堆栈的这一重要组件能够帮助组织实施多云和混合策略。
OpenShift Service Mesh 构建在 Istio、Kiali 和 Jaeger 等多个开源项目之上,提供了在微服务应用程序架构中对通信逻辑进行编程的能力。 因此,开发团队可以完全专注于开发解决业务问题的应用程序和服务。
让开发者的生活更轻松
可视化所有服务之间的连接并查看交互拓扑的能力也有助于更好地理解服务间关系的复杂情况。 通过将这些强大的功能整合到 OpenShift Service Mesh 中,红帽为开发人员提供了成功开发和部署云原生微服务所需的一组扩展工具。
为了简化服务网格的创建,我们的解决方案允许您使用适当的 Kubernetes 运算符在现有 OpenShift 实例中轻松实现此级别的管理。 该操作员负责所有必需组件的安装、网络集成和操作管理,使您可以立即开始使用新创建的服务网格来部署实际应用程序。
降低实施和管理服务网格的劳动力成本使您能够快速创建和测试应用程序概念,并且不会在开发过程中失去对情况的控制。 为什么要等到管理服务间通信成为一个真正的问题呢? OpenShift Service Mesh 可以在您实际需要之前轻松提供您所需的可扩展性。
OpenShift Service Mesh 为 OpenShift 用户提供的优势包括:
- 跟踪和监控(Jaeger)。 激活服务网格以提高可管理性可能会伴随一定的性能下降,因此 OpenShift Service Mesh 可以测量性能的基线水平,然后使用该数据进行后续优化。
- 可视化(Kiali)。 服务网格的可视化表示有助于理解服务网格的拓扑以及服务如何交互的整体情况。
- Kubernetes 服务网格运营商。 通过自动执行安装、维护和服务生命周期管理等常见任务,最大限度地减少管理应用程序时的管理需求。 通过添加业务逻辑,您可以进一步简化管理并加快生产中新功能的引入。 OpenShift Service Mesh 运营商部署 Istio、Kiali 和 Jaeger 包,并提供一次性实现所有所需功能的配置逻辑。
- 支持多个网络接口 (multus)。 OpenShift Service Mesh 消除了手动步骤,使开发人员能够使用 SCC(安全上下文约束)在增强安全模式下运行代码。 特别是,它提供了集群中工作负载的额外隔离,例如,命名空间可以指定哪些工作负载可以作为 root 运行,哪些不能。 因此,可以将备受开发人员追捧的 Istio 优势与集群管理员所需的精心编写的安全措施结合起来。
- 与红帽 3scale API 管理集成。 对于需要提高服务 API 访问安全性的开发人员或 IT 运营商,OpenShift Service Mesh 提供了原生 Red Hat 3scale Istio Mixer Adapter 组件,与服务网格不同,它允许您在 API 级别控制服务间通信。
对于Service Mesh技术的进一步发展,今年年初红帽宣布参与该行业项目
尝试 OpenShift
服务网格技术有助于极大地简化混合云中微服务堆栈的使用。 因此,我们鼓励每一个积极使用 Kubernetes 和容器的人
来源: habr.com