企业现在热衷于采用微服务架构，因为它具有敏捷性和灵活性。容器和作为首选的容器编排工具—Kubernetes的兴起使得从单体架构向微服务架构的转变变得更加容易。然而，在大规模使用微服务架构时出现了一系列新的挑战：

• DevOps和架构师很难管理服务之间的流量
• 由于微服务部署在多个集群和云中，数据走出了（防火墙）边界，变得容易受到攻击；
• 安全性成为一个重大问题 对网络拓扑的整体可见性对于SRE来说成为一场噩梦
• 实施新的安全工具，或者调整现有的API网关或Ingress控制器，只是一种临时解决方案，无法完全解决上述问题。

架构师需要的是一种彻底的基础设施实现，以应对不断增长的网络、安全和可观察性挑战。而这就是服务网格的概念所涉及的地方。

什么是服务网格？

服务网格（Service Mesh）是一种将服务之间的通信从应用层解耦到基础设施层的技术。在服务网格中，通过代理服务之间的流量来实现基础设施层的抽象。

image.png

代理作为一个Sidecar容器与应用程序一起部署。流入和流出服务的流量被代理拦截，并提供高级流量管理和安全功能。此外，服务网格还提供对整个网络拓扑的可观察性。在服务网格架构中，代理的集合被称为数据平面（data plane），负责配置和管理数据平面代理的控制器被称为控制平面（control plane）。Kubernetes为什么需要服务网格？—在开始阶段，大多数DevOps只需要处理少量的服务。随着应用程序规模的扩大和服务数量的增加，网络和安全管理变得复杂起来。繁琐的安全合规性—从不同云供应商的多个集群中部署的应用程序通过网络相互通信。对于这种流量来说，遵守某些标准以防止入侵者进入并确保安全通信至关重要。问题在于安全策略通常是针对单个集群的，并不能跨集群边界工作。这就需要一种能够在多个集群中强制执行一致安全策略的解决方案。混乱的网络管理—DevOps工程师通常需要控制服务之间的流量，例如进行金丝雀部署。他们还希望通过注入故障和实施断路器来测试系统的弹性和可靠性。要实现对网络的这种细粒度控制，DevOps工程师需要在Kubernetes和云环境中创建大量的配置和脚本。缺乏对网络的可视化—随着应用程序分布在网络上并进行相互通信，SRE（Site Reliability Engineer）很难跟踪网络基础设施的健康状况和性能。这严重影响了他们识别和解决网络问题的能力。通过实施服务网格，可以解决上述问题，提供一些功能，使得管理部署到Kubernetes的应用程序变得轻松无痛。

Service Mesh在Kubernetes中的关键特性

Service Mesh充当了一个集中化的平台，用于在Kubernetes中部署的微服务的网络、安全和可观察性。集中化的安全性 通过使用服务网格，可以更容易地实现安全合规性，因为可以从一个中心平面进行配置，而不是针对每个服务进行配置。服务网格平台可以强制执行跨集群边界工作的一致性安全策略。 服务网格提供了细粒度的身份验证、授权和访问控制。

• 身份验证：mTLS实现、JWT
• 授权：可以设置策略来允许、拒绝或对传入请求执行自定义操作
• 访问控制：可以在方法、服务和命名空间级别设置RBAC策略
• 高级网络和弹性测试
• 服务网格提供了对服务之间流量流向的细粒度控制。

DevOps工程师可以将流量分割到不同的服务之间，或者根据一定的权重进行路由。此外，服务网格还提供以下功能，以便通过少量工作来测试基础设施的弹性：

• 故障注入
• 超时设置
• 重试
• 断路器
• 镜像
• 统一的可观察性

实施服务网格有助于SRE和运维团队集中监控应用程序在网格中的健康状况和性能。服务网格提供以下用于可观察性和实时可见性的遥测数据：

• 指标：用于监控性能，查看延迟、流量、错误和饱和度等。
• 分布式跟踪：用于理解请求的生命周期，分析服务依赖关系和流量流向。
• 访问日志：用于审计服务行为。

为Kubernetes考虑的顶级服务网格软件

在市场上可以找到各种服务网格软件，如Istio、Linkerd、HashiCorp Consul、Kong KUMA、Google Anthos（基于Istio构建）、VMware Tanzu等。然而，超过90%的用户使用Istio或Linkerd服务网格软件，这是因为它们拥有强大而活跃的开源生态系统，提供创新和支持。

Istio

Istio是最受欢迎的、经过CNCF认证的开源服务网格软件。它使用Envoy代理作为sidecar，而控制平面用于管理和配置这些代理。

image.png

Istio为大规模应用程序提供了网络、安全和可观察性功能。来自Google、Microsoft、IBM等公司的开发人员积极参与了Istio项目的贡献。

Linkerd

Linkerd是由Buoyant开发的轻量级开源服务网格软件。它提供了服务网格的基本功能，并具有目标服务、身份服务和代理注入器。

image.png

超过80%的Linkerd贡献来自其创始人Buoyant自身。

服务网格在Kubernetes中的好处

以下是企业在Kubernetes中实施服务网格可以获得的一些好处：

• 100%网络和数据安全

服务网格有助于维护一个零信任网络，在处理请求之前不断进行身份验证和授权。DevOps工程师可以实施诸如mTLS之类的功能，它可以在整个集群范围内和跨集群边界工作。

image.png

在当前充满中间人攻击（MITM）和拒绝服务（DoS）等攻击的动态威胁环境中，零信任网络有助于维护安全的基础设施。

• 变更失败率降低80%

如今，企业在完全推出之前会将应用程序发布给一小部分实际用户。这有助于DevOps和SRE分析应用程序性能，识别任何错误，并避免潜在的停机时间。金丝雀部署和蓝/绿部署是两种常见的部署策略。服务网格提供的细粒度流量控制，包括基于权重进行流量分割，使得DevOps工程师更容易执行这些部署策略。

image.png

• 99.99%可用和弹性的基础设施

服务网格软件提供的遥测数据帮助SRE和运维团队快速识别和应对错误和威胁。大多数服务网格软件与Prometheus、Grafana、Kiali、Jaeger等监控工具集成，它们提供的仪表板帮助运营人员可视化服务的健康状况、性能和行为。

image.png

• 开发者体验提升5倍

大多数应用程序开发者不喜欢在他们的应用程序中配置网络和安全逻辑。他们的关注点往往是业务逻辑和功能的构建。实施服务网格可以减少开发者的工作量，因为他们只需关注应用程序代码。他们可以将网络和安全配置完全交给基础设施级别的服务网格来处理。这种分离有助于开发者专注于他们的核心职责，即提供业务逻辑。

成功实施服务网格的三个支柱

由于服务网格是一个激进的概念，对企业来说，成功实施并实现其价值可能会让人感到不知所措。如果你是架构师或首席信息官（CIO），可以考虑以下三个支柱来成功实施服务网格。

image.png

技术支持

从技术支持的角度评估服务网格软件非常重要。如果是一个成熟的DevOps组织，在CI/CD过程中使用各种开源和开放标准，请确保服务网格软件能够与CI/CD工具（无论版本如何）良好集成。例如，如果正在使用Argo CD进行GitOps部署，或者使用Prometheus进行监控，那么服务网格软件必须能够在较少的干预下与这些工具集成。

企业支持

开源软件的采用率正在上升。但是，对软件的支持对于企业来说是确保其IT系统可用于业务的首要需求。评估一个由庞大社区支持的服务网格软件（对于支持非常有帮助），并且还有第三方供应商生态系统可以提供24*7的支持，并具有固定的服务级别协议（SLA）。

培训和入职支持

确保有足够的阅读材料、文档和视频可供使用，这将有助于服务网格软件的用户学习，因为如果内部员工（如DevOps和SRE）无法采用该软件，那就没有意义了。最后，服务网格不仅仅是软件，而是一种应用操作模式。不要急于开始项目。相反，研究和评估最适合组织需求和需求的最佳服务网格。

服务网格是Kubernetes工作负载的未来发展方向

服务网格实施的目标是使在Kubernetes中部署的应用程序更易管理。随着服务从单个集群溢出到多个集群，采用服务网格将成为必要。随着Kubernetes的普及，服务网格最终将成为大多数组织中的关键组件。

作者：Anas T

更多技术干货尽在wx“云原生数据库”