NGINX.COM
Web Server Load Balancing with NGINX Plus

编者按 —— “我是否需要 service mesh?”一文已重定向至此处。

本文是以下系列博文中的一篇(共十篇):

  1. 生产级 Kubernetes 助您降低复杂性
  2. 如何通过高级流量管理提高 Kubernetes 的弹性
  3. 如何提高 Kubernetes 环境的可视性
  4. 使用流量管理工具保护 Kubernetes 的六种方法
  5. Ingress Controller 选型指南,第一部分:确定需求
  6. Ingress Controller 选型指南,第二部分:评估风险和技术前瞻性
  7. Ingress Controller 选型指南,第三部分:开源、默认和商用版本能力对比
  8. Ingress Controller 选型指南,第四部分:NGINX Ingress Controller 选项
  9. 如何选择 Service Mesh ?(本文)
  10. NGINX Ingress Controller 在动态 Kubernetes 云环境中的性能测试

您还可以免费下载整套博文集结成的电子书:《Kubernetes:从测试到生产》

近年来,随着企业不断加大对微服务和容器化应用的投资,service mesh 已从前沿技术稳步转向主流应用。根据 2020 年云原生计算基金会在 2020 年开展的一项关于云原生技术使用情况的调查,我们得出了以下结论。

要点 1:使用 service mesh 的人数迅速增长。

要点 2:使用容器技术的人数增加表明,越来越多的企业需要高级流量管理和安全防护工具,并将从服务网格中受益。

要点 3:三大容器挑战相互关联。

您做好使用 service mesh 的准备了吗?

NGINX 团队认为,这已经不是“我是否必须使用 service mesh?”的二元问题,而是“我何时才能做好使用 service mesh 的准备?”这样的问题。我们认为,对于在生产环境中部署容器并使用 Kubernetes 进行编排的任何人而言,其应用和基础架构设施的成熟度水平都有可能达到足以让 service mesh 的价值体现出来的水平。

但与任何技术一样,在实际需要 service mesh 之前就提前部署的做法弊大于利,它带来的风险和开销要超出可为您的企业所带来的潜在好处。对于想要采用 service mesh 的客户,我们根据以下六点来确定其准备情况并了解其现代化进程。您对以下陈述的肯定回答越多,service mesh 为您创造的价值就越大。

1:Kubernetes 是您生产环境中的唯一平台。
无论您是已将生产应用迁移到 Kubernetes,还是刚开始测试将应用迁移到容器工作负载,Kubernetes 确实已经在您的长期应用管理路线图中。

2:您需要一个零信任的生产环境,并需要在 service 之间配置双向 TLS (mTLS)。
您已为生产应用采用零信任模型,并需要在容器化环境中保持这种级别的安全性,或者您正在使用迁移作为强制功能来增强您的服务级别安全性。

3:无论从 service 的数量还是深度的角度来看,您的应用都很复杂。
您拥有一个大型的分布式应用。它有多个 API 依赖项,并很可能需要外部依赖项。

4:您拥有一个成熟的生产 CI/CD 流水线。
此处“成熟”的定义取决于您的企业。我们将该术语用在以编程方式部署 Kubernetes 基础架构和应用的过程,可能使用的工具包括 Git、Jenkins、Artifactory 或 Selenium。

5:您经常在生产环境中进行部署 —— 至少每天一次。
我们发现,对于这个问题,大多数人的回答都是“否” —— 尽管他们已将应用迁移到了生产 Kubernetes 中,但他们还没有使用 Kubernetes 来支持持续的版本修订。

6:您的 DevOps 团队已准备好开始使用强大的工具部署超现代应用!

即使 service mesh 为 NetOps 团队拥有,但通常由 DevOps 团队在集群内进行管理,后者需要准备好将网格添加到其堆栈中。

对上述 6 个陈述的回答不都是“是”?没有关系!请继续阅读,了解您在做好准备之后,接下来该做的工作,包括您可以做些什么来让您的团队做好使用 service mesh 的准备。

如何选择适合您的应用的 service mesh

在您准备好使用 service mesh 之后,您还需要从众多 service mesh 选项中做出选择。就像 Kubernetes 已成为事实上的容器编排标准一样,Istio 通常被视为事实上的 service mesh 标准。事实上,Istio 很容易被认为是唯一的选择,不仅因为它很流行,还因为它的目标是解决 Kubernetes 网络环境中的所有问题。

尽管有宣传自家产品的嫌疑,但我们还是要在这里告诉您,Istio 既不是唯一的选择,也不是适用于每个人或每个用例的选择。Istio 让您的环境变得非常复杂,可能需要集整个工程师团队的力量来运行,而最终带来的问题通常比解决的问题还要多。

为了明确说明哪种 service mesh 最适合您的应用,我们建议您与您的团队和利益相关者举行一次战略规划会议。下面是一个对话指南,可帮助您推动这些讨论。

第 1 步:您为何想要使用 service mesh?
换句话说,您需要 service mesh 解决什么问题?举例来说,您的企业可能要求在 service 之间配置 mTLS,或者您需要“端到端”加密,包括从边缘进入(针对入向流量)和从网格内流出(针对出向流量)的流量。或者,您可能需要为您的全新 Kubernetes service 配备企业级流量管理工具。

第 2 步:如何使用 service mesh?
这取决于您的角色。

  • 如果您是开发人员:

    • 您是否计划提高正在迁移到 Kubernetes 的传统应用的安全性?
    • 在将应用重构为原生 Kubernetes 应用时,您是否打算将安全性纳入其中??
  • 如果您负责平台和基础架构:

    • 您是否打算将 service mesh 添加到 CI/CD 流水线中,以便在每个新集群中自动部署和配置,并确保其在开发人员启动新实例时可用?

第 3 步:影响您选择的因素有哪些?
您的 service mesh 是否需要不受基础架构的限制?是否需要与您的可视化工具兼容?是否需要 Kubernetes 原生?是否需要易于使用?您是否预见到未来要使用与网格中的 service 到 service (东西向)流量管理工具相同的工具在边缘管理出入向(南北向)流量?

回答完这些问题之后,您将会获得明确的需求(以作为您的评估选项)清单。

NGINX 如何助您一臂之力

我们很高兴宣布,NGINX Service Mesh(2020 年作为开发版本推出)现已正式投入生产。NGINX Service Mesh 是针对开发人员优化的免费的轻量级服务网格,它提供了最简单的方法来实现 mTLS,以及 Kubernetes 中东西向(service 到 service)流量和南北向(ingress和 egress)流量的端到端加密。为了以一种侵入性最小但仍提供高级灵活性和关键洞察力的方式让您完全控制应用数据平面,我们构建了自己的 service mesh。

我们相信,如果您对以下网格特性有需求,那一定会对 NGINX Service Mesh 一见钟情:

  • 易于使用。您将管理 service mesh,但不想仅仅为了向已经非常复杂的 Kubernetes 环境添加 mTLS 和高级流量管理工具而再使用一套复杂的工具。
  • 轻量级。您需要一个不会耗尽资源或影响性能的组件。.
  • 不受基础架构的限制。您计划在所有 Kubernetes 环境中使用相同的 service mesh。
  • 与您的生态系统兼容。您需要一个 Kubernetes 原生的 service mesh,它与 Ingress controller 和可视化工具集成,且不会增加延迟。

NGINX Service Mesh 架构简介

NGINX Service Mesh 有两个主要的组件。

控制平面

我们构建了一个轻量级的控制平面,可与 Kubernetes API 服务器搭配使用,为应用提供动态支持和管理。它不仅会随着应用的扩展和部署而做出响应和更新,以便让每个工作负载实例自动得到保护,还能与其他应用组件集成 —— 通过实现“一次设置,自动运行”让您专注于处理有价值的业务问题。

数据平面

NGINX Service Mesh 的真正厉害之处是全面集成的高性能数据平面。我们的数据平面利用 NGINX Plus 的强大功能来运行高可用和可扩展的容器化环境,将企业流量管理、性能和可扩展性提升到了市场最高水平。它提供了生产级 service mesh 部署所需的无缝且透明的负载均衡、反向代理、流量路由、身份和加密功能。当与基于 NGINX Plus 版本的 NGINX Ingress Controller 搭配使用时,它还可提供可通过单个配置管理的统一的数据平面。

NGINX Service Mesh 的优势

您可从 NGINX Service Mesh 获得的几项优势:

较低的复杂性

NGINX Service Mesh 易于使用且不受基础架构的限制。它实现了 Service Mesh Interface (SMI) 规范,该规范定义了 Kubernetes service mesh 的标准接口,并提供了 SMI 扩展,在部署新应用时,可极大地减少人工操作和生产流量中断。NGINX Service Mesh 还与 NGINX Ingress Controller 进行了原生集成,创建了一个统一的数据平面,支持您在边缘位置集中和简化出入向(南北向)流量管理以及 service 到 service (东西向)反向代理 sidecar 流量管理的配置。与其他网格不同,NGINX Service Mesh 不需要将 sidecar 注入 NGINX Ingress Controller,因此不会增加 Kubernetes 环境的延迟和复杂性。

更高的弹性

借助我们的智能容器流量管理功能,您可以指定策略来限制流向新部署的 service 实例的流量,并随着时间的推移逐渐放宽限制。借助速率限制和断路器等功能,您可以完全控制通过 service 的流量。您可以利用各种强大的流量分配模型,包括速率整形、服务质量 (QoS)、服务节流、蓝绿部署、灰度发布、断路器模式、A/B 测试和 API 网关功能。

如欲了解更多信息,请阅读我们的博文“如何通过高级流量管理提高 Kubernetes 的弹性”并观看 NGINX 工程师 Kate Osborn 关于如何使用 NGINX Service Mesh 进行流量分割的演示视频。

细粒度的流量洞察

NGINX Service Mesh 可使用 OpenTracing 和 Prometheus 进行指标收集和分析。NGINX Plus API 通过 NGINX Service Mesh sidecar 和 NGINX Ingress Controller pod 生成指标。使用内置的 Grafana 仪表盘查看指标(指标信息可精确到毫秒、每天的覆盖和流量峰值)。

如欲了解更多信息,请阅读我们的博文 “如何提高 Kubernetes 环境的可视性”,并观看如何在 NGINX 中使用 Prometheus 和 Grafana 的直播。

保护容器化应用

将 mTLS 加密和七层防护扩展到各个微服务,并利用访问控制来定义描述应用拓扑的策略 —— 让您能够细粒度控制哪些 service 被授权进行相互通信。NGINX Service Mesh 支持高级安全功能(包括配置控制和治理),以及对出入向和 service 到 service 流量的放行列表支持。借助基于 NGINX Plus 版本的 NGINX Ingress Controller,您还可以默认拦截访问内部 service 的南北向流量,并将 NGINX App Protect

观看 NGINX 工程师 Aidan Carson 关于使用访问控制来管理端到端加密的零信任环境的演示。

没有准备好使用 service mesh?

如果您还没有准备好使用网格,那么您可能对 Kubernetes 不熟悉,或者正在努力克服大型生产部署所面对的障碍。现在正逢其时,您可以采用两个数据平面组件(Ingress controller 和内置安全防护)来解决复杂性、安全性、可视化和可扩展性等常见的 Kubernetes 挑战。如欲了解更多信息,请阅读我们的博文“生产级 Kubernetes 助您降低复杂性”.

立即行动

欢迎参加我们即将举办的网络研讨会:您是否为 service mesh 做好了准备?从心动转向行动,深入了解如何选择 service mesh!

NGINX Service Mesh 完全免费,您可立即下载并在 10 分钟内完成部署!您可查看我们的文档,并观看产品经理 Alan Murphy 所做的简短演示。我们希望了解您的使用体验,欢迎您在 GitHub发表您的反馈意见。

如果事实证明 Istio 最能满足您的需求,请查看 F5 的 Aspen Mesh。它是一个建立在开源 Istio 之上的企业级 service mesh,拥有实时流量 GUI,是寻求交付 5G 服务的提供商的完美之选。

Hero image
Kubernetes:
从测试到生产

通过多种流量管理工具提升弹性、可视性和安全性

关于作者

Jenn Gile

Manager, Product Marketing for NGINX

关于 F5 NGINX

F5, Inc. 是备受欢迎的开源软件 NGINX 背后的商业公司。我们为现代应用的开发和交付提供一整套技术。我们的联合解决方案弥合了 NetOps 和 DevOps 之间的横沟,提供从代码到用户的多云应用服务。访问 nginx-cn.net 了解更多相关信息。